Concepts & Examples

ScreenOS Reference Guide

Volume 1:
Overview

Release 6.1.0, Rev. 03

Juniper Networks, Inc.

1194 North Mathilda Avenue
Sunnyvale, CA 94089
USA
408-745-2000
www.juniper.net
 Copyright Notice
Copyright © 2009 Juniper Networks, Inc. All rights reserved.

Juniper Networks, the Juniper Networks logo, JUNOS, NetScreen, ScreenOS, and Steel-Belted Radius are registered trademarks of Juniper Networks, Inc.
in the United States and other countries. JUNOSe is a trademark of Juniper Networks, Inc. All other trademarks, service marks, registered trademarks, or
registered service marks are the property of their respective owners.

All specifications are subject to change without notice. Juniper Networks assumes no responsibility for any inaccuracies in this document or for any
obligation to update information in this document. Juniper Networks reserves the right to change, modify, transfer, or otherwise revise this publication
without notice.

FCC Statement
The following information is for FCC compliance of Class A devices: This equipment has been tested and found to comply with the limits for a Class A
digital device, pursuant to part 15 of the FCC rules. These limits are designed to provide reasonable protection against harmful interference when the
equipment is operated in a commercial environment. The equipment generates, uses, and can radiate radio-frequency energy and, if not installed and
used in accordance with the instruction manual, may cause harmful interference to radio communications. Operation of this equipment in a residential
area is likely to cause harmful interference, in which case users will be required to correct the interference at their own expense.

The following information is for FCC compliance of Class B devices: The equipment described in this manual generates and may radiate radio-frequency
energy. If it is not installed in accordance with Juniper Networks’ installation instructions, it may cause interference with radio and television reception.
This equipment has been tested and found to comply with the limits for a Class B digital device in accordance with the specifications in part 15 of the FCC
rules. These specifications are designed to provide reasonable protection against such interference in a residential installation. However, there is no
guarantee that interference will not occur in a particular installation.

If this equipment does cause harmful interference to radio or television reception, which can be determined by turning the equipment off and on, the user
is encouraged to try to correct the interference by one or more of the following measures:

 Reorient or relocate the receiving antenna.

 Increase the separation between the equipment and receiver.

 Consult the dealer or an experienced radio/TV technician for help.

 Connect the equipment to an outlet on a circuit different from that to which the receiver is connected.

Caution: Changes or modifications to this product could void the user's warranty and authority to operate this device.

Disclaimer
THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED
WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED
WARRANTY, CONTACT YOUR JUNIPER NETWORKS REPRESENTATIVE FOR A COPY.

ii 
Table of Contents
Volume 1:
Overview
About the Concepts & Examples ScreenOS Reference Guide xlvii
Volume Organization ................................................................................... xlix
Document Conventions................................................................................... lv
Web User Interface Conventions ............................................................. lv
Command Line Interface Conventions .................................................... lvi
Naming Conventions and Character Types ............................................. lvi
Illustration Conventions ......................................................................... lvii
Requesting Technical Support ...................................................................... lviii
Self-Help Online Tools and Resources.................................................... lviii
Opening a Case with JTAC ....................................................................... lix
Document Feedback ...................................................................................... lix

Master Index...........................................................................................................IX-I

Volume 2:
Fundamentals
About This Volume ix
Document Conventions.................................................................................... x
Web User Interface Conventions .............................................................. x
Command Line Interface Conventions ...................................................... x
Naming Conventions and Character Types .............................................. xi
Illustration Conventions .......................................................................... xii
Requesting Technical Support ........................................................................ xii
Self-Help Online Tools and Resources..................................................... xiii
Opening a Case with JTAC ...................................................................... xiii
Document Feedback ..................................................................................... xiii

Chapter 1 ScreenOS Architecture 1

Security Zones ................................................................................................. 2
Security Zone Interfaces................................................................................... 3
Physical Interfaces..................................................................................... 3
Subinterfaces............................................................................................. 3
Virtual Routers ................................................................................................. 4
Policies.............................................................................................................5
Virtual Private Networks .................................................................................. 6
Virtual Systems ................................................................................................9
Packet-Flow Sequence.................................................................................... 10
Jumbo Frames................................................................................................ 13

Table of Contents  iii

 Concepts & Examples ScreenOS Reference Guide

ScreenOS Architecture Example..................................................................... 14

Example: (Part 1) Enterprise with Six Zones............................................ 14
Example: (Part 2) Interfaces for Six Zones ............................................... 16
Example: (Part 3) Two Routing Domains ................................................. 18
Example: (Part 4) Policies ........................................................................ 20

Chapter 2 Zones 25
Viewing Preconfigured Zones......................................................................... 26
Security Zones ............................................................................................... 28
Global Zone ............................................................................................. 28
SCREEN Options...................................................................................... 28
Binding a Tunnel Interface to a Tunnel Zone.................................................. 29
Configuring Security Zones and Tunnel Zones ............................................... 30
Creating a Zone ....................................................................................... 30
Modifying a Zone..................................................................................... 31
Deleting a Zone ....................................................................................... 32
Function Zones ..............................................................................................33

Chapter 3 Interfaces 35
Interface Types ..............................................................................................36
Logical Interfaces..................................................................................... 36
Physical Interfaces ............................................................................ 36
Wireless Interfaces............................................................................ 36
Bridge Group Interfaces..................................................................... 37
Subinterfaces .................................................................................... 37
Aggregate Interfaces ......................................................................... 37
Redundant Interfaces ........................................................................ 37
Virtual Security Interfaces .................................................................38
Function Zone Interfaces ......................................................................... 38
Management Interfaces..................................................................... 38
High Availability Interfaces................................................................ 38
Tunnel Interfaces..................................................................................... 39
Deleting Tunnel Interfaces ................................................................ 42
Viewing Interfaces ......................................................................................... 43
Configuring Security Zone Interfaces ............................................................. 44
Binding an Interface to a Security Zone ................................................... 44
Unbinding an Interface from a Security Zone .......................................... 46
Addressing an L3 Security Zone Interface................................................ 47
Public IP Addresses ........................................................................... 47
Private IP Addresses.......................................................................... 48
Addressing an Interface .................................................................... 48
Modifying Interface Settings .................................................................... 49
Creating a Subinterface in the Root System ............................................. 50
Deleting a Subinterface............................................................................ 50
Creating a Secondary IP Address ................................................................... 51
Backup System Interfaces .............................................................................. 52
Configuring a Backup Interface................................................................ 52
Configuring an IP Tracking Backup Interface..................................... 52
Configuring a Tunnel-if Backup Interface .......................................... 53
Configuring a Route Monitoring Backup Interface ............................. 57
Loopback Interfaces ....................................................................................... 58
Creating a Loopback Interface .................................................................59
Setting the Loopback Interface for Management...................................... 59

iv  Table of Contents
 Table of Contents

Setting BGP on a Loopback Interface ....................................................... 59

Setting VSIs on a Loopback Interface....................................................... 60
Setting the Loopback Interface as a Source Interface ............................... 60
Interface State Changes.................................................................................. 61
Physical Connection Monitoring .............................................................. 63
Tracking IP Addresses ............................................................................. 63
Interface Monitoring ................................................................................ 68
Monitoring Two Interfaces ................................................................ 69
Monitoring an Interface Loop ............................................................ 70
Security Zone Monitoring ........................................................................ 73
Down Interfaces and Traffic Flow ............................................................ 74
Failure on the Egress Interface .......................................................... 75
Failure on the Ingress Interface ......................................................... 76

Chapter 4 Interface Modes 79

Transparent Mode.......................................................................................... 80
Zone Settings........................................................................................... 81
VLAN Zone........................................................................................ 81
Predefined Layer 2 Zones .................................................................81
Traffic Forwarding ................................................................................... 81
Unknown Unicast Options ....................................................................... 82
Flood Method.................................................................................... 83
ARP/Trace-Route Method .................................................................. 84
Configuring VLAN1 Interface for Management .................................. 87
Configuring Transparent Mode.......................................................... 89
NAT Mode...................................................................................................... 92
Inbound and Outbound NAT Traffic ........................................................ 94
Interface Settings..................................................................................... 95
Configuring NAT Mode ............................................................................ 95
Route Mode.................................................................................................... 98
Interface Settings..................................................................................... 99
Configuring Route Mode .......................................................................... 99

Chapter 5 Building Blocks for Policies 103

Addresses ....................................................................................................103
Address Entries .....................................................................................104
Adding an Address ..........................................................................104
Modifying an Address .....................................................................105
Deleting an Address ........................................................................105
Address Groups .....................................................................................105
Creating an Address Group .............................................................107
Editing an Address Group Entry ......................................................108
Removing a Member and a Group...................................................108
Services........................................................................................................108
Predefined Services ...............................................................................108
Internet Control Messaging Protocol ...............................................110
Handling ICMP Unreachable Errors .................................................112
Internet-Related Predefined Services...............................................113
Microsoft Remote Procedure Call Services ......................................114
Dynamic Routing Protocols.............................................................116
Streaming Video..............................................................................116
Sun Remote Procedure Call Services ...............................................117
Security and Tunnel Services ..........................................................117

Table of Contents  v
 Concepts & Examples ScreenOS Reference Guide

IP-Related Services..........................................................................118
Instant Messaging Services..............................................................118
Management Services .....................................................................118
Mail Services ...................................................................................119
UNIX Services .................................................................................119
Miscellaneous Services ....................................................................120
Custom Services ....................................................................................120
Adding a Custom Service ................................................................121
Modifying a Custom Service............................................................122
Removing a Custom Service............................................................122
Setting a Service Timeout ......................................................................122
Service Timeout Configuration and Lookup.....................................122
Contingencies .................................................................................123
Example..........................................................................................124
Defining a Custom Internet Control Message Protocol Service...............125
Remote Shell Application Layer Gateway...............................................126
Sun Remote Procedure Call Application Layer Gateway.........................126
Typical RPC Call Scenario................................................................126
Customizing Sun RPC Services ........................................................127
Customizing Microsoft Remote Procedure Call Application Layer Gateway..
127
Real-Time Streaming Protocol Application Layer Gateway.....................129
Dual-Stack Environment .................................................................130
RTSP Request Methods ...................................................................130
RTSP Status Codes ..........................................................................132
Configuring a Media Server in a Private Domain .............................133
Configuring a Media Server in a Public Domain ..............................135
Stream Control Transmission Protocol Application Layer Gateway ........137
Point-to-Point Tunneling Protocol Application Layer Gateway ...............137
Configuring the PPTP ALG...............................................................139
Service Groups.......................................................................................139
Modifying a Service Group ..............................................................140
Removing a Service Group ..............................................................141
Dynamic IP Pools.........................................................................................141
Port Address Translation .......................................................................142
Creating a DIP Pool with PAT ................................................................143
Modifying a DIP Pool .............................................................................144
Sticky DIP Addresses .............................................................................144
Using DIP in a Different Subnet .............................................................145
Using a DIP on a Loopback Interface .....................................................150
Creating a DIP Group.............................................................................154
Setting a Recurring Schedule........................................................................157

Chapter 6 Policies 159

Basic Elements.............................................................................................160
Three Types of Policies ................................................................................161
Interzone Policies ..................................................................................161
Intrazone Policies ..................................................................................161
Global Policies .......................................................................................162
Policy Set Lists .............................................................................................163
Policies Defined ...........................................................................................164
Policies and Rules..................................................................................164
Anatomy of a Policy ..............................................................................165
ID....................................................................................................166

vi  Table of Contents
 Table of Contents

Zones ..............................................................................................166
Addresses .......................................................................................166
Wildcard Addresses.........................................................................166
Services...........................................................................................167
Action .............................................................................................167
Application......................................................................................168
Name ..............................................................................................168
VPN Tunneling ................................................................................168
L2TP Tunneling ...............................................................................169
Deep Inspection ..............................................................................169
Placement at the Top of the Policy List ...........................................169
Session Limiting..............................................................................169
Source Address Translation.............................................................170
Destination Address Translation......................................................170
No Hardware Session ......................................................................170
User Authentication ........................................................................170
HA Session Backup .........................................................................172
Web Filtering ..................................................................................172
Logging ...........................................................................................172
Counting .........................................................................................173
Traffic Alarm Threshold ..................................................................173
Schedules........................................................................................173
Antivirus Scanning ..........................................................................173
Traffic Shaping................................................................................173
Policies Applied............................................................................................175
Viewing Policies.....................................................................................175
Creating Policies ....................................................................................175
Creating Interzone Policies Mail Service ..........................................175
Creating an Interzone Policy Set .....................................................179
Creating Intrazone Policies..............................................................183
Creating a Global Policy ..................................................................185
Entering a Policy Context ......................................................................186
Multiple Items per Policy Component....................................................186
Setting Address Negation.......................................................................187
Modifying and Disabling Policies ...........................................................190
Policy Verification..................................................................................190
Reordering Policies................................................................................191
Removing a Policy .................................................................................192

Chapter 7 Traffic Shaping 193

Managing Bandwidth at the Policy Level ......................................................193
Setting Traffic Shaping .................................................................................194
Setting Service Priorities ..............................................................................197
Setting Priority Queuing ...............................................................................199
Ingress Policing ............................................................................................203
Shaping Traffic on Virtual Interfaces ............................................................203
Interface-Level Traffic Shaping ..............................................................204
Policy-Level Traffic Shaping ...................................................................205
Packet Flow ...........................................................................................206
Example: Route-Based VPN with Ingress Policing ..................................206
Example: Policy-Based VPN with Ingress Policing..................................210
Traffic Shaping Using a Loopback Interface .................................................214
DSCP Marking and Shaping..........................................................................214
Enabling Differentiated Services Code Point ...................................215

Table of Contents  vii

 Concepts & Examples ScreenOS Reference Guide

Chapter 8 System Parameters 217

Domain Name System Support ....................................................................217
DNS Lookup ..........................................................................................218
DNS Status Table ...................................................................................219
Setting the DNS Server and Refresh Schedule .................................219
Setting a DNS Refresh Interval ........................................................220
Dynamic Domain Name System............................................................220
Setting Up DDNS for a Dynamic DNS Server...................................221
Setting Up DDNS for a DDO Server .................................................222
Proxy DNS Address Splitting..................................................................223
Dynamic Host Configuration Protocol ..........................................................225
Configuring a DHCP Server....................................................................227
Customizing DHCP Server Options .................................................230
Placing the DHCP Server in an NSRP Cluster...................................232
DHCP Server Detection ...................................................................232
Enabling DHCP Server Detection ....................................................232
Disabling DHCP Server Detection....................................................232
Assigning a Security Device as a DHCP Relay Agent ..............................233
Forwarding All DHCP Packets .........................................................237
Configuring Next-Server-IP..............................................................237
Using a Security Device as a DHCP Client..............................................238
Propagating TCP/IP Settings ..................................................................240
Configuring DHCP in Virtual Systems ....................................................242
Setting DHCP Message Relay in Virtual Systems ..........................................242
Point-to-Point Protocol over Ethernet ...........................................................243
Setting Up PPPoE ..................................................................................243
Configuring PPPoE on Primary and Backup Untrust Interfaces..............246
Configuring Multiple PPPoE Sessions over a Single Interface .................247
PPPoE and High Availability ..................................................................249
License Keys ................................................................................................250
Registration and Activation of Subscription Services ....................................251
Trial Service...........................................................................................251
Updating Subscription Keys...................................................................252
Adding Antivirus, Web Filtering, Anti-Spam, and Deep Inspection to an
Existing or a New Device ................................................................252
System Clock ...............................................................................................253
Date and Time.......................................................................................253
Daylight Saving Time.............................................................................253
Time Zone .............................................................................................253
Network Time Protocol..........................................................................254
Configuring Multiple NTP Servers....................................................254
Configuring a Backup NTP Server....................................................254
Device as an NTP Server .................................................................255
Maximum Time Adjustment............................................................255
NTP and NSRP ................................................................................256
Setting a Maximum Time Adjustment Value to an NTP Server ........256
Securing NTP Servers ......................................................................257

viii  Table of Contents

 Table of Contents

Index..........................................................................................................................IX-I

Volume 3:
Administration
About This Volume vii
Document Conventions.................................................................................. vii
Web User Interface Conventions ............................................................ vii
Command Line Interface Conventions ................................................... viii
Naming Conventions and Character Types ............................................ viii
Illustration Conventions ............................................................................ x
Requesting Technical Support .......................................................................... x
Self-Help Online Tools and Resources....................................................... xi
Opening a Case with JTAC ........................................................................ xi
Document Feedback ....................................................................................... xi

Chapter 1 Administration 1
Management via the Web User Interface ......................................................... 2
WebUI Help ............................................................................................... 2
Copying the Help Files to a Local Drive ............................................... 3
Pointing the WebUI to the New Help Location .................................... 3
HyperText Transfer Protocol...................................................................... 4
Session ID.................................................................................................. 4
Secure Sockets Layer ................................................................................. 5
SSL Configuration................................................................................ 7
Redirecting HTTP to SSL ..................................................................... 8
Management via the Command Line Interface................................................. 9
Telnet ........................................................................................................ 9
Securing Telnet Connections ................................................................... 10
Secure Shell ............................................................................................. 11
Client Requirements.......................................................................... 12
Basic SSH Configuration on the Device ............................................. 13
Authentication .................................................................................. 14
SSH and Vsys .................................................................................... 16
Host Key ........................................................................................... 16
Example: SSHv1 with PKA for Automated Logins ............................. 17
Secure Copy ............................................................................................ 18
Serial Console.......................................................................................... 19
Remote Console ...................................................................................... 20
Remote Console Using V.92 Modem Port.......................................... 20
Remote Console Using an AUX Port.................................................. 21
Modem Port ............................................................................................ 22
Management via NetScreen-Security Manager ............................................... 22
Initiating Connectivity Between NSM Agent and the MGT System ........... 23
Enabling, Disabling, and Unsetting NSM Agent........................................ 24
Setting the Primary Server IP Address of the Management System ......... 25
Setting Alarm and Statistics Reporting..................................................... 25
Configuration Synchronization ................................................................ 26
Example: Viewing the Configuration State ........................................ 27
Example: Retrieving the Configuration Hash..................................... 27
Retrieving the Configuration Timestamp ................................................. 27
Controlling Administrative Traffic .................................................................. 28
MGT and VLAN1 Interfaces...................................................................... 29

Table of Contents  ix
 Concepts & Examples ScreenOS Reference Guide

Example: Administration Through the MGT Interface .......................29

Example: Administration Through the VLAN1 Interface .................... 29
Setting Administrative Interface Options ................................................. 30
Setting Manage IPs for Multiple Interfaces ............................................... 31
Levels of Administration ................................................................................ 33
Root Administrator .................................................................................. 33
Read/Write Administrator........................................................................ 34
Read-Only Administrator......................................................................... 34
Virtual System Administrator................................................................... 34
Virtual System Read-Only Administrator ................................................. 35
Defining Admin Users .................................................................................... 35
Example: Adding a Read-Only Admin ..................................................... 35
Example: Modifying an Admin ................................................................ 35
Example: Deleting an Admin ................................................................... 36
Example: Configuring Admin Accounts for Dialup Connections............... 36
Example: Clearing an Admin’s Sessions .................................................. 37
Securing Administrative Traffic ...................................................................... 37
Changing the Port Number ...................................................................... 38
Changing the Admin Login Name and Password ..................................... 39
Example: Changing an Admin User’s Login Name and Password ..... 40
Example: Changing Your Own Password .......................................... 40
Setting the Minimum Length of the Root Admin Password ............... 41
Resetting the Device to the Factory Default Settings................................ 41
Restricting Administrative Access ............................................................ 42
Example: Restricting Administration to a Single Workstation............ 42
Example: Restricting Administration to a Subnet .............................. 42
Restricting the Root Admin to Console Access .................................. 42
VPN Tunnels for Administrative Traffic....................................................43
Administration Through a Route-Based Manual Key VPN Tunnel ...... 44
Administration Through a Policy-Based Manual Key VPN Tunnel...... 47
Password Policy ............................................................................................. 51
Setting a Password Policy ........................................................................ 51
Removing a Password Policy ................................................................... 52
Viewing a Password Policy ...................................................................... 52
Recovering from a Rejected Default Admin Password ............................. 52
Creating a Login Banner................................................................................. 53

Chapter 2 Monitoring Security Devices 55

Storing Log Information ................................................................................. 55
Event Log ....................................................................................................... 57
Viewing the Event Log by Severity Level and Keyword............................ 58
Sorting and Filtering the Event Log.......................................................... 59
Downloading the Event Log..................................................................... 60
Example: Downloading the Entire Event Log .................................... 60
Example: Downloading the Event Log for Critical Events .................. 60
Traffic Log...................................................................................................... 61
Viewing the Traffic Log ............................................................................ 62
Example: Viewing Traffic Log Entries................................................ 62
Sorting and Filtering the Traffic Log .................................................. 62
Example: Sorting the Traffic Log by Time ......................................... 63
Removing the Reason for Close Field ...................................................... 64
Self Log .......................................................................................................... 66
Viewing the Self Log ................................................................................ 66
Sorting and Filtering the Self Log ...................................................... 66

x  Table of Contents
 Table of Contents

Example: Filtering the Self Log by Time ............................................ 67

Downloading the Self Log ........................................................................ 67
Downloading the Asset Recovery Log ............................................................ 68
Traffic Alarms ................................................................................................ 68
Example: Policy-Based Intrusion Detection.............................................. 69
Example: Compromised System Notification........................................... 70
Example: Sending Email Alerts................................................................ 71
Syslog ............................................................................................................ 71
Example: Enabling Multiple Syslog Servers.............................................. 72
Enabling WebTrends for Notification Events ........................................... 72
Simple Network Management Protocol .......................................................... 74
Implementation Overview ....................................................................... 76
Defining a Read/Write SNMP Community ............................................... 77
VPN Tunnels for Self-Initiated Traffic ............................................................. 78
Example: Self-Generated Traffic Through a Route-Based Tunnel.............. 79
Example: Self-Generated Traffic Through a Policy-Based Tunnel ............. 86
Viewing Screen Counters ............................................................................... 92

Index..........................................................................................................................IX-I

Volume 4:
Attack Detection and Defense Mechanisms
About This Volume ix
Document Conventions.................................................................................... x
Web User Interface Conventions .............................................................. x
Command Line Interface Conventions ...................................................... x
Naming Conventions and Character Types .............................................. xi
Illustration Conventions .......................................................................... xii
Requesting Technical Support ........................................................................ xii
Self-Help Online Tools and Resources..................................................... xiii
Opening a Case with JTAC ...................................................................... xiii
Document Feedback ..................................................................................... xiii

Chapter 1 Protecting a Network 1

Stages of an Attack........................................................................................... 2
Detection and Defense Mechanisms ................................................................ 2
Exploit Monitoring ........................................................................................... 5
Example: Monitoring Attacks from the Untrust Zone................................. 5

Chapter 2 Reconnaissance Deterrence 7

IP Address Sweep ............................................................................................ 8
Port Scanning................................................................................................... 9
Network Reconnaissance Using IP Options ....................................................10
Operating System Probes............................................................................... 12
SYN and FIN Flags Set ............................................................................. 12
FIN Flag Without ACK Flag ...................................................................... 13
TCP Header Without Flags Set .................................................................14
Evasion Techniques ....................................................................................... 15
FIN Scan .................................................................................................. 15
Non-SYN Flags......................................................................................... 15
IP Spoofing ..............................................................................................18

Table of Contents  xi
 Concepts & Examples ScreenOS Reference Guide

Example: L3 IP Spoof Protection ....................................................... 20

Example: L2 IP Spoof Protection ....................................................... 22
IP Source Route Options.......................................................................... 23

Chapter 3 Denial of Service Attack Defenses 27

Firewall DoS Attacks ...................................................................................... 28
Session Table Flood ................................................................................. 28
Source-Based and Destination-Based Session Limits ......................... 28
Example: Source-Based Session Limiting .......................................... 30
Example: Destination-Based Session Limiting ................................... 30
Aggressive Aging............................................................................... 31
Example: Aggressively Aging Out Sessions........................................ 32
CPU Protection with Blacklisting DoS Attack Traffic .......................... 33
Example............................................................................................ 34
Prioritizing Critical Traffic .................................................................35
SYN-ACK-ACK Proxy Flood ...................................................................... 36
Network DoS Attacks ..................................................................................... 38
SYN Flood................................................................................................ 38
Example: SYN Flood Protection ........................................................ 44
SYN Cookie..............................................................................................48
ICMP Flood ..............................................................................................50
UDP Flood ............................................................................................... 51
Land Attack ............................................................................................. 52
OS-Specific DoS Attacks ................................................................................. 53
Ping of Death........................................................................................... 53
Teardrop Attack....................................................................................... 54
WinNuke ................................................................................................. 55

Chapter 4 Content Monitoring and Filtering 57

Fragment Reassembly.................................................................................... 58
Malicious URL Protection......................................................................... 58
Application Layer Gateway ...................................................................... 59
Example: Blocking Malicious URLs in Packet Fragments ................... 60
Antivirus Scanning ......................................................................................... 62
External AV Scanning .............................................................................. 62
Scanning Modes................................................................................ 63
Load-Balancing ICAP Scan Servers ....................................................63
Internal AV Scanning ............................................................................... 64
AV Scanning of IM Traffic ........................................................................ 65
IM Clients.......................................................................................... 65
IM Server .......................................................................................... 66
IM Protocols ...................................................................................... 67
Instant Messaging Security Issues ..................................................... 67
IM Security Issues ............................................................................. 67
Scanning Chat Messages ................................................................... 68
Scanning File Transfers ..................................................................... 68
AV Scanning Results ................................................................................ 69
Policy-Based AV Scanning ....................................................................... 70
Scanning Application Protocols................................................................ 71
Scanning FTP Traffic ......................................................................... 72
Scanning HTTP Traffic ...................................................................... 74
Scanning IMAP and POP3 Traffic ...................................................... 76
Scanning SMTP Traffic ...................................................................... 77

xii  Table of Contents

 Table of Contents

Redirecting Traffic to ICAP AV Scan Servers...................................... 79

Updating the AV Pattern Files for the Embedded Scanner .......................80
Subscribing to the AV Signature Service ............................................ 80
Updating AV Patterns from a Server.................................................. 81
Updating AV Patterns from a Proxy Server ....................................... 83
AV Scanner Global Settings...................................................................... 83
AV Resource Allotment ..................................................................... 83
Fail-Mode Behavior ........................................................................... 84
Maximum Content Size and Maximum Messages (Internal AV Only) 84
HTTP Keep-Alive ............................................................................... 85
HTTP Trickling (Internal AV Only) ..................................................... 86
AV Profiles............................................................................................... 87
Assigning an AV Profile to a Firewall Policy....................................... 88
Initiating an AV Profile for Internal AV .............................................. 88
Example: (Internal AV) Scanning for All Traffic Types .......................89
Example: AV Scanning for SMTP and HTTP Traffic Only................... 89
AV Profile Settings............................................................................. 90
Anti-Spam Filtering ........................................................................................ 94
Blacklists and Whitelists .......................................................................... 94
Basic Configuration.................................................................................. 95
Filtering Spam Traffic........................................................................ 95
Dropping Spam Messages .................................................................95
Defining a Blacklist .................................................................................. 96
Defining a Whitelist ................................................................................. 96
Defining a Default Action......................................................................... 96
Enabling a Spam-Blocking List Server ...................................................... 97
Testing Anti-Spam ................................................................................... 97
Web Filtering ................................................................................................. 98
Using the CLI to Initiate Web-Filtering Modes .......................................... 98
Integrated Web Filtering .......................................................................... 99
SurfControl Servers .........................................................................100
Web Filtering Cache........................................................................100
Configuring Integrated Web Filtering ..............................................101
Example: Integrated Web Filtering..................................................106
Redirect Web Filtering ...........................................................................108
Virtual System Support....................................................................109
Configuring Redirect Web Filtering .................................................110
Example: Redirect Web Filtering.....................................................113

Chapter 5 Deep Inspection 117

Overview .....................................................................................................118
Attack Object Database Server .....................................................................122
Predefined Signature Packs ...................................................................122
Updating Signature Packs ......................................................................123
Before You Start Updating Attack Objects .......................................124
Immediate Update ..........................................................................124
Automatic Update ...........................................................................125
Automatic Notification and Immediate Update ...............................126
Manual Update................................................................................127
Updating DI Patterns from a Proxy Server ......................................129
Attack Objects and Groups ...........................................................................130
Supported Protocols ..............................................................................131
Stateful Signatures .................................................................................134
TCP Stream Signatures ..........................................................................135

Table of Contents  xiii

 Concepts & Examples ScreenOS Reference Guide

Protocol Anomalies................................................................................135
Attack Object Groups.............................................................................136
Changing Severity Levels.................................................................136
Example: Deep Inspection for P2P..................................................137
Disabling Attack Objects........................................................................139
Attack Actions..............................................................................................140
Example: Attack Actions—Close Server, Close, Close Client ............141
Brute Force Attack Actions ....................................................................148
Brute Force Attack Objects..............................................................149
Brute Force Attack Target................................................................149
Brute Force Attack Timeout.............................................................149
Example 1.......................................................................................150
Example 2.......................................................................................150
Example 3.......................................................................................151
Attack Logging .............................................................................................151
Example: Disabling Logging per Attack Group.................................151
Mapping Custom Services to Applications ....................................................153
Example: Mapping an Application to a Custom Service...................154
Example: Application-to-Service Mapping for HTTP Attacks ............156
Customized Attack Objects and Groups........................................................157
User-Defined Stateful Signature Attack Objects......................................157
Regular Expressions........................................................................158
Example: User-Defined Stateful Signature Attack Objects ...............159
TCP Stream Signature Attack Objects ....................................................161
Example: User-Defined Stream Signature Attack Object..................162
Configurable Protocol Anomaly Parameters ..........................................163
Example: Modifying Parameters .....................................................163
Negation ......................................................................................................164
Example: Attack Object Negation....................................................164
Granular Blocking of HTTP Components ......................................................168
ActiveX Controls....................................................................................169
Java Applets...........................................................................................169
EXE Files ...............................................................................................169
ZIP Files.................................................................................................169
Example: Blocking Java Applets and .exe Files................................170

Chapter 6 Intrusion Detection and Prevention 171

IDP-Capable Security Devices.......................................................................172
Traffic Flow in an IDP-Capable Device .........................................................173
Configuring Intrusion Detection and Prevention ..........................................175
Preconfiguration Tasks ..........................................................................175
Example 1: Basic IDP Configuration ......................................................176
Example 2: Configuring IDP for Active/Passive Failover ........................178
Example 3: Configuring IDP for Active/Active Failover ..........................180
Configuring Security Policies ........................................................................183
About Security Policies ..........................................................................183
Managing Security Policies ....................................................................183
Installing Security Policies .....................................................................184
Using IDP Rulebases ....................................................................................184
Role-Based Administration of IDP Rulebases .........................................185
Configuring Objects for IDP Rules..........................................................185
Using Security Policy Templates ............................................................186
Enabling IDP in Firewall Rules .....................................................................186
Enabling IDP..........................................................................................187

xiv  Table of Contents

 Table of Contents

Specifying Inline or Inline Tap Mode .....................................................187

Configuring IDP Rules ..................................................................................188
Adding the IDP Rulebase .......................................................................189
Matching Traffic ....................................................................................190
Source and Destination Zones.........................................................190
Source and Destination Address Objects .........................................191
Example: Setting Source and Destination........................................191
Example: Setting Multiple Sources and Destinations .......................191
Services...........................................................................................192
Example: Setting Default Services ...................................................192
Example: Setting Specific Services ..................................................193
Example: Setting Nonstandard Services ..........................................193
Terminal Rules ................................................................................195
Example: Setting Terminal Rules.....................................................195
Defining Actions ....................................................................................196
Setting Attack Objects............................................................................198
Adding Attack Objects Individually..................................................198
Adding Attack Objects by Category .................................................198
Example: Adding Attack Objects by Service ....................................198
Adding Attack Objects by Operating System ...................................198
Adding Attack Objects by Severity ..................................................199
Setting IP Action ....................................................................................199
Choosing an IP Action .....................................................................200
Choosing a Blocking Option ............................................................200
Setting Logging Options ..................................................................200
Setting Timeout Options .................................................................200
Setting Notification ................................................................................200
Setting Logging ...............................................................................201
Setting an Alert ...............................................................................201
Logging Packets ..............................................................................201
Setting Severity......................................................................................201
Setting Targets.......................................................................................202
Entering Comments...............................................................................202
Configuring Exempt Rules............................................................................202
Adding the Exempt Rulebase.................................................................203
Defining a Match ...................................................................................204
Source and Destination Zones.........................................................204
Source and Destination Address Objects .........................................204
Example: Exempting a Source/Destination Pair ..............................205
Setting Attack Objects............................................................................205
Example: Exempting Specific Attack Objects ..................................205
Setting Targets.......................................................................................205
Entering Comments...............................................................................206
Creating an Exempt Rule from the Log Viewer ......................................206
Configuring Backdoor Rules .........................................................................207
Adding the Backdoor Rulebase ..............................................................207
Defining a Match ...................................................................................208
Source and Destination Zones.........................................................208
Source and Destination Address Objects .........................................209
Services...........................................................................................209
Setting the Operation ............................................................................209
Setting Actions.......................................................................................209
Setting Notification ................................................................................210
Setting Logging ...............................................................................210

Table of Contents  xv
 Concepts & Examples ScreenOS Reference Guide

Setting an Alert ...............................................................................210

Logging Packets ..............................................................................210
Setting Severity......................................................................................211
Setting Targets.......................................................................................211
Entering Comments...............................................................................211
Configuring IDP Attack Objects ....................................................................211
About IDP Attack Object Types..............................................................211
Signature Attack Objects .................................................................212
Protocol Anomaly Attack Objects ....................................................212
Compound Attack Objects...............................................................212
Viewing Predefined IDP Attack Objects and Groups ..............................212
Viewing Predefined Attacks.............................................................213
Viewing Predefined Groups .............................................................213
Creating Custom IDP Attack Objects......................................................214
Creating a Signature Attack Object..................................................216
Creating a Protocol Anomaly Attack................................................221
Creating a Compound Attack ..........................................................222
Editing a Custom Attack Object.......................................................224
Deleting a Custom Attack Object.....................................................224
Creating Custom IDP Attack Groups ......................................................225
Configuring Static Groups................................................................225
Configuring Dynamic Groups ..........................................................226
Example: Creating a Dynamic Group ..............................................227
Updating Dynamic Groups ..............................................................228
Editing a Custom Attack Group .......................................................229
Deleting a Custom Attack Group .....................................................229
Configuring the Device as a Standalone IDP Device .....................................229
Enabling IDP..........................................................................................229
Example: Configuring a Firewall Rule for Standalone IDP ...............230
Configuring Role-Based Administration .................................................230
Example: Configuring an IDP-Only Administrator ...........................231
Managing IDP ..............................................................................................232
About Attack Database Updates.............................................................232
Downloading Attack Database Updates .................................................232
Using Updated Attack Objects .........................................................233
Updating the IDP Engine.................................................................233
Viewing IDP Logs...................................................................................235
ISG-IDP Devices ...........................................................................................236
Compiling a Policy.................................................................................236
Policy Size Multiplier .......................................................................236
Unloading Existing Policies .............................................................237

Chapter 7 Suspicious Packet Attributes 239

ICMP Fragments ..........................................................................................240
Large ICMP Packets......................................................................................241
Bad IP Options .............................................................................................242
Unknown Protocols......................................................................................243
IP Packet Fragments ....................................................................................244
SYN Fragments ............................................................................................245

xvi  Table of Contents

 Table of Contents

Appendix A Contexts for User-Defined Signatures A-I

Index..........................................................................................................................IX-I

Volume 5:
Virtual Private Networks
About This Volume vii
Document Conventions................................................................................. viii
Web User Interface Conventions ........................................................... viii
Command Line Interface Conventions ................................................... viii
Naming Conventions and Character Types .............................................. ix
Illustration Conventions ............................................................................ x
Requesting Technical Support .......................................................................... x
Self-Help Online Tools and Resources....................................................... xi
Opening a Case with JTAC ........................................................................ xi
Document Feedback ....................................................................................... xi

Chapter 1 Internet Protocol Security 1

Introduction to Virtual Private Networks .......................................................... 2
IPSec Concepts ................................................................................................3
Modes........................................................................................................ 4
Transport Mode .................................................................................. 4
Tunnel Mode ....................................................................................... 4
Protocols ................................................................................................... 5
Authentication Header ........................................................................ 6
Encapsulating Security Payload........................................................... 6
Key Management ...................................................................................... 7
Manual Key ......................................................................................... 7
AutoKey IKE........................................................................................ 7
Security Associations ................................................................................. 8
Tunnel Negotiation........................................................................................... 8
Phase 1...................................................................................................... 9
Main and Aggressive Modes ................................................................ 9
Diffie-Hellman Exchange................................................................... 10
Phase 2.................................................................................................... 11
Perfect Forward Secrecy ................................................................... 11
Replay Protection.............................................................................. 12
IKE and IPSec Packets.................................................................................... 12
IKE Packets ............................................................................................. 12
IPSec Packets .......................................................................................... 15
IKE Version 2........................................................................................... 17
Initial Exchanges............................................................................... 17
CREATE_CHILD_SA Exchange .......................................................... 19
Informational Exchanges .................................................................. 19
Enabling IKEv2 on a Security Device ....................................................... 19
Example: Configuring an IKEv2 Gateway .......................................... 20
Authentication Using Extensible Authentication Protocol .................. 24
IKEv2 EAP Passthrough ........................................................................... 25
Example............................................................................................ 25

Table of Contents  xvii

 Concepts & Examples ScreenOS Reference Guide

Chapter 2 Public Key Cryptography 29

Introduction to Public Key Cryptography ....................................................... 30
Signing a Certificate................................................................................. 30
Verifying a Digital Signature .................................................................... 30
Public Key Infrastructure................................................................................ 32
Certificates and CRLs ..................................................................................... 34
Requesting a Certificate Manually............................................................ 36
Loading Certificates and Certificate Revocation Lists ............................... 38
Configuring CRL Settings ......................................................................... 39
Obtaining a Local Certificate Automatically ............................................. 40
Automatic Certificate Renewal.................................................................43
Key-Pair Generation................................................................................. 44
Online Certificate Status Protocol................................................................... 44
Specifying a Certificate Revocation Check Method .................................. 45
Viewing Status Check Attributes .............................................................. 46
Specifying an Online Certificate Status Protocol Responder URL ............. 46
Removing Status Check Attributes........................................................... 46
Self-Signed Certificates................................................................................... 47
Certificate Validation ............................................................................... 48
Manually Creating Self-Signed Certificates ............................................... 49
Setting an Admin-Defined Self-Signed Certificate .................................... 50
Certificate Auto-Generation...................................................................... 54
Deleting Self-Signed Certificates .............................................................. 55

Chapter 3 Virtual Private Network Guidelines 57

Cryptographic Options ................................................................................... 58
Site-to-Site Cryptographic Options ........................................................... 58
Dialup VPN Options................................................................................. 65
Route-Based and Policy-Based Tunnels .......................................................... 72
Packet Flow: Site-to-Site VPN ......................................................................... 73
Tunnel Configuration Guidelines .................................................................... 79
Route-Based Virtual Private Network Security Considerations ........................ 81
Null Route................................................................................................ 81
Dialup or Leased Line .............................................................................. 83
VPN Failover to Leased Line or Null Route............................................... 84
Decoy Tunnel Interface ........................................................................... 86
Virtual Router for Tunnel Interfaces......................................................... 87
Reroute to Another Tunnel ...................................................................... 87

Chapter 4 Site-to-Site Virtual Private Networks 89

Site-to-Site VPN Configurations ...................................................................... 90
Route-Based Site-to-Site VPN, AutoKey IKE ............................................. 96
Policy-Based Site-to-Site VPN, AutoKey IKE ...........................................105
Route-Based Site-to-Site VPN, Dynamic Peer .........................................111
Policy-Based Site-to-Site VPN, Dynamic Peer.........................................119
Route-Based Site-to-Site VPN, Manual Key.............................................128
Policy-Based Site-to-Site VPN, Manual Key.............................................134
Dynamic IKE Gateways Using FQDN ...........................................................139
Aliases ...................................................................................................140
Setting AutoKey IKE Peer with FQDN ....................................................141
VPN Sites with Overlapping Addresses.........................................................150
Transparent Mode VPN ................................................................................161

xviii  Table of Contents

 Table of Contents

Chapter 5 Dialup Virtual Private Networks 169

Dialup ..........................................................................................................170
Policy-Based Dialup VPN, AutoKey IKE..................................................170
Route-Based Dialup VPN, Dynamic Peer................................................176
Policy-Based Dialup VPN, Dynamic Peer ...............................................183
Bidirectional Policies for Dialup VPN Users............................................188
Group IKE ID................................................................................................193
Group IKE ID with Certificates ...............................................................193
Wildcard and Container ASN1-DN IKE ID Types....................................195
Creating a Group IKE ID (Certificates) ....................................................197
Setting a Group IKE ID with Preshared Keys..........................................202
Shared IKE ID ..............................................................................................208

Chapter 6 Layer 2 Tunneling Protocol 215

Introduction to L2TP ....................................................................................215
Packet Encapsulation and Decapsulation .....................................................218
Encapsulation ........................................................................................218
Decapsulation........................................................................................219
Setting L2TP Parameters ..............................................................................221
L2TP and L2TP-over-IPSec ...........................................................................223
Configuring L2TP...................................................................................223
Configuring L2TP-over-IPSec .................................................................228
Bidirectional L2TP-over-IPSec ................................................................235

Chapter 7 Advanced Virtual Private Network Features 241

NAT-Traversal ..............................................................................................242
Probing for NAT.....................................................................................243
Traversing a NAT Device .......................................................................245
UDP Checksum......................................................................................247
Keepalive Packets..................................................................................247
Initiator/Responder Symmetry ..............................................................247
Enabling NAT-Traversal .........................................................................249
Using IKE IDs with NAT-Traversal..........................................................250
VPN Monitoring ...........................................................................................252
Rekey and Optimization Options...........................................................253
Source Interface and Destination Address .............................................254
Policy Considerations ............................................................................255
Configuring the VPN Monitoring Feature ...............................................255
SNMP VPN Monitoring Objects and Traps .............................................263
Multiple Tunnels per Tunnel Interface ..........................................................265
Route-to-Tunnel Mapping ......................................................................265
Remote Peers’ Addresses ......................................................................267
Manual and Automatic Table Entries .....................................................268
Manual Table Entries.......................................................................268
Automatic Table Entries ..................................................................268
Setting VPNs on a Tunnel Interface to Overlapping Subnets............270
Binding Automatic Route and NHTB Table Entries ..........................288
Using OSPF for Automatic Route Table Entries ...............................300
Redundant VPN Gateways............................................................................301
VPN Groups ...........................................................................................302
Monitoring Mechanisms ........................................................................303
IKE Heartbeats ................................................................................304
Dead Peer Detection .......................................................................304

Table of Contents  xix

 Concepts & Examples ScreenOS Reference Guide

IKE Recovery Procedure..................................................................305

TCP SYN-Flag Checking .........................................................................307
Creating Redundant VPN Gateways.................................................308
Creating Back-to-Back VPNs .........................................................................314
Creating Hub-and-Spoke VPNs .....................................................................321

Chapter 8 AutoConnect-Virtual Private Networks 331

Overview .....................................................................................................331
How It Works...............................................................................................331
NHRP Messages.....................................................................................332
AC-VPN Tunnel Initiation .......................................................................333
Configuring AC-VPN ..............................................................................334
Network Address Translation ..........................................................334
Configuration on the Hub................................................................334
Configuration on Each Spoke ..........................................................335
Example ................................................................................................336

Index..........................................................................................................................IX-I

Volume 6:
Voice-over-Internet Protocol
About This Volume vii
Document Conventions................................................................................. viii
Web User Interface Conventions ........................................................... viii
Command Line Interface Conventions ................................................... viii
Naming Conventions and Character Types .............................................. ix
Illustration Conventions ............................................................................ x
Requesting Technical Support .......................................................................... x
Self-Help Online Tools and Resources....................................................... xi
Opening a Case with JTAC ........................................................................ xi
Document Feedback ....................................................................................... xi

Chapter 1 H.323 Application Layer Gateway 1

Overview ......................................................................................................... 1
Alternate Gatekeeper ....................................................................................... 2
Examples ......................................................................................................... 2
Example: Gatekeeper in the Trust Zone ..................................................... 2
Example: Gatekeeper in the Untrust Zone ................................................. 4
Example: Outgoing Calls with NAT ............................................................ 5
Example: Incoming Calls with NAT............................................................ 8
Example: Gatekeeper in the Untrust Zone with NAT................................ 10

Chapter 2 Session Initiation Protocol Application Layer Gateway 15

Overview ....................................................................................................... 15
SIP Request Methods ............................................................................... 16
Classes of SIP Responses ......................................................................... 18
SIP Application Layer Gateway ................................................................ 19
Session Description Protocol Sessions ..................................................... 20
Pinhole Creation ...................................................................................... 21
Session Inactivity Timeout....................................................................... 22
SIP Attack Protection ............................................................................... 23

xx  Table of Contents
 Table of Contents

Example: SIP Protect Deny ............................................................... 23

Example: Signaling-Inactivity and Media-Inactivity Timeouts ............ 24
Example: UDP Flooding Protection ................................................... 24
Example: SIP Connection Maximum ................................................. 25
SIP with Network Address Translation ........................................................... 25
Outgoing Calls ......................................................................................... 26
Incoming Calls......................................................................................... 26
Forwarded Calls....................................................................................... 27
Call Termination ...................................................................................... 27
Call Re-INVITE Messages ......................................................................... 27
Call Session Timers.................................................................................. 27
Call Cancellation ...................................................................................... 27
Forking .................................................................................................... 28
SIP Messages ........................................................................................... 28
SIP Headers ............................................................................................. 28
SIP Body.................................................................................................. 30
SIP NAT Scenario..................................................................................... 30
Examples ....................................................................................................... 32
Incoming SIP Call Support Using the SIP Registrar................................... 33
Example: Incoming Call (Interface DIP)............................................. 34
Example: Incoming Call (DIP Pool)....................................................37
Example: Incoming Call with MIP ..................................................... 39
Example: Proxy in the Private Zone .................................................. 41
Example: Proxy in the Public Zone ................................................... 44
Example: Three-Zone, Proxy in the DMZ .......................................... 46
Example: Untrust Intrazone .............................................................. 49
Example: Trust Intrazone.................................................................. 53
Example: Full-Mesh VPN for SIP........................................................ 55
Bandwidth Management for VoIP Services .............................................. 64

Chapter 3 Media Gateway Control Protocol Application Layer Gateway 67

Overview ....................................................................................................... 67
MGCP Security ............................................................................................... 68
About MGCP................................................................................................... 68
Entities in MGCP...................................................................................... 68
Endpoint ........................................................................................... 69
Connection ....................................................................................... 69
Call.................................................................................................... 69
Call Agent ......................................................................................... 69
Commands..............................................................................................70
Response Codes ...................................................................................... 72
Examples ....................................................................................................... 73
Media Gateway in Subscribers’ Homes—Call Agent at the ISP ................. 73
ISP-Hosted Service................................................................................... 76

Chapter 4 Skinny Client Control Protocol Application Layer Gateway 81

Overview ....................................................................................................... 81
SCCP Security ................................................................................................ 82
About SCCP.................................................................................................... 83
SCCP Components................................................................................... 83
SCCP Client ....................................................................................... 83
Call Manager ..................................................................................... 83
Cluster ..............................................................................................83

Table of Contents  xxi

 Concepts & Examples ScreenOS Reference Guide

SCCP Transactions................................................................................... 84
Client Initialization ............................................................................ 84
Client Registration............................................................................. 84
Call Setup.......................................................................................... 85
Media Setup ...................................................................................... 85
SCCP Control Messages and RTP Flow..................................................... 86
SCCP Messages........................................................................................ 87
Examples ....................................................................................................... 87
Example: Call Manager/TFTP Server in the Trust Zone...................... 88
Example: Call Manager/TFTP Server in the Untrust Zone .................. 90
Example: Three-Zone, Call Manager/TFTP Server in the DMZ ........... 92
Example: Intrazone, Call Manager/TFTP Server in Trust Zone ........... 95
Example: Intrazone, Call Manager/TFTP Server in Untrust Zone ....... 99
Example: Full-Mesh VPN for SCCP ..................................................101

Chapter 5 Apple iChat Application Layer Gateway 111

Overview .....................................................................................................111
Configuring the AppleiChat ALG ...................................................................112
Configuration Examples ...............................................................................113
Scenario 1: Private–Public Network.......................................................113
Scenario 2: Intrazone Call Within Private Network ................................117
Scenario 3: Users Across Different Networks .........................................120

Index..........................................................................................................................IX-I

Volume 7:
Routing
About This Volume ix
Document Conventions.................................................................................... x
Web User Interface Conventions .............................................................. x
Command Line Interface Conventions ...................................................... x
Naming Conventions and Character Types .............................................. xi
Illustration Conventions .......................................................................... xii
Requesting Technical Support ........................................................................ xii
Self-Help Online Tools and Resources..................................................... xiii
Opening a Case with JTAC ...................................................................... xiii
Document Feedback ..................................................................................... xiii

Chapter 1 Static Routing 1

Overview ......................................................................................................... 2
How Static Routing Works ......................................................................... 2
When to Configure Static Routes ............................................................... 3
Configuring Static Routes........................................................................... 5
Setting Static Routes ........................................................................... 5
Setting a Static Route for a Tunnel Interface ....................................... 8
Enabling Gateway Tracking ....................................................................... 9
Forwarding Traffic to the Null Interface ......................................................... 10
Preventing Route Lookup in Other Routing Tables .................................. 10
Preventing Tunnel Traffic from Being Sent on Non-Tunnel Interfaces...... 10
Preventing Loops Created by Summarized Routes................................... 10
Permanently Active Routes ............................................................................ 11

xxii  Table of Contents

 Table of Contents

Changing Routing Preference with Equal Cost Multipath................................ 11

Chapter 2 Routing 13
Overview ....................................................................................................... 14
Virtual Router Routing Tables......................................................................... 15
Destination-Based Routing Table ............................................................. 16
Source-Based Routing Table .................................................................... 17
Source Interface-Based Routing Table...................................................... 19
Creating and Modifying Virtual Routers.......................................................... 21
Modifying Virtual Routers ........................................................................ 21
Assigning a Virtual Router ID ................................................................... 22
Forwarding Traffic Between Virtual Routers ............................................ 23
Configuring Two Virtual Routers .............................................................. 23
Creating and Deleting Virtual Routers...................................................... 25
Creating a Custom Virtual Router ...................................................... 26
Deleting a Custom Virtual Router ...................................................... 26
Virtual Routers and Virtual Systems......................................................... 26
Creating a Virtual Router in a Vsys ....................................................27
Sharing Routes Between Virtual Routers ........................................... 28
Limiting the Number of Routing Table Entries ......................................... 29
Routing Features and Examples ..................................................................... 30
Route Selection........................................................................................ 30
Setting a Route Preference ................................................................ 30
Route Metrics .................................................................................... 31
Changing the Default Route Lookup Sequence .................................. 32
Route Lookup in Multiple Virtual Routers .......................................... 34
Configuring Equal Cost Multipath Routing ............................................... 35
Route Redistribution................................................................................ 37
Configuring a Route Map................................................................... 38
Route Filtering .................................................................................. 39
Configuring an Access List ................................................................ 40
Redistributing Routes into OSPF ....................................................... 40
Exporting and Importing Routes Between Virtual Routers .......................42
Configuring an Export Rule ............................................................... 42
Configuring Automatic Export........................................................... 43

Chapter 3 Open Shortest Path First 45

Overview ....................................................................................................... 46
Areas ....................................................................................................... 46
Router Classification ................................................................................ 47
Hello Protocol .......................................................................................... 47
Network Types ........................................................................................ 48
Broadcast Networks .......................................................................... 48
Point-to-Point Networks .................................................................... 48
Point-to-Multipoint Networks ............................................................ 48
Link-State Advertisements ....................................................................... 49
Basic OSPF Configuration .............................................................................. 49
Creating and Removing an OSPF Routing Instance ................................. 50
Creating an OSPF Instance................................................................ 50
Removing an OSPF Instance ............................................................. 51
Creating and Deleting an OSPF Area ....................................................... 51
Creating an OSPF Area...................................................................... 52
Deleting an OSPF Area...................................................................... 52

Table of Contents  xxiii

 Concepts & Examples ScreenOS Reference Guide

Assigning Interfaces to an OSPF Area ...................................................... 53

Assigning Interfaces to Areas ............................................................ 53
Configuring an Area Range ............................................................... 53
Enabling OSPF on Interfaces ................................................................... 54
Enabling OSPF on Interfaces............................................................. 54
Disabling OSPF on an Interface......................................................... 54
Verifying the Configuration...................................................................... 55
Redistributing Routes into Routing Protocols ................................................. 56
Summarizing Redistributed Routes ................................................................ 57
Summarizing Redistributed Routes.......................................................... 57
Global OSPF Parameters ................................................................................ 58
Advertising the Default Route .................................................................. 59
Virtual Links ............................................................................................ 59
Creating a Virtual Link....................................................................... 60
Creating an Automatic Virtual Link....................................................61
Setting OSPF Interface Parameters ................................................................ 62
Security Configuration.................................................................................... 64
Authenticating Neighbors ........................................................................ 64
Configuring a Clear-Text Password....................................................64
Configuring an MD5 Password .......................................................... 64
Configuring an OSPF Neighbor List.......................................................... 65
Rejecting Default Routes.......................................................................... 66
Protecting Against Flooding ..................................................................... 66
Configuring the Hello Threshold........................................................ 66
Configuring the LSA Threshold .......................................................... 67
Enabling Reduced Flooding............................................................... 67
Creating an OSPF Demand Circuit on a Tunnel Interface ............................... 67
Point-to-Multipoint Tunnel Interface............................................................... 68
Setting the OSPF Link-Type ..................................................................... 68
Disabling the Route-Deny Restriction ...................................................... 69
Creating a Point-to-Multipoint Network....................................................69

Chapter 4 Routing Information Protocol 73

Overview ....................................................................................................... 74
Basic RIP Configuration.................................................................................. 75
Creating and Deleting a RIP Instance....................................................... 75
Creating a RIP Instance ..................................................................... 76
Deleting a RIP Instance ..................................................................... 76
Enabling and Disabling RIP on Interfaces ................................................ 76
Enabling RIP on an Interface............................................................. 77
Disabling RIP on an Interface............................................................ 77
Redistributing Routes .............................................................................. 77
Viewing RIP Information................................................................................ 78
Viewing the RIP Database........................................................................ 78
Viewing RIP Details ................................................................................. 79
Viewing RIP Neighbor Information .......................................................... 80
Viewing RIP Details for a Specific Interface ............................................. 81
Global RIP Parameters ................................................................................... 82
Advertising the Default Route ........................................................................ 83
Configuring RIP Interface Parameters ............................................................ 84
Security Configuration.................................................................................... 85
Authenticating Neighbors by Setting a Password ..................................... 85
Configuring Trusted Neighbors ................................................................ 86
Rejecting Default Routes.......................................................................... 87

xxiv  Table of Contents

 Table of Contents

Protecting Against Flooding ..................................................................... 87

Configuring an Update Threshold...................................................... 88
Enabling RIP on Tunnel Interfaces ....................................................88
Optional RIP Configurations........................................................................... 89
Setting the RIP Version ............................................................................ 89
Enabling and Disabling a Prefix Summary............................................... 91
Enabling a Prefix Summary............................................................... 91
Disabling a Prefix Summary.............................................................. 92
Setting Alternate Routes .......................................................................... 92
Demand Circuits on Tunnel Interfaces..................................................... 93
Configuring a Static Neighbor .................................................................. 95
Configuring a Point-to-Multipoint Tunnel Interface......................................... 95

Chapter 5 Border Gateway Protocol 101

Overview .....................................................................................................102
Types of BGP Messages .........................................................................102
Path Attributes.......................................................................................103
External and Internal BGP .....................................................................103
Basic BGP Configuration...............................................................................104
Creating and Enabling a BGP Instance ...................................................105
Creating a BGP Routing Instance.....................................................105
Removing a BGP Instance ...............................................................106
Enabling and Disabling BGP on Interfaces .............................................106
Enabling BGP on Interfaces .............................................................106
Disabling BGP on Interfaces ............................................................106
Configuring BGP Peers and Peer Groups................................................107
Configuring a BGP Peer ...................................................................108
Configuring an IBGP Peer Group .....................................................108
Verifying the BGP Configuration ............................................................110
Security Configuration..................................................................................111
Authenticating BGP Neighbors ...............................................................111
Rejecting Default Routes........................................................................112
Optional BGP Configurations........................................................................113
Redistributing Routes into BGP ..............................................................114
Configuring an AS-Path Access List........................................................114
Adding Routes to BGP............................................................................115
Conditional Route Advertisement....................................................116
Setting the Route Weight.................................................................116
Setting Route Attributes ..................................................................117
Route-Refresh Capability .......................................................................117
Requesting an Inbound Routing Table Update ................................118
Requesting an Outbound Routing Table Update ..............................118
Configuring Route Reflection .................................................................118
Configuring a Confederation..................................................................120
BGP Communities .................................................................................122
Route Aggregation .................................................................................123
Aggregating Routes with Different AS-Paths ....................................123
Suppressing More-Specific Routes in Updates .................................124
Selecting Routes for Path Attribute..................................................125
Changing Attributes of an Aggregated Route ...................................126

Chapter 6 Policy-Based Routing 127

Policy Based Routing Overview....................................................................128

Table of Contents  xxv

 Concepts & Examples ScreenOS Reference Guide

Extended Access-Lists............................................................................128
Match Groups ........................................................................................128
Action Groups........................................................................................129
Route Lookup with PBR ...............................................................................130
Configuring PBR...........................................................................................130
Configuring an Extended Access List .....................................................131
Configuring a Match Group ....................................................................132
Configuring an Action Group .................................................................133
Configuring a PBR Policy .......................................................................134
Binding a PBR Policy .............................................................................134
Binding a PBR Policy to an Interface ...............................................134
Binding a PBR Policy to a Zone .......................................................134
Binding a PBR Policy to a Virtual Router .........................................135
Viewing PBR Output.....................................................................................135
Viewing an Extended Access List...........................................................135
Viewing a Match Group..........................................................................136
Viewing an Action Group .......................................................................136
Viewing a PBR Policy Configuration.......................................................137
Viewing a Complete PBR Configuration .................................................137
Advanced PBR Example...............................................................................138
Routing..................................................................................................139
PBR Elements........................................................................................140
Extended Access Lists .....................................................................140
Match Groups..................................................................................141
Action Group...................................................................................141
PBR Policies ....................................................................................142
Interface Binding ...................................................................................142
Advanced PBR with High Availability and Scalability....................................142
Resilient PBR Solution ...........................................................................142
Scalable PBR Solution ............................................................................143

Chapter 7 Multicast Routing 145

Overview .....................................................................................................145
Multicast Addresses ...............................................................................146
Reverse Path Forwarding.......................................................................146
Multicast Routing on Security Devices..........................................................147
Multicast Routing Table .........................................................................147
Configuring a Static Multicast Route ......................................................148
Access Lists ...........................................................................................149
Configuring Generic Routing Encapsulation on Tunnel Interfaces ..........149
Multicast Policies..........................................................................................151

Chapter 8 Internet Group Management Protocol 153

Overview .....................................................................................................154
Hosts .....................................................................................................154
Multicast Routers ...................................................................................155
IGMP on Security Devices ............................................................................155
Enabling and Disabling IGMP on Interfaces ...........................................155
Enabling IGMP on an Interface........................................................155
Disabling IGMP on an Interface .......................................................156
Configuring an Access List for Accepted Groups ....................................156
Configuring IGMP ..................................................................................157
Verifying an IGMP Configuration ...........................................................159

xxvi  Table of Contents

 Table of Contents

IGMP Operational Parameters ...............................................................160

IGMP Proxy..................................................................................................161
Membership Reports Upstream to the Source........................................162
Configuring IGMP Proxy ........................................................................163
Configuring IGMP Proxy on an Interface................................................164
Multicast Policies for IGMP and IGMP Proxy Configurations ..................165
Creating a Multicast Group Policy for IGMP .....................................165
Creating an IGMP Proxy Configuration............................................166
Setting Up an IGMP Sender Proxy .........................................................172

Chapter 9 Protocol Independent Multicast 179

Overview .....................................................................................................180
PIM-SM ..................................................................................................182
Multicast Distribution Trees.............................................................182
Designated Router...........................................................................183
Mapping Rendezvous Points to Groups ...........................................183
Forwarding Traffic on the Distribution Tree ....................................184
PIM-SSM ................................................................................................186
Configuring PIM-SM on Security Devices......................................................186
Enabling and Deleting a PIM-SM Instance for a VR ................................187
Enabling PIM-SM Instance...............................................................187
Deleting a PIM-SM Instance.............................................................187
Enabling and Disabling PIM-SM on Interfaces........................................187
Enabling PIM-SM on an Interface ....................................................188
Disabling PIM-SM on an Interface ...................................................188
Multicast Group Policies.........................................................................188
Static-RP-BSR Messages ..................................................................188
Join-Prune Messages .......................................................................189
Defining a Multicast Group Policy for PIM-SM .................................189
Setting a Basic PIM-SM Configuration...........................................................190
Verifying the Configuration ..........................................................................194
Configuring Rendezvous Points....................................................................196
Configuring a Static Rendezvous Point ..................................................196
Configuring a Candidate Rendezvous Point ...........................................197
Security Considerations................................................................................198
Restricting Multicast Groups ..................................................................198
Restricting Multicast Sources .................................................................199
Restricting Rendezvous Points...............................................................200
PIM-SM Interface Parameters.......................................................................201
Defining a Neighbor Policy ....................................................................201
Defining a Bootstrap Border ..................................................................202
Configuring a Proxy Rendezvous Point ........................................................202
PIM-SM and IGMPv3 ....................................................................................212

Chapter 10 ICMP Router Discovery Protocol 213

Overview .....................................................................................................213
Configuring ICMP Router Discovery Protocol ...............................................214
Enabling ICMP Router Discovery Protocol .............................................214
Configuring ICMP Router Discovery Protocol from the WebUI...............214
Configuring ICMP Router Discovery Protocol from the CLI ....................215
Advertising an Interface ..................................................................215
Broadcasting the Address................................................................215
Setting a Maximum Advertisement Interval ....................................215

Table of Contents  xxvii

 Concepts & Examples ScreenOS Reference Guide

Setting a Minimum Advertisement Interval .....................................215

Setting an Advertisement Lifetime Value.........................................216
Setting a Response Delay ................................................................216
Setting an Initial Advertisement Interval .........................................216
Setting a Number of Initial Advertisement Packets..........................216
Disabling IRDP .............................................................................................217
Viewing IRDP Settings..................................................................................217

Index..........................................................................................................................IX-I

Volume 8:
Address Translation
About This Volume v
Document Conventions................................................................................... vi
Web User Interface Conventions ............................................................. vi
Command Line Interface Conventions ..................................................... vi
Naming Conventions and Character Types ............................................. vii
Illustration Conventions ......................................................................... viii
Requesting Technical Support ....................................................................... viii
Self-Help Online Tools and Resources....................................................... ix
Opening a Case with JTAC ........................................................................ ix
Document Feedback ....................................................................................... ix

Chapter 1 Address Translation 1

Introduction to Address Translation ................................................................. 1
Source Network Address Translation ......................................................... 1
Destination Network Address Translation.................................................. 3
Policy-Based NAT-Dst.......................................................................... 4
Mapped Internet Protocol.................................................................... 6
Virtual Internet Protocol ...................................................................... 6
Policy-Based Translation Options ..................................................................... 7
Example: NAT-Src from a DIP Pool with PAT............................................. 7
Example: NAT-Src From a DIP Pool Without PAT ...................................... 7
Example: NAT-Src from a DIP Pool with Address Shifting.......................... 8
Example: NAT-Src from the Egress Interface IP Address............................ 8
Example: NAT-Dst to a Single IP Address with Port Mapping..................... 8
Example: NAT-Dst to a Single IP Address Without Port Mapping ............... 9
Example: NAT-Dst from an IP Address Range to a Single IP Address......... 9
Example: NAT-Dst Between IP Address Ranges ....................................... 10
Directional Nature of NAT-Src and NAT-Dst ................................................... 10

Chapter 2 Source Network Address Translation 13

Introduction to NAT-Src ................................................................................. 13
NAT-Src from a DIP Pool with PAT Enabled ................................................... 15
Example: NAT-Src with PAT Enabled....................................................... 15
NAT-Src from a DIP Pool with PAT Disabled .................................................. 18
Example: NAT-Src with PAT Disabled ...................................................... 18
NAT-Src from a DIP Pool with Address Shifting.............................................. 20
Example: NAT-Src with Address Shifting ................................................. 21
NAT-Src from the Egress Interface IP Address................................................ 24
Example: NAT-Src Without DIP ............................................................... 24

xxviii  Table of Contents

 Table of Contents

Chapter 3 Destination Network Address Translation 27

Introduction to NAT-Dst ................................................................................. 28
Packet Flow for NAT-Dst.......................................................................... 29
Routing for NAT-Dst ................................................................................ 32
Example: Addresses Connected to One Interface.............................. 33
Example: Addresses Connected to One Interface
But Separated by a Router .......................................................... 34
Example: Addresses Separated by an Interface................................. 34
NAT-Dst—One-to-One Mapping ..................................................................... 35
Example: One-to-One Destination Translation......................................... 36
Translating from One Address to Multiple Addresses............................... 38
Example: One-to-Many Destination Translation ................................ 38
NAT-Dst—Many-to-One Mapping ................................................................... 41
Example: Many-to-One Destination Translation....................................... 41
NAT-Dst—Many-to-Many Mapping .................................................................44
Example: Many-to-Many Destination Translation .................................... 45
NAT-Dst with Port Mapping............................................................................ 47
Example: NAT-Dst with Port Mapping ..................................................... 47
NAT-Src and NAT-Dst in the Same Policy ....................................................... 50
Example: NAT-Src and NAT-Dst Combined.............................................. 50

Chapter 4 Mapped and Virtual Addresses 63

Mapped IP Addresses..................................................................................... 63
MIP and the Global Zone ......................................................................... 64
Example: MIP on an Untrust Zone Interface...................................... 65
Example: Reaching a MIP from Different Zones................................ 67
Example: Adding a MIP to a Tunnel Interface ................................... 70
MIP-Same-as-Untrust ............................................................................... 70
Example: MIP on the Untrust Interface ............................................. 71
MIP and the Loopback Interface .............................................................. 73
Example: MIP for Two Tunnel Interfaces .......................................... 74
MIP Grouping .......................................................................................... 79
Example: MIP Grouping with Multi-Cell Policy................................... 79
Virtual IP Addresses ....................................................................................... 80
VIP and the Global Zone .......................................................................... 82
Example: Configuring Virtual IP Servers............................................ 82
Example: Editing a VIP Configuration ............................................... 84
Example: Removing a VIP Configuration........................................... 84
Example: VIP with Custom and Multiple-Port Services ...................... 85

Index..........................................................................................................................IX-I

Volume 9:
User Authentication
About This Volume vii
Document Conventions................................................................................. viii
Web User Interface Conventions ........................................................... viii
Command Line Interface Conventions ................................................... viii
Naming Conventions and Character Types .............................................. ix
Illustration Conventions ............................................................................ x
Requesting Technical Support .......................................................................... x

Table of Contents  xxix

 Concepts & Examples ScreenOS Reference Guide

Self-Help Online Tools and Resources....................................................... xi

Opening a Case with JTAC ........................................................................ xi
Document Feedback ....................................................................................... xi

Chapter 1 Authentication 1
User Authentication Types ............................................................................... 1
Admin Users .................................................................................................... 2
Multiple-Type Users.......................................................................................... 4
Group Expressions ........................................................................................... 5
Example: Group Expressions (AND)........................................................... 6
Example: Group Expressions (OR) ............................................................. 8
Example: Group Expressions (NOT)........................................................... 9
Banner Customization.................................................................................... 10
Example: Customizing a WebAuth Banner .............................................. 10
Login Banner.................................................................................................. 10
Example: Creating a Login Banner........................................................... 11

Chapter 2 Authentication Servers 13

Authentication Server Types .......................................................................... 13
Local Database............................................................................................... 15
Example: Local Database Timeout........................................................... 16
External Authentication Servers ..................................................................... 17
Auth Server Object Properties.................................................................. 18
Auth Server Types.......................................................................................... 19
Remote Authentication Dial-In User Service ............................................ 19
RADIUS Auth Server Object Properties.............................................. 20
Supported User Types and Features .................................................. 20
RADIUS Dictionary File ..................................................................... 21
RADIUS Access Challenge .................................................................22
Supported RADIUS Enhancements for Auth and XAuth Users ........... 24
SecurID.................................................................................................... 27
SecurID Auth Server Object Properties.............................................. 28
Supported User Types and Features .................................................. 28
Lightweight Directory Access Protocol ..................................................... 29
LDAP Auth Server Object Properties ................................................. 30
Supported User Types and Features .................................................. 30
Terminal Access Control Access Control System Plus (TACACS+)........... 30
TACACS+Server Object Properties ................................................... 32
Prioritizing Admin Authentication .................................................................. 32
Defining Auth Server Objects ......................................................................... 33
Example: RADIUS Auth Server ................................................................ 33
Example: SecurID Auth Server.................................................................35
Example: LDAP Auth Server .................................................................... 36
Example: TACACS+ Auth Server............................................................. 38
Defining Default Auth Servers ........................................................................ 39
Example: Changing Default Auth Servers ................................................ 39

Chapter 3 Infranet Authentication 41

Unified Access Control Solution ..................................................................... 42
How the Security Device Works with the Infranet Controller ......................... 43
Dynamic Discovery of Infranet Enforcers ................................................ 44
Infranet Controller Clustering......................................................................... 45

xxx  Table of Contents

 Table of Contents

Chapter 4 Authentication Users 47

Referencing Auth Users in Policies .................................................................48
Run-Time Authentication......................................................................... 48
Pre-Policy Check Authentication (WebAuth) ............................................ 49
Referencing Auth User Groups in Policies ...................................................... 50
Example: Run-Time Authentication (Local User) ...................................... 51
Example: Run-Time Authentication (Local User Group) ........................... 52
Example: Run-Time Authentication (External User) ................................. 54
Example: Run-Time Authentication (External User Group) ...................... 55
Example: Local Auth User in Multiple Groups .......................................... 58
Example: WebAuth (Local User Group) ....................................................60
Example: WebAuth (External User Group) ............................................... 61
Example: WebAuth + SSL Only (External User Group) ........................... 63

Chapter 5 IKE, XAuth, and L2TP Users 67

IKE Users and User Groups ............................................................................ 67
Example: Defining IKE Users................................................................... 68
Example: Creating an IKE User Group ..................................................... 69
Referencing IKE Users in Gateways ......................................................... 70
XAuth Users and User Groups ........................................................................ 70
Event Logging for IKE Mode .................................................................... 71
XAuth Users in IKE Negotiations.............................................................. 72
Example: XAuth Authentication (Local User) ..................................... 73
Example: XAuth Authentication (Local User Group) .......................... 75
Example: XAuth Authentication (External User) ................................ 76
Example: XAuth Authentication (External User Group)...................... 78
Example: XAuth Authentication and Address Assignments
(Local User Group) ...................................................................... 81
XAuth Client ............................................................................................ 85
Example: Security Device as an XAuth Client.................................... 85
L2TP Users and User Groups .......................................................................... 86
Example: Local and External L2TP Auth Servers...................................... 86

Chapter 6 Extensible Authentication for Wireless and Ethernet Interfaces 91

Overview ....................................................................................................... 92
Supported EAP Types..................................................................................... 92
Enabling and Disabling 802.1X Authentication .............................................. 93
Ethernet Interfaces .................................................................................. 93
Wireless Interfaces .................................................................................. 93
Configuring 802.1X Settings........................................................................... 94
Configuring 802.1X Port Control ............................................................. 94
Configuring 802.1X Control Mode ........................................................... 95
Setting the Maximum Number of Simultaneous Users............................. 95
Configuring the Reauthentication Period ................................................. 96
Enabling EAP Retransmissions ................................................................ 96
Configuring EAP Retransmission Count ................................................... 97
Configuring EAP Retransmission Period .................................................. 97
Configuring the Silent (Quiet) Period ....................................................... 97
Configuring Authentication Server Options ....................................................98
Specifying an Authentication Server ........................................................ 98
Ethernet Interfaces............................................................................ 98
Wireless Interfaces............................................................................ 98
Setting the Account Type......................................................................... 99

Table of Contents  xxxi

 Concepts & Examples ScreenOS Reference Guide

Enabling Zone Verification....................................................................... 99

Viewing 802.1X Information ........................................................................100
Viewing 802.1X Global Configuration Information ................................100
Viewing 802.1X Information for an Interface ........................................100
Viewing 802.1X Statistics ......................................................................100
Viewing 802.1X Session Statistics..........................................................101
Viewing 802.1X Session Details.............................................................102
Configuration Examples ...............................................................................102
Configuring the Security Device with a Directly Connected Client and
RADIUS Server ................................................................................102
Configuring a Security Device with a Hub Between a Client and the Security
Device.............................................................................................103
Configuring the Authentication Server with a Wireless Interface ...........104

Index..........................................................................................................................IX-I

Volume 10:
Virtual Systems
About This Volume v
Document Conventions................................................................................... vi
Web User Interface Conventions ............................................................. vi
Command Line Interface Conventions ..................................................... vi
Naming Conventions and Character Types ............................................. vii
Illustration Conventions ......................................................................... viii
Requesting Technical Support ....................................................................... viii
Self-Help Online Tools and Resources....................................................... ix
Opening a Case with JTAC ........................................................................ ix
Document Feedback ....................................................................................... ix

Chapter 1 Virtual Systems 1

Overview ......................................................................................................... 2
Vsys Objects .................................................................................................... 4
Creating a Virtual System Object and Admin ............................................. 4
Setting a Default Virtual Router for a Virtual System.................................. 6
Binding Zones to a Shared Virtual Router .................................................. 6
Logging In as a Virtual System Admin.............................................................. 7
Virtual System Profiles ..................................................................................... 8
Virtual System Session Counters................................................................ 9
Virtual System Session Information ......................................................... 10
Behavior in High-Availability Pairs ........................................................... 10
Creating a Vsys Profile............................................................................. 10
Setting Resource Limits ........................................................................... 10
Adding Session Limits Through Virtual-System Profile Assignment.......... 12
Setting a Session Override ....................................................................... 13
Overriding a Session Limit Reached Alarm ....................................... 13
Deleting a Vsys Profile ............................................................................. 14
Viewing Vsys Settings .............................................................................. 14
Viewing Overrides............................................................................. 14
Viewing a Profile ............................................................................... 15
Viewing Session Statistics.................................................................. 16
Sharing and Partitioning CPU Resources ........................................................ 17
Configuring CPU Weight .......................................................................... 17

xxxii  Table of Contents

 Table of Contents

Fair Mode Packet Flow ............................................................................ 18

Returning from Fair Mode to Shared Mode.............................................. 19
Enabling the CPU Limit Feature ............................................................... 20
Measuring CPU Usage.............................................................................. 20
Detailed Session Scan Debugging ............................................................ 23
Setting the Shared-to-Fair Mode CPU Utilization Threshold...................... 23
Configuring a Method for Returning to Shared Mode............................... 26
Setting a Fixed Root Vsys CPU Weight..................................................... 27
Virtual Systems and Virtual Private Networks ................................................ 27
Viewing Security Associations.................................................................. 28
Viewing IKE Cookies................................................................................ 28
Policy Scheduler............................................................................................. 29
Creating a Policy Scheduler ..................................................................... 29
Binding a Policy Schedule to a Policy....................................................... 30
Viewing Policy Schedules......................................................................... 30
Deleting a Policy Schedule....................................................................... 30

Chapter 2 Traffic Sorting 33

Overview ....................................................................................................... 33
Sorting Traffic.......................................................................................... 33
Sorting Through Traffic............................................................................ 34
Dedicated and Shared Interfaces ............................................................. 39
Dedicated Interfaces ......................................................................... 39
Shared Interfaces .............................................................................. 39
Importing and Exporting Physical Interfaces.................................................. 41
Importing a Physical Interface to a Virtual System................................... 41
Exporting a Physical Interface from a Virtual System .............................. 42

Chapter 3 VLAN-Based Traffic Classification 43

Overview ....................................................................................................... 43
VLANs...................................................................................................... 44
VLANs with Vsys...................................................................................... 44
VLANs with VSDs..................................................................................... 45
Example: Binding VLAN Group with VSD .......................................... 46
Configuring Layer 2 Virtual Systems .............................................................. 46
Example 1: Configuring a Single Port ................................................ 48
Example 2: Configuring Two 4-Port Aggregates with Separate Untrust
Zones ......................................................................................... 51
Example 3: Configuring Two 4-Port Aggregates that Share One
Untrusted Zone........................................................................... 58
Defining Subinterfaces and VLAN Tags .......................................................... 64
Communicating Between Virtual Systems...................................................... 67
VLAN Retagging ............................................................................................. 70
Configuring VLAN Retagging.................................................................... 71
Example............................................................................................ 72

Chapter 4 IP-Based Traffic Classification 75

Overview ....................................................................................................... 75
Designating an IP Range to the Root System ................................................. 76
Configuring IP-Based Traffic Classification ..................................................... 77

Table of Contents  xxxiii

 Concepts & Examples ScreenOS Reference Guide

Index..........................................................................................................................IX-I

Volume 11:
High Availability
About This Volume v
Document Conventions................................................................................... vi
Web User Interface Conventions ............................................................. vi
Command Line Interface Conventions ..................................................... vi
Naming Conventions and Character Types ............................................. vii
Illustration Conventions ......................................................................... viii
Requesting Technical Support ....................................................................... viii
Self-Help Online Tools and Resources....................................................... ix
Opening a Case with JTAC ........................................................................ ix
Document Feedback ....................................................................................... ix

Chapter 1 NetScreen Redundancy Protocol 1

High Availability Overview ............................................................................... 1
NSRP Overview................................................................................................3
NSRP Default Settings................................................................................ 4
NSRP-Lite .................................................................................................. 4
NSRP-Lite Default Settings ......................................................................... 6
Basic NSRP Settings................................................................................... 6
Control Link Messages ........................................................................ 7
Data Link Messages............................................................................. 8
Dynamic Routing Advisory.................................................................. 8
Dual Link Probes................................................................................. 9
NSRP Clusters ................................................................................................ 10
Example............................................................................................ 10
Cluster Names ......................................................................................... 12
Active/Passive Configuration ............................................................. 13
Active/Active Configuration ............................................................... 13
Active/Active Full-Mesh Configuration ............................................... 15
NSRP Cluster Authentication and Encryption........................................... 16
Run-Time Objects .................................................................................... 16
RTO Mirror Operational States ................................................................ 18
NSRP Cluster Synchronization .................................................................19
File Synchronization.......................................................................... 19
Configuration Synchronization .......................................................... 20
Route Synchronization ...................................................................... 20
Run-Time Object Synchronization..................................................... 21
System Clock Synchronization .......................................................... 21
Coldstart Synchronization .................................................................21
Virtual Security Device Groups ....................................................................... 22
Preempt Option....................................................................................... 23
Member States ........................................................................................ 23
Heartbeat Message .................................................................................. 24
Virtual Security Interfaces and Static Routes............................................ 25
Configuration Examples ................................................................................. 26
Cabling Devices for Active/Active Full-Mesh NSRP ................................... 26
Creating an NSRP Cluster ........................................................................ 29
Configuring an Active/Passive NSRP Cluster ............................................ 31
Configuring an Active/Active NSRP Cluster .............................................. 35

xxxiv  Table of Contents

 Table of Contents

Synchronizing RTOs Manually .................................................................40

Configuring Manual Link Probes .............................................................. 41
Configuring Automatic Link Probes ......................................................... 41
Configuring NSRP in an IPv6 Environment.............................................. 42
Configuring an Active/Active NSRP Cluster........................................ 42
Configuring the IPv6 Environment ....................................................42
Resetting the Configuration............................................................... 43
Configuring Active/Active NSRP in Transparent Mode ............................. 44

Chapter 2 Interface Redundancy and Failover 49

Redundant Interfaces and Zones.................................................................... 49
Holddown Time Settings.......................................................................... 50
Aggregate Interfaces ................................................................................ 51
Interface Failover ........................................................................................... 52
Backup Interface Traffic........................................................................... 52
Primary Interface Traffic ......................................................................... 53
Automatic Traffic Failover ....................................................................... 53
Serial Interfaces....................................................................................... 54
Default Route Deletion ...................................................................... 54
Default Route Addition...................................................................... 54
Policy Deactivation ........................................................................... 55
Monitoring Failover ................................................................................. 55
Interface Failover with IP Tracking .......................................................... 56
Active-to-Backup Tunnel Failover............................................................. 56
Interface Failover with VPN Tunnel Monitoring ....................................... 56
NSRP Object Monitoring to Trigger Failover ................................................... 57
Security Module....................................................................................... 59
Physical Interface .................................................................................... 59
Zone Objects ........................................................................................... 59
Tracked IP Objects................................................................................... 60
Track IP for Device Failover..................................................................... 61
Virtual Security Device Group Failover ........................................................... 62
Virtual System Failover .................................................................................. 63
Device Failover ..............................................................................................63
Example 1......................................................................................... 64
Example 2......................................................................................... 64
VRRP Support ................................................................................................ 65
Configuration Examples ................................................................................. 66
Configuring Track IP for Device Failover.................................................. 66
Configuring a Redundant VPN Tunnel ..................................................... 69
Configuring Virtual Security Interfaces..................................................... 73
Configuring Dual Active Tunnels.............................................................. 76
Configuring Interface Failover Using Track IP .......................................... 80
Configuring Tunnel Failover Weights ....................................................... 82
Configuring Virtual System Failover......................................................... 88

Index..........................................................................................................................IX-I

Volume 12:
WAN, DSL, Dial, and Wireless
About This Volume ix
Document Conventions.................................................................................... x

Table of Contents  xxxv

 Concepts & Examples ScreenOS Reference Guide

Web User Interface Conventions .............................................................. x

Command Line Interface Conventions ...................................................... x
Naming Conventions and Character Types .............................................. xi
Illustration Conventions .......................................................................... xii
Requesting Technical Support ........................................................................ xii
Self-Help Online Tools and Resources..................................................... xiii
Opening a Case with JTAC ...................................................................... xiii
Document Feedback ..................................................................................... xiii

Chapter 1 Wide Area Networks 1

WAN Overview ................................................................................................1
Serial ......................................................................................................... 2
T1.............................................................................................................. 3
E1.............................................................................................................. 3
T3.............................................................................................................. 4
E3.............................................................................................................. 4
ISDN.......................................................................................................... 5
WAN Interface Options .................................................................................... 7
Hold Time.................................................................................................. 8
Frame Checksum....................................................................................... 9
Idle-cycle Flag............................................................................................ 9
Start/End Flag ............................................................................................ 9
Line Encoding.......................................................................................... 10
Alternate Mark Inversion Encoding ................................................... 10
B8ZS and HDB3 Line Encoding ......................................................... 11
Byte Encoding................................................................................... 11
Line Buildout..................................................................................... 11
Framing Mode ......................................................................................... 12
Superframe for T1............................................................................. 12
Extended Superframe for T1 ............................................................. 12
C-Bit Parity Framing for T3 ............................................................... 13
Clocking .................................................................................................. 13
Clocking Mode .................................................................................. 13
Clocking Source ................................................................................ 14
Internal Clock Rate............................................................................ 14
Transmit Clock Inversion .................................................................. 16
Signal Handling ....................................................................................... 16
Loopback Signal ...................................................................................... 17
Remote and Local Loopback ............................................................. 17
Loopback Mode................................................................................. 18
CSU Compatibility Mode .................................................................. 20
Remote Loopback Response ............................................................. 21
FEAC Response ................................................................................. 21
Time Slots................................................................................................ 22
Fractional T1..................................................................................... 22
Fractional E1..................................................................................... 22
Bit Error Rate Testing .............................................................................. 23
ISDN Options........................................................................................... 24
Switch Type ...................................................................................... 24
SPID.................................................................................................. 24
TEI Negotiation ................................................................................. 25
Calling Number ................................................................................. 25
T310 Value........................................................................................ 25
Send Complete.................................................................................. 26

xxxvi  Table of Contents

 Table of Contents

BRI Mode................................................................................................. 26
Leased-Line Mode ............................................................................. 26
Dialer Enable .................................................................................... 26
Dialer Options ......................................................................................... 27
Disabling a WAN Interface....................................................................... 28
WAN Interface Encapsulation......................................................................... 29
Point-to-Point Protocol............................................................................. 29
Frame Relay ............................................................................................ 29
Cisco-High-Level Data Link Control (Cisco-HDLC) .................................... 30
Basic Encapsulation Options.................................................................... 31
Unnumbered Interfaces .................................................................... 31
Protocol Maximum Transmission Unit Configuration ........................ 31
Static IP Address Configuration ......................................................... 32
Keepalives......................................................................................... 32
PPP Encapsulation Options...................................................................... 33
PPP Access Profile............................................................................. 33
PPP Authentication Method............................................................... 34
Password .......................................................................................... 35
Network Control Protocol.................................................................. 35
PPP Authentication Protocols .................................................................. 36
Challenge Handshake Authentication Protocol .................................. 36
Password Authentication Protocol..................................................... 36
Local Database User.......................................................................... 37
Frame Relay Encapsulation Options ........................................................ 37
Keepalive Messages .......................................................................... 37
Frame Relay LMI Type ...................................................................... 38
Creating and Configuring PVCs ......................................................... 39
Inverse Address Resolution Protocol ................................................. 40
Inverse Neighbor Discovery Protocol ................................................ 40
Multilink Encapsulation .................................................................................. 41
Overview ................................................................................................. 41
Basic Multilink Bundle Configuration ....................................................... 42
Bundle Identifier ............................................................................... 42
Drop Timeout.................................................................................... 42
Fragment Threshold.......................................................................... 43
Minimum Links ................................................................................. 44
Basic Configuration Steps.................................................................. 44
Maximum Received Reconstructed Unit............................................ 45
Sequence-Header Format.................................................................. 45
Multilink Frame Relay Configuration Options .......................................... 46
Basic Configuration Steps.................................................................. 46
Link Assignment for MLFR ................................................................ 47
Acknowledge Retries......................................................................... 47
Acknowledge Timer .......................................................................... 47
Hello Timer ....................................................................................... 48
WAN Interface Configuration Examples ......................................................... 48
Configuring a Serial Interface .................................................................. 48
Configuring a T1 Interface ....................................................................... 49
Configuring an E1 Interface ..................................................................... 50
Configuring a T3 Interface ....................................................................... 50
Configuring an E3 Interface ..................................................................... 51
Configuring a Device for ISDN Connectivity ............................................ 52
Step 1: Selecting the ISDN Switch Type ................................................... 52
Step 2: Configuring a PPP Profile............................................................. 52

Table of Contents  xxxvii

 Concepts & Examples ScreenOS Reference Guide

Step 3: Setting Up the ISDN BRI Interface................................................ 53

Dialing Out to a Single Destination Only ........................................... 53
Dialing Out Using the Dialer Interface ............................................... 53
Using Leased-Line Mode.................................................................... 57
Step 4: Routing Traffic to the Destination ................................................ 57
Encapsulation Configuration Examples .......................................................... 59
Configuring PPP Encapsulation................................................................ 59
Configuring MLPPP Encapsulation ........................................................... 60
Configuring Frame Relay Encapsulation .................................................. 62
Configuring MLFR Encapsulation ............................................................. 62
Configuring Cisco HDLC Encapsulation....................................................64
Configuring IPv6 on WAN Interfaces ....................................................... 65
Configuring IPv6 on Point-to-Point Protocol Interface .......................65
Configuring IPv6 on a Multilink Point-to-Point Protocol Interface ...... 67
Configuring IPv6 on a Frame Relay Interface .................................... 69
Configuring IPv6 on a Multilink Frame Relay Interface ..................... 71

Chapter 2 Digital Subscriber Line 75

Digital Subscriber Line Overview ................................................................... 75
Asynchronous Transfer Mode .................................................................. 76
ATM Quality of Service...................................................................... 77
Point-to-Point Protocol over ATM ...................................................... 78
Multilink Point-to-Point Protocol........................................................ 79
Discrete Multitone for DSL Interfaces ...................................................... 79
Annex Mode ............................................................................................ 80
Virtual Circuits ......................................................................................... 81
VPI/VCI and Multiplexing Method...................................................... 81
PPPoE or PPPoA ............................................................................... 82
Static IP Address and Netmask ................................................................ 83
ADSL Interface ............................................................................................... 83
G.SHDSL Interface.......................................................................................... 84
Line-Rate ................................................................................................. 85
Loopback Mode ....................................................................................... 85
Operation, Administration, and Maintenance .......................................... 85
Signal-to-Noise Ratio................................................................................ 86
ADSL Configuration Examples ....................................................................... 87
Example 1: (Small Business/Home) PPPoA on ADSL Interface................. 88
Example 2: (Small Business/Home) 1483 Bridging on ADSL Interface ..... 90
Example 3: (Small Business) 1483 Routing on ADSL Interface................. 92
Example 4: (Small Business/Home) Dialup Backup .................................. 94
Example 5: (Small Business/Home) Ethernet Backup............................... 97
Example 6: (Small Business/Home) ADSL Backup..................................100
Example 7: (Small Business) MLPPP ADSL.............................................103
Example 8: (Small Business) Allow Access to Local Servers ...................105
Example 9: (Branch Office) VPN Tunnel Through ADSL.........................107
Example 10: (Branch Office) Secondary VPN Tunnel .............................111

Chapter 3 ISP Failover and Dial Recovery 119

Setting ISP Priority for Failover ....................................................................119
Defining Conditions for ISP Failover ............................................................120
Configuring a Dialup Recovery Solution .......................................................120

xxxviii  Table of Contents

 Table of Contents

Chapter 4 Wireless Local Area Network 125

Overview .....................................................................................................126
Wireless Product Interface Naming Differences.....................................127
Basic Wireless Network Feature Configuration.............................................127
Creating a Service Set Identifier.............................................................128
Suppressing SSID Broadcast............................................................128
Isolating a Client .............................................................................128
Setting the Operation Mode for a 2.4 GHz Radio Transceiver ................129
Setting the Operation Mode for a 5GHz Radio Transceiver ....................130
Configuring Minimum Data Transmit Rate ............................................130
Configuring Transmit Power..................................................................131
Reactivating a WLAN Configuration.......................................................131
Configuring Authentication and Encryption for SSIDs ..................................132
Configuring Wired Equivalent Privacy ...................................................133
Multiple WEP Keys..........................................................................133
Configuring Open Authentication ....................................................135
Configuring WEP Shared-Key Authentication ..................................136
Configuring Wi-Fi Protected Access .......................................................138
Configuring 802.1X Authentication for WPA and WPA2 .................138
Configuring Preshared Key Authentication for WPA and WPA2 ......139
Specifying Antenna Use ...............................................................................140
Setting the Country Code, Channel, and Frequency .....................................141
Using Extended Channels ............................................................................141
Performing a Site Survey..............................................................................142
Locating Available Channels.........................................................................143
Setting an Access Control List Entry .............................................................143
Configuring Super G .....................................................................................144
Configuring Atheros XR (Extended Range) ...................................................145
Configuring Wi-Fi Multimedia Quality of Service ..........................................146
Enabling WMM ......................................................................................146
Configuring WMM Quality of Service .....................................................146
Access Categories............................................................................146
WMM Default Settings.....................................................................147
Example..........................................................................................149
Configuring Advanced Wireless Parameters.................................................150
Configuring Aging Interval .....................................................................151
Configuring Beacon Interval ..................................................................151
Configuring Delivery Traffic Indication Message Period .........................152
Configuring Burst Threshold ..................................................................152
Configuring Fragment Threshold ...........................................................153
Configuring Request to Send Threshold .................................................153
Configuring Clear to Send Mode ............................................................154
Configuring Clear to Send Rate ..............................................................154
Configuring Clear to Send Type .............................................................154
Configuring Slot Time ............................................................................155
Configuring Preamble Length ................................................................155
Working with Wireless Interfaces.................................................................156
Binding an SSID to a Wireless Interface.................................................156
Binding a Wireless Interface to a Radio .................................................157
Creating Wireless Bridge Groups............................................................157
Disabling a Wireless Interface................................................................158
Viewing Wireless Configuration Information................................................158
Configuration Examples ...............................................................................159
Example 1: Open Authentication and WEP Encryption .........................159

Table of Contents  xxxix

 Concepts & Examples ScreenOS Reference Guide

Example 2: WPA-PSK Authentication with Passphrase and

Automatic Encryption .....................................................................160
Example 3: WLAN in Transparent Mode................................................160
Example 4: Multiple and Differentiated Profiles.....................................164

Appendix A Wireless Information A-I

802.11a Channel Numbers ...........................................................................A-I
802.11b and 802.11g Channels ................................................................. A-III
Turbo-Mode Channel Numbers .................................................................. A-IV

Index..........................................................................................................................IX-I

Volume 13:
General Packet Radio Service
About This Volume v
Document Conventions................................................................................... vi
Web User Interface Conventions ............................................................. vi
Command Line Interface Conventions ..................................................... vi
Naming Conventions and Character Types ............................................. vii
Illustration Conventions ......................................................................... viii
Requesting Technical Support ....................................................................... viii
Self-Help Online Tools and Resources....................................................... ix
Opening a Case with JTAC ........................................................................ ix
Document Feedback ....................................................................................... ix

Chapter 1 GPRS 1
The Security Device as a GPRS Tunneling Protocol Firewall ............................. 2
Gp and Gn Interfaces ................................................................................. 2
Gi Interface................................................................................................3
Operational Modes .................................................................................... 3
Virtual System Support .............................................................................. 4
Policy-Based GPRS Tunneling Protocol............................................................. 4
Example: Configuring Policies to Enable GTP Inspection ........................... 5
GPRS Tunneling Protocol Inspection Object ..................................................... 6
Example: Creating a GTP Inspection Object............................................... 7
GTP Message Filtering ...................................................................................... 7
Packet Sanity Check .................................................................................. 7
Message-Length Filtering ........................................................................... 8
Example: Setting GTP Message Lengths .............................................. 8
Message-Type Filtering .............................................................................. 9
Example: Permitting and Denying Message Types .............................. 9
Supported Message Types ...................................................................9
Message-Rate Limiting............................................................................. 11
Example: Setting a Rate Limit ........................................................... 11
Sequence Number Validation .................................................................. 12
Example: Enabling Sequence Number Validation.............................. 12
IP Fragmentation..................................................................................... 13
GTP-in-GTP Packet Filtering ..................................................................... 13
Example: Enabling GTP-in-GTP Packet Filtering ................................ 13
Deep Inspection ...................................................................................... 13
Example: Enabling Deep Inspection on the TEID .............................. 13

xl  Table of Contents
 Table of Contents

GTP Information Elements ............................................................................. 14

Access Point Name Filtering .................................................................... 14
Example: Setting an APN and a Selection Mode ................................ 15
IMSI Prefix Filtering ................................................................................. 16
Example: Setting a Combined IMSI Prefix and APN Filter ................. 16
Radio Access Technology ........................................................................ 17
Example: Setting an RAT and APN Filter........................................... 17
Routing Area Identity and User Location Information.............................. 17
Example: Setting an RAI and APN Filter............................................ 17
Example: Setting a ULI and APN Filter .............................................. 18
APN Restriction ....................................................................................... 18
IMEI-SV.................................................................................................... 18
Example: Setting an IMEI-SV and APN Filter ..................................... 18
Protocol and Signaling Requirements ...................................................... 19
Combination Support for IE Filtering ....................................................... 20
Supported R6 Information Elements ....................................................... 21
3GPP R6 IE Removal ............................................................................... 23
Example: R6 Removal....................................................................... 23
GTP Tunnels................................................................................................... 23
GTP Tunnel Limiting ................................................................................ 23
Example: Setting GTP Tunnel Limits ................................................. 23
Stateful Inspection ................................................................................... 24
GTP Tunnel Establishment and Teardown......................................... 24
Inter SGSN Routing Area Update ....................................................... 24
Tunnel Failover for High Availability........................................................ 25
Hanging GTP Tunnel Cleanup .................................................................. 25
Example: Setting the Timeout for GTP Tunnels ................................. 26
SGSN and GGSN Redirection .......................................................................... 26
Overbilling-Attack Prevention ........................................................................ 26
Overbilling-Attack Description .................................................................26
Overbilling-Attack Solution ...................................................................... 28
Example: Configuring the Overbilling Attack Prevention Feature ...... 29
GTP Traffic Monitoring ................................................................................... 31
Traffic Logging......................................................................................... 31
Example: Enabling GTP Packet Logging ............................................ 32
Traffic Counting....................................................................................... 33
Example: Enabling GTP Traffic Counting........................................... 33
Lawful Interception.................................................................................. 34
Example: Enabling Lawful Interception ............................................. 34

Index..........................................................................................................................IX-I

Volume 14:
Dual-Stack Architecture with IPv6
About This Volume vii
Document Audience...................................................................................... viii
Document Conventions................................................................................. viii
Web User Interface Conventions ........................................................... viii
Command Line Interface Conventions ................................................... viii
Naming Conventions and Character Types .............................................. ix
Illustration Conventions ............................................................................ x
Requesting Technical Support .......................................................................... x

Table of Contents  xli

 Concepts & Examples ScreenOS Reference Guide

Self-Help Online Tools and Resources....................................................... xi

Opening a Case with JTAC ........................................................................ xi
Document Feedback ....................................................................................... xi

Chapter 1 Internet Protocol Version 6 Introduction 1

Overview ......................................................................................................... 2
IPv6 Addressing ............................................................................................... 2
Notation .................................................................................................... 2
Prefixes ..................................................................................................... 3
Address Types ........................................................................................... 3
Unicast Addresses ............................................................................... 3
Anycast Addresses .............................................................................. 4
Multicast Addresses............................................................................. 4
IPv6 Headers.................................................................................................... 4
Basic Header ............................................................................................. 4
Extension Headers..................................................................................... 6
IPv6 Packet Handling ....................................................................................... 7
IPv6 Router and Host Modes............................................................................ 8
IPv6 Tunneling Guidelines................................................................................ 8

Chapter 2 IPv6 Configuration 9

Overview ....................................................................................................... 10
Address Autoconfiguration ...................................................................... 10
Extended Unique Identifier ............................................................... 10
Router Advertisement Messages ....................................................... 11
Router Solicitation Messages ............................................................. 11
Prefix Lists ........................................................................................ 11
Neighbor Discovery ................................................................................. 12
Neighbor Cache Table ....................................................................... 12
Neighbor Unreachability Detection ................................................... 13
Neighbor Entry Categories ................................................................ 13
Neighbor Reachability States............................................................. 13
How Reachability State Transitions Occur......................................... 15
Enabling an IPv6 Environment ...................................................................... 17
Enabling IPv6 at the Device Level............................................................ 17
Disabling IPv6 at the Device Level ........................................................... 18
Configuring an IPv6 Host ............................................................................... 18
Binding the IPv6 Interface to a Zone........................................................ 18
Enabling IPv6 Host Mode ........................................................................ 19
Setting an Interface Identifier .................................................................. 19
Configuring Address Autoconfiguration ................................................... 20
Configuring Neighbor Discovery .............................................................. 20
Configuring an IPv6 Router ............................................................................ 21
Binding the IPv6 Interface to a Zone........................................................ 21
Enabling IPv6 Router Mode ..................................................................... 21
Setting an Interface Identifier .................................................................. 22
Setting Address Autoconfiguration........................................................... 22
Outgoing Router Advertisements Flag ............................................... 22
Managed Configuration Flag.............................................................. 23
Other Parameters Configuration Flag ................................................ 23
Disabling Address Autoconfiguration ....................................................... 23
Setting Advertising Time Intervals ........................................................... 24
Advertised Reachable Time Interval .................................................. 24

xlii  Table of Contents

 Table of Contents

Advertised Retransmit Time Interval................................................. 24

Maximum Advertisement Interval..................................................... 25
Minimum Advertisement Interval ..................................................... 25
Advertised Default Router Lifetime ................................................... 25
Advertising Packet Characteristics ........................................................... 26
Link MTU Value................................................................................. 26
Current Hop Limit ............................................................................. 26
Advertising Router Characteristics ........................................................... 27
Link Layer Address Setting................................................................ 27
Advertised Router Preference............................................................ 27
Configuring Neighbor Discovery Parameters ........................................... 27
Neighbor Unreachability Detection ................................................... 28
MAC Session-Caching........................................................................ 28
Static Neighbor Cache Entries ........................................................... 28
Base Reachable Time ........................................................................ 29
Probe Time ....................................................................................... 29
Retransmission Time ........................................................................ 29
Duplicate Address Detection Retry Count.......................................... 30
Viewing IPv6 Interface Parameters ................................................................ 30
Viewing Neighbor Discovery Configurations ............................................ 30
Viewing the Current RA Configuration ..................................................... 31
Configuration Examples ................................................................................. 31
IPv6 Router ............................................................................................. 31
IPv6 Host................................................................................................. 31

Chapter 3 Connection and Network Services 33

Overview ....................................................................................................... 34
Dynamic Host Configuration Protocol Version 6 ............................................ 34
Device-Unique Identification.................................................................... 34
Identity Association Prefix Delegation-Identification................................ 35
Prefix Features ........................................................................................ 35
Server Preference .................................................................................... 36
Configuring a DHCPv6 Server.................................................................. 36
Configuring a DHCPv6 Client................................................................... 38
Viewing DHCPv6 Settings ........................................................................ 39
Configuring Domain Name System Servers....................................................40
Requesting DNS and DNS Search List Information .................................. 41
Setting Proxy DNS Address Splitting ........................................................ 42
Configuring PPPoE ......................................................................................... 44
Setting Fragmentation.................................................................................... 45

Chapter 4 Static and Dynamic Routing 47

Overview ....................................................................................................... 48
Dual Routing Tables................................................................................. 48
Static and Dynamic Routing .................................................................... 49
Upstream and Downstream Prefix Delegation......................................... 49
Static Routing................................................................................................. 50
RIPng Configuration....................................................................................... 51
Creating and Deleting a RIPng Instance................................................... 52
Creating a RIPng Instance .................................................................52
Deleting a RIPng Instance .................................................................52
Enabling and Disabling RIPng on Interfaces ............................................ 53
Enabling RIPng on an Interface......................................................... 53

Table of Contents  xliii

 Concepts & Examples ScreenOS Reference Guide

Disabling RIPng on an Interface ........................................................ 53

Global RIPng Parameters ............................................................................... 54
Advertising the Default Route .................................................................. 54
Rejecting Default Routes.......................................................................... 55
Configuring Trusted Neighbors ................................................................ 55
Redistributing Routes .............................................................................. 56
Protecting Against Flooding by Setting an Update Threshold ................... 57
RIPng Interface Parameters ........................................................................... 58
Route, Interface, and Offset Metrics ........................................................ 58
Access Lists and Route Maps............................................................. 59
Static Route Redistribution................................................................ 59
Configuring Split Horizon with Poison Reverse ........................................ 61
Viewing Routing and RIPng Information ........................................................ 62
Viewing the Routing Table ....................................................................... 62
Viewing the RIPng Database.................................................................... 62
Viewing RIPng Details by Virtual Router .................................................. 63
Viewing RIPng Details by Interface.......................................................... 64
Viewing RIPng Neighbor Information ...................................................... 65
Configuration Examples ................................................................................. 66
Enabling RIPng on Tunnel Interfaces ....................................................... 66
Avoiding Traffic Loops to an ISP Router................................................... 68
Configuring the Customer Premises Equipment ................................ 68
Configuring the Gateway................................................................... 72
Configuring the ISP Router................................................................ 74
Setting a Null Interface Redistribution to OSPF........................................ 75
Redistributing Discovered Routes to OSPF .............................................. 76
Setting Up OSPF-Summary Import .......................................................... 76

Chapter 5 Address Translation 79

Overview ....................................................................................................... 80
Translating Source IP Addresses .............................................................. 81
DIP from IPv6 to IPv4 ....................................................................... 81
DIP from IPv4 to IPv6 ....................................................................... 81
Translating Destination IP Addresses....................................................... 82
MIP from IPv6 to IPv4....................................................................... 82
MIP from IPv4 to IPv6....................................................................... 83
Configuration Examples ................................................................................. 84
IPv6 Hosts to Multiple IPv4 Hosts ............................................................ 84
IPv6 Hosts to a Single IPv4 Host .............................................................. 86
IPv4 Hosts to Multiple IPv6 Hosts ............................................................ 88
IPv4 Hosts to a Single IPv6 Host .............................................................. 89
Translating Addresses for Domain Name System Servers........................ 91

Chapter 6 IPv6 in an IPv4 Environment 95

Overview ....................................................................................................... 95
Configuring Manual Tunneling ....................................................................... 96
Configuring 6to4 Tunneling............................................................................ 99
6to4 Routers..........................................................................................100
6to4 Relay Routers ................................................................................100
Tunnels to Remote Native Hosts............................................................101
Tunnels to Remote 6to4 Hosts...............................................................104

xliv  Table of Contents

 Table of Contents

Chapter 7 IPSec Tunneling 109

Overview .....................................................................................................110
IPSec 6in6 Tunneling ...................................................................................110
IPSec 4in6 Tunneling ...................................................................................113
IPSec 6in4 Tunneling ...................................................................................118
Manual Tunneling with Fragmentation Enabled ...........................................122
IPv6 to IPv6 Route-Based VPN Tunnel ...................................................123
IPv4 to IPv6 Route-Based VPN Tunnel ...................................................125

Chapter 8 IPv6 XAuth User Authentication 129

Overview .....................................................................................................130
RADIUSv6..............................................................................................130
Single Client, Single Server..............................................................130
Multiple Clients, Single Server .........................................................130
Single Client, Multiple Servers .........................................................131
Multiple Hosts, Single Server ...........................................................131
IPSec Access Session Management........................................................132
IPSec Access Session.......................................................................132
Enabling and Disabling IAS Functionality ........................................134
Releasing an IAS Session.................................................................134
Limiting IAS Settings .......................................................................134
Dead Peer Detection..............................................................................135
Configuration Examples ...............................................................................136
XAuth with RADIUS ...............................................................................136
RADIUS with XAuth Route-Based VPN...................................................137
RADIUS with XAuth and Domain Name Stripping .................................141
IP Pool Range Assignment.....................................................................145
RADIUS Retries......................................................................................151
Calling-Station-Id ...................................................................................151
IPSec Access Session .............................................................................152
Dead Peer Detection..............................................................................161

Appendix A Switching A-I

Index..........................................................................................................................IX-I

Table of Contents  xlv

 Concepts & Examples ScreenOS Reference Guide

xlvi  Table of Contents

About the Concepts & Examples
ScreenOS Reference Guide

Juniper Networks security devices integrate the following firewall, virtual private
network (VPN), and traffic-shaping features to provide flexible protection for
security zones when connecting to the Internet:

 Firewall: A firewall screens traffic crossing the boundary between a private LAN
and the public network, such as the Internet.

 Layered Security: The layered security solution is deployed at different

locations to repel attacks. If one layer fails, the next one catches the attack.
Some functions help protect remote locations with site-to-site VPNs. Devices
deployed at the perimeter repel network-based attacks. Another layer, using
Intrusion Detection Prevention (IDP) and Deep Inspection, automatically
detects and prevents attacks from inflicting damages.

Network segmentation, the final security layer (also known as virtualization),

divides the network up into secure domains to protect critical resources from
unauthorized roaming users and network attacks.

 Content Security: Protects users from malicious URLs and provides embedded
antivirus scanning and Web filtering. In addition, works with third-party
products to provide external antivirus scanning, anti-spam, and Web filtering.

 VPN: A VPN provides a secure communications channel between two or more

remote network appliances.

 Integrated Networking Functions: Dynamic routing protocols learn

reachability and advertise dynamically changing network topologies. In
addition, traffic shaping functionality allows administrative monitoring and
control of traffic passing across the Juniper Networks firewall to maintain a
network’s quality-of-service (QoS) level.

 Centralized Management: The Netscreen-Security Manager tool simplifies

configuration, deployment, and management of security devices.

 Redundancy: High availability of interfaces, routing paths, security devices,

and—on high-end Juniper Networks devices—power supplies and fans, to avoid
a single point of failure in any of these areas.

 xlvii
 Concepts & Examples ScreenOS Reference Guide

Figure 1: Key Features in ScreenOS

Untrust Zone
LAN LAN

Internet

Redundancy: The backup device

maintains identical configuration
and sessions as those on the
primary device to assume the place
of the primary device if necessary.
VPNs: Secure communication (Note: Interfaces, routing paths,
tunnels between sites for traffic power supplies, and fans can also
passing through the Internet be redundant.)

Backup Device
Firewall: Screening traffic
between the protected LAN and
the Internet

Integrated Networking Functions: Traffic Shaping: Efficient

Performs routing functions and prioritization of traffic as it
communicates and interacts with traverses the firewall
routing devices in the environment
LAN Dynamic Routing: Dst Use
The routing table
Trust Zone automatically updates by 0.0.0.0/0 1.1.1.250
communicating with 1.1.1.0/24 eth3
dynamic routing peers. 1.2.1.0/24 eth2
10.1.0.0/16 trust-vr
10.2.2.0/24 tunnel.1
10.3.3.0/24 tunnel.2

The ScreenOS system provides all the features needed to set up and manage any
security appliance or system. This document is a reference guide for configuring
and managing a Juniper Networks security device through ScreenOS.

xlviii 
 About the Concepts & Examples ScreenOS Reference Guide

Volume Organization
The Concepts & Examples ScreenOS Reference Guide is a multi-volume manual. The
following information outlines and summarizes the material in each volume:

Volume 1: Overview

 “Table of Contents” contains a master table of contents for all volumes in the
manual.

 “Master Index” is an index of all volumes in the manual.

Volume 2: Fundamentals

 Chapter 1, “ScreenOS Architecture,” presents the fundamental elements of the

architecture in ScreenOS and concludes with a four-part example illustrating an
enterprise-based configuration incorporating most of those elements. In this
and all subsequent chapters, each concept is accompanied by illustrative
examples.

 Chapter 2, “Zones,” explains security zones, tunnel zones, and function zones.

 Chapter 3, “Interfaces,” describes the various physical, logical, and virtual

interfaces on security devices.

 Chapter 4, “Interface Modes,” explains the concepts behind Transparent,

Network Address Translation (NAT), and Route interface operational modes.

 Chapter 5, “Building Blocks for Policies,” discusses the elements used for
creating policies and virtual private networks (VPNs): addresses (including VIP
addresses), services, and DIP pools. It also presents several example
configurations that support the H.323 protocol.

 Chapter 6, “Policies,” explores the components and functions of policies and

offers guidance on their creation and application.

 Chapter 7, “Traffic Shaping,” explains how you can prioritize services and
manage bandwidth at the interface and policy levels.

 Chapter 8, “System Parameters,” presents the concepts behind Domain Name

System (DNS) addressing, using Dynamic Host Configuration Protocol (DHCP)
to assign or relay TCP/IP settings, downloading and uploading system
configurations and software, and setting the system clock.

Volume Organization  xlix

 Concepts & Examples ScreenOS Reference Guide

Volume 3: Administration

 Chapter 1, “Administration,” explains the different means available for

managing a security device both locally and remotely. This chapter also
explains the privileges pertaining to each of the four levels of network
administrators that can be defined.

 Chapter 2, “Monitoring Security Devices,” explains various monitoring methods

and provides guidance in interpreting monitoring output.

Volume 4: Attack Detection and Defense Mechanisms

 Chapter 1, “Protecting a Network,” outlines the basic stages of an attack and

the firewall options available to combat the attacker at each stage.

 Chapter 2, “Reconnaissance Deterrence,” describes the options available for

blocking IP address sweeps, port scans, and attempts to discover the type of
operating system (OS) of a targeted system.

 Chapter 3, “Denial of Service Attack Defenses,” explains firewall, network, and

OS-specific DoS attacks and how ScreenOS mitigates such attacks.

 Chapter 4, “Content Monitoring and Filtering,” describes how to protect users

from malicious uniform resource locators (URLs) and how to configure the
security device to work with third party products to provide antivirus scanning,
anti-spam, and Web filtering.

 Chapter 5, “Deep Inspection,” describes how to configure the Juniper Networks

security device to obtain Deep Inspection (DI) attack object updates, how to
create user-defined attack objects and attack object groups, and how to apply
DI at the policy level.

 Chapter 6, “Intrusion Detection and Prevention,” describes Juniper Networks

Intrusion Detection and Prevention (IDP) technology, which can both detect
and stop attacks when deployed inline to your network. The chapter describes
how to apply IDP at the policy level to drop malicious packets or connections
before the attacks can enter your network.

 Chapter 7, “Suspicious Packet Attributes,” presents several SCREEN options

that protect network resources from potential attacks indicated by unusual IP
and ICMP packet attributes.

 Appendix A, “Contexts for User-Defined Signatures,” provides descriptions of

contexts that you can specify when defining a stateful signature attack object.

l  Volume Organization
 About the Concepts & Examples ScreenOS Reference Guide

Volume 5: Virtual Private Networks

 Chapter 1, “Internet Protocol Security,” provides background information about

IPSec, presents a flow sequence for Phase 1 in IKE negotiations in Aggressive
and Main modes, and concludes with information about IKE and IPSec packet
encapsulation.

 Chapter 2, “Public Key Cryptography,” provides an introduction to public key

cryptography, certificate use, and certificate revocation list (CRL) use within the
context of Public Key Infrastructure (PKI).

 Chapter 3, “Virtual Private Network Guidelines,” offers some useful information

to help in the selection of the available VPN options. It also presents a packet
flow chart to demystify VPN packet processing.

 Chapter 4, “Site-to-Site Virtual Private Networks,” provides extensive examples

of VPN configurations connecting two private networks.

 Chapter 5, “Dialup Virtual Private Networks,” provides extensive examples of

client-to-LAN communication using AutoKey IKE. It also details group IKE ID
and shared IKE ID configurations.

 Chapter 6, “Layer 2 Tunneling Protocol,” explains Layer 2 Tunneling Protocol

(L2TP) and provides configuration examples for L2TP and L2TP-over-IPSec.

 Chapter 7, “Advanced Virtual Private Network Features,” contains information

and examples for the more advanced VPN configurations, such as
NAT-Traversal, VPN monitoring, binding multiple tunnels to a single tunnel
interface, and hub-and-spoke and back-to-back tunnel designs.

 Chapter 8, “AutoConnect-Virtual Private Networks,” describes how ScreenOS

uses Next Hop Resolution Protocol (NHRP) messages to enable security devices
to set up AutoConnect VPNs as needed. The chapter provides an example of a
typical scenario in which AC-VPN might be used.

Volume 6: Voice-over-Internet Protocol

 Chapter 1, “H.323 Application Layer Gateway,” describes the H.323 protocol

and provides examples of typical scenarios.

 Chapter 2, “Session Initiation Protocol Application Layer Gateway,” describes

the Session Initiation Protocol (SIP) and shows how the SIP ALG processes calls
in Route and Network Address Translation (NAT) modes. Examples of typical
scenarios follow a summary of the SIP architecture.

 Chapter 3, “Media Gateway Control Protocol Application Layer Gateway,”

presents an overview of the Media Gateway Control Protocol (MGCP) ALG and
lists the firewall security features of the implementation. Examples of typical
scenarios follow a summary of the MGCP architecture.

 Chapter 4, “Skinny Client Control Protocol Application Layer Gateway,”

presents an overview of the Skinny Client Control Protocol (SCCP) ALG and lists
the firewall security features of the implementation. Examples of typical
scenarios follow a summary of the SCCP architecture.

Volume Organization  li
 Concepts & Examples ScreenOS Reference Guide

 Chapter 5, “Apple iChat Application Layer Gateway,” presents an overview of

the AppleiChat ALG and lists the firewall security features of the
implementation. Examples of typical scenarios follow a summary of the
AppleiChat architecture.

Volume 7: Routing

 Chapter 1, “Static Routing,” describes the ScreenOS routing table, the basic
routing process on the security device, and how to configure static routes on
security devices.

 Chapter 2, “Routing,” explains how to configure virtual routers on security

devices and how to redistribute routing table entries between protocols or
between virtual routers.

 Chapter 3, “Open Shortest Path First,” describes how to configure the OSPF
dynamic routing protocol on security devices.

 Chapter 4, “Routing Information Protocol,” describes how to configure the RIP

dynamic routing protocol on security devices.

 Chapter 5, “Border Gateway Protocol,” describes how to configure the BGP

dynamic routing protocol on security devices.

 Chapter 6, “Policy-Based Routing,” describes policy based routing (PBR). PBR

provides a flexible routing mechanism for data forwarding over networks that
rely on Application Layer support such as for antivirus (AV), deep inspection
(DI), or Web filtering.

 Chapter 7, “Multicast Routing,” introduces basic multicast routing concepts.

 Chapter 8, “Internet Group Management Protocol,” describes how to configure

the Internet Group Management Protocol (IGMP) on security devices.

 Chapter 9, “Protocol Independent Multicast,” explains how to configure

Protocol Independent Multicast - Sparse Mode (PIM-SM) and Protocol
Independent Multicast - Source Specific Multicast (PIM-SSM) on Juniper
Networks security devices.

 Chapter 10, “ICMP Router Discovery Protocol,” explains how to set up an

Internet Control Messages Protocol (ICMP) message exchange between a host
and a router.

Volume 8: Address Translation

 Chapter 1, “Address Translation,” gives an overview of the various translation

options, which are covered in detail in subsequent chapters.

 Chapter 2, “Source Network Address Translation,” describes NAT-src, the

translation of the source IP address in a packet header, with and without Port
Address Translation (PAT).

 Chapter 3, “Destination Network Address Translation,” describes NAT-dst, the

translation of the destination IP address in a packet header, with and without
destination port address mapping. This section also includes information about

lii  Volume Organization

 About the Concepts & Examples ScreenOS Reference Guide

the packet flow when doing NAT-src, routing considerations, and address
shifting.

 Chapter 4, “Mapped and Virtual Addresses,” describes the mapping of one

destination IP address to another based on IP address alone (mapped IP) or
based on destination IP address and destination port number (virtual IP).

Volume 9: User Authentication

 Chapter 1, “Authentication,” details the various authentication methods and

uses that ScreenOS supports.

 Chapter 2, “Authentication Servers,” presents the options of using one of three

possible types of external authentication server—RADIUS, SecurID, TACACS+,
or LDAP—or the internal database and shows how to configure the security
device to work with each type.

 Chapter 3, “Infranet Authentication,” details how the security device is

deployed in a unified access control (UAC) solution. Juniper Networks unified
access control solution (UAC) secures and assures the delivery of applications
and services across an enterprise infranet.

 Chapter 4, “Authentication Users,” explains how to define profiles for

authentication users and how to add them to user groups stored either locally
or on an external RADIUS authentication server.

 Chapter 5, “IKE, XAuth, and L2TP Users,” explains how to define IKE, XAuth,
and L2TP users. Although the XAuth section focuses primarily on using the
security device as an XAuth server, it also includes a subsection on configuring
select security devices to act as an XAuth client.

 Chapter 6, “Extensible Authentication for Wireless and Ethernet Interfaces,”

explains the options available for and examples of how to use the Extensible
Authentication Protocol to provide authentication for Ethernet and wireless
interfaces.

Volume 10: Virtual Systems

 Chapter 1, “Virtual Systems,” discusses virtual systems and profiles, objects,

and administrative tasks.

 Chapter 2, “Traffic Sorting,” explains how ScreenOS sorts traffic.

 Chapter 3, “VLAN-Based Traffic Classification,” describes VLAN-based traffic

classification for virtual systems, and VLAN retagging.

 Chapter 4, “IP-Based Traffic Classification,” explains IP-based traffic

classification for virtual systems.

Volume Organization  liii

 Concepts & Examples ScreenOS Reference Guide

Volume 11: High Availability

 Chapter 1, “NetScreen Redundancy Protocol,” explains how to cable, configure,

and manage Juniper Networks security devices in a redundant group to provide
high availability (HA) using the NetScreen Redundancy Protocol (NSRP).

 Chapter 2, “Interface Redundancy and Failover,” describes the various ways in

which Juniper Networks security devices provide interface redundancy.

Volume 12: WAN, DSL, Dial, and Wireless

 Chapter 1, “Wide Area Networks,” describes how to configure a wide area

network (WAN).

 Chapter 2, “Digital Subscriber Line,” describes the asymmetric digital

subscriber line (ADSL) and G.symmetrical digital subscriber line (G.SHDSL)
interfaces.

 Chapter 3, “ISP Failover and Dial Recovery,” describes how to set priority and
define conditions for ISP failover and how to configure a dialup recovery
solution.

 Chapter 4, “Wireless Local Area Network,” describes the wireless interfaces on

Juniper Networks wireless devices and provides example configurations.

 Appendix A, “Wireless Information,” lists available channels, frequencies, and

regulatory domains and lists the channels that are available on wireless devices
for each country.

Volume 13: General Packet Radio Service

 Chapter 1, “GPRS,” describes the GPRS Tunneling Protocol (GTP) features in

ScreenOS and demonstrates how to configure GTP functionality on a Juniper
Networks security device.

Volume 14: Dual-Stack Architecture with IPv6

 Chapter 1, “Internet Protocol Version 6 Introduction,” explains IPv6 headers,

concepts, and tunneling guidelines.

 Chapter 2, “IPv6 Configuration,” explains how to configure an interface for

operation as an IPv6 router or host.

 Chapter 3, “Connection and Network Services,” explains how to configure

Dynamic Host Configuration Protocol version 6 (DHCPv6), Domain Name
System (DNS), Point-to-Point Protocol over Ethernet (PPPoE), and
fragmentation.

 Chapter 4, “Static and Dynamic Routing,” explains how to set up static and
dynamic routing. This chapter explains ScreenOS support for Routing
Information Protocol-Next Generation (RIPng).

 Chapter 5, “Address Translation,” explains how to use Network Address

Translation (NAT) with dynamic IP (DIP) and mapped-IP (MIP) addresses to
traverse IPv4/IPv6 boundaries.

liv  Volume Organization

 About the Concepts & Examples ScreenOS Reference Guide

 Chapter 6, “IPv6 in an IPv4 Environment,” explains manual and dynamic

tunneling.

 Chapter 7, “IPSec Tunneling,” explains how to configure IPSec tunneling to

connect dissimilar hosts.

 Chapter 8, “IPv6 XAuth User Authentication,” explains how to configure

Remote Authentication Dial In User Service (RADIUS) and IPSec Access Session
(IAS) management.

 Appendix A, “Switching,” lists options for using the security device as a switch
to pass IPv6 traffic.

Document Conventions
This document uses the conventions described in the following sections:

 “Web User Interface Conventions” on page lv

 “Command Line Interface Conventions” on page lvi

 “Naming Conventions and Character Types” on page lvi

 “Illustration Conventions” on page lvii

Web User Interface Conventions

The Web user interface (WebUI) contains a navigational path and configuration
settings. To enter configuration settings, begin by clicking a menu item in the
navigation tree on the left side of the screen. As you proceed, your navigation path
appears at the top of the screen, with each page separated by angle brackets.

The following example shows the WebUI path and parameters for defining an
address:

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: addr_1

IP Address/Domain Name:
IP/Netmask: (select), 10.2.2.5/32
Zone: Untrust

To open Online Help for configuration settings, click the question mark (?) in the
upper left of the screen.

The navigation tree also provides a Help > Config Guide configuration page to help
you configure security policies and Internet Protocol Security (IPSec). Select an
option from the list, and follow the instructions on the page. Click the ? character in
the upper left for Online Help on the Config Guide.

Document Conventions  lv
 Concepts & Examples ScreenOS Reference Guide

Command Line Interface Conventions

The following conventions are used to present the syntax of command line
interface (CLI) commands in text and examples.

In text, commands are in boldface type and variables are in italic type.

In examples:

 Variables are in italic type.

 Anything inside square brackets [ ] is optional.

 Anything inside braces { } is required.

 If there is more than one choice, each choice is separated by a pipe ( | ). For
example, the following command means “set the management options for the
ethernet1, the ethernet2, or the ethernet3 interface”:

set interface { ethernet1 | ethernet2 | ethernet3 } manage

NOTE: When entering a keyword, you only have to type enough letters to identify the
word uniquely. Typing set adm u whee j12fmt54 will enter the command set
admin user wheezer j12fmt54. However, all the commands documented in this
guide are presented in their entirety.

Naming Conventions and Character Types

ScreenOS employs the following conventions regarding the names of objects—such
as addresses, admin users, auth servers, IKE gateways, virtual systems, VPN
tunnels, and zones—defined in ScreenOS configurations:

 If a name string includes one or more spaces, the entire string must be
enclosed within double quotes; for example:

set address trust “local LAN” 10.1.1.0/24

 Any leading spaces or trailing text within a set of double quotes are trimmed;
for example, “ local LAN ” becomes “local LAN”.

 Multiple consecutive spaces are treated as a single space.

 Name strings are case-sensitive, although many CLI keywords are

case-insensitive. For example, “local LAN” is different from “local lan”.

ScreenOS supports the following character types:

 Single-byte character sets (SBCS) and multiple-byte character sets (MBCS).

Examples of SBCS are ASCII, European, and Hebrew. Examples of MBCS—also
referred to as double-byte character sets (DBCS)—are Chinese, Korean, and
Japanese.

 ASCII characters from 32 (0x20 in hexadecimals) to 255 (0xff), except double

quotes ( “ ), which have special significance as an indicator of the beginning or
end of a name string that includes spaces.

lvi  Document Conventions

 About the Concepts & Examples ScreenOS Reference Guide

NOTE: A console connection only supports SBCS. The WebUI supports both SBCS and
MBCS, depending on the character sets that your browser supports.

Illustration Conventions
Figure 2 shows the basic set of images used in illustrations throughout this manual.

Figure 2: Images in Illustrations

Autonomous System Local Area Network (LAN)
or with a Single Subnet
Virtual Routing Domain or
Security Zone

Dynamic IP (DIP) Pool

Internet

Policy Engine
Security Zone Interfaces:
White = Protected Zone Interface
(example = Trust Zone)
Black = Outside Zone Interface
(example = Untrust Zone)
Generic Network Device

Tunnel Interface

Server

VPN Tunnel

Router

Juniper Networks
Switch Security Devices

Hub

Document Conventions  lvii

 Concepts & Examples ScreenOS Reference Guide

Requesting Technical Support

Technical product support is available through the Juniper Networks Technical
Assistance Center (JTAC). If you are a customer with an active J-Care or JNASC
support contract, or are covered under warranty, and need postsales technical
support, you can access our tools and resources online or open a case with JTAC.

 JTAC policies—For a complete understanding of our JTAC procedures and

policies, review the JTAC User Guide located at
http://www.juniper.net/customers/support/downloads/710059.pdf.

 Product warranties—For product warranty information, visit

http://www.juniper.net/support/warranty/.

 JTAC hours of operation—The JTAC centers have resources available 24 hours a

day, 7 days a week, 365 days a year.

Self-Help Online Tools and Resources

For quick and easy problem resolution, Juniper Networks has designed an online
self-service portal called the Customer Support Center (CSC) that provides you with
the following features:

 Find CSC offerings—http://www.juniper.net/customers/support/

 Find product documentation—http://www.juniper.net/techpubs/

 Find solutions and answer questions using our Knowledge Base—

http://kb.juniper.net/

 Download the latest versions of software and review your release notes—
http://www.juniper.net/customers/csc/software/

 Search technical bulletins for relevant hardware and software notifications—

http://www.juniper.net/alerts/

 Join and participate in the Juniper Networks Community Forum—

http://www.juniper.net/company/communities/

 Open a case online in the CSC Case Manager—

http://www.juniper.net/customers/cm/

 To verify service entitlement by product serial number, use our Serial Number
Entitlement (SNE) Tool—
https://tools.juniper.net/SerialNumberEntitlementSearch/

lviii  Requesting Technical Support

 About the Concepts & Examples ScreenOS Reference Guide

Opening a Case with JTAC

You can open a case with JTAC on the Web or by telephone.

 Use the Case Manager tool in the CSC at http://www.juniper.net/customers/cm/.

 Call 1-888-314-JTAC (1-888-314-5822—toll free in USA, Canada, and Mexico).

For international or direct-dial options in countries without toll-free numbers, visit

us at http://www.juniper.net/customers/support/requesting-support/.

Document Feedback
If you find any errors or omissions in this document, contact Juniper Networks at
[email protected].

Document Feedback  lix

 Concepts & Examples ScreenOS Reference Guide

lx  Document Feedback
Master Index
Numerics removing ....................................................... 2-108
3DES ............................................................................. 5-6 entries ................................................................. 2-104
3DES encryption .................................................... 14-119 group entries, editing ........................................ 2-108
4in6 tunneling groups ................................................................. 2-105
basic setup ....................................................... 14-113 See also addresses
definition .......................................................... 14-113 address groups ............................................. 2-105, 2-166
6in4 tunneling ........................................................ 14-109 creating ............................................................... 2-107
basic setup ....................................................... 14-118 editing ................................................................. 2-108
over IPv4 WAN ................................................ 14-118 entries, removing .............................................. 2-108
6over4 tunneling options ................................................................ 2-106
addresses, handling .......................................... 14-96 address sweep .............................................................. 4-8
definition ............................................................ 14-95 address translation
manual tunneling .............................................. 14-96 See NAT, NAT-dst, and NAT-src
types ................................................................... 14-95 addresses
when to use ....................................................... 14-95 address book entries .......................... 2-104 to 2-108
6to4 autoconfiguration .............................................. 14-10
addresses .................................... 14-8, 14-99, 14-104 defined ................................................................ 2-166
hosts ................................................................. 14-104 in policies ........................................................... 2-166
relay routers ..........................................14-99, 14-100 IP, host and network IDs .................................... 2-47
routers ...................................................14-99, 14-100 IP, lifetime for XAuth users ................................ 9-72
tunneling .................................................14-95, 14-99 L2TP assignments ............................................... 9-86
tunneling, description ....................................... 14-99 link-local ............................................................. 14-11
MAC .............................................14-12, 14-20, 14-28
A negation .............................................................. 2-187
AAL5 netmasks ............................................................ 2-103
encapsulations ................................................... 12-76 private ................................................................... 2-48
multiplexing ....................................................... 12-84 public .................................................................... 2-47
Access Concentrator (AC)........................................ 14-44 splitting ............................................................... 14-42
access control list wildcards ................................................ 2-103, 2-166
See ACL addresses, handling
access lists 4in6 tunneling ................................................. 14-114
for routes .............................................................. 7-40 6to4 tunneling ................................................. 14-101
IGMP ................................................................... 7-156 destination address translation ....................... 14-82
multicast routing ............................................... 7-149 DIP, from IPv4 to IPv6...................................... 14-82
PIM-SM ............................................................... 7-198 DIP, from IPv6 to IPv4...................................... 14-81
Access Point Name IPv4 hosts to a single IPv6 host ..................... 14-111
See APN IPv6 hosts to multiple IPv4 hosts .................... 14-85
access policies manual tunneling .............................................. 14-96
See policies addresses, overlapping ranges ................... 10-65, 10-76
ACL .......................................................................... 12-143 addresses, XAuth
ActiveX controls, blocking ...................................... 4-169 assignments ......................................................... 9-70
address books authentication, and ............................................. 9-81
addresses timeout ................................................................. 9-72
adding............................................................ 2-104 admin users .................................................................. 9-2
modifying ...................................................... 2-105 authentication, prioritizing ................................. 9-32

Master Index  IX-I

 Concepts & Examples ScreenOS Reference Guide

privileges from RADIUS ....................................... 9-2 asset recovery log ...................................................... 3-68
server support ..................................................... 9-14 Asynchronous Transfer Mode
timeout ................................................................. 9-18 See ATM
administration ATM ........................................................................... 12-77
CLI ........................................................................... 3-9 ATM Adaptation Layer 5 .......................................... 12-84
restricting ............................................................. 3-42 attack actions .............................................4-140 to 4-148
WebUI .................................................................... 3-2 close .................................................................... 4-140
administration, vsys .................................................. 10-7 close client ......................................................... 4-140
administrative traffic ................................................. 3-29 close server ........................................................ 4-140
admins ........................................................................ 10-2 drop .................................................................... 4-140
changing passwords ..................................10-4, 10-7 drop packet ........................................................ 4-140
types ..................................................................... 10-4 ignore.................................................................. 4-140
ADSL none .................................................................... 4-141
configuring interface ........................................ 12-84 attack database updates
overview ............................................................. 12-83 downloading ...................................................... 4-232
VPN tunnel ....................................................... 12-107 overview ............................................................. 4-232
Advanced Encryption Standard (AES) ....................... 5-6 attack object database ..............................4-122 to 4-129
AES128 encryption ............................................... 14-119 auto notification and manual update.............. 4-126
agents, zombie ..................................................4-27, 4-29 automatic update .............................................. 4-125
aggregate interfaces .......................................2-37, 11-51 changing the default URL ................................. 4-128
aggressive aging ............................................4-31 to 4-36 immediate update ............................................. 4-124
Aggressive mode ....................................................... 5-10 manual update........................................4-127, 4-128
AH ..........................................................................5-3, 5-5 attack object groups ................................................ 4-136
AIM ............................................................................ 4-133 applied in policies ............................................. 4-130
alarms changing severity .............................................. 4-136
email alert ............................................................ 3-68 Help URLs .......................................................... 4-134
NetScreen-Security Manager, reporting to ....... 3-25 logging ................................................................ 4-151
thresholds .................................................2-173, 3-69 severity levels .................................................... 4-136
traffic ........................................................3-68 to 3-71 attack objects ................................. 4-119, 4-130 to 4-135
ALGs ...................................................................4-59, 6-19 brute force...............................................4-148, 4-149
Apple iChat ........................................................ 6-111 custom ................................................................ 4-214
for custom services ........................................... 2-168 disabling ............................................................. 4-139
MS RPC ............................................................... 2-127 IDP ...................................................................... 4-185
RTSP ................................................................... 2-129 negation ............................................................. 4-164
SIP ......................................................................... 6-15 overview ............................................................. 4-211
SIP NAT ................................................................ 6-25 protocol anomalies ................................4-135, 4-163
alternate gatekeepers .................................................. 6-2 protocol anomaly .............................................. 4-212
America Online Instant Messaging re-enabling ......................................................... 4-139
See AIM signature............................................................. 4-212
anti-replay checking .........................................5-62, 5-69 stateful signatures ............................................. 4-134
APN stream signatures .............................................. 4-135
filtering .................................................13-14 to 13-15 TCP stream signatures ...................................... 4-161
selection mode .................................................. 13-15 attack protection
Apple iChat ALG....................................................... 6-111 policy level ............................................................. 4-4
call-answer-time ................................................ 6-112 security zone level ................................................ 4-4
reassembly ......................................................... 6-113 attacks
Application Layer Gateways common objectives ............................................... 4-1
See ALGs detection and defense options ..................4-2 to 4-4
application options, in policies .............................. 2-168 DOS ...........................................................4-27 to 4-56
ARP ..................................................................2-82, 11-60 ICMP
broadcasts .......................................................... 11-30 floods ............................................................... 4-50
gratuitous ............................................................. 2-45 fragments ...................................................... 4-240
lookup ................................................................. 11-39 IP packet fragments .......................................... 4-244
ARP, ingress IP address............................................. 2-84 land ....................................................................... 4-52

IX-II  Master Index

 Master Index

large ICMP packets............................................ 4-241 pre-policy.............................................................. 9-49

Overbilling............................................13-26 to 13-28 auth users, run-time
Ping of Death ....................................................... 4-53 auth process ......................................................... 9-48
Replay ................................................................... 5-12 authentication ...................................................... 9-48
session table floods ....................................4-17, 4-28 user groups, external .......................................... 9-55
stages of ................................................................. 4-2 user groups, local ................................................ 9-52
SYN floods ................................................4-38 to 4-43 users, external ..................................................... 9-54
SYN fragments................................................... 4-245 users, local ........................................................... 9-51
teardrop ................................................................ 4-54 auth users, WebAuth .................................................. 9-49
UDP floods ........................................................... 4-51 user groups, external .......................................... 9-61
unknown MAC addresses ................................... 4-43 user groups, local ................................................ 9-60
unknown protocols ........................................... 4-243 with SSL (user groups, external) ........................ 9-63
WinNuke .............................................................. 4-55 authentication .............................14-110, 14-113, 14-136
auth servers ....................................................9-13 to 9-40 algorithms ........................5-6, 5-61, 5-64, 5-67, 5-71
addresses ............................................................. 9-18 Allow Any ........................................................... 2-172
authentication process ....................................... 9-17 NSRP ................................................................... 11-30
backup .................................................................. 9-18 NSRP-Lite ............................................................ 11-16
default ..........................................................9-39, 9-40 policies ................................................................ 2-170
defining ....................................................9-33 to 9-40 prioritizing ............................................................ 9-32
external ................................................................ 9-17 users .................................................................... 2-171
ID number ............................................................ 9-18 Authentication and Encryption
idle timeout .......................................................... 9-18 Wi-Fi Protected Access
LDAP .........................................................9-29 to 9-30 See WPA
maximum number .............................................. 9-14 Wireless Equivalent Privacy
objects .................................................................. 9-18 See WEP
SecurID ................................................................. 9-27 authentication and encryption
SecurID, defining................................................. 9-35 multiple WEP keys .......................................... 12-133
TACACS+, defining ............................................ 9-38 RADIUS server, using ...................................... 12-134
types ..................................................................... 9-18 Authentication Header (AH) ....................................... 5-5
XAuth queries ...................................................... 9-71 authentication servers
auth servers, RADIUS ....................................9-19 to 9-22 See auth servers
defining ................................................................ 9-33 authentication users
user-type support ................................................ 9-20 See auth users
auth users .......................................................9-47 to 9-66 autoconfiguration
admin ..................................................................... 9-2 address autoconfiguration ................................ 14-10
groups ..........................................................9-47, 9-50 router advertisement messages ...................... 14-11
IKE ...............................................................9-14, 9-67 stateless .............................................................. 14-10
in policies ............................................................. 9-48 AutoKey IKE VPN ......................................3-43, 3-79, 5-7
L2TP ...................................................................... 9-86 AutoKey IKE VPN management ................................. 5-7
local database ..........................................9-15 to 9-16 Autonomous System (AS) numbers ....................... 7-105
logins, with different ............................................. 9-5 AV objects, timeout .................................................... 4-89
manual key .......................................................... 9-14 AV scanning
multiple-type .......................................................... 9-4 AV resources per client ....................................... 4-83
pre-policy auth ................................................... 2-172 content
run-time authentication .................................... 2-171 size ................................................................... 4-85
server support...................................................... 9-14 decompression .................................................... 4-90
timeout ................................................................. 9-18 fail-mode .............................................................. 4-84
types and applications ................................9-1 to 9-5 file extensions ...................................................... 4-91
user types ............................................................. 9-13 FTP ........................................................................ 4-72
WebAuth ...................................................2-172, 9-14 HTTP ..................................................................... 4-74
XAuth .................................................................... 9-70 HTTP keep-alive ................................................... 4-85
auth users, authentication HTTP trickling ...................................................... 4-86
auth servers, with ................................................ 9-14 IMAP ..................................................................... 4-76
point of ................................................................... 9-1 message drop....................................................... 4-85

Master Index  IX-III

 Concepts & Examples ScreenOS Reference Guide

MIME .................................................................... 4-75 suppressing ........................................................ 7-124

POP3..................................................................... 4-76 weight, setting ................................................... 7-116
SMTP .................................................................... 4-77 BGP routes, aggregate
subscription ......................................................... 4-80 aggregation ........................................................ 7-123
using pattern files in ........................................... 4-85 AS-Path in........................................................... 7-125
AS-Set in ............................................................. 7-123
B attributes of ........................................................ 7-126
back store ................................................................... 3-94 BGP, configuring
backdoor rulebase peer groups ........................................................ 7-107
adding to Security Policy.................................. 4-207 peers ................................................................... 7-107
overview ............................................................. 4-207 steps .................................................................... 7-104
backdoor rules ...........................................4-207 to 4-211 BGP, enabling
configuring actions ........................................... 4-209 in VRs ................................................................. 7-105
configuring Match columns ............................. 4-208 on interfaces ...................................................... 7-106
configuring operation ....................................... 4-209 bit stream ................................................................... 3-93
configuring services .......................................... 4-209 black holes, traffic ................................................... 11-65
configuring severity .......................................... 4-211 blacklists, contents and creating.............................. 4-33
configuring source and destination ................ 4-209 bridge groups
configuring targets ............................................ 4-211 logical interface ................................................... 2-37
configuring zones .............................................. 4-208 unbinding ............................................................. 2-46
bandwidth ................................................................ 2-174 browser requirements ................................................. 3-2
guaranteed .................................. 2-174, 2-193, 2-199 brute force attacks ................................................... 4-148
managing ........................................................... 2-193 bypass-auth ................................................................ 9-71
maximum ................................... 2-174, 2-193, 2-199
maximum, unlimited........................................ 2-194 C
priority CA certificates ...................................................5-32, 5-35
default ........................................................... 2-198 cables, serial ............................................................... 3-19
levels.............................................................. 2-198 call-answer-time, Apple iChat ALG ........................ 6-112
queues ........................................................... 2-197 C-bit parity mode..................................................... 12-13
banners ....................................................................... 9-10 Certificate Revocation List ...............................5-33, 5-44
BGP loading .................................................................. 5-33
AS-path access list ............................................. 7-114 certificates .................................................................... 5-7
communities ...................................................... 7-122 CA.................................................................5-32, 5-35
confederations ................................................... 7-120 loading .................................................................. 5-38
configurations, security .................................... 7-111 loading CRL .......................................................... 5-33
configurations, verifying .................................. 7-110 local....................................................................... 5-35
external .............................................................. 7-103 requesting ............................................................ 5-36
internal ............................................................... 7-103 revocation ...................................................5-35, 5-44
load-balancing ..................................................... 7-36 via email ............................................................... 5-35
message types ................................................... 7-102 Challenge Handshake Authentication Protocol .... 12-36
neighbors, authenticating ................................ 7-111 See CHAP
parameters ......................................................... 7-113 channels, finding available ................................... 12-143
path attributes ................................................... 7-103 CHAP ........................................ 5-218, 5-221, 9-81, 12-36
protocol overview ............................................. 7-102 Chargen .................................................................... 4-131
regular expressions ........................................... 7-114 CLI .......................................................... 3-9, 14-28, 14-30
virtual router, creating an instance in ............ 7-105 set arp always-on-dest ...............................2-74, 2-77
BGP routes set vip multi -port ................................................ 8-81
adding................................................................. 7-115 clock, system
aggregation ........................................................ 7-123 See system clock
attributes, setting .............................................. 7-117 cluster names, NSRP ....................................11-12, 11-29
conditional advertisement ............................... 7-116 clusters ...........................................................11-12, 11-35
default, rejecting ............................................... 7-112 clusters, Unified Access Control ............................... 9-41
redistributing ..................................................... 7-114 Coldstart Synchronization ...................................... 11-21
reflection ............................................................ 7-118 command line interface

IX-IV  Master Index

 Master Index

See CLI key methods ........................................................ 5-59

common names ......................................................... 9-30 PFS .............................................................. 5-63, 5-69
CompactFlash ............................................................ 3-56 Phase 1 modes .......................................... 5-59, 5-66
compatibility-mode option, T3 interfaces ............ 12-20 site-to-site ................................................ 5-58 to 5-65
configuration site-to-site VPN recommendations .................... 5-65
ADSL 2/2+ PIM ................................................. 12-84 Transport mode ................................................... 5-70
full-mesh............................................................. 11-63 Tunnel mode ........................................................ 5-70
virtual circuits .................................................... 12-81 CSU compatibility, T3 interfaces ............................ 12-20
VPI/VCI pair........................................................ 12-81 custom services........................................................ 2-120
configuration examples custom services, in root and vsys .......................... 2-121
6to4 host, tunneling to a ................................ 14-104 customer premises equipment (CPE) ...... 14-37, 14-132
access lists and route maps ............................. 14-59
DNS server information, requesting ............... 14-41 D
IPv4 tunneling over IPv6 (autokey IKE) ....... 14-115 Data Encryption Standard (DES) ................................ 5-6
IPv6 data messages ............................................................ 11-8
requests to multiple IPv4 hosts .................. 14-85 databases, local ............................................. 9-15 to 9-16
to an IPv4 network over IPv4 ................... 14-111 DDNS servers ........................................................... 2-220
tunneling over IPv4 (autokey IKE) ........... 14-119 DDO
manual tunneling .............................................. 14-97 servers ................................................................ 2-220
native host, tunneling to ................................ 14-101 servers, setting up DDNS for ........................... 2-222
PPPoE instance, configuring ............................ 14-44 DDoS ........................................................................... 4-27
prefixes, delegating ................................14-36, 14-38 decompression ........................................................... 4-90
static route redistribution ................................. 14-59 deep inspection (DI) ................................. 4-137 to 4-161
configuration settings, browser requirements.......... 3-2 attack actions ...................................... 4-140 to 4-148
connection policy for Infranet Enforcer, configuring..... attack object database ....................... 4-122 to 4-129
9-42 attack object groups .......................................... 4-136
console ........................................................................ 3-56 attack object negation....................................... 4-164
containers ................................................................. 5-196 attack objects ..................................................... 4-119
content changing severity .............................................. 4-136
filtering ...................................................4-57 to 4-115 context ..................................................................... 4-I
content size ................................................................ 4-85 custom attack objects ....................................... 4-157
control messages ..................................................... 11-14 custom services .................................. 4-153 to 4-157
HA ......................................................................... 11-7 custom signatures .............................. 4-158 to 4-161
HA physical link heartbeats ............................... 11-7 disabling attack objects .................................... 4-139
RTO heartbeats.................................................... 11-7 license keys ........................................................ 4-120
cookies, SYN............................................................... 4-48 logging attack object groups ............................ 4-151
country codes and channels, regulatory domain for ..... overview ............................................................. 4-118
12-141 pattern files, using ............................................. 4-120
CPE routers ............................................................... 2-220 protocol anomalies ............................................ 4-135
CPU protection and utilization ................................. 4-33 reenabling attack objects.................................. 4-139
CREATE ....................................................................... 5-11 regular expressions ............................ 4-158 to 4-159
CRL signature packs .................................................. 4-122
See Certificate Revocation List stateful signatures ............................................. 4-134
cryptographic options ...................................5-58 to 5-71 stream signatures .............................................. 4-135
anti-replay checking ...................................5-62, 5-69 demand circuits, RIP ................................................. 7-93
authentication algorithms ..... 5-61, 5-64, 5-67, 5-71 denial of service
authentication types ..................................5-60, 5-66 See DoS
certificate bit lengths .................................5-60, 5-66 deny messages ......................................................... 4-103
dialup ........................................................5-65 to 5-71 deny messages, creating and editing .................... 4-103
dialup VPN recommendations ........................... 5-71 DES ................................................................................ 5-6
encryption algorithms .................. 5-61 to 5-67, 5-71 destination gateway................................................. 14-96
ESP ...............................................................5-64, 5-70 device failover .......................................................... 11-63
IKE ID ................................ 5-61 to 5-62, 5-67 to 5-68 devices, resetting to factory defaults ....................... 3-41
IPSec protocols ...........................................5-63, 5-70 Device-Unique Identification (DUID) ..................... 14-34

Master Index  IX-V

 Concepts & Examples ScreenOS Reference Guide

DH domain lookups ................................................. 14-42

IKEv2 .................................................................... 5-18 IPv4 or IPv6 addresses ..................................... 14-40
DHCP ........................................2-96, 2-100, 2-243, 4-131 partial domain names ...................................... 14-34
client ................................................................... 2-226 proxy .................................................................. 14-42
HA ....................................................................... 2-232 refresh ................................................................ 14-40
PXE scenario...................................................... 2-237 search list ........................................................... 14-41
relay agent ......................................................... 2-226 servers .............................................................. 14-130
server .................................................................. 2-226 servers, tunneling to ......................................... 14-42
DHCPv6 Domain Name System (DNS) addresses
client and server................................................ 14-34 splitting ....................................................14-42, 14-43
delegated prefixes ............................................. 14-36 translating .......................................................... 14-91
purposes ............................................................. 14-33 DoS
TLA and SLA ...................................................... 14-35 firewall ......................................................4-28 to 4-37
DI pattern files ......................................................... 4-129 network ....................................................4-38 to 4-52
dictionary file, RADIUS ............................................... 9-2 OS-specific ...............................................4-53 to 4-56
Diffie-Hellman............................................................ 5-10 session table floods ....................................4-17, 4-28
Diffie-Hellman groups ........................................... 14-119 DoS attacks .....................................................4-27 to 4-56
DiffServ .............................................. 2-174, 2-200, 2-214 drop-no-rpf-route ....................................................... 4-19
See also DSCP marking DSCP marking ................................... 2-194, 2-200, 2-214
digital signature ......................................................... 5-30 dual-stack architecture ............................................ 14-48
DIP ...........................................2-98, 2-141 to 2-145, 3-95 networks, dissimilar.......................................... 14-48
fix-port ................................................................ 2-144 routing tables ..................................................... 14-48
groups ...................................................2-154 to 2-156 WAN backbones, dissimilar ............................. 14-48
PAT ..........................................................2-142, 2-143 dual-stack environment .......................................... 2-130
pools ................................................................... 2-170 Duplicate Address Detection (DAD)
pools, modifying ............................................... 2-144 function .............................................................. 14-30
DIP pools Retry Count ........................................................ 14-30
address considerations ....................................... 8-14 dynamic DNS servers .............................................. 2-220
extended interfaces .......................................... 5-150 dynamic IP ............................................................... 14-80
NAT for VPNs..................................................... 5-150 See DIP
NAT-src ................................................................... 8-1 dynamic packet filtering ............................................. 4-3
size ........................................................................ 8-14
Discard ...................................................................... 4-131 E
Discrete multitone EAP messages ............................................................ 5-25
See DMT Echo .......................................................................... 4-131
dissimilar IP stacks .......................................14-82, 14-84 ECMP..................................................................7-36, 7-58
distinguished name (DN) ........................................ 5-193 election support ....................................................... 11-65
distinguished names ................................................. 9-30 email alert notification .....................................3-71, 3-73
DMT ...............................................................12-79, 12-80 Encapsulating Security Payload
DN ............................................................................. 5-193 See ESP
DNS ................................................................2-217, 4-131 encapsulation .............................. 14-100, 14-109, 14-115
addresses, splitting ........................................... 2-224 encryption .................................................14-110, 14-113
dynamic ............................................................. 2-220 3DES ................................................................. 14-119
lookups ............................................................... 2-218 AES128 ............................................................. 14-119
lookups, domain ............................................... 2-223 algorithms .............................. 5-6, 5-61, 5-64 to 5-71
servers ................................................................ 2-244 NSRP ................................................................... 11-30
servers, tunneling to ......................................... 2-223 NSRP-Lite ........................................................... 11-16
status table ......................................................... 2-219 SecurID ................................................................. 9-28
DNS, L2TP settings .................................................. 5-221 endpoint host state mode
Domain Name System Base Reachable Time ........................................ 14-29
See DNS Duplicate Address Detection (DAD) ................ 14-30
Domain Name System (DNS) Probe Forever state ........................................... 14-29
DHCP client host ............................................... 14-41 Probe Time ........................................................ 14-29
DHCPv6 search list ........................................... 14-34 Reachable Time ................................................. 14-29

IX-VI  Master Index

 Master Index

Retransmission Time ........................................ 14-29 HA ......................................................................... 2-38

Stale mode ......................................................... 14-29 management ........................................................ 2-38
ESP ................................................................. 5-3, 5-5, 5-6
authenticate only................................................. 5-64 G
encrypt and authenticate ..........................5-64, 5-70 G-ARP .......................................................................... 2-45
encrypt only ......................................................... 5-64 Gatekeeper Confirm (GCF) messages ........................ 6-2
evasion ............................................................4-15 to 4-25 Generic Routing Encapsulation (GRE) ................... 7-149
event log ..................................................................... 3-57 Gi interface ................................................................. 13-2
exchanges global unicast addresses ........................... 14-99, 14-118
CHILD_SA ............................................................. 5-11 global zones ................................................................ 8-82
informational ....................................................... 5-19 Gn interface ................................................................ 13-2
initial ..................................................................... 5-17 Gopher ...................................................................... 4-131
exe files, blocking .................................................... 4-169 Gp interface ................................................................ 13-2
exempt rulebase GPRS Tunneling Protocol (GTP)
adding to security policies ............................... 4-203 See GTP
overview ............................................................. 4-202 graphs, historical ...................................................... 2-173
exempt rules ..............................................4-202 to 4-206 group expressions ............................................. 9-5 to 9-9
exempt rules, configuring ....................................... 4-203 operators ................................................................ 9-5
attacks ................................................................ 4-205 server support ...................................................... 9-14
from the Log Viewer ......................................... 4-206 users ........................................................................ 9-5
Match columns .................................................. 4-204 group IKE ID
source and destination ..................................... 4-204 certificates ........................................... 5-193 to 5-202
targets ................................................................. 4-205 preshared keys ................................... 5-202 to 5-208
zones................................................................... 4-204 groups
exploits addresses ............................................................ 2-105
See attacks services ............................................................... 2-139
extended channels, setting for WLAN ................. 12-141 VLAN ................................................................... 11-44
Extensible Authentication Protocol passthrough ... 5-25 VSD ..................................................................... 11-44
GTP
F Access Point Name (APN) filtering .................. 13-14
factory defaults, resetting devices to ....................... 3-41 GTP-in-GTP packet filtering .............................. 13-13
fail-mode ..................................................................... 4-84 IMSI prefix filtering ........................................... 13-16
failover ........................................................11-49 to 11-92 inspection objects................................... 13-4 to 13-6
Active/Active ...................................................... 11-13 IP fragmentation................................................ 13-13
Active/Passive .................................................... 11-13 packet sanity check ............................................. 13-7
devices ................................................................ 11-63 policy-based ......................................................... 13-4
dual Untrust interfaces ..........................11-52, 11-55 protocol ................................................................ 13-2
object monitoring .............................................. 11-57 standards .............................................................. 13-8
virtual systems................................................... 11-63 stateful inspection ............................................. 13-24
VSD groups ........................................................ 11-62 tunnel timeout ................................................... 13-26
fallback priorities, assigning ..................................... 9-32 GTP messages........................................................... 13-10
file extensions, AV scanning ..................................... 4-91 length, filtering by ............................................... 13-8
filter source route ...................................................... 3-96 rate, limiting by ................................................. 13-11
FIN scans .................................................................... 4-15 type, filtering by .................................................. 13-9
FIN without ACK flag ................................................. 4-13 types ...................................................... 13-9 to 13-10
Finger ........................................................................ 4-131 versions 0 and 1 ................................................ 13-10
floods GTP traffic
ICMP ..................................................................... 4-50 counting .............................................................. 13-33
session table ........................................................ 4-28 logging ................................................................ 13-31
SYN ................................................. 4-38 to 4-43, 4-48 GTP tunnels
UDP ....................................................................... 4-51 failover ................................................................ 13-25
fragment reassembly ....................................4-58 to 4-61 limiting................................................................ 13-23
full-mesh configuration ........................................... 11-63 timeout ............................................................... 13-25
function zone interfaces ........................................... 2-38

Master Index  IX-VII

 Concepts & Examples ScreenOS Reference Guide

H IDP
HA attack objects ..................................................... 4-185
See high availability basic configuration............................................ 4-175
See also NSRP configuring device for standalone IDP ........... 4-229
hanging GTP tunnel ................................................. 13-25 configuring inline or inline tap mode ............. 4-187
hardware sessions ................................................... 2-137 enabling in firewall rule .................................... 4-186
hash-based message authentication code ................ 5-6 rulebase, overview ............................................ 4-188
hashing, Secure Hashing Algorithm (SHA) ......... 14-119 IDP engine
heartbeats updating ............................................................. 4-233
HA physical link .................................................. 11-7 IDP modes ................................................................ 4-187
RTO ....................................................................... 11-7 IDP rulebases
Help files ....................................................................... 3-2 adding to security policies ............................... 4-189
high availability ...............................................13-4, 13-25 role-based administration ................................ 4-185
Active/Active ...................................................... 11-13 types ................................................................... 4-184
Active/Passive .................................................... 11-13 IDP rules ................................................................... 4-188
cabling ..................................................11-27 to 11-29 IDP rules, configuring.............................................. 4-190
data link ............................................................... 11-8 actions ................................................................ 4-196
DHCP .................................................................. 2-232 address objects .................................................. 4-185
interfaces, virtual HA .......................................... 2-39 attack severity ................................................... 4-201
IP tracking .......................................................... 11-60 attacks ................................................................ 4-198
link probes ........................................................... 11-9 IDP attack objects ............................................. 4-185
messages .............................................................. 11-7 IP actions ............................................................ 4-199
virtual interfaces ............................................... 11-28 Match columns .................................................. 4-190
high availability interfaces notifications ....................................................... 4-201
aggregate............................................................ 11-51 service objects ................................................... 4-185
cabling network as HA links ............................ 11-28 services ............................................................... 4-192
redundant .......................................................... 11-49 source and destination ..................................... 4-191
high-watermark threshold ........................................ 4-31 targets ................................................................. 4-202
historical graphs ...................................................... 2-173 terminal rules .................................................... 4-195
HMAC ............................................................................ 5-6 IDP rules, entering comments ........ 4-202, 4-206, 4-211
Host mode ...................................................14-44, 14-114 IDP-capable system ................................................. 4-172
HTTP IEEE 802.1Q VLAN standard .................................. 10-43
blocking components .........................4-168 to 4-170 IGMP
keep-alive ............................................................. 4-85 access lists, using .............................................. 7-156
session ID ............................................................... 3-4 configuration, basic .......................................... 7-157
session timeout ................................................... 4-32 configuration, verifying .................................... 7-159
trickling ................................................................ 4-86 host messages ................................................... 7-154
HyperText Transfer Protocol interfaces, enabling on ..................................... 7-155
See HTTP parameters ..............................................7-159, 7-160
policies, multicast.............................................. 7-165
I querier ................................................................ 7-155
iChat ALG .................................................................. 6-111 IGMP proxies ............................................................ 7-161
ICMP ......................................................................... 4-132 on interfaces ...................................................... 7-163
fragments ........................................................... 4-240 sender ................................................................. 7-172
large packets ...................................................... 4-241 IKE ................................................ 5-7, 5-96, 5-105, 5-170
ICMP floods ................................................................ 4-50 group IKE ID user ................................5-193 to 5-208
ICMP services ........................................................... 2-125 group IKE ID, container .................................... 5-196
message codes .................................................. 2-125 group IKE ID, wildcards ................................... 5-196
message types ................................................... 2-125 heartbeats .......................................................... 5-304
IDENT ....................................................................... 4-132 hello messages .................................................. 5-304
Identity Association Prefix Delegation Identification IKE ID ................................ 5-61 to 5-62, 5-67 to 5-68
(IAPD-ID).....................................................14-35, 14-37 IKE ID recommendations ................................... 5-80
Ident-Reset ................................................................. 3-28 IKE ID, Windows 2000 ..........................5-229, 5-237
idle session timeout .................................................. 9-18 local ID, ASN1-DN ............................................. 5-195

IX-VIII  Master Index

 Master Index

Phase 1 proposals, predefined ............................ 5-9 down, logically ..................................................... 2-61

Phase 2 proposals, predefined .......................... 5-11 down, physically .................................................. 2-61
proxy IDs .............................................................. 5-11 dual routing tables ............................................. 14-48
redundant gateways ...........................5-301 to 5-314 extended............................................................. 5-150
remote ID, ASN1-DN......................................... 5-195 function zone ....................................................... 2-38
shared IKE ID user ..............................5-208 to 5-214 Gi ........................................................................... 13-2
IKE users ............................................... 9-14, 9-67 to 9-70 Gn .......................................................................... 13-2
defining ................................................................ 9-68 Gp .......................................................................... 13-2
groups ................................................................... 9-68 HA function zone................................................. 2-38
groups, and .......................................................... 9-67 HA, dual ................................................................ 11-8
groups, defining .................................................. 9-69 interface tables, viewing ..................................... 2-43
IKE ID ..........................................................9-67, 9-81 IP tracking (See IP tracking)
server support...................................................... 9-14 L3 security zones ................................................. 2-47
with other user types ............................................ 9-4 loopback ............................................................... 2-58
IKEv2 manageable .......................................................... 3-31
Diffie-Hellman ..................................................... 5-18 management options .......................................... 3-28
EAP passthrough ................................................. 5-25 MGT ....................................................................... 2-38
enabling ................................................................ 5-17 MIP ........................................................................ 8-64
enabling on a security device ............................ 5-19 modifying ............................................................. 2-49
messages .............................................................. 5-25 ND ....................................................................... 14-27
SA .......................................................................... 5-17 NDP ..................................................................... 14-28
IMSI prefix filtering.................................................. 13-16 NUD .................................................................... 14-28
inactive SA .................................................................. 3-96 null ........................................................................ 5-95
INDP .......................................................................... 12-40 physical
informational exchanges .......................................... 5-19 exporting from vsys ..................................... 10-42
Infranet Controller importing to vsys ......................................... 10-41
actions .................................................................. 9-43 in security zones ............................................ 2-36
overview ............................................................... 9-42 policy-based NAT tunnel .................................... 2-39
resource policies .................................................. 9-43 PPPoE ................................................................. 14-44
Infranet Enforcer redundant ................................................. 2-37, 11-49
connection policy, configuring .......................... 9-42 secondary IP addresses ...................................... 2-51
overview ............................................................... 9-42 shared ..................................................... 10-39, 10-75
initial exchanges ........................................................ 5-17 state changes ....................................................... 2-61
inline mode .............................................................. 4-187 tunnel ..............................................2-39, 2-39 to 2-42
inline tap mode ........................................................ 4-187 up, logically .......................................................... 2-61
in-short error .............................................................. 3-94 up, physically ....................................................... 2-61
inspections ................................................................... 4-3 viewing interface tables ...................................... 2-43
Instant Messaging .................................................... 4-133 VIP ......................................................................... 8-80
AIM...................................................................... 4-133 virtual HA ................................................. 2-39, 11-28
IRC ...................................................................... 4-133 VLAN1 ................................................................... 2-81
MSN Messenger ................................................. 4-133 VSI ......................................................................... 2-38
Yahoo! Messenger ............................................. 4-133 VSIs ..................................................................... 11-25
Integrated Surf Control ..................................4-99, 4-108 zones, unbinding from ....................................... 2-46
Integrated SurfControl, predefined profile ........... 4-104 interfaces, enabling IGMP on ................................. 7-155
interface redundancy ................................11-49 to 11-92 interfaces, monitoring .......................2-68 to 2-73, 11-30
interfaces loops ..................................................................... 2-69
addressing ............................................................ 2-47 security zones ...................................................... 2-73
aggregate ...................................................2-37, 11-51 Interior Gateway Protocol (IGP) .............................. 14-49
binding to zone ................................................... 2-44 internal flash storage ................................................. 3-56
connections, monitoring .................................... 2-63 Internet Group Management Protocol
dedicated .................................................10-39, 10-75 See IGMP
default ................................................................... 2-48 Internet Key Exchange
DHCPv6 .............................................................. 14-33 See IKE
DIP ...................................................................... 2-141 Internet Key Exchange version 2

Master Index  IX-IX

 Concepts & Examples ScreenOS Reference Guide

See IKEv2 egress interface, on .................................2-75 to 2-76

Internet Protocol (IP) addresses ingress interface, on ...............................2-76 to 2-78
See IP addresses tracked IP threshold ............................................ 2-64
Internet Protocol Control Protocol ......................... 12-35 IP-based traffic classification .................................. 10-75
Internet Protocol version 6 Control Protocol ........ 12-35 IPCP........................................................................... 12-35
Internet Service Providers ....2-223, 14-34, 14-42, 14-96 IPSec
intrusion detection and prevention, defined........ 4-171 AH ........................................................ 5-2, 5-63, 5-70
Inverse Neighbor Discovery Protocol .................... 12-40 digital signature ................................................... 5-30
IP addresses ESP ....................................................... 5-2, 5-63, 5-70
adding to a blacklist ............................................ 4-33 L2TP-over-IPSec .................................................... 5-4
extended ............................................................ 5-150 SAs ......................................................... 5-2, 5-8, 5-11
host IDs ................................................................ 2-47 SPI ........................................................................... 5-2
interfaces, tracking on ........................................ 2-63 Transport mode .................. 5-4, 5-218, 5-223, 5-228
L3 security zones ....................................2-47 to 2-48 tunnel...................................................................... 5-2
Manage ................................................................. 2-95 Tunnel mode.......................................................... 5-4
manage IP ............................................................ 3-31 tunnel negotiation ................................................. 5-8
NetScreen-Security Manager servers ................ 3-25 IPSec Access Session (IAS).................................... 14-132
network IDs ......................................................... 2-47 IPv4
ports, defining for each .................................... 2-104 addresses, mapped ................................14-80, 14-85
private .................................................................. 2-47 WAN ................................................................. 14-110
private address ranges ....................................... 2-48 IPv4 to IPv6
public .................................................................... 2-47 host mapping ..................................................... 14-89
secondary............................................................. 2-51 network mapping .............................................. 14-88
secondary, routing between .............................. 2-51 IPv4/IPv6 boundaries .................... 14-79 to 14-84, 14-88
IP addresses, virtual .................................................. 8-80 IPv6
IP options .......................................................4-10 to 4-11 addresses, SLA ................................................... 14-35
attributes ..................................................4-10 to 4-11 addresses, TLA .................................................. 14-35
incorrectly formatted........................................ 4-242 backbone ...............................................14-83, 14-113
loose source route ......................... 4-11, 4-23 to 4-25 networks, island .............................................. 14-110
record route ......................................................... 4-11 IPv6 to IPv4 host mapping ..................................... 14-86
security ........................................................4-10, 4-11 IPv6/IPv4 boundaries ................................14-80 to 14-86
source route ......................................................... 4-23 IPv6CP ...................................................................... 12-35
stream ID ............................................................. 4-11 IRC ............................................................................. 4-133
strict source route ......................... 4-11, 4-23 to 4-25 ISG-IDP ...................................................................... 4-236
timestamp ............................................................ 4-11 ISP ............................................................................. 2-223
IP packet fragments ................................................ 4-244 failover holddown timer ................................. 12-120
IP pools priority .............................................................. 12-119
See DIP pools ISP IP address and netmask ................................... 12-83
IP Security
See IPSec J
IP spoofing .....................................................4-18 to 4-23 Java applets, blocking .............................................. 4-169
drop-no-rpf-route ................................................ 4-19
Layer 2 ........................................................4-19, 4-22 K
Layer 3 ........................................................4-18, 4-20 keepalive
IP tracking ...................................................11-60, 12-121 frequency, NAT-T .............................................. 5-247
dynamic option ................................................... 2-64 L2TP .................................................................... 5-226
interfaces, shared................................................ 2-64 keys
interfaces, supported .......................................... 2-63 manual.....................................................5-128, 5-134
object failure threshold....................................... 2-65 preshared ........................................................... 5-170
ping and ARP ..................................................... 11-60 keys, license ............................................................. 2-250
rerouting traffic .......................................2-63 to 2-78 keys, vsys .................................................................. 10-39
vsys ....................................................................... 2-64
weights ................................................................. 2-65 L
IP tracking, failure L2TP .................................................. 5-215 to 5-240, 13-3

IX-X  Master Index

 Master Index

access concentrator: See LAC timeout ................................................................. 9-16

address assignments........................................... 9-86 user types supported .......................................... 9-16
bidirectional ....................................................... 5-218 LockLatency .............................................................. 10-23
compulsory configuration ................................ 5-215 log entries
decapsulation ..................................................... 5-219 enabling in IDP rules ......................................... 4-235
default parameters ............................................ 5-221 Log Viewer
encapsulation..................................................... 5-218 creating an exempt rule ................................... 4-206
external auth server ............................................ 9-86 logging.................................................2-172, 3-55 to 3-68
hello signal ..............................................5-226, 5-231 asset recovery log ................................................ 3-68
Keep Alive ...............................................5-226, 5-231 attack object groups .......................................... 4-151
L2TP-only on Windows 2000 .......................... 5-217 CompactFlash (PCMCIA)..................................... 3-56
local database ...................................................... 9-86 console.................................................................. 3-56
network server: See LNS email ..................................................................... 3-56
operational mode .............................................. 5-218 event log ............................................................... 3-57
RADIUS server ................................................... 5-221 internal ................................................................. 3-56
ScreenOS support ............................................. 5-217 NetScreen-Security Manager .............................. 3-25
SecurID server ................................................... 5-221 self log................................................................... 3-66
tunnel.................................................................. 5-223 SNMP .......................................................... 3-56, 3-74
user authentication ............................................. 9-86 syslog .......................................................... 3-56, 3-72
voluntary configuration .................................... 5-215 USB........................................................................ 3-56
Windows 2000 tunnel authentication .5-226, 5-231 WebTrends ................................................. 3-56, 3-72
L2TP policies ............................................................ 2-169 logging, traffic ............................................................ 13-4
L2TP users .................................................................. 9-86 loopback interfaces ................................................... 2-58
server support...................................................... 9-14 loose source route IP option ...............4-11, 4-23 to 4-25
with XAuth ............................................................. 9-4 low-watermark threshold .......................................... 4-31
L2TP-over-IPSec .................................... 5-4, 5-223, 5-228 LPR spooler .............................................................. 4-132
bidirectional ....................................................... 5-218
tunnel.................................................................. 5-223 M
LAC ............................................................................ 5-215 MAC addresses ..................................14-12, 14-20, 14-28
NetScreen-Remote 5.0...................................... 5-215 Main mode ................................................................... 5-9
Windows 2000 .................................................. 5-215 malicious URL protection............................. 4-58 to 4-61
land attacks ................................................................ 4-52 Manage IP ................................................................... 2-95
lawful interception ................................................... 13-34 manage IP ................................................................... 3-31
Layer 2 Tunneling Protocol manage IP, VSD group 0 ........................................... 11-3
See L2TP management client IP addresses ............................. 3-42
LDAP ................................................... 4-132, 9-29 to 9-30 Management information base II
common name identifiers.................................. 9-30 See MIB II
distinguished names ........................................... 9-30 management methods
server ports .......................................................... 9-30 CLI ........................................................................... 3-9
structure ............................................................... 9-29 console.................................................................. 3-19
user types supported .......................................... 9-30 SSL........................................................................... 3-5
license keys .............................................................. 2-250 Telnet ...................................................................... 3-9
advanced mode ................................................. 4-120 WebUI ..................................................................... 3-2
attack pattern update ....................................... 4-120 management options
Lightweight Directory Access Protocol interfaces .............................................................. 3-28
See LDAP manageable .......................................................... 3-31
link-local addresses ......................................14-11, 14-13 MGT interface ...................................................... 3-29
Link-State Advertisement (LSA) suppression .......... 7-67 NetScreen-Security Manager .............................. 3-28
LNS ............................................................................ 5-215 ping ....................................................................... 3-28
load sharing .............................................................. 11-88 SNMP .................................................................... 3-28
load-balancing by path cost.............................7-36, 7-58 SSH ........................................................................ 3-28
local certificate ........................................................... 5-35 SSL......................................................................... 3-28
local database Telnet .................................................................... 3-28
IKE users .............................................................. 9-68 Transparent mode ............................................... 3-29

Master Index  IX-XI

 Concepts & Examples ScreenOS Reference Guide

VLAN1 .................................................................. 3-29 IPv6 hosts to a single IPv4 host ....................... 14-86
WebUI .................................................................. 3-28 IPv6 hosts to multiple IPv4 hosts .................... 14-84
manual 6over4 tunneling ....................................... 14-95 IPv6-to-IPv4 network mapping........................ 14-84
Manual Key MIP from IPv6 to IPv4 ...................................... 14-82
management ......................................................... 5-7 reachable from other zones ............................... 8-67
manual keys ........................................ 5-128, 5-134, 9-14 same-as-untrust interface .......................8-70 to 8-73
manual keys, VPNs ...........................................3-43, 3-79 MIP, creating
manual tunneling .................................................... 14-96 addresses ............................................................. 8-65
mapped IP on tunnel interface .............................................. 8-70
See MIP on zone interface ................................................ 8-65
mapping MIP, default
host, IPv4 to IPv6 .............................................. 14-89 netmasks .............................................................. 8-66
host, IPv6 to IPv4 .............................................. 14-86 virtual routers ...................................................... 8-66
network, IPv4 to IPv6 ....................................... 14-88 MIP, to zone with interface-based NAT.................... 2-94
Maximum Transmission Unit (MTU) ..................... 14-11 MIP, virtual systems................................................. 10-33
MD5 .............................................................................. 5-6 MIP, VPNs ................................................................. 5-150
Message Digest version 5 (MD5) ............................... 5-6 Mobile Station (MS) mode ...................................... 13-15
message drop ............................................................. 4-85 mode config ............................................................... 9-71
messages mode, Transparent .................................................. 10-44
alert ....................................................................... 3-57 modem ports ....................................................3-20, 3-22
control ................................................................ 11-14 modes
critical ................................................................... 3-57 Aggressive ............................................................ 5-10
data ....................................................................... 11-8 Host........................................................14-44, 14-114
debug .................................................................... 3-57 L2TP operational ............................................... 5-218
deny .................................................................... 4-103 Main ........................................................................ 5-9
deny, creating and editing ............................... 4-103 NAT and Route .................................................... 11-3
EAP ....................................................................... 5-25 NAT, traffic to Untrust zone ............................... 2-79
emergency ........................................................... 3-57 Phase 1 cryptographic ...............................5-59, 5-66
error ...................................................................... 3-57 preempt .............................................................. 11-23
GCF ......................................................................... 6-2 Router ................................................................. 14-50
HA ......................................................................... 11-7 Stale .................................................................... 14-29
IKEv2 .................................................................... 5-25 Transparent.......................................................... 2-80
info ........................................................................ 3-57 Transport ....................5-4, 5-70, 5-218, 5-223, 5-228
notification ........................................................... 3-57 Tunnel............................................................5-4, 5-70
RCF ......................................................................... 6-2 modes, operational
warning ................................................................ 3-57 NAT ....................................................................... 13-4
WebTrends .......................................................... 3-73 Route .................................................................... 13-3
MGT interface ............................................................. 2-38 Transparent.......................................................... 13-3
MGT interface, management options ...................... 3-29 modes, selection
MIB files, importing ................................................. 5-263 APN ..................................................................... 13-15
MIB II .................................................................3-28, 3-74 Mobile Station (MS) ........................................... 13-15
Microsoft Network Instant Messenger Network .............................................................. 13-15
See MSN Instant Messenger Verified ............................................................... 13-15
Microsoft-Remote Procedure Call modulus ...................................................................... 5-10
See MS-RPC MS RPC ALG, defined .............................................. 2-127
MIME, AV scanning ................................................... 4-75 MSN Messenger ....................................................... 4-133
MIP ..............................................2-11, 8-63, 14-80, 14-82 MS-RPC ..................................................................... 4-133
address ranges .................................................... 8-66 multicast
bidirectional translation ....................................... 8-6 addresses ........................................................... 7-146
definition ................................................................ 8-6 distribution trees ............................................... 7-182
global zone ........................................................... 8-64 policies................................................................ 7-151
grouping, multi-cell policies ............................... 8-79 policies for IGMP ............................................... 7-165
IPv4 hosts to a single IPv6 host ...................... 14-89 reverse path forwarding ................................... 7-146
IPv4 hosts to multiple IPv6 hosts .................... 14-88 routing tables ..................................................... 7-147

IX-XII  Master Index

 Master Index

static routes........................................................ 7-148 port addresses ....................................................... 8-2

multicast routing unidirectional ............................................... 8-6, 8-10
IGMP ................................................................... 7-153 NAT-T .......................................................... 5-242 to 5-250
PIM ...................................................................... 7-179 enabling .............................................................. 5-249
multimedia sessions, SIP .......................................... 6-15 IKE packet .......................................................... 5-245
multiplexing, configuring........................................ 12-81 initiator and responder ..................................... 5-247
IPSec packet ....................................................... 5-246
N keepalive frequency .......................................... 5-247
NAT obstacles for VPNs............................................. 5-245
definition ................................................................ 8-1 probing for NAT .................................. 5-243 to 5-244
IPSec and NAT ................................................... 5-242 NAT-Traversal
NAT servers........................................................ 5-242 See NAT-T
NAT-src with NAT-dst .............................8-50 to 8-61 NCP............................................................................ 12-35
NAT mode ................................... 2-92 to 2-97, 11-3, 13-4 negation, address..................................................... 2-187
interface settings ................................................. 2-95 negation, deep inspection (DI) ............................... 4-164
traffic to Untrust zone................................2-79, 2-94 Neighbor Advertisement (NA) ................................ 14-29
NAT vector error......................................................... 3-96 Neighbor Cache table 14-12, 14-13, 14-15, 14-24, 14-28
NAT-dst ............................................................8-28 to 8-61 Neighbor Cache table, neighbor entry categories 14-13
address shifting ..................................................... 8-5 Neighbor Discovery (ND) ........................................ 14-27
packet flow ...............................................8-29 to 8-31 Accept Incoming RAs ........................................ 14-20
port mapping ...................................... 8-4, 8-28, 8-47 age of neighbor entry ....................................... 14-12
route considerations ..................... 8-29, 8-32 to 8-34 bypassing MAC session-caching ...................... 14-28
unidirectional translation ............................8-6, 8-10 definition ............................................................ 14-12
VPNs ................................................................... 5-150 enabling .............................................................. 14-28
with MIPs or VIPs .................................................. 8-3 Neighbor Cache table ............................ 14-12, 14-28
NAT-dst, addresses neighbor reachability state ............................... 14-12
range to range ............................................8-10, 8-44 neighbor reachability status ............................. 14-29
range to single IP..........................................8-9, 8-41 packets currently queued for transmission .... 14-12
ranges ..................................................................... 8-4 reachability status ............................................. 14-27
shifting .........................................................8-28, 8-44 Neighbor Discovery (ND), displaying .................... 14-30
NAT-dst, single IP Neighbor Discovery Parameter (NDP) ....... 14-20, 14-28
with port mapping ................................................ 8-8 Neighbor Solicitation (NS) ................14-13, 14-29, 14-30
without port mapping ........................................... 8-9 setting ................................................................. 14-29
NAT-dst, translation Neighbor Unreachability Detection (NUD)............ 14-13
one-to-many......................................................... 8-38 Neighbor Cache table ........................................ 14-24
one-to-one ............................................................ 8-35 Neighbor Unreachability Detection (NUD), Neighbor
native hosts .................................................14-99, 14-101 Cache table ............................................................ 14-13
NAT-Protocol Translation ......................................... 2-126 NetBIOS .................................................................... 4-133
NAT-PT ............................................................2-126, 14-79 NetInfo ...................................................................... 2-226
NAT-PT, IPSec, when to use .................................. 14-110 netmasks ........................................................ 2-48, 2-166
NAT-src .................................................... 8-1, 8-13 to 8-25 netmasks, classifying device addresses by ........... 2-103
egress interface ............................... 8-8, 8-24 to 8-25 netmasks, MIP default ............................................... 8-66
fixed port ........................................ 8-14, 8-18 to 8-19 NetScreen Redundancy Protocol
interface-based ...................................................... 8-2 See NSRP
VPNs ................................................................... 5-152 NetScreen Reliable Transport Protocol
NAT-src, addresses See NRTP
shifting ......................................................8-20 to 8-24 NetScreen-Remote
shifting, range considerations ........................... 8-20 AutoKey IKE VPN .............................................. 5-170
NAT-src, DIP pools ....................................................... 8-1 dynamic peer ......................................... 5-176, 5-183
fixed port ................................................................ 8-7 NAT-T option ...................................................... 5-242
with address shifting............................................. 8-8 NetScreen-Security Manager
with PAT ........................................... 8-7, 8-15 to 8-17 definition .............................................................. 3-22
NAT-src, Route mode ................................................. 2-98 enabling NSM Agent ........................................... 3-24
NAT-src, translation events, reporting ................................................. 3-25

Master Index  IX-XIII

 Concepts & Examples ScreenOS Reference Guide

initial connectivity setup .................................... 3-23 interface monitoring ......................................... 11-30

logging .................................................................. 3-25 load sharing ....................................................... 11-88
management options ......................................... 3-28 manage IP .......................................................... 11-60
management system ....................... 3-22, 3-23, 3-25 master ................................................................ 11-13
NSM Agent ..................................................3-22, 3-25 NAT and Route modes ....................................... 11-3
reporting events .................................................. 3-26 NTP synchronization .............................2-256, 11-21
UI .......................................................................... 3-22 packet forwarding and dynamic routing .......... 11-8
Network Address Translation (NAT) ......................... 3-95 preempt mode ................................................... 11-23
Network Address Translation-Port Translation priority numbers ............................................... 11-22
DIP redundant interfaces........................................... 2-37
from IPv6 to IPv4......................................... 14-81 redundant ports ................................................... 11-3
DIP addresses, translating ............................... 14-82 RTOs ................................................................... 11-35
dynamic IP (DIP) ............................................... 14-80 secondary path .................................................. 11-30
IPv4 hosts to a single IPv6 host ...................... 14-89 secure communications ................................... 11-30
IPv4 hosts to multiple IPv6 hosts .................... 14-88 virtual systems ....................................11-63 to 11-92
IPv6 hosts to a single IPv4 host ...................... 14-86 VSD groups ................................. 4-182, 11-22, 11-35
IPv6 hosts to multiple IPv4 hosts .................... 14-84 VSIs ..............................................................2-38, 11-2
MIP from IPv4 to IPv6 ...................................... 14-83 VSIs, static routes ....................... 11-25, 11-75, 11-76
NAT-PT ............................................................... 14-80 NSRP clusters ................................................11-31, 11-35
outgoing service requests .....................14-80, 14-84 names ......................................................11-12, 11-29
source address translation ............................... 14-81 NSRP data
when to use ....................................................... 14-80 link ........................................................................ 11-8
Network Address Translation-Port Translation (NAT-PT) messages .............................................................. 11-8
14-79 NSRP HA
Network Control Protocol ....................................... 12-35 cabling, network interfaces .............................. 11-28
Network mode ......................................................... 13-15 interfaces .............................................................. 11-6
network, bandwidth ................................................ 2-193 ports, redundant interfaces.............................. 11-49
next-hop gateway .................................................... 14-29 session backup .................................................. 11-16
NFS ............................................................................ 4-132 NSRP ports
NHTB table .................................................5-265 to 5-269 failover................................................................ 11-49
addressing scheme ........................................... 5-267 NSRP RTOs .................................................11-16 to 11-17
automatic entries .............................................. 5-268 states................................................................... 11-18
manual entries .................................................. 5-268 sync..................................................................... 11-21
mapping routes to tunnels ............................... 5-265 NSRP synchronization
NNTP ......................................................................... 4-132 NTP, NSRP ......................................................... 11-21
NRTP ......................................................................... 11-20 RTOs ................................................................... 11-21
NSM Agent ........................................................3-22, 3-23 NSRP-Lite .................................................................. 11-20
enabling................................................................ 3-24 clusters ............................................................... 11-12
events, reporting ................................................. 3-25 secure communications ................................... 11-16
NSRP ........................................................................... 11-1 NSRP-Lite synchronization
ARP broadcasts ................................................. 11-30 disabling ............................................................. 11-20
ARP lookup ........................................................ 11-39 NTP.................................................. 2-254 to 2-257, 4-132
backup ................................................................ 11-13 authentication types ......................................... 2-257
cabling ..................................................11-27 to 11-29 maximum time adjustment ............................. 2-255
clear cluster command ..................................... 11-12 multiple servers ................................................. 2-254
config sync ......................................................... 11-20 NSRP synchronization ...................................... 2-256
control messages .....................................11-7, 11-14 secure servers .................................................... 2-257
debug cluster command .................................. 11-12 servers ................................................................ 2-254
default settings .................................................... 11-6 service ................................................................ 2-257
DHCP .................................................................. 2-232 NTP, NSRP synchronization .................................... 11-21
DIP groups ...........................................2-154 to 2-156 Null interface, defining routes with ......................... 7-10
full-mesh configuration .........................11-27, 11-63 null route .................................................................... 5-95
HA session backup ............................................ 2-172
hold-down time ......................................11-36, 11-39

IX-XIV  Master Index

 Master Index

O Overbilling attacks
objects description ......................................................... 13-26
attack objects ..................................................... 4-211 prevention ........................................... 13-26 to 13-31
attack objects, creating custom ....................... 4-214 prevention, configuring .................................... 13-29
attack objects, protocol anomaly .................... 4-212 solutions ............................................................. 13-28
attack objects, signature ................................... 4-212
objects, monitoring ................................................. 11-57 P
OCSP (Online Certificate Status Protocol)............... 5-44 P2P ............................................................................ 4-133
client ..................................................................... 5-44 BitTorrent ........................................................... 4-133
responder ............................................................. 5-44 DC ....................................................................... 4-133
Open Shortest Path First eDonkey ............................................................. 4-133
See OSPF FastTrack ............................................................ 4-133
operating systems, probing hosts for ..........4-12 to 4-14 Gnutella............................................................... 4-133
operational modes KaZaa .................................................................. 4-133
NAT ....................................................................... 13-4 MLdonkey........................................................... 4-133
Route .................................................................... 13-3 Skype .................................................................. 4-133
Transparent.......................................................... 13-3 SMB ..................................................................... 4-133
OSPF WinMX ................................................................ 4-133
broadcast networks............................................. 7-48 packet flow .................................................... 2-10 to 2-12
configuration steps.............................................. 7-49 inbound VPN ........................................... 5-76 to 5-78
ECMP support ...................................................... 7-58 outbound VPN ..................................................... 5-76
flooding, protecting against ............................... 7-66 policy-based VPN.................................... 5-78 to 5-79
flooding, reduced LSA......................................... 7-67 route-based VPN ..................................... 5-73 to 5-78
global parameters ............................................... 7-58 packet flow, NAT-dst...................................... 8-29 to 8-31
hello protocol ....................................................... 7-47 packets ........................................................................ 3-96
interface parameters........................................... 7-62 address spoofing attack ...................................... 3-94
interfaces, assigning to areas............................. 7-53 collision....................................................... 3-93, 3-94
interfaces, tunnel ................................................ 7-68 denied ................................................................... 3-96
link-state advertisements ................................... 7-46 dropped ...................................................... 3-95, 3-96
link-type, setting .................................................. 7-68 fragmented ........................................................... 3-96
load-balancing ..................................................... 7-36 incoming .............................................................. 3-93
LSA suppression .................................................. 7-67 Internet Control Message Protocol (ICMP) ...... 3-92,
neighbors, authenticating................................... 7-64 3-95
neighbors, filtering .............................................. 7-65 IPSec ..................................................................... 3-95
not so stubby area............................................... 7-47 land attack ............................................................ 3-95
point-to-multipoint .............................................. 7-68 Network Address Translation (NAT) ................. 3-95
point-to-point network........................................ 7-48 Point to Point Tunneling Protocol (PPTP)......... 3-94
security configuration ......................................... 7-64 received ................................... 3-93, 3-94, 3-95, 3-96
stub area............................................................... 7-47 transmitted underrun ......................................... 3-94
virtual links .......................................................... 7-59 unreceivable ......................................................... 3-94
OSPF areas ................................................................. 7-46 unroutable ............................................................ 3-95
defining ................................................................ 7-51 PAP .....................................................5-218, 5-221, 12-36
interfaces, assigning to ....................................... 7-53 parent connection...................................................... 3-95
OSPF routers Password Authentication Protocol ......................... 12-36
adjacency ............................................................. 7-47 See PAP
backup designated .............................................. 7-47 passwords
creating OSPF instance in VR ............................ 7-50 forgetting .............................................................. 3-39
designated ............................................................ 7-47 root admin ........................................................... 3-41
types ..................................................................... 7-47 passwords, changing admin’s ........................ 10-4, 10-7
OSPF routes PAT ........................................................2-137, 2-142, 8-14
default, rejecting.................................................. 7-66 pattern files .............................................................. 4-120
redistributed, summarizing................................ 7-57 updating from a proxy server .......................... 4-129
redistributing ....................................................... 7-56 using in AV scanning .......................................... 4-85
route-deny restriction, disabling ....................... 7-69 PCMCIA ....................................................................... 3-56

Master Index  IX-XV

 Concepts & Examples ScreenOS Reference Guide

Peer-to-Peer bidirectional VPNs ..................................2-168, 5-135

See P2P changing ............................................................. 2-190
Perfect Forward Secrecy context................................................................ 4-122
See PFS core section ...............................................4-17, 4-120
PFS ........................................................... 5-11, 5-63, 5-69 counting ............................................................. 2-173
Phase 1 ......................................................................... 5-9 deep inspection (DI) .......................................... 2-169
proposals ................................................................ 5-9 deny .................................................................... 2-167
proposals, predefined ........................................... 5-9 DIP groups ......................................................... 2-155
Phase 2 ....................................................................... 5-11 disabling ............................................................. 2-190
proposals .............................................................. 5-11 editing ................................................................. 2-190
proposals, predefined ......................................... 5-11 enabling .............................................................. 2-190
physical interface functions of ........................................................ 2-159
logical interface ................................................... 2-36 global ........................................... 2-162, 2-175, 2-185
physical interfaces HA session backup ............................................ 2-172
C-bit parity mode .............................................. 12-13 ID ........................................................................ 2-166
CSU compatibility ............................................. 12-20 internal rules ...................................................... 2-164
exporting from vsys .......................................... 10-42 interzone ..................................... 2-161, 2-175, 2-179
importing to vsys .............................................. 10-41 intrazone ..................................... 2-161, 2-175, 2-183
PIM-SM ..................................................................... 7-182 L2TP .................................................................... 2-169
configuration steps ........................................... 7-186 L2TP tunnels ...................................................... 2-169
configuring rendezvous points ........................ 7-196 lookup sequence ............................................... 2-163
designated router .............................................. 7-183 management...................................................... 2-175
IGMPv3 ............................................................... 7-212 managing bandwidth ........................................ 2-193
instances, creating ............................................ 7-187 maximum limit.................................................. 2-107
interface parameters ........................................ 7-201 multiple items per component ........................ 2-186
proxy RP ............................................................ 7-202 name ................................................................... 2-168
rendezvous points ............................................. 7-183 NAT-dst ............................................................... 2-170
security configurations ..................................... 7-198 NAT-src ............................................................... 2-170
traffic, forwarding ............................................. 7-184 no hardware session ......................................... 2-170
PIM-SSM ................................................................... 7-186 order ................................................................... 2-191
ping management options ....................................... 3-28 PBR ..................................................................... 7-127
Ping of Death ............................................................. 4-53 permit ................................................................. 2-167
pinholes ...................................................................... 6-21 policy context .................................................... 2-186
PKI............................................................................... 5-32 policy set lists .................................................... 2-163
PKI keys ........................................................................ 3-6 position at top.........................................2-169, 2-191
point-to-multipoint configuration, OSPF................. 7-68 reject ................................................................... 2-167
Point-to-Point Protocol removing ............................................................ 2-192
See PPP reordering .......................................................... 2-191
Point-to-Point Protocol (PPP) .................................. 14-44 required elements ............................................. 2-160
Point-to-Point Protocol over ATM root system ........................................................ 2-164
See PPPoA schedules ............................................................ 2-173
Point-to-Point Protocol over Ethernet security zones .................................................... 2-166
See PPPoE service book ....................................................... 2-108
Point-to-Point Protocol over Ethernet (PPPoE) ..... 14-44 service groups .................................................... 2-139
Point-to-Point Tunneling Protocol (PPTP) .....2-137, 3-94 services ............................................................... 2-167
policies .................................................................2-3, 13-4 services in ...............................................2-108, 2-167
actions ................................................................ 2-167 shadowing ...............................................2-190, 2-191
address groups .................................................. 2-166 traffic logging ..................................................... 2-172
address negation ............................................... 2-187 traffic shaping .................................................... 2-173
addresses ........................................................... 2-166 tunnel.................................................................. 2-167
addresses in ....................................................... 2-166 types .....................................................2-161 to 2-162
alarms ................................................................. 2-173 verifying ............................................................. 2-190
application, linking service to explicitly ......... 2-168 virtual systems .................................................. 2-164
authentication.................................................... 2-170 VPN dialup user groups .................................... 2-166

IX-XVI  Master Index

 Master Index

VPNs ................................................................... 2-168 protocol distribution, NetScreen-Security Manager,

policies, configuring .................................................. 13-5 reporting to .............................................................. 3-25
policies, multicast .................................................... 7-151 Protocol Independent Multicast
policy based routing (PBR) ..................................... 7-127 See PIM
policy push ............................................................... 4-236 protocols
policy.gz.v ................................................................. 4-236 CHAP....................................................... 5-218, 12-36
policy-based NAT IGP ....................................................................... 14-49
See NAT-dst and NAT-src INDP .................................................................... 12-40
policy-based NAT, tunnel interfaces ......................... 2-39 IPCP .................................................................... 12-35
policy-based VPNs ..................................................... 5-72 IPv6CP ................................................................ 12-35
Port Address Translation NCP ..................................................................... 12-35
See PAT NRTP ................................................................... 11-20
port address translation (PAT) ................................ 2-137 NSRP ..................................................................... 11-1
port scan ....................................................................... 4-9 PAP.......................................................... 5-218, 12-36
Portmapper .............................................................. 4-132 PPP .......................................................... 5-216, 14-44
ports PPPoE ................................................................. 14-44
failover ................................................................ 11-49 VRRP ....................................................... 11-60, 11-65
mapping ........................................................8-4, 8-28 protocols, CHAP ......................................................... 9-81
numbers ............................................................... 8-87 proxy IDs .................................................................... 5-11
primary trusted and untrusted ........................ 11-49 matching .................................................... 5-73, 5-79
redundant ............................................................. 11-3 VPNs and NAT .................................... 5-150 to 5-151
secondary trusted and untrusted .................... 11-49 proxy servers
ports, modem ...................................................3-20, 3-22 configuring for DI pattern updates .................. 4-129
ports, trunk ............................................................... 10-44 public addresses......................................................... 2-47
PPP .................................................................5-216, 12-76 Public key infrastructure
PPPoA................................................. 12-76, 12-78, 12-84 See PKI
PPPoE ................................................. 12-76, 12-84, 14-44 Public/private key pair............................................... 5-33
PPPoE - Point-to-Point Protocol over Ethernet ..... 14-44 PXE ............................................................................ 2-237
PPTP .......................................................................... 2-137 PXE server ................................................................ 2-237
PPTP ALG .................................................................. 2-137
preempt mode ......................................................... 11-23 Q
prefix lists ................................................................. 14-11 QoS ............................................................................ 2-193
preshared key............................................................... 5-7
preshared keys ......................................................... 5-170 R
priorities, assigning ................................................... 9-32 RA .............................................................................. 14-11
priority queuing ....................................................... 2-197 RADIUS ..................................... 3-39, 4-132, 9-19 to 9-22
private addresses ....................................................... 2-48 auth server objects .............................................. 9-33
probe ......................................................................... 14-29 dictionary file ......................................................... 9-2
Probe Time ............................................................... 14-29 dictionary files ..................................................... 9-21
probes L2TP .................................................................... 5-221
network .................................................................. 4-8 object properties.................................................. 9-20
open ports .............................................................. 4-9 ports ...................................................................... 9-20
operating systems ......................................4-12, 4-14 retry timeout ........................................................ 9-20
proposals shared secret ........................................................ 9-20
Phase 1 ..........................................................5-9, 5-79 RADIUSv6 ............................................................... 14-130
Phase 2 ........................................................5-11, 5-79 rate limiting, GTP-C messages ................................ 13-11
Protected EAP ............................................................ 5-24 reachability states .................................................... 14-14
protocol anomalies .................................................. 4-135 reachability states, transitions ................................ 14-15
ALGs .................................................................... 4-133 reassembly, Apple iChat ALG.................................. 6-113
basic network protocols ................................... 4-131 reconnaissance................................................ 4-7 to 4-25
configuring parameters .................................... 4-163 address sweep ....................................................... 4-8
Instant Messaging applications........................ 4-133 FIN scans .............................................................. 4-15
P2P applications ................................................ 4-133 IP options ............................................................. 4-10
supported protocols ............................4-131 to 4-134 port scan................................................................. 4-9

Master Index  IX-XVII

 Concepts & Examples ScreenOS Reference Guide

SYN and FIN flags set ......................................... 4-12 rejecting default ................................................... 7-87
TCP packet without flags.................................... 4-14 summary, configuring ........................................ 7-91
record route IP option ............................................... 4-11 RIP, configuring
redundancy, interface ............................................. 11-49 demand circuits ................................................... 7-94
redundant gateways ..................................5-301 to 5-314 security ................................................................. 7-85
recovery procedure ........................................... 5-305 steps ...................................................................... 7-75
TCP SYN flag checking ..................................... 5-307 RIP, viewing
Registration Confirm (RCF) messages....................... 6-2 database ....................................................7-79, 14-63
regular expressions ...................................4-158 to 4-159 interface details ................................................... 7-81
rekey option, VPN monitoring ............................... 5-253 neighbor information ..............................7-80, 14-65
Remote Authentication Dial-in User Service protocol details .........................................7-79, 14-63
See RADIUS RIPng..............................................................14-47, 14-49
remote termination point ........................14-101, 14-104 interface cost metric ..............................14-58, 14-59
replay protection ....................................................... 5-12 metric calculation .............................................. 14-59
request packets, outgoing from IPv6 to IPv4 ....... 14-82 offset metric............................................14-58, 14-59
request/response pairs .............................................. 5-18 route metric ............................................14-58, 14-59
requirements, basic functional ................................ 10-4 route redistribution ........................................... 14-49
Retransmission Time .............................................. 14-30 rlogin ......................................................................... 4-132
rexec ......................................................................... 4-132 role-based administration
RFC 1777, Lightweight Directory Access Protocol .. 9-29 configuring IDP-only administrator ................ 4-230
RFCs IDP rulebases ..................................................... 4-185
0792, Internet Control Message Protocol ....... 2-125 root admin, logging in............................................... 3-42
1038, Revised IP Security Option .................... 4-10 route lookup
1349, Type of Service in the Internet Protocol Suite .. multiple VRs......................................................... 7-34
2-174 sequence .............................................................. 7-32
1918, Address Allocation for Private Internets . 2-48 Route mode .............................. 2-98 to 2-101, 11-3, 13-3
2132, DHCP Options and BOOTP Vendor Extensions interface settings ................................................. 2-99
2-230 NAT-src ................................................................. 2-98
2326, Real Time Streaming Protocol (RTSP)... 2-133 route tracking ......................................................... 12-121
2474, Definition of the Differentiated Services Field route-based VPNs ..........................................5-72 to 5-73
(DS Field) in the IPv4 and IPv6 Headers ....... 2-174 Router Advertisement (RA) ..................................... 14-11
791, Internet Protocol..................................... 4-10 Router mode ............................................................ 14-50
793, Transmission Control Protocol................. 4-13 Router Solicitation (RS) ........................................... 14-11
RIP routers
authenticating neighbors ................................... 7-85 upstream ............................................................ 14-36
configuration ..................................................... 14-51 virtual .......................................................14-48, 14-99
database ............................................................... 7-92 routers, CPE .............................................................. 2-220
demand circuit configuration ............................ 7-93 routes
filtering neighbors ............................................... 7-86 exporting .............................................................. 7-42
flooding, protecting against ....................7-87, 14-57 filtering ................................................................. 7-39
global parameters ....................................7-82, 14-54 importing ............................................................. 7-42
instances, creating in VR.........................7-75, 14-52 maps ..................................................................... 7-38
interface parameters ...............................7-84, 14-58 metrics.................................................................. 7-31
interfaces, enabling on ............................7-76, 14-53 null ........................................................................ 5-95
load-balancing ..................................................... 7-36 preference ............................................................ 7-30
neighbors, filtering ............................................ 14-55 redistributing ....................................................... 7-37
point-to-multipoint .............................................. 7-95 selection ............................................................... 7-30
prefix summary................................................... 7-91 Routing Information Protocol
versions ................................................................ 7-89 See RIP
versions, protocol................................................ 7-89 routing tables ............................................................. 7-15
RIP routes lookup ................................................................... 7-32
alternate ............................................................... 7-92 lookup in multiple VRs ....................................... 7-34
default, rejecting ............................................... 14-55 multicast ............................................................. 7-147
redistributing ............................................7-77, 14-56 route selection ..................................................... 7-30

IX-XVIII  Master Index

 Master Index

types ..................................................................... 7-15 TCP packet without flags, detect ....................... 4-14
routing, multicast..................................................... 7-145 teardrop ................................................................ 4-54
routing, policy based ............................................... 7-127 UDP floods ........................................................... 4-51
RSA authentication ................................................ 14-119 unknown protocols, drop ................................. 4-243
rsh.............................................................................. 4-132 VLAN and MGT zones ........................................... 4-2
RTOs ............................................................11-16 to 11-17 WinNuke attacks ................................................. 4-55
operational states .............................................. 11-18 SCREEN, MGT zone ................................................... 2-28
peers ................................................................... 11-24 ScreenOS
synchronization ................................................. 11-21 function zones ..................................................... 2-33
RTSP .......................................................................... 4-132 global zone ........................................................... 2-28
RTSP ALG overview ................................................................. 2-1
defined ............................................................... 2-129 packet flow .............................................. 2-10 to 2-12
dual-stack environment .................................... 2-130 policies .................................................................... 2-3
request methods ............................................... 2-130 RADIUS vendor IDs ............................................. 9-22
servers in private domain ................................ 2-133 security zones .............................................. 2-2, 2-28
servers in public domain .................................. 2-135 security zones, global ........................................... 2-2
status codes ....................................................... 2-132 security zones, predefined ................................... 2-2
rules, derived from policies .................................... 2-164 tunnel zones ......................................................... 2-29
run-time authentication .................................2-171, 9-48 virtual systems ....................................................... 2-9
Run-Time Objects zones ........................................................ 2-25 to 2-33
See RTOs ScreenOS interfaces
security zones ........................................................ 2-3
S subinterfaces .......................................................... 2-3
SA policy ..................................................................... 3-96 ScreenOS zones ......................................................... 10-6
SAs ........................................................................5-8, 5-11 SDP ................................................................. 6-19 to 6-20
check in packet flow ........................................... 5-75 secondary IP addresses ............................................. 2-51
SCEP (Simple Certificate Enrollment Protocol) ...... 5-40 secondary path ........................................................ 11-30
schedules .......................................................2-157, 2-173 Secure Copy
SCP See SCP
enabling ................................................................ 3-18 Secure Hash Algorithm-1
example client command .................................. 3-18 See SHA-1
SCREEN Secure Shell
address sweep ....................................................... 4-8 See SSH
bad IP options, drop ......................................... 4-242 Secure Sockets Layer
drop unknown MAC addresses.......................... 4-43 See SSL
FIN with no ACK.................................................. 4-15 SecurID ....................................................................... 9-27
FIN without ACK flag, drop ................................ 4-13 ACE servers .......................................................... 9-28
ICMP auth server object ................................................ 9-35
fragments, block .......................................... 4-240 authentication port .............................................. 9-28
ICMP floods .......................................................... 4-50 authenticator ........................................................ 9-27
IP options ............................................................. 4-10 encryption types .................................................. 9-28
IP packet fragments, block .............................. 4-244 L2TP .................................................................... 5-221
IP spoofing ...............................................4-18 to 4-23 token codes .......................................................... 9-27
land attacks .......................................................... 4-52 Use Duress option ............................................... 9-28
large ICMP packets, block ................................ 4-241 user type support ................................................ 9-28
loose source route IP option, detect ................. 4-25 SecurID clients
Ping of Death ....................................................... 4-53 retries .................................................................... 9-28
port scan ................................................................ 4-9 timeout ................................................................. 9-28
source route IP option, deny ............................. 4-25 security associations
strict source route IP option, detect .................. 4-25 IKEv2 .................................................................... 5-17
SYN and FIN flags set ......................................... 4-12 See SAs
SYN floods ................................................4-38 to 4-43 Security Associations (SA) ......................................... 3-95
SYN fragments, detect ...................................... 4-245 security IP option ............................................. 4-10, 4-11
SYN-ACK-ACK proxy floods ............................... 4-36 Security Policies ....................................................... 4-183

Master Index  IX-XIX

 Concepts & Examples ScreenOS Reference Guide

security policies ALGs .................................................................... 2-168

rulebase execution ............................................ 4-186 in vsys................................................................. 2-121
rulebases ............................................................ 4-183 session ID ..................................................................... 3-4
rules .................................................................... 4-183 session idle timeout .................................................. 9-18
templates ........................................................... 4-186 session limits..................................................4-28 to 4-31
security zones .............................................................. 2-2 destination-based .......................................4-29, 4-30
determination, destination zone ....................... 2-12 source-based ...............................................4-28, 4-30
determination, source zone ............................... 2-10 session table floods ..........................................4-17, 4-28
global ...................................................................... 2-2 session timeout
predefined.............................................................. 2-2 HTTP ..................................................................... 4-32
See zones session timeouts
security zones, interfaces ........................................... 2-3 TCP........................................................................ 4-31
physical ................................................................ 2-36 UDP ....................................................................... 4-32
selection modes SHA-1 ............................................................................ 5-6
APN ..................................................................... 13-15 shared VRs................................................................ 10-39
Mobile Station (MS) ........................................... 13-15 shared zones ............................................................ 10-39
Network.............................................................. 13-15 signature packs, DI .................................................. 4-122
Verified ............................................................... 13-15 signatures
self log......................................................................... 3-66 stateful ................................................................ 4-134
sequence-number validation .................................. 13-12 SIP
serial cables ................................................................ 3-19 ALG ..............................................................6-19, 6-22
Server Message Block connection information ...................................... 6-20
See SMB defined ................................................................. 6-15
servers media announcements ....................................... 6-20
DDNS .................................................................. 2-220 messages .............................................................. 6-16
DDO .................................................................... 2-220 multimedia sessions ........................................... 6-15
setting up DDNS for DDO ................................ 2-222 pinholes ................................................................ 6-19
servers, auth request methods ................................................. 6-16
See auth servers response codes .................................................... 6-18
servers, SecurID ACE ................................................. 9-28 RTCP ..................................................................... 6-20
service book RTP ....................................................................... 6-20
entries, modifying (CLI) .................................... 2-122 SDP ...........................................................6-19 to 6-20
entries, removing (CLI) ..................................... 2-122 signaling ............................................................... 6-19
service book, service groups (WebUI) ..................... 6-65 SIP NAT
service book, services call setup .....................................................6-25, 6-30
adding................................................................. 2-121 defined ................................................................. 6-25
custom ................................................................ 2-108 DIP pool, using a ................................................. 6-37
custom (CLI)....................................................... 2-121 DIP, using incoming ........................................... 6-33
preconfigured .................................................... 2-108 DIP, using interface ............................................ 6-34
service groups ............................................2-139 to 2-141 incoming, with MIP ....................................6-37, 6-39
creating .............................................................. 2-139 proxy in DMZ....................................................... 6-46
deleting............................................................... 2-141 proxy in private zone ................................6-41, 6-88
modifying ........................................................... 2-140 proxy in public zone ........................................... 6-44
service groups (WebUI) ........................................... 2-139 Trust intrazone .................................................... 6-53
service provider, information from ....................... 12-76 untrust intrazone ........................................6-49, 6-95
service requests, outgoing ...........................14-84, 14-86 VPN, using full-mesh................................6-55, 6-101
services ..................................................................... 2-108 SIP timeouts
custom ................................................................ 4-153 inactivity ............................................................... 6-22
defined ............................................................... 2-167 media inactivity ..........................................6-23, 6-24
drop-down list ................................................... 2-108 session inactivity ................................................. 6-22
ICMP ................................................................... 2-125 signaling inactivity .....................................6-23, 6-24
in policies ........................................................... 2-167 site survey .............................................................. 12-142
timeout threshold.............................................. 2-122 Site-Local Aggregator (SLA)..........................14-35, 14-37
services, custom ...................................................... 2-120 SKEYSEED .................................................................. 5-18

IX-XX  Master Index

 Master Index

SMB stateful........................................................................... 4-3

NetBIOS .............................................................. 4-133 inspection ............................................................... 4-3
SMTP server IP ........................................................... 3-71 signatures ........................................................... 4-134
SNMP .................................................................3-28, 3-74 stateless address autoconfiguration ....................... 14-10
cold start trap ...................................................... 3-74 static IP address ....................................................... 12-84
configuration........................................................ 3-77 static routing...............................................7-2, 7-2 to 7-9
encryption ...................................................3-76, 3-78 configuring ............................................................. 7-5
management options .......................................... 3-28 multicast ............................................................. 7-148
MIB files, importing .......................................... 5-263 Null interface, forwarding on ............................. 7-10
VPN monitoring ................................................. 5-263 using........................................................................ 7-3
SNMP community statistics, reporting to NSM ....................................... 3-26
private................................................................... 3-77 stream ID IP option ................................................... 4-11
public .................................................................... 3-77 stream signatures .................................................... 4-135
SNMP traps strict source route IP option ...............4-11, 4-23 to 4-25
100, hardware problems .................................... 3-75 subinterfaces .................................................... 2-3, 10-64
200, firewall problems ....................................... 3-75 configuring (vsys) .............................................. 10-64
300, software problems ..................................... 3-75 creating (root system) ......................................... 2-50
400, traffic problems .......................................... 3-75 creating (vsys) .................................................... 10-64
500, VPN problems ............................................. 3-75 deleting ................................................................. 2-50
allow or deny ....................................................... 3-76 multiple per vsys ............................................... 10-64
system alarm ....................................................... 3-74 subnets, overlapping ............................................... 10-65
traffic alarm ......................................................... 3-74 subrate option .......................................................... 12-20
types ..................................................................... 3-75 subscriptions
SNMPTRAP ............................................................... 4-132 registration and activation ................ 2-251 to 2-252
software keys ........................................................... 10-39 temporary service ............................................. 2-251
source address translation ...................................... 14-81 Sun RPC ALG
source interface-based routing (SIBR) ..................... 7-19 call scenarios...................................................... 2-126
source route................................................................ 3-96 Super G ................................................................... 12-144
source-based routing (SBR) ...................................... 7-17 SurfControl ..................................................... 4-99, 4-108
SSH ...................................................... 3-11 to 3-16, 4-132 SYN and FIN flags set ................................................ 4-12
authentication method priority ......................... 3-15 SYN checking .......................................4-15, 4-15 to 4-18
automated logins ................................................. 3-17 asymmetric routing ............................................. 4-16
connection procedure ......................................... 3-12 reconnaissance hole............................................ 4-17
forcing PKA authentication only ....................... 3-16 session interruption ............................................ 4-17
loading public keys, CLI ..................................... 3-15 session table floods ............................................. 4-17
loading public keys, TFTP .........................3-15, 3-17 SYN cookies ................................................................ 4-48
loading public keys, WebUI ............................... 3-15 SYN floods ..................................................... 4-38 to 4-43
management options .......................................... 3-28 alarm threshold ................................................... 4-42
password authentication .................................... 3-14 attack threshold ................................................... 4-41
PKA ....................................................................... 3-15 attacks................................................................... 4-38
PKA authentication ............................................. 3-14 destination threshold .......................................... 4-42
SSID drop unknown MAC addresses .......................... 4-43
binding to wireless interface.......................... 12-156 queue size ............................................................ 4-43
SSL ......................................................................3-5, 4-132 source threshold .................................................. 4-42
SSL Handshake Protocol SYN cookies ......................................................... 4-48
See SSLHP threshold .............................................................. 4-39
SSL management options ......................................... 3-28 timeout ................................................................. 4-43
SSL, with WebAuth .................................................... 9-64 SYN fragments ......................................................... 4-245
SSLHP............................................................................ 3-5 SYN-ACK-ACK proxy floods ...................................... 4-36
state transitions synchronization
endpoint host..................................................... 14-15 configuration ...................................................... 11-20
next-hop gateway router .................................. 14-15 RTOs ................................................................... 11-21
static entry ......................................................... 14-17 syslog............................................................... 3-56, 4-132
tunnel gateway .................................................. 14-16 encryption ............................................................ 3-78

Master Index  IX-XXI

 Concepts & Examples ScreenOS Reference Guide

facility ................................................ 3-72, 3-81, 3-88 IP-based .............................................................. 10-75

host ....................................................................... 3-72 logging .......................................................2-172, 13-4
hostname .................................3-72, 3-73, 3-81, 3-88 prioritizing............................................................ 4-33
messages .............................................................. 3-71 priority ................................................................ 2-174
port .................................................... 3-72, 3-81, 3-88 redirecting HTTP with WebAuth ....................... 9-50
security facility ................................. 3-72, 3-81, 3-88 shaping ............................................................... 2-193
system clock ..............................................2-253 to 2-257 sorting...................................................10-33 to 10-41
date & time ........................................................ 2-253 through traffic, vsys sorting ...............10-34 to 10-37
sync with client ................................................. 2-253 VLAN-based.............................. 10-42, 10-43 to 10-70
time zone ........................................................... 2-253 traffic alarms ..................................................3-68 to 3-71
system parameters .................................................. 2-257 traffic shaping .......................................................... 2-193
service priorities ................................................ 2-197
T traffic, prioritizing critical ......................................... 4-35
T3 interfaces Transparent mode ........2-80 to 2-92, 10-44, 10-45, 13-3
C-bit parity mode .............................................. 12-13 ARP/trace-route ................................................... 2-83
CSU compatibility ............................................. 12-20 blocking non-ARP traffic .................................... 2-82
TACACS+ blocking non-IP traffic ........................................ 2-82
auth server objects .............................................. 9-38 broadcast traffic .................................................. 2-81
clients retries ....................................................... 9-32 drop unknown MAC addresses.......................... 4-43
clients timeout ..................................................... 9-32 flood ...................................................................... 2-83
object properties ................................................. 9-32 in Active/Active NSRP ....................................... 11-44
ports...................................................................... 9-32 routes .................................................................... 2-82
retry timeout........................................................ 9-32 unicast options .................................................... 2-83
shared secret ....................................................... 9-32 Transparent mode, management options .............. 3-29
tags, VLANs .................................................................. 2-3 Transport mode ........................ 5-4, 5-218, 5-223, 5-228
TCP Triple DES
packet without flags ............................................ 4-14 See 3DES
session timeouts.................................................. 4-31 trunk ports ................................................................ 10-44
stream signatures.............................................. 4-161 trunk ports, Transparent mode .............................. 10-44
SYN flag checking ............................................. 5-307 trustee administrator............................................. 12-119
TCP proxy ................................................................... 3-96 tunnel interfaces ........................................................ 2-39
teardrop attacks ......................................................... 4-54 definition .............................................................. 2-39
Telnet .................................................................3-9, 4-132 policy-based NAT ................................................ 2-39
Telnet management options .................................... 3-28 Tunnel mode ................................................................ 5-4
Telnet, logging in via ................................................. 3-10 tunnel termination points....................................... 14-99
templates tunnel tracking ....................................................... 12-121
security policy ................................................... 4-186 Tunneled TLS .............................................................. 5-24
TFTP .......................................................................... 4-132
three-way handshakes .............................................. 4-38 U
threshold UAC clusters................................................................ 9-41
low-watermark .................................................... 4-31 UDP
thresholds checksum ........................................................... 5-247
high-watermark ................................................... 4-31 NAT-T encapsulation......................................... 5-242
time zone ................................................................. 2-253 UDP session timeouts ............................................... 4-32
timeout ..........................................................13-25, 13-26 Unified Access Control (UAC) ................................... 9-41
admin users ......................................................... 9-18 unified access control solution
auth users............................................................. 9-18 overview of ...........................................................9-vii
timestamp IP option ................................................. 4-11 unknown protocols .................................................. 4-243
TLS .............................................................................. 5-24 unknown unicast options .............................2-82 to 2-87
token codes ................................................................ 9-27 ARP ...........................................................2-84 to 2-87
Top-Level Aggregator (TLA)..................................... 14-35 flood ..........................................................2-83 to 2-84
trace-route .................................................................. 2-85 trace-route ............................................................ 2-85
traffic updating IDP engine................................................ 4-233
counting ....................................................2-173, 13-4 upstream routers ..................................................... 14-36

IX-XXII  Master Index

 Master Index

URL filtering Virtual Router Redundancy Protocol (VRRP) ........ 11-65

See Web filtering virtual routers ............................................... 14-48, 14-99
USB .............................................................................. 3-56 See VRs
users virtual routers, MIP default ....................................... 8-66
admin ..................................................................... 9-2 virtual routers, RIP .................................... 14-51 to 14-67
admin, timeout .................................................... 9-18 virtual security device groups
group IKE ID ........................................5-193 to 5-208 See VSD groups
groups, server support ........................................ 9-14 virtual security interface
IKE See VSI
See IKE users virtual system support............................................... 13-4
L2TP ..........................................................9-86 to 9-89 virtual systems ............................................................. 2-9
multiple-type .......................................................... 9-4 admins .................................................................. 3-34
shared IKE ID .......................................5-208 to 5-214 failover ................................................................ 11-63
WebAuth .............................................................. 9-14 load sharing ....................................................... 11-88
XAuth ........................................................9-70 to 9-84 manageability and security of ......................... 10-77
users, auth NSRP ................................................................... 11-63
See auth users read-only admins ................................................ 3-34
users, IKE VIP ....................................................................... 10-33
See IKE users VLAN groups............................................................. 11-44
users, multiple administrative .................................. 3-33 VLAN zone .................................................................. 2-81
VLAN1
V interface...................................................... 2-81, 2-87
VC .............................................................................. 12-76 zones ..................................................................... 2-81
VCI ............................................................................. 12-76 VLAN1, management options .................................. 3-29
vendor IDs, VSA ......................................................... 9-22 VLAN-based traffic classification ..10-42, 10-43 to 10-70
vendor-specific attributes ......................................... 9-21 VLANs
Verified mode ........................................................... 13-15 communicating with another VLAN 10-41, 10-67 to
Verisign ....................................................................... 5-44 10-70
VIP ............................................................................... 2-11 creating ................................................ 10-45 to 10-67
configuring ........................................................... 8-82 subinterfaces ...................................................... 10-64
definition ................................................................ 8-6 tag ........................................................... 10-45, 10-64
editing ................................................................... 8-84 Transparent mode ................................. 10-44, 10-45
global zones ......................................................... 8-82 trunking .............................................................. 10-44
reachable from other zones ............................... 8-82 VLAN-based traffic classification ..... 10-42, 10-43 to
removing .............................................................. 8-84 10-70
required information .......................................... 8-82 VLANs, tags ................................................................... 2-3
VIP services VNC ........................................................................... 4-132
custom and multi-port ............................8-85 to 8-88 voice-over IP
custom, low port numbers ................................. 8-81 bandwidth management .................................... 6-64
VIP, to zone with interface-based NAT .................... 2-94 VPI ............................................................................. 12-76
virtual adapters .......................................................... 9-70 VPI/VCI
virtual channel identifier configuring ......................................................... 12-81
See VCI values .................................................................. 12-84
virtual circuit VPN idletime .............................................................. 9-73
See VC VPN monitoring ...........................5-252 to 5-263, 12-121
virtual HA interfaces .......................................2-39, 11-28 destination address ............................ 5-254 to 5-256
virtual IP destination address, XAuth .............................. 5-254
See VIP ICMP echo requests........................................... 5-263
virtual path identifier outgoing interface .............................. 5-254 to 5-256
See VPI policies ................................................................ 5-255
Virtual Path Identifier/Virtual Channel Identifier rekey option ........................................... 5-253, 5-269
See VPI/VCI routing design ...................................................... 5-81
virtual private networks SNMP .................................................................. 5-263
See VPNs status changes ....................................... 5-252, 5-255

Master Index  IX-XXIII

 Concepts & Examples ScreenOS Reference Guide

VPNs filtering ................................................................. 7-39

Aggressive mode ................................................. 5-10 importing ............................................................. 7-42
AutoKey IKE ....................................... 3-43, 3-79, 5-7 maps ..................................................................... 7-38
configuration tips ....................................5-79 to 5-81 preference ............................................................ 7-30
cryptographic options.............................5-58 to 5-71 redistribution ....................................................... 7-37
Diffie-Hellman exchange.................................... 5-10 selection ............................................................... 7-30
for administrative traffic .................................... 3-78 VRs, routing tables
FQDN aliases ..................................................... 5-140 lookup ................................................................... 7-32
FQDN for gateways ............................5-139 to 5-150 lookup in multiple VRs ....................................... 7-34
Main mode ............................................................. 5-9 maximum entries ................................................ 7-29
manual key .......................................................... 3-79 VSA attribute types .................................................... 9-22
manual keys ........................................................ 3-43 VSAs ............................................................................ 9-21
MIP...................................................................... 5-150 VSD groups ............................ 4-182, 11-13, 11-22, 11-44
multiple tunnels per tunnel interface5-265 to 5-299 failover................................................................ 11-62
NAT for overlapping addresses .........5-150 to 5-161 heartbeats ...............................................11-24, 11-30
NAT-dst............................................................... 5-150 hold-down time ......................................11-36, 11-39
NAT-src ............................................................... 5-152 member states .....................................11-23 to 11-24
packet flow ..............................................5-73 to 5-79 priority numbers ............................................... 11-22
Phase 1 ................................................................... 5-9 VSIs...................................................................11-2, 11-22
Phase 2 ................................................................. 5-11 multiple VSIs per VSD group ........................... 11-63
policies ............................................................... 2-168 static routes........................................................ 11-25
policies for bidirectional ................................... 5-135 vsys
proxy IDs, matching ........................................... 5-79 admin ................................................................... 10-7
redundant gateways ...........................5-301 to 5-314 keys ..................................................................... 10-39
redundant groups, recovery procedure .......... 5-305 objects, creating .................................................. 10-4
replay protection ................................................. 5-12
route- vs policy-based ......................................... 5-72 W
SAs .......................................................................... 5-8 Web filtering ......................... 2-172, 4-98, 4-108 to 4-115
to zone with interface-based NAT ..................... 2-94 applying profiles to policies ............................. 4-105
Transport mode .................................................... 5-4 blocked URL message....................................... 4-112
tunnel always up ............................................... 5-253 blocked URL message type .............................. 4-112
tunnel zones ........................................................ 2-29 cache................................................................... 4-100
VPN groups ........................................................ 5-302 communication timeout ................................... 4-111
VPN monitoring and rekey .............................. 5-253 integrated ............................................................. 4-99
VRRP ..............................................................11-60, 11-65 profiles ................................................................ 4-103
VRs ..................................................................7-37 to 7-42 redirect ............................................................... 4-108
access lists ........................................................... 7-40 routing ................................................................ 4-113
BGP .......................................................7-104 to 7-111 server status ....................................................... 4-113
ECMP .................................................................... 7-36 servers per vsys ................................................. 4-109
forwarding traffic between .................................. 2-4 SurfControl
introduction ........................................................... 2-4 CPA servers..................................................... 4-99
modifying ............................................................. 7-22 SCFP .............................................................. 4-110
on vsys ................................................................. 7-26 server name .................................................. 4-111
OSPF .........................................................7-49 to 7-67 server port .................................................... 4-111
RIP ............................................................7-75 to 7-89 SurfControl servers ........................................... 4-100
route metrics ....................................................... 7-31 URL categories ................................................... 4-102
router IDs ............................................................. 7-22 Websense server name and server port ........ 4-111
SBR ....................................................................... 7-17 Web user interface
shared ................................................................. 10-39 See WebUI
shared, creating a ............................................. 10-40 WebAuth ............................................................9-14, 9-49
SIBR ...................................................................... 7-19 external user groups ........................................... 9-61
using two.............................................................. 7-23 pre-policy auth process ...................................... 9-49
VRs, routes redirecting HTTP traffic ...................................... 9-50
exporting .............................................................. 7-42 user groups, local ................................................ 9-60

IX-XXIV  Master Index

 Master Index

with SSL (user groups, external) ........................ 9-63 WLAN WAP operation modes
WebAuth, pre-policy auth process ......................... 2-172 802.11b clients, configuring ............ 12-129, 12-130
WebTrends .........................................................3-56, 3-72 802.11g clients, configuring .......................... 12-129
encryption ...................................................3-73, 3-78 WLAN, wireless interfaces
messages .............................................................. 3-73 binding.............................................................. 12-156
WebUI ................................................................3-2, 14-30 WMM
Help files ................................................................ 3-2 access categories ............................................. 12-146
management options .......................................... 3-28 configuring quality of service ......................... 12-146
WebUI, on sample client, downstream router ..... 14-38 default settings ................................................ 12-147
WEP......................................................................... 12-133 enabling ............................................................ 12-146
Whois ........................................................................ 4-132
wildcard addresses .................................................. 2-166 X
wildcards .......................................................5-196, 13-14 XAuth
WinNuke attacks ........................................................ 4-55 authentication .................................................. 14-136
WINS bypass-auth .......................................................... 9-71
L2TP settings ..................................................... 5-221 client authentication ........................................... 9-85
WINS server ........................................................... 14-130 defined .................................................................. 9-70
Wired Equivalent Privacy query remote settings ......................................... 9-71
See WEP ScreenOS as client............................................... 9-85
wireless bridge groups .......................................... 12-157 TCP/IP assignments ............................................ 9-72
wireless interface virtual adapters .................................................... 9-70
logical interface ................................................... 2-36 VPN idletime ........................................................ 9-73
wireless interfaces VPN monitoring ................................................. 5-254
binding SSID to ................................................ 12-156 when to use ...................................................... 14-130
binding to radio ............................................... 12-157 XAuth addresses
configuring ....................................................... 12-156 assignments ......................................................... 9-70
disabling ........................................................... 12-158 authentication, and ............................................. 9-81
Wireless Local Area Network IP address lifetime.................................. 9-72 to 9-73
See WLAN timeout ................................................................. 9-72
WLAN XAuth users ................................................... 9-70 to 9-84
access control list ............................................ 12-143 authentication ...................................................... 9-70
advanced parameters ..................................... 12-150 local authentication ............................................. 9-73
aging interval ................................................... 12-151 local group authentication .................................. 9-75
authentication and encryption ...................... 12-132 server support ...................................................... 9-14
beacon interval ................................................ 12-151 with L2TP ............................................................... 9-4
bridge groups ................................................... 12-157 XAuth, external
burst threshold ................................................ 12-152 auth server queries.............................................. 9-71
Clear to Send mode ........................................ 12-154 user authentication ............................................. 9-76
Clear to Send rate............................................ 12-154 user group authentication .................................. 9-78
Clear to Send type ........................................... 12-154 XR, configuring ...................................................... 12-145
configurations, reactivating ........................... 12-144
configuring Super G ........................................ 12-144 Y
country codes and channels .......................... 12-141 Yahoo! Messenger .................................................... 4-133
DTIM ................................................................. 12-152
extended channels .......................................... 12-141 Z
finding available channels .............................. 12-143 zip files, blocking ..................................................... 4-169
fragment threshold ......................................... 12-153 zombie agents .................................................. 4-27, 4-29
preamble length .............................................. 12-155 zones .....................................................2-25 to 2-33, 10-6
Request to Send threshold ............................. 12-153 defining................................................................. 2-30
site survey ........................................................ 12-142 editing ................................................................... 2-31
slot time ........................................................... 12-155 function ................................................................ 2-33
viewing wireless configuration information 12-158 function, MGT interface ...................................... 2-38
WMM ................................................................ 12-146 global .................................................................... 2-28
XR ..................................................................... 12-145 global security ........................................................ 2-2

Master Index  IX-XXV

 Concepts & Examples ScreenOS Reference Guide

Layer 2 ................................................................. 2-81

shared ................................................................. 10-39
tunnel ................................................................... 2-29
VLAN ............................................................2-33, 2-81
vsys ....................................................................... 10-6
zones, global .............................................................. 8-82
zones, ScreenOS ............................................2-25 to 2-33
predefined.............................................................. 2-2
security interfaces ................................................. 2-3
zones, security ....................................................2-2, 2-28
determination, destination zone ....................... 2-12
determination, source zone ............................... 2-10
global ...................................................................... 2-2
interfaces, monitoring ........................................ 2-73
interfaces, physical ............................................. 2-36

IX-XXVI  Master Index

Concepts & Examples
ScreenOS Reference Guide

Volume 2:
Fundamentals

Release 6.1.0, Rev. 03

Juniper Networks, Inc.

1194 North Mathilda Avenue
Sunnyvale, CA 94089
USA
408-745-2000
www.juniper.net
 Copyright Notice
Copyright © 2009 Juniper Networks, Inc. All rights reserved.

Juniper Networks, the Juniper Networks logo, JUNOS, NetScreen, ScreenOS, and Steel-Belted Radius are registered trademarks of Juniper Networks, Inc.
in the United States and other countries. JUNOSe is a trademark of Juniper Networks, Inc. All other trademarks, service marks, registered trademarks, or
registered service marks are the property of their respective owners.

All specifications are subject to change without notice. Juniper Networks assumes no responsibility for any inaccuracies in this document or for any
obligation to update information in this document. Juniper Networks reserves the right to change, modify, transfer, or otherwise revise this publication
without notice.

FCC Statement
The following information is for FCC compliance of Class A devices: This equipment has been tested and found to comply with the limits for a Class A
digital device, pursuant to part 15 of the FCC rules. These limits are designed to provide reasonable protection against harmful interference when the
equipment is operated in a commercial environment. The equipment generates, uses, and can radiate radio-frequency energy and, if not installed and
used in accordance with the instruction manual, may cause harmful interference to radio communications. Operation of this equipment in a residential
area is likely to cause harmful interference, in which case users will be required to correct the interference at their own expense.

The following information is for FCC compliance of Class B devices: The equipment described in this manual generates and may radiate radio-frequency
energy. If it is not installed in accordance with Juniper Networks’ installation instructions, it may cause interference with radio and television reception.
This equipment has been tested and found to comply with the limits for a Class B digital device in accordance with the specifications in part 15 of the FCC
rules. These specifications are designed to provide reasonable protection against such interference in a residential installation. However, there is no
guarantee that interference will not occur in a particular installation.

If this equipment does cause harmful interference to radio or television reception, which can be determined by turning the equipment off and on, the user
is encouraged to try to correct the interference by one or more of the following measures:

 Reorient or relocate the receiving antenna.

 Increase the separation between the equipment and receiver.

 Consult the dealer or an experienced radio/TV technician for help.

 Connect the equipment to an outlet on a circuit different from that to which the receiver is connected.

Caution: Changes or modifications to this product could void the user's warranty and authority to operate this device.

Disclaimer
THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED
WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED
WARRANTY, CONTACT YOUR JUNIPER NETWORKS REPRESENTATIVE FOR A COPY.

ii 
Table of Contents
About This Volume ix
Document Conventions.................................................................................... x
Web User Interface Conventions .............................................................. x
Command Line Interface Conventions ...................................................... x
Naming Conventions and Character Types .............................................. xi
Illustration Conventions .......................................................................... xii
Requesting Technical Support ........................................................................ xii
Self-Help Online Tools and Resources..................................................... xiii
Opening a Case with JTAC ...................................................................... xiii
Document Feedback ..................................................................................... xiii

Chapter 1 ScreenOS Architecture 1

Security Zones ................................................................................................. 2
Security Zone Interfaces................................................................................... 3
Physical Interfaces..................................................................................... 3
Subinterfaces............................................................................................. 3
Virtual Routers ................................................................................................. 4
Policies.............................................................................................................5
Virtual Private Networks .................................................................................. 6
Virtual Systems ................................................................................................9
Packet-Flow Sequence.................................................................................... 10
Jumbo Frames................................................................................................ 13
ScreenOS Architecture Example..................................................................... 14
Example: (Part 1) Enterprise with Six Zones............................................ 14
Example: (Part 2) Interfaces for Six Zones ............................................... 16
Example: (Part 3) Two Routing Domains ................................................. 18
Example: (Part 4) Policies ........................................................................ 20

Chapter 2 Zones 25
Viewing Preconfigured Zones......................................................................... 26
Security Zones ............................................................................................... 28
Global Zone ............................................................................................. 28
SCREEN Options...................................................................................... 28
Binding a Tunnel Interface to a Tunnel Zone.................................................. 29
Configuring Security Zones and Tunnel Zones ............................................... 30
Creating a Zone ....................................................................................... 30
Modifying a Zone..................................................................................... 31
Deleting a Zone ....................................................................................... 32
Function Zones ..............................................................................................33

Chapter 3 Interfaces 35
Interface Types ..............................................................................................36

Table of Contents  iii

 Concepts & Examples ScreenOS Reference Guide

Logical Interfaces..................................................................................... 36
Physical Interfaces ............................................................................ 36
Wireless Interfaces............................................................................ 36
Bridge Group Interfaces..................................................................... 37
Subinterfaces .................................................................................... 37
Aggregate Interfaces ......................................................................... 37
Redundant Interfaces ........................................................................ 37
Virtual Security Interfaces .................................................................38
Function Zone Interfaces ......................................................................... 38
Management Interfaces..................................................................... 38
High Availability Interfaces................................................................ 38
Tunnel Interfaces..................................................................................... 39
Deleting Tunnel Interfaces ................................................................ 42
Viewing Interfaces ......................................................................................... 43
Configuring Security Zone Interfaces ............................................................. 44
Binding an Interface to a Security Zone ................................................... 44
Unbinding an Interface from a Security Zone .......................................... 46
Addressing an L3 Security Zone Interface................................................ 47
Public IP Addresses ........................................................................... 47
Private IP Addresses.......................................................................... 48
Addressing an Interface .................................................................... 48
Modifying Interface Settings .................................................................... 49
Creating a Subinterface in the Root System ............................................. 50
Deleting a Subinterface............................................................................ 50
Creating a Secondary IP Address ................................................................... 51
Backup System Interfaces .............................................................................. 52
Configuring a Backup Interface................................................................ 52
Configuring an IP Tracking Backup Interface..................................... 52
Configuring a Tunnel-if Backup Interface .......................................... 53
Configuring a Route Monitoring Backup Interface ............................. 57
Loopback Interfaces ....................................................................................... 58
Creating a Loopback Interface .................................................................59
Setting the Loopback Interface for Management...................................... 59
Setting BGP on a Loopback Interface ....................................................... 59
Setting VSIs on a Loopback Interface....................................................... 60
Setting the Loopback Interface as a Source Interface ............................... 60
Interface State Changes.................................................................................. 61
Physical Connection Monitoring .............................................................. 63
Tracking IP Addresses ............................................................................. 63
Interface Monitoring ................................................................................ 68
Monitoring Two Interfaces ................................................................ 69
Monitoring an Interface Loop ............................................................ 70
Security Zone Monitoring ........................................................................ 73
Down Interfaces and Traffic Flow ............................................................ 74
Failure on the Egress Interface .......................................................... 75
Failure on the Ingress Interface ......................................................... 76

Chapter 4 Interface Modes 79

Transparent Mode.......................................................................................... 80
Zone Settings........................................................................................... 81
VLAN Zone........................................................................................ 81
Predefined Layer 2 Zones .................................................................81
Traffic Forwarding ................................................................................... 81
Unknown Unicast Options ....................................................................... 82

iv  Table of Contents
 Table of Contents

Flood Method.................................................................................... 83
ARP/Trace-Route Method .................................................................. 84
Configuring VLAN1 Interface for Management .................................. 87
Configuring Transparent Mode.......................................................... 89
NAT Mode...................................................................................................... 92
Inbound and Outbound NAT Traffic ........................................................ 94
Interface Settings..................................................................................... 95
Configuring NAT Mode ............................................................................ 95
Route Mode.................................................................................................... 98
Interface Settings..................................................................................... 99
Configuring Route Mode .......................................................................... 99

Chapter 5 Building Blocks for Policies 103

Addresses ....................................................................................................103
Address Entries .....................................................................................104
Adding an Address ..........................................................................104
Modifying an Address .....................................................................105
Deleting an Address ........................................................................105
Address Groups .....................................................................................105
Creating an Address Group .............................................................107
Editing an Address Group Entry ......................................................108
Removing a Member and a Group...................................................108
Services........................................................................................................108
Predefined Services ...............................................................................108
Internet Control Messaging Protocol ...............................................110
Handling ICMP Unreachable Errors .................................................112
Internet-Related Predefined Services...............................................113
Microsoft Remote Procedure Call Services ......................................114
Dynamic Routing Protocols.............................................................116
Streaming Video..............................................................................116
Sun Remote Procedure Call Services ...............................................117
Security and Tunnel Services ..........................................................117
IP-Related Services..........................................................................118
Instant Messaging Services..............................................................118
Management Services .....................................................................118
Mail Services ...................................................................................119
UNIX Services .................................................................................119
Miscellaneous Services ....................................................................120
Custom Services ....................................................................................120
Adding a Custom Service ................................................................121
Modifying a Custom Service............................................................122
Removing a Custom Service............................................................122
Setting a Service Timeout ......................................................................122
Service Timeout Configuration and Lookup.....................................122
Contingencies .................................................................................123
Example..........................................................................................124
Defining a Custom Internet Control Message Protocol Service...............125
Remote Shell Application Layer Gateway...............................................126
Sun Remote Procedure Call Application Layer Gateway.........................126
Typical RPC Call Scenario................................................................126
Customizing Sun RPC Services ........................................................127
Customizing Microsoft Remote Procedure Call Application Layer Gateway..
127
Real-Time Streaming Protocol Application Layer Gateway.....................129

Table of Contents  v
 Concepts & Examples ScreenOS Reference Guide

Dual-Stack Environment .................................................................130

RTSP Request Methods ...................................................................130
RTSP Status Codes ..........................................................................132
Configuring a Media Server in a Private Domain .............................133
Configuring a Media Server in a Public Domain ..............................135
Stream Control Transmission Protocol Application Layer Gateway ........137
Point-to-Point Tunneling Protocol Application Layer Gateway ...............137
Configuring the PPTP ALG...............................................................139
Service Groups.......................................................................................139
Modifying a Service Group ..............................................................140
Removing a Service Group ..............................................................141
Dynamic IP Pools.........................................................................................141
Port Address Translation .......................................................................142
Creating a DIP Pool with PAT ................................................................143
Modifying a DIP Pool .............................................................................144
Sticky DIP Addresses .............................................................................144
Using DIP in a Different Subnet .............................................................145
Using a DIP on a Loopback Interface .....................................................150
Creating a DIP Group.............................................................................154
Setting a Recurring Schedule........................................................................157

Chapter 6 Policies 159

Basic Elements.............................................................................................160
Three Types of Policies ................................................................................161
Interzone Policies ..................................................................................161
Intrazone Policies ..................................................................................161
Global Policies .......................................................................................162
Policy Set Lists .............................................................................................163
Policies Defined ...........................................................................................164
Policies and Rules..................................................................................164
Anatomy of a Policy ..............................................................................165
ID....................................................................................................166
Zones ..............................................................................................166
Addresses .......................................................................................166
Wildcard Addresses.........................................................................166
Services...........................................................................................167
Action .............................................................................................167
Application......................................................................................168
Name ..............................................................................................168
VPN Tunneling ................................................................................168
L2TP Tunneling ...............................................................................169
Deep Inspection ..............................................................................169
Placement at the Top of the Policy List ...........................................169
Session Limiting..............................................................................169
Source Address Translation.............................................................170
Destination Address Translation......................................................170
No Hardware Session ......................................................................170
User Authentication ........................................................................170
HA Session Backup .........................................................................172
Web Filtering ..................................................................................172
Logging ...........................................................................................172
Counting .........................................................................................173
Traffic Alarm Threshold ..................................................................173
Schedules........................................................................................173

vi  Table of Contents
 Table of Contents

Antivirus Scanning ..........................................................................173

Traffic Shaping................................................................................173
Policies Applied............................................................................................175
Viewing Policies.....................................................................................175
Creating Policies ....................................................................................175
Creating Interzone Policies Mail Service ..........................................175
Creating an Interzone Policy Set .....................................................179
Creating Intrazone Policies..............................................................183
Creating a Global Policy ..................................................................185
Entering a Policy Context ......................................................................186
Multiple Items per Policy Component....................................................186
Setting Address Negation.......................................................................187
Modifying and Disabling Policies ...........................................................190
Policy Verification..................................................................................190
Reordering Policies................................................................................191
Removing a Policy .................................................................................192

Chapter 7 Traffic Shaping 193

Managing Bandwidth at the Policy Level ......................................................193
Setting Traffic Shaping .................................................................................194
Setting Service Priorities ..............................................................................197
Setting Priority Queuing ...............................................................................199
Ingress Policing ............................................................................................203
Shaping Traffic on Virtual Interfaces ............................................................203
Interface-Level Traffic Shaping ..............................................................204
Policy-Level Traffic Shaping ...................................................................205
Packet Flow ...........................................................................................206
Example: Route-Based VPN with Ingress Policing ..................................206
Example: Policy-Based VPN with Ingress Policing..................................210
Traffic Shaping Using a Loopback Interface .................................................214
DSCP Marking and Shaping..........................................................................214
Enabling Differentiated Services Code Point ...................................215

Chapter 8 System Parameters 217

Domain Name System Support ....................................................................217
DNS Lookup ..........................................................................................218
DNS Status Table ...................................................................................219
Setting the DNS Server and Refresh Schedule .................................219
Setting a DNS Refresh Interval ........................................................220
Dynamic Domain Name System............................................................220
Setting Up DDNS for a Dynamic DNS Server...................................221
Setting Up DDNS for a DDO Server .................................................222
Proxy DNS Address Splitting..................................................................223
Dynamic Host Configuration Protocol ..........................................................225
Configuring a DHCP Server....................................................................227
Customizing DHCP Server Options .................................................230
Placing the DHCP Server in an NSRP Cluster...................................232
DHCP Server Detection ...................................................................232
Enabling DHCP Server Detection ....................................................232
Disabling DHCP Server Detection....................................................232
Assigning a Security Device as a DHCP Relay Agent ..............................233
Forwarding All DHCP Packets .........................................................237
Configuring Next-Server-IP..............................................................237

Table of Contents  vii

 Concepts & Examples ScreenOS Reference Guide

Using a Security Device as a DHCP Client..............................................238

Propagating TCP/IP Settings ..................................................................240
Configuring DHCP in Virtual Systems ....................................................242
Setting DHCP Message Relay in Virtual Systems ..........................................242
Point-to-Point Protocol over Ethernet ...........................................................243
Setting Up PPPoE ..................................................................................243
Configuring PPPoE on Primary and Backup Untrust Interfaces..............246
Configuring Multiple PPPoE Sessions over a Single Interface .................247
PPPoE and High Availability ..................................................................249
License Keys ................................................................................................250
Registration and Activation of Subscription Services ....................................251
Trial Service...........................................................................................251
Updating Subscription Keys...................................................................252
Adding Antivirus, Web Filtering, Anti-Spam, and Deep Inspection to an
Existing or a New Device ................................................................252
System Clock ...............................................................................................253
Date and Time.......................................................................................253
Daylight Saving Time.............................................................................253
Time Zone .............................................................................................253
Network Time Protocol..........................................................................254
Configuring Multiple NTP Servers....................................................254
Configuring a Backup NTP Server....................................................254
Device as an NTP Server .................................................................255
Maximum Time Adjustment............................................................255
NTP and NSRP ................................................................................256
Setting a Maximum Time Adjustment Value to an NTP Server ........256
Securing NTP Servers ......................................................................257

Index..........................................................................................................................IX-I

viii  Table of Contents

About This Volume

Volume 2: Fundamentals describes the ScreenOS architecture and its elements,

including examples for configuring various elements. This volume contains the
following chapters:

 Chapter 1, “ScreenOS Architecture,” presents the fundamental elements of the

architecture in ScreenOS and concludes with a four-part example illustrating an
enterprise-based configuration incorporating most of those elements. In this
and all subsequent chapters, each concept is accompanied by illustrative
examples.

 Chapter 2, “Zones,” explains security, tunnel, and function zones.

 Chapter 3, “Interfaces,” describes the various physical, logical, and virtual

interfaces on security devices.

 Chapter 4, “Interface Modes,” explains the concepts behind Transparent,

Network Address Translation (NAT), and Route interface operational modes.

 Chapter 5, “Building Blocks for Policies,” discusses the elements used for
creating policies and virtual private networks (VPNs): addresses (including VIP
addresses), services, and DIP pools. It also presents several example
configurations that support the H.323 protocol.

 Chapter 6, “Policies,” explores the components and functions of policies and

offers guidance on their creation and application.

 Chapter 7, “Traffic Shaping,” explains how you can prioritize services and
manage bandwidth at the interface and policy levels.

 Chapter 8, “System Parameters,” presents the concepts behind Domain Name

System (DNS) addressing, using Dynamic Host Configuration Protocol (DHCP)
to assign or relay TCP/IP settings, downloading and uploading system
configurations and software, and setting the system clock.

 ix
 Concepts & Examples ScreenOS Reference Guide

Document Conventions
This document uses the conventions described in the following sections:

 “Web User Interface Conventions” on page x

 “Command Line Interface Conventions” on page x

 “Naming Conventions and Character Types” on page xi

 “Illustration Conventions” on page xii

Web User Interface Conventions

The Web user interface (WebUI) contains a navigational path and configuration
settings. To enter configuration settings, begin by clicking a menu item in the
navigation tree on the left side of the screen. As you proceed, your navigation path
appears at the top of the screen, with each page separated by angle brackets.

The following example shows the WebUI path and parameters for defining an
address:

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: addr_1

IP Address/Domain Name:
IP/Netmask: (select), 10.2.2.5/32
Zone: Untrust

To open Online Help for configuration settings, click the question mark (?) in the
upper left of the screen.

The navigation tree also provides a Help > Config Guide configuration page to help
you configure security policies and Internet Protocol Security (IPSec). Select an
option from the list, and follow the instructions on the page. Click the ? character in
the upper left for Online Help on the Config Guide.

Command Line Interface Conventions

The following conventions are used to present the syntax of command line
interface (CLI) commands in text and examples.

In text, commands are in boldface type and variables are in italic type.

In examples:

 Variables are in italic type.

 Anything inside square brackets [ ] is optional.

 Anything inside braces { } is required.

x  Document Conventions
 About This Volume

 If there is more than one choice, each choice is separated by a pipe ( | ). For
example, the following command means “set the management options for the
ethernet1, the ethernet2, or the ethernet3 interface”:

set interface { ethernet1 | ethernet2 | ethernet3 } manage

NOTE: When entering a keyword, you only have to type enough letters to identify the
word uniquely. Typing set adm u whee j12fmt54 will enter the command set
admin user wheezer j12fmt54. However, all the commands documented in this
guide are presented in their entirety.

Naming Conventions and Character Types

ScreenOS employs the following conventions regarding the names of objects—such
as addresses, admin users, auth servers, IKE gateways, virtual systems, VPN
tunnels, and zones—defined in ScreenOS configurations:

 If a name string includes one or more spaces, the entire string must be
enclosed within double quotes; for example:

set address trust “local LAN” 10.1.1.0/24

 Any leading spaces or trailing text within a set of double quotes are trimmed;
for example, “ local LAN ” becomes “local LAN”.

 Multiple consecutive spaces are treated as a single space.

 Name strings are case-sensitive, although many CLI keywords are

case-insensitive. For example, “local LAN” is different from “local lan”.

ScreenOS supports the following character types:

 Single-byte character sets (SBCS) and multiple-byte character sets (MBCS).

Examples of SBCS are ASCII, European, and Hebrew. Examples of MBCS—also
referred to as double-byte character sets (DBCS)—are Chinese, Korean, and
Japanese.

 ASCII characters from 32 (0x20 in hexadecimals) to 255 (0xff), except double

quotes ( “ ), which have special significance as an indicator of the beginning or
end of a name string that includes spaces.

NOTE: A console connection only supports SBCS. The WebUI supports both SBCS and
MBCS, depending on the character sets that your browser supports.

Document Conventions  xi
 Concepts & Examples ScreenOS Reference Guide

Illustration Conventions
Figure 1 shows the basic set of images used in illustrations throughout this volume.

Figure 1: Images in Illustrations

Autonomous System Local Area Network (LAN)
or with a Single Subnet
Virtual Routing Domain or
Security Zone

Dynamic IP (DIP) Pool

Internet

Policy Engine
Security Zone Interfaces:
White = Protected Zone Interface
(example = Trust Zone)
Black = Outside Zone Interface
(example = Untrust Zone)
Generic Network Device

Tunnel Interface

Server

VPN Tunnel

Router

Juniper Networks
Switch Security Devices

Hub

Requesting Technical Support

Technical product support is available through the Juniper Networks Technical
Assistance Center (JTAC). If you are a customer with an active J-Care or JNASC
support contract, or are covered under warranty, and need postsales technical
support, you can access our tools and resources online or open a case with JTAC.

 JTAC policies—For a complete understanding of our JTAC procedures and

policies, review the JTAC User Guide located at
http://www.juniper.net/customers/support/downloads/710059.pdf.

 Product warranties—For product warranty information, visit

http://www.juniper.net/support/warranty/.

 JTAC hours of operation—The JTAC centers have resources available 24 hours a

day, 7 days a week, 365 days a year.

xii  Requesting Technical Support

 About This Volume

Self-Help Online Tools and Resources

For quick and easy problem resolution, Juniper Networks has designed an online
self-service portal called the Customer Support Center (CSC) that provides you with
the following features:

 Find CSC offerings—http://www.juniper.net/customers/support/

 Find product documentation—http://www.juniper.net/techpubs/

 Find solutions and answer questions using our Knowledge Base—

http://kb.juniper.net/

 Download the latest versions of software and review your release notes—
http://www.juniper.net/customers/csc/software/

 Search technical bulletins for relevant hardware and software notifications—

http://www.juniper.net/alerts/

 Join and participate in the Juniper Networks Community Forum—

http://www.juniper.net/company/communities/

 Open a case online in the CSC Case Manager—

http://www.juniper.net/customers/cm/

 To verify service entitlement by product serial number, use our Serial Number
Entitlement (SNE) Tool—
https://tools.juniper.net/SerialNumberEntitlementSearch/

Opening a Case with JTAC

You can open a case with JTAC on the Web or by telephone.

 Use the Case Manager tool in the CSC at http://www.juniper.net/customers/cm/.

 Call 1-888-314-JTAC (1-888-314-5822—toll free in USA, Canada, and Mexico).

For international or direct-dial options in countries without toll-free numbers, visit

us at http://www.juniper.net/customers/support/requesting-support/.

Document Feedback
If you find any errors or omissions in this document, contact Juniper Networks at
[email protected].

Document Feedback  xiii

 Concepts & Examples ScreenOS Reference Guide

xiv  Document Feedback

Chapter 1
ScreenOS Architecture

Juniper Networks ScreenOS architecture offers you flexibility in designing the layout
of your network security. On Juniper Networks security devices with more than two
interfaces, you can create numerous security zones and configure policies to
regulate traffic between and within zones. You can bind one or more interfaces to
each zone and enable different management and firewall options for each zone.
ScreenOS allows you to create the number of zones required by your network
environment, assign the number of interfaces required by each zone, and design
each interface according to your needs.

This chapter presents an overview of ScreenOS. It contains the following sections:

 “Security Zones” on page 2

 “Security Zone Interfaces” on page 3

 “Virtual Routers” on page 4

 “Policies” on page 5

 “Virtual Private Networks” on page 6

 “Virtual Systems” on page 9

 “Packet-Flow Sequence” on page 10

 “Jumbo Frames” on page 13

The chapter concludes with a four-part example that illustrates a basic configuration
for a security device using ScreenOS:

 “Example: (Part 1) Enterprise with Six Zones” on page 14

 “Example: (Part 2) Interfaces for Six Zones” on page 16

 “Example: (Part 3) Two Routing Domains” on page 18

 “Example: (Part 4) Policies” on page 20

 1
 Concepts & Examples ScreenOS Reference Guide

Security Zones
A security zone is a collection of one or more network segments requiring the
regulation of inbound and outbound traffic via policies (see “Policies” on page 5).
Security zones are logical entities to which one or more interfaces are bound. With
many types of Juniper Networks security devices, you can define multiple security
zones, the exact number of which you determine based on your network needs. In
addition to user-defined zones, you can also use the predefined zones: Trust,
Untrust, and DMZ (for Layer 3 operation), or V1-Trust, V1-Untrust, and V1-DMZ (for
Layer 2 operation). If you want, you can continue using just the predefined zones.
You can also ignore the predefined zones and use user-defined zones exclusively.
Optionally, you can use both kinds of zones—predefined and user-defined—side by
side. This flexibility for zone configuration allows you to create a network design
that best suits your specific needs. See Figure 2.

NOTE: The one security zone that requires no network segment is the global zone. (For
more information, see “Global Zone” on page 28.) Additionally, any zone without
an interface bound to it nor any address book entries can also be said not to
contain any network segments.

If you upgrade from an earlier version of ScreenOS, all your configurations for
these zones remain intact.

You cannot delete a predefined security zone. You can, however, delete a
user-defined zone. When you delete a security zone, you also automatically delete
all addresses configured for that zone.

Figure 2 shows a network configured with five security zones—three default zones
(Trust, Untrust, DMZ) and two user-defined zones (Finance, Eng). Traffic passes
from one security zone to another only if a policy permits it.

Figure 2: Predefined Security Zones

Finance

Untrust

Trust
Policy Security Device
Engine

Eng DMZ

2  Security Zones
 Chapter 1: ScreenOS Architecture

Security Zone Interfaces

An interface for a security zone can be thought of as a doorway through which
TCP/IP traffic can pass between that zone and any other zone.

Through the policies you define, you can permit traffic between zones to flow in one
direction or in both. With the routes that you define, you specify the interfaces that
traffic from one zone to another must use. Because you can bind multiple interfaces
to a zone, the routes you chart are important for directing traffic to the interfaces of
your choice.

NOTE: For traffic to flow between interfaces bound to the same zone, no policy is
required because both interfaces have security equivalency. ScreenOS requires
policies for traffic between zones, not within a zone.

To permit traffic to flow from zone to zone, you bind an interface to the zone
and—for an interface in Route or NAT mode (see “Interface Modes” on
page 79)—assign an IP address to the interface. Two common interface types are
physical interfaces and—for those devices with virtual-system support—
subinterfaces (that is, a Layer 2 substantiation of a physical interface). For more
information, see “Interfaces” on page 35.

Physical Interfaces
A physical interface relates to components that are physically present on the
security device. The interface-naming convention differs from device to device.

NOTE: To see the naming conventions for a specific security device, refer to the
installation and configuration guide for that device.

Subinterfaces
On devices that support virtual LANs (VLANs), you can logically divide a physical
interface into several virtual subinterfaces, each of which borrows the bandwidth it
needs from the physical interface from which it stems. A subinterface is an
abstraction that functions identically to a physical interface and is distinguished by
802.1Q VLAN tagging. The security device directs traffic to and from a zone with a
subinterface via its IP address and VLAN tag. For convenience, administrators
usually use the same number for a VLAN tag as the subinterface number. For
example, the interface ethernet1/2 using VLAN tag 3 is named ethernet1/2.3. This
refers to the interface module in the first bay, the second port on that module, and
subinterface number 3 (ethernet1/2.3).

NOTE: 802.1Q is an IEEE standard that defines the mechanisms for the implementation
of virtual bridged LANs and the ethernet frame formats used to indicate VLAN
membership via VLAN tagging.

Security Zone Interfaces  3

 Concepts & Examples ScreenOS Reference Guide

Note that although a subinterface shares part of its identity with a physical
interface, the zone to which you bind it is not dependent on the zone to which you
bind the physical interface. You can bind the subinterface ethernet1/2.3 to a
different zone than that to which you bind the physical interface ethernet1/2, or to
which you bind ethernet1/2.2. Similarly, there are no restrictions in terms of
IP-address assignments. The term subinterface does not imply that its address be in
a subnet of the address space of the physical interface.

Virtual Routers
A virtual router (VR) functions as a router. It has its own interfaces and its own
unicast and multicast routing tables. In ScreenOS, a security device supports two
predefined virtual routers. This allows the security device to maintain two separate
unicast and multicast routing tables and to conceal the routing information in one
virtual router from the other. For example, the untrust-vr is typically used for
communication with untrusted parties and does not contain any routing
information for the protected zones. Routing information for the protected zones is
maintained by the trust-vr. Thus, no internal network information can be gathered
by the covert extraction of routes from the untrust-vr, see Figure 3.

Figure 3: Virtual Router Security Zones

trust-vr routing domain untrust-vr routing domain

Finance
Untrust

Trust

Eng DMZ Note: The castle icon represents

an interface for a security zone.

Route Forwarding

When there are two virtual routers on a security device, traffic is not automatically
forwarded between zones that reside in different VRs, even if there are policies that
permit the traffic. If you want traffic to pass between virtual routers, you need to
either export routes between the VRs or configure a static route in one VR that
defines the other VR as the next hop. For more information about using two virtual
routers, see Volume 7: Routing.

4  Virtual Routers
 Chapter 1: ScreenOS Architecture

Policies
Juniper Networks security devices secure a network by inspecting, and then
allowing or denying, all connection attempts that require passage from one security
zone to another.

By default, a security device denies all traffic in all directions. Through the creation
of policies, you can control the traffic flow from zone to zone by defining the kinds
of traffic permitted to pass from specified sources to specified destinations at
scheduled times. At the broadest level, you can allow all kinds of traffic from any
source in one zone to any destination in all other zones without any scheduling
restrictions. At the narrowest level, you can create a policy that allows only one kind
of traffic between a specified host in one zone and another specified host in
another zone during a scheduled period, see Figure 4.

NOTE: Some security devices ship with a default policy that allows all outbound traffic
from the Trust to the Untrust zone but denies all inbound traffic from the Untrust
zone to the Trust zone.

Figure 4: Default Policy

Broadly defined Internet access: Any service Narrowly defined Internet access: SMTP service
from any point in the Trust zone to any point from a mail server in the Trust zone to a mail server
in the Untrust zone at any time in the Untrust zone from 5:00 AM to 7:00 PM

Untrust Untrust
Zone Zone

Trust Trust
Zone Zone

Every time a packet attempts to pass from one zone to another or between two
interfaces bound to the same zone, the security device checks its policy set lists for
a policy that permits such traffic (see “Policy Set Lists” on page 163). To allow traffic
to pass from one security zone to another—for example, from zone A to zone
B—you must configure a policy that permits zone A to send traffic to zone B. To
allow traffic to flow the other way, you must configure another policy permitting
traffic from zone B to zone A. For any traffic to pass from one zone to another, there
must be a policy that permits it. Also, if intrazone blocking is enabled, there must
be a policy to permit traffic to pass from one interface to another within that zone.
See Figure 5 on page 6.

Policies  5
 Concepts & Examples ScreenOS Reference Guide

Figure 5: Policy Architecture

trust-vr routing domain untrust-vr routing domain

Finance
Untrust

Policy
Trust Engine

DMZ
Eng Note: The castle icon represents
an interface for a security zone.

Route Forwarding

NOTE: For more information, see “Policies” on page 159.

If you configure multicast routing on a security device, you might have to configure
multicast policies. By default, a security device does not permit multicast control
traffic between zones. Multicast control traffic refers to the messages transmitted by
multicast protocols, such as Protocol Independent Multicast (PIM). Multicast policies
control the flow of multicast control traffic only. To allow data traffic (both unicast
and multicast) to pass between zones, you must configure firewall policies. (For
more information, see “Multicast Policies” on page 7-151.)

Virtual Private Networks

ScreenOS supports several virtual private network (VPN) configuration options. The
two main types are as follows:

 Route-based VPN—A route lookup determines which traffic the security device
encapsulates. Policies either permit or deny traffic to the destination specified
in the route. If the policy permits the traffic and the route references a tunnel
interface bound to a VPN tunnel, then the security device also encapsulates it.
This configuration separates the application of policies from the application of
VPN tunnels. Once configured, such tunnels exist as available resources for
securing traffic en route between one security zone and another.

 Policy-based VPN—A policy lookup determines which traffic the security

device encapsulates when the policy references a particular VPN tunnel and
specifies “tunnel” as the action.

6  Virtual Private Networks

 Chapter 1: ScreenOS Architecture

A route-based VPN is good choice for site-to-site VPN configurations because you
can be apply multiple policies to traffic passing through a single VPN tunnel. A
policy-based VPN is a good choice for dialup VPN configurations because the dialup
client might not have an internal IP address to which you can set a route. See
Figure 6.

The following steps provide a sense of the main elements involved in a route-based
VPN configuration:

1. While configuring the VPN tunnel (for example, vpn-to-SF, where SF is the
destination or end entity), specify a physical interface or subinterface on the
local device as the outgoing interface. (The IP address for this interface is what
the remote peer must use when configuring its remote gateway.)

2. Create a tunnel interface (for example, tunnel.1), and bind it to a security zone.

NOTE: You do not have to bind the tunnel interface to the same zone for which VPN
traffic is destined. Traffic to any zone can access a tunnel interface if a route points
to that interface.

3. Bind the tunnel interface tunnel.1 to the VPN tunnel vpn-to-SF.

4. To direct traffic through this tunnel, set up a route stating that traffic to SF must
use tunnel.1.

Figure 6: VPN Traffic

Policy Tunnel
Source Zone Engine Interface Destination Zone
VPN Tunnel
Routing
Table

tunnel.1 vpn-to-SF
Packet sent Packet arrives

At this point, the tunnel is ready for traffic bound for SF. You can now create
address-book entries, such as “Trust LAN” (10.1.1.0/24) and “SF LAN” (10.2.2.0/24)
and set up policies to permit or block different types of traffic from a specified
source, such as Trust LAN, to a specified destination, such as SF LAN. See Figure 7
on page 8.

Virtual Private Networks  7

 Concepts & Examples ScreenOS Reference Guide

Figure 7: VPN Traffic from Untrust Security Zone

The local security device routes traffic from the Trust zone to SF LAN in the Untrust zone through
the tunnel.1 interface. Because tunnel.1 is bound to the VPN tunnel vpn-to-SF, the device encrypts
the traffic and sends it through that tunnel to the remote peer.

untrust-vr routing domain

SF LAN
Untrust Zone 10.2.2.0/24
To Reach Use Outgoing Interface
1.1.1.0/24 eth1/2 eth1/2, 1.1.1.1/24
10.2.2.0/24 tunnel.1
0.0.0.0/0 1.1.1.250

Interface
tunnel.1

Local Device Default Gateway: VPN Tunnel

1.1.1.250 vpn-to-SF

trust-vr routing domain

Trust Zone
eth3/2–10.1.1.1/24
To Reach Use
10.1.1.0/24 eth3/2
0.0.0.0/0 untrust-vr

NOTE: For detailed information about VPNs, see Volume 5: Virtual Private Networks.

8  Virtual Private Networks

 Chapter 1: ScreenOS Architecture

Virtual Systems
Some Juniper Networks security devices support virtual systems (vsys). A virtual
system is a subdivision of the main system that appears to the user to be a
standalone entity. Virtual systems reside separately from each other and from the
root system within the same security device. The application of ScreenOS to virtual
systems involves the coordination of three main components: zones, interfaces,
and virtual routers. Figure 8 presents a conceptual overview of how ScreenOS
integrates these components at both the root and vsys levels.

Figure 8: Vsys Architecture

Note: The castle icon represents

a security zone interface.
trust-vr

untrust-vr Finance
DMZ

Mail Trust Eng

shared interface for

root and vsys1
root sys vsys1-vr
Untrust
Trust-vsys1
vsys1
subinterface
dedicated to vsys2-vr
vsys2 vsys2
Trust-vsys2
vsys3
physical interface
dedicated to vsys3 vsys3-vr
Trust-vsys3

NOTE: For further information about virtual systems and the application of zones,
interfaces, and virtual routers within the context of virtual systems, see Volume 10:
Virtual Systems.

Virtual Systems  9
 Concepts & Examples ScreenOS Reference Guide

Packet-Flow Sequence
In ScreenOS, the flow sequence of an incoming packet progresses as presented in
Figure 9.

Figure 9: Packet Flow Sequence Through Security Zones

Incoming
Packet
SCREEN Session MIP/VIP Route Policy NAT-Dst and/or Create Perform
Filter Lookup Host IP Lookup Lookup NAT-Src Session Operation

PBR Policy Set List

Incoming If packet does not Session Table
Interface match an existing src dst service action d 977 vsys id 0, flag
session, perform 000040/00,
steps 4-9. Forwarding Table
Source pid -1, did 0, time 180
10.10.10.0/24 eth1/1 13 (01) 10.10.10.1/1168 ->
Zone 0.0.0.0/0 untrust-vr 211.68.1.2/80, 6,
If it does match, go directly
to step 9. 002be0c0066b,
Permit = Forward packet subif 0, tun 0
Destination Interface Deny = Drop packet
and Reject = Drop packet and
If network traffic, Security Destination Zone send
source zone = Zones TCP RST to source
security zone to Tunnel = Use specified
which interface or tunnel for
VPN encryption
subinterface is
bound.
If destination zone = security zone,
If VPN traffic to
tunnel interface use the security zone for policy
bound to VPN lookup.
tunnel, source zone
= security zone in
which tunnel
interface is
configured. If destination zone = tunnel zone, use
If VPN traffic to the source zone for policy lookup.
tunnel interface in a
tunnel zone, source Tunnel
zone = carrier zone. Zone

1. The interface module identifies the incoming interface and, consequently, the
source zone to which the interface is bound.

The interface module uses the following criteria to determine the source zone:

 If the packet is not encapsulated, the source zone is the security zone to
which the incoming interface or subinterface is bound.

 If the packet is encapsulated and the tunnel interface is bound to a VPN

tunnel, the source zone is the security zone in which the tunnel interface is
configured.

 If the packet is encapsulated and the tunnel interface is in a tunnel zone,

the source zone is the corresponding carrier zone (a security zone that
carries a tunnel zone) for that tunnel zone.

2. If you have enabled SCREEN options for the source zone, the security device
activates the SCREEN module at this point. SCREEN checking can produce one
of the following three results:

10  Packet-Flow Sequence
 Chapter 1: ScreenOS Architecture

 If a SCREEN mechanism detects anomalous behavior for which it is

configured to block the packet, the security device drops the packet and
makes an entry in the event log.

 If a SCREEN mechanism detects anomalous behavior for which it is

configured to record the event but not block the packet, the security device
records the event in the SCREEN counters list for the ingress interface and
proceeds to the next step.

 If the SCREEN mechanisms detect no anomalous behavior, the security

device proceeds to the next step.

3. The session module performs a session lookup, attempting to match the packet
with an existing session.

 If the packet does not match an existing session, the security device
performs First Packet Processing, a procedure involving steps 4 through 9.

 If the packet matches an existing session, the security device performs Fast
Processing, using the information available from the existing session entry
to process the packet. Fast Processing bypasses steps 4 through 8 because
the information generated by those steps has already been obtained during
the processing of the first packet in the session.

4. If a mapped IP (MIP) or virtual IP (VIP) address is used, the address-mapping

module resolves the MIP or VIP so that the routing table can search for the
actual host address.

5. Prior to route lookup, ScreenOS checks the packet for policy based routing
(PBR). If PBR is enabled on that in-interface, the following actions apply to the
packet:

 The PBR policy bound to that in-interface is applied to the packet.

 If no PBR policy exists at the interface level, the PBR policy bound to the
zone associated with the in-interface is applied to the packet.

 If no PBR policy exists at the zone level, the PBR policy bound to the VR
associated with the in-interface is applied to the packet.

NOTE: For more information about policy based routing, see Volume 7: Routing.

If PBR is not enabled, the route table lookup finds the interface that leads to the
destination address. In so doing, the interface module identifies the destination
zone to which that interface is bound.

Packet-Flow Sequence  11
 Concepts & Examples ScreenOS Reference Guide

The interface module uses the following criteria to determine the destination zone:

 If the destination zone is a security zone, that zone is used for the policy
lookup.

 If the destination zone is a tunnel zone, the corresponding carrier zone is

used for the policy lookup.

 If the destination zone is the same as the source zone and intrazone
blocking is disabled for that zone, the security device bypasses steps 6 and
7 and creates a session (step 8). If intrazone blocking is enabled, then the
security device drops the packet.

6. The policy engine searches the policy set lists for a policy between the
addresses in the identified source and destination zones.

The action configured in the policy determines how the security device handles
the packet:

 If the action is permit, the security device will forward the packet to its
destination.

 If the action is deny, the security device will drop the packet.

 If the action is reject, the security device will drop the packet and—if the
protocol is TCP—send a reset (RST) to the source IP address.

 If the action is tunnel, the security device will forward the packet to the
VPN module, which encapsulates the packet and transmits it using the
specified VPN tunnel settings.

7. If destination address translation (NAT-dst) is specified in the policy, the NAT

module translates the original destination address in the IP packet header to a
different address.

If source address translation is specified (either interface-based NAT or

policy-based NAT-src), the NAT module translates the source address in the IP
packet header before forwarding it either to its destination or to the VPN
module.

(If both NAT-dst and NAT-src are specified in the same policy, the security device
first performs NAT-dst and then NAT-src.)

8. The session module creates a new entry in the session table containing the
results of steps 1 through 7.

The security device then uses the information maintained in the session entry
when processing subsequent packets of the same session.

9. The security device performs the operation specified in the session.

Some typical operations are source address translation, VPN tunnel selection
and encryption, decryption, and packet forwarding.

12  Packet-Flow Sequence
 Chapter 1: ScreenOS Architecture

Jumbo Frames
On some devices you can increase throughput by increasing the maximum packet
size, or message transmission unit (MTU), the device can process. Refer to the
installation and configuration guide for your device to find out if it supports jumbo
frames.

Frame size ranges from 1514 through 9830 bytes. To put the device in jumbo frame
mode, set the maximum frame size to a value from1515 through 9830 inclusive, for
example: set envar max-frame-size=9830. Use the unset envar max-frame-size
command to return the device to normal maximum frame size, which is 1514 bytes
(alternatively, you can use the command: set envar max-frame-size=1514). The
maximum frame size does not include the 4-byte frame check sequence at the end
of the frame. You must restart the system for changes to environmental variables to
take effect.

In jumbo frame mode, the following apply:

 Deep inspection (DI) is not supported.

 Packets sent through aggregate interfaces might be out of order.

 NSRP forwarding is not supported.

 Maximum firewall or VPN throughput requires at least four sessions (for

firewall) or tunnels (for VPN)

Jumbo Frames  13
 Concepts & Examples ScreenOS Reference Guide

ScreenOS Architecture Example

The following sections comprise a four-part example that illustrates some of the
concepts covered in the previous sections:

 “Example: (Part 1) Enterprise with Six Zones” on page 14

 “Example: (Part 2) Interfaces for Six Zones” on page 16

 “Example: (Part 3) Two Routing Domains” on page 18

 “Example: (Part 4) Policies” on page 20

Example: (Part 1) Enterprise with Six Zones

This is the first of a four-part example, the purpose of which is to illustrate some of
the concepts covered in the previous sections. For the second part, in which the
interfaces for each zone are set, see “Example: (Part 2) Interfaces for Six Zones” on
page 16. Here you configure the following six zones for an enterprise:

 Finance

 Trust

 Eng

 Mail

 Untrust

 DMZ

The Trust, Untrust, and DMZ zones are pre-configured. You must define the
Finance, Eng, and Mail zones. By default, a user-defined zone is placed in the
trust-vr routing domain. Thus, you do not have to specify a virtual router for the
Finance and Eng zones. However, in addition to configuring the Mail zone, you must
also specify that it be in the untrust-vr routing domain. You must also shift virtual
router bindings for the Untrust and DMZ zones from the trust-vr to the untrust-vr,
see Figure 10 on page 15.

NOTE: For more information about virtual routers and their routing domains, see
Volume 7: Routing.

14  ScreenOS Architecture Example

 Chapter 1: ScreenOS Architecture

Figure 10: Zone-to-Virtual Router Bindings

trust-vr routing domain untrust-vr routing domain

Finance Mail

Trust Untrust

Eng DMZ

WebUI
Network > Zones > New: Enter the following, then click OK:

Zone Name: Finance

Virtual Router Name: trust-vr
Zone Type: Layer 3: (select)

Network > Zones > New: Enter the following, then click OK:

Zone Name: Eng

Virtual Router Name: trust-vr
Zone Type: Layer 3: (select)

Network > Zones > New: Enter the following, then click OK:

Zone Name: Mail

Virtual Router Name: untrust-vr
Zone Type: Layer 3: (select)

Network > Zones > Edit (for Untrust): Select untrust-vr in the Virtual Router
Name drop-down list, then click OK.

Network > Zones > Edit (for DMZ): Select untrust-vr in the Virtual Router
Name drop-down list, then click OK.

CLI
set zone name finance
set zone name eng
set zone name mail
set zone mail vrouter untrust-vr
set zone untrust vrouter untrust-vr
set zone dmz vrouter untrust-vr
save

ScreenOS Architecture Example  15

 Concepts & Examples ScreenOS Reference Guide

Example: (Part 2) Interfaces for Six Zones

This is the second part of an ongoing example. For the first part, in which zones are
configured, see “Example: (Part 1) Enterprise with Six Zones” on page 14. For the
next part, in which virtual routers are configured, see “Example: (Part 3) Two
Routing Domains” on page 18. This part of the example demonstrates how to bind
interfaces to zones and configure them with an IP address and various
management options, see Figure 11.

Figure 11: Interface-to-Zone Bindings

1.3.3.1/24
eth1/1
Finance
10.1.2.1/24
VLAN tag 1 Mail
eth3/2.1 1.4.4.1/24
VLAN tag 2
eth1/1.2

Trust Untrust
10.1.1.1/24 1.1.1.1/24
eth3/2 eth1/2

Eng
10.1.3.1/24 DMZ
eth3/1 1.2.2.1/24
eth2/2

WebUI
1. Interface ethernet3/2
Network > Interfaces > Edit (for ethernet3/2): Enter the following, then click
OK:

Zone Name: Trust

Static IP: (select this option when present)
IP Address/Netmask: 10.1.1.1/24
Manageable: (select)
Management Services: WebUI, Telnet, SNMP, SSH (select)
Other Services: Ping (select)
2. Interface ethernet3/2.1
Network > Interfaces > Sub-IF New: Enter the following, then click OK:

Interface Name: ethernet3/2.1

Zone Name: Finance
Static IP: (select this option when present)
IP Address/Netmask: 10.1.2.1/24
VLAN Tag: 1
Other Services: Ping (select)

16  ScreenOS Architecture Example

 Chapter 1: ScreenOS Architecture

3. Interface ethernet3/1
Network > Interfaces > Edit (for ethernet3/1): Enter the following, then click
OK:

Zone Name: Eng

Static IP: (select this option when present)
IP Address/Netmask: 10.1.3.1/24
Other Services: Ping (select)
4. Interface ethernet1/1
Network > Interfaces > Edit (for ethernet1/1): Enter the following, then click
OK:

Zone Name: Mail

Static IP: (select this option when present)
IP Address/Netmask: 1.3.3.1/24
5. Interface ethernet1/1.2
Network > Interfaces > Sub-IF New: Enter the following, then click OK:

Interface Name: ethernet1/1.2

Zone Name: Mail
Static IP: (select this option when present)
IP Address/Netmask: 1.4.4.1/24
VLAN Tag: 2
6. Interface ethernet1/2
Network > Interfaces > Edit (for ethernet1/2): Enter the following, then click
OK:

Zone Name: Untrust

Static IP: (select this option when present)
IP Address/Netmask: 1.1.1.1/24
Manageable: (select)
Management Services: SNMP (select)
7. Interface ethernet2/2
Network > Interfaces > Edit (for ethernet2/2): Enter the following, then click
OK:

Zone Name: DMZ

Static IP: (select)
IP Address/Netmask: 1.2.2.1/24

CLI
1. Interface ethernet3/2
set interface ethernet3/2 zone trust
set interface ethernet3/2 ip 10.1.1.1/24
set interface ethernet3/2 manage ping
set interface ethernet3/2 manage webui
set interface ethernet3/2 manage telnet
set interface ethernet3/2 manage snmp
set interface ethernet3/2 manage ssh

ScreenOS Architecture Example  17

 Concepts & Examples ScreenOS Reference Guide

2. Interface ethernet3/2.1
set interface ethernet3/2.1 tag 1 zone finance
set interface ethernet3/2.1 ip 10.1.2.1/24
set interface ethernet3/2.1 manage ping
3. Interface ethernet3/1
set interface ethernet3/1 zone eng
set interface ethernet3/1 ip 10.1.3.1/24
set interface ethernet3/1 manage ping
4. Interface ethernet1/1
set interface ethernet1/1 zone mail
set interface ethernet1/1 ip 1.3.3.1/24
5. Interface ethernet1/1.2
set interface ethernet1/1.2 tag 2 zone mail
set interface ethernet1/1.2 ip 1.4.4.1/24
6. Interface ethernet1/2
set interface ethernet1/2 zone untrust
set interface ethernet1/2 ip 1.1.1.1/24
set interface ethernet1/2 manage snmp
7. Interface ethernet2/2
set interface ethernet2/2 zone dmz
set interface ethernet2/2 ip 1.2.2.1/24
save

Example: (Part 3) Two Routing Domains

This is the third part of an ongoing example. For the previous part, in which
interfaces for the various security zones are defined, see “Example: (Part 2)
Interfaces for Six Zones” on page 16. For the next part, in which the policies are set,
see “Example: (Part 4) Policies” on page 20. In this example, you only have to
configure a route for the default gateway to the Internet. The other routes are
automatically created by the security device when you create the interface IP
addresses, see Figure 12 on page 19.

18  ScreenOS Architecture Example

 Chapter 1: ScreenOS Architecture

Figure 12: Routing Domains

trust-vr untrust-vr

Finance
10.1.2.1/24 1.3.3.1/24
VLAN tag 1 eth1/1, Route Mail
eth3/2.1, NAT

1.4.4.1/24
VLAN tag 2
eth1/1.2, Route

Trust Untrust
10.1.1.1/24 1.1.1.1/24
eth3/2, NAT eth1/2, Route

Eng DMZ
10.1.3.1/24 1.2.2.1/24
eth3/1, NAT eth2/2, Route

Route Forwarding

WebUI
Network > Routing > Destination > (select trust-vr) New: Enter the following,
then click OK:

Network Address/Netmask: 0.0.0.0/0

Next Hop Virtual Router Name: (select); untrust-vr

Network > Routing > Destination > (select untrust-vr) New: Enter the
following, then click OK:

Network Address/Netmask: 0.0.0.0/0

Gateway: (select)
Interface: ethernet1/2
Gateway IP Address: 1.1.1.254

CLI
set vrouter trust-vr route 0.0.0.0/0 vrouter untrust-vr
set vrouter untrust-vr route 0.0.0.0/0 interface eth1/2 gateway 1.1.1.254
save

ScreenOS Architecture Example  19

 Concepts & Examples ScreenOS Reference Guide

The security device automatically creates the routes shown in Table 1 and Table 2
(except as indicated).

Table 1: Route Table for trust-vr

To Reach: Use Interface: Use Gateway/Vrouter: Created by:

0.0.0.0/0 n/a untrust-vr User-configured
10.1.3.0/24 eth3/1 0.0.0.0 Security device
10.1.1.0/24 eth3/2 0.0.0.0 Security device
10.1.2.0/24 eth3/2.1 0.0.0.0 Security device

Table 2: Route Table for untrust-vr

To Reach: Use Interface: Use Gateway/Vrouter: Created by:

1.2.2.0/24 eth2/2 0.0.0.0 Security device
1.1.1.0/24 eth1/2 0.0.0.0 Security device
1.4.4.0/24 eth1/1.2 0.0.0.0 Security device
1.3.3.0/24 eth1/1 0.0.0.0 Security device
0.0.0.0/0 eth1/2 1.1.1.254 User-configured

Example: (Part 4) Policies

This is the last part of an ongoing example. The previous part is “Example: (Part 3)
Two Routing Domains” on page 18. This part of the example demonstrates how to
configure new policies. See Figure 13.

Figure 13: Policies

trust-vr trust-vr
routing domain routing domain

Finance
Mail

Policy
Trust Engine Untrust

Eng
DMZ

Route Forwarding

20  ScreenOS Architecture Example

 Chapter 1: ScreenOS Architecture

For the purpose of this example, before you begin configuring new policies, you
need to create new service groups.

NOTE: When you create a zone, the security device automatically creates the address Any
for all hosts within that zone. This example makes use of the address Any for the
hosts.

WebUI
1. Service Groups
Policy > Policy Elements > Services > Groups > New: Enter the following,
then click OK:

Group Name: Mail-Pop3

Select Mail, then use the << button to move that service from the
Available Members column to the Group Members column.

Select Pop3, then use the << button to move that service from the
Available Members column to the Group Members column.

Policy > Policy Elements > Services > Groups > New: Enter the following,
then click OK:

Group Name: HTTP-FTPGet

Select HTTP, then use the << button to move that service from the
Available Members column to the Group Members column.

Select FTP-Get, then use the << button to move that service from the
Available Members column to the Group Members column.

2. Policies
Policy > Policies > (From: Finance, To: Mail) New: Enter the following, then
click OK:

Source Address:
Address Book Entry: (select), Any
Destination Address:
Address Book Entry: (select), Any
Service: Mail-Pop3
Action: Permit

Policy > Policies > (From: Trust, To: Mail) New: Enter the following, then click
OK:

Source Address:
Address Book Entry: (select), Any
Destination Address:
Address Book Entry: (select), Any
Service: Mail-Pop3
Action: Permit

ScreenOS Architecture Example  21

 Concepts & Examples ScreenOS Reference Guide

Policy > Policies > (From: Eng, To: Mail) New: Enter the following, then click
OK:

Source Address:
Address Book Entry: (select), Any
Destination Address:
Address Book Entry: (select), Any
Service: Mail-Pop3
Action: Permit

Policy > Policies > (From: Untrust, To: Mail) New: Enter the following, then
click OK:

Source Address:
Address Book Entry: (select), Any
Destination Address:
Address Book Entry: (select), Any
Service: Mail
Action: Permit

Policy > Policies > (From: Finance, To: Untrust) New: Enter the following, then
click OK:

Source Address:
Address Book Entry: (select), Any
Destination Address:
Address Book Entry: (select), Any
Service: HTTP-FTPGet
Action: Permit

Policy > Policies > (From: Finance, To: DMZ) New: Enter the following, then
click OK:

Source Address:
Address Book Entry: (select), Any
Destination Address:
Address Book Entry: (select), Any
Service: HTTP-FTPGet
Action: Permit

Policy > Policies > (From: Trust, To: Untrust) New: Enter the following, then
click OK:

Source Address:
Address Book Entry: (select), Any
Destination Address:
Address Book Entry: (select), Any
Service: HTTP-FTPGet
Action: Permit

22  ScreenOS Architecture Example

 Chapter 1: ScreenOS Architecture

Policy > Policies > (From: Trust, To: DMZ) New: Enter the following, then click
OK:

Source Address:
Address Book Entry: (select), Any
Destination Address:
Address Book Entry: (select), Any
Service: HTTP-FTPGet
Action: Permit

Policy > Policies > (From: Eng, To: DMZ) New: Enter the following, then click
OK:

Source Address:
Address Book Entry: (select), Any
Destination Address:
Address Book Entry: (select), Any
Service: HTTP-FTPGet
Action: Permit

Policy > Policies > (From: Eng, To: DMZ) New: Enter the following, then click
OK:

Source Address:
Address Book Entry: (select), Any
Destination Address:
Address Book Entry: (select), Any
Service: FTP-Put
Action: Permit

Policy > Policies > (From: Untrust, To: DMZ) New: Enter the following, then
click OK:

Source Address:
Address Book Entry: (select), Any
Destination Address:
Address Book Entry: (select), Any
Service: HTTP-FTPGet
Action: Permit

CLI
1. Service Groups
set group service mail-pop3 add mail
set group service mail-pop3 add pop3
set group service http-ftpget add http
set group service http-ftpget add ftp-get

ScreenOS Architecture Example  23

 Concepts & Examples ScreenOS Reference Guide

2. Policies
set policy from finance to mail any any mail-pop3 permit
set policy from trust to mail any any mail-pop3 permit
set policy from eng to mail any any mail-pop3 permit
set policy from untrust to mail any any mail permit
set policy from finance to untrust any any http-ftpget permit
set policy from finance to dmz any any http-ftpget permit
set policy from trust to untrust any any http-ftpget permit
set policy from trust to dmz any any http-ftpget permit
set policy from eng to untrust any any http-ftpget permit
set policy from eng to dmz any any http-ftpget permit
set policy from eng to dmz any any ftp-put permit
set policy from untrust to dmz any any http-ftpget permit
save

24  ScreenOS Architecture Example

Chapter 2
Zones

A zone can be a segment of network space to which security measures are applied
(a security zone), a logical segment to which a VPN tunnel interface is bound (a
tunnel zone), or either a physical or a logical entity that performs a specific function
(a function zone).

This chapter examines each type of zone, with particular emphasis given to the
security zone. It contains the following sections:

 “Viewing Preconfigured Zones” on page 26

 “Security Zones” on page 28

 “Binding a Tunnel Interface to a Tunnel Zone” on page 29

 “Configuring Security Zones and Tunnel Zones” on page 30

 “Function Zones” on page 33

 25
 Concepts & Examples ScreenOS Reference Guide

Viewing Preconfigured Zones

When you first boot up a security device, you can see a number of preconfigured
zones. To view these zones using the WebUI, click Network > Zones in the menu
column on the left. See Figure 14.

To view these zones using the CLI, use the get zone command. See Figure 15 on
page 27.

Figure 14: Network > Zones Page in the WebUI

26  Viewing Preconfigured Zones

 Chapter 2: Zones

Figure 15 shows the output of the get zone CLI command.

Figure 15: get zone Output

ns500> get zone

Total of 13 zones in vsys root

The root and virtual systems share these zones.

ID Name) Type) Attr) VR) Default-IF) VSYS) These zones (ID 0 and 10) do not and
cannot have an interface.
0) Null) Null) Shared) untrust-vr) null) Root)
1) Untrust) Sec(L3)) Shared) trust-vr) ethernet1/2) Root)
2) Trust) Sec(L3)) ) trust-vr) ethernet3/2) Root)
3) DMZ) Sec(L3)) ) trust-vr) ethernet2/2) Root) These zones (ID 1-3 and 11-14) provide backward
4) Self) Func) ) trust-vr) self) Root) compatibility when upgrading from a release prior to
5) MGT) Func) ) trust-vr) mgt) Root) ScreenOS 3.1.0—the upper 3 for devices in NAT or
6) HA) Func) ) trust-vr) ha) Root) Route mode, the lower 3 for devices in Transparent
mode.
10) Global) Sec(L3)) ) trust-vr) null) Root)
11) V1-Untrust) Sec(L2)) ) trust-vr) v1-untrust)
12) V1-Trust) Sec(L2)) ) trust-vr) v1-trust) Root)
13) V1-DMZ) Sec(L2)) ) trust-vr) v1-dmz) Root)
14) VLAN) Func) ) trust-vr vlan) Root)
16) Untrust-Tun) Tun) ) trust-vr) null)
-----------------------------------------------------------------------

By default, VPN tunnel interfaces are bound to the Untrust-Tun zone, whose carrier zone
is the Untrust zone. (When upgrading, existing tunnels are bound to the Untrust-Tun zone.)
Zone numbers 7-9 and 15 are reserved for future use.

The preconfigured zones shown in Figure 14 and Figure 15 can be grouped into
four different zone types:

 Security: Untrust, Trust, DMZ, Global, V1-Untrust, V1-Trust, V1-DMZ, V1-Null

 Tunnel: Untrust-Tun

 Function: Null, Self, MGT, HA, VLAN

 Null: Null

Viewing Preconfigured Zones  27

 Concepts & Examples ScreenOS Reference Guide

Security Zones
On a single security device, you can configure multiple security zones, dividing the
network into segments to which you can apply various security options to satisfy
the needs of each segment. At a minimum, you must define two security zones,
basically to protect one area of the network from the other. On some security
platforms, you can define many security zones, bringing finer granularity to your
network security design—and without deploying multiple security appliances to do
so.

Global Zone
You can identify a security zone because it has an address book and can be
referenced in policies. The Global zone satisfies these criteria. However, it does not
have one element that all other security zones have—an interface. The Global zone
serves as a storage area for mapped IP (MIP) and virtual IP (VIP) addresses. The
predefined Global zone address “Any” applies to all MIPs, VIPs, and other
user-defined addresses set in the Global zone. Because traffic going to these
addresses is mapped to other addresses, the Global zone does not require an
interface for traffic to flow through it.

The Global zone also contains addresses for use in global policies. For information
about global policies, see “Global Policies” on page 162.

NOTE: Any policy that uses the Global zone as its destination cannot support NAT or
traffic shaping.

SCREEN Options
A Juniper Networks firewall secures a network by inspecting, and then allowing or
denying, all connection attempts that require passage from one security zone to
another. For every security zone, and the MGT zone, you can enable a set of
predefined SCREEN options that detect and block various kinds of traffic that the
security device determines as potentially harmful.

For more information about available SCREEN options, see Volume 4:

Attack Detection and Defense Mechanisms.

28  Security Zones
 Chapter 2: Zones

Binding a Tunnel Interface to a Tunnel Zone

A tunnel zone is a logical segment that hosts one or more tunnel interfaces. A
tunnel zone is conceptually affiliated with a security zone in a “child-parent”
relationship. The security zone acting as the “parent,” which you can also conceive
of as a carrier zone, provides the firewall protection to the encapsulated traffic. The
tunnel zone provides packet encapsulation/decapsulation, and—by supporting
tunnel interfaces with IP addresses and netmasks that can host mapped IP (MIP)
addresses and dynamic IP (DIP) pools—can also provide policy-based NAT services.

The security device uses the routing information for the carrier zone to direct traffic
to the tunnel endpoint. The default tunnel zone is Untrust-Tun, and it is associated
with the Untrust zone. You can create other tunnel zones and bind them to other
security zones, with a maximum of one tunnel zone per carrier zone per virtual
system.

NOTE: The root system and all virtual systems can share the Untrust zone. However, each
system has its own separate Untrust-Tun zone.

By default, a tunnel zone is in the trust-vr routing domain, but you can also move a
tunnel zone into another routing domain. See Figure 16.

Figure 16: Tunnel Zone Routing Domain

The interface of the security zone

Security Zone hosting the tunnel zone provides firewall
protection for the encapsulated traffic.
Tunnel Zone
Traffic to or from a VPN tunnel VPN Tunnel
Tunnel
Interface Security Zone
The tunnel interface—which, when Interface
bound to a tunnel zone, must have an
IP address/netmask—supports
policy-based NAT for pre-encapsulated
and post-decapsulated VPN traffic.

Outbound traffic enters the tunnel zone via the tunnel interface, is encapsulated, and exits via the security zone interface.
Inbound traffic enters via the security zone interface, is decapsulated in the tunnel zone, and exits via the tunnel interface.

When upgrading from a version of ScreenOS earlier than 3.1.0, existing tunnel
interfaces are bound by default to the preconfigured Untrust-Tun tunnel zone, which
is a “child” of the preconfigured Untrust security zone. You can bind multiple tunnel
zones to the same security zone; however, you cannot bind a tunnel zone to another
tunnel zone.

In this example, you create a tunnel interface and name it tunnel.3. You bind it to
the Untrust-Tun zone, and assign it IP address 3.3.3.3/24. You then define a
mapped IP (MIP) address on tunnel.3, translating 3.3.3.5 to 10.1.1.5, which is the
address of a server in the Trust zone. Both the Untrust zone, which is the carrier
zone for the Untrust-Tun zone, and the Trust zone are in the trust-vr routing domain.

Binding a Tunnel Interface to a Tunnel Zone  29

 Concepts & Examples ScreenOS Reference Guide

WebUI
1. Tunnel Interface
Network > Interfaces > New Tunnel IF: Enter the following, then click OK:

Tunnel Interface Name: tunnel.3

Zone (VR): Untrust-Tun (trust-vr)
Fixed IP: (select)
IP Address / Netmask: 3.3.3.3/24
2. MIP
Network > Interfaces > Edit (for tunnel.3) > MIP > New: Enter the following,
then click OK:

Mapped IP: 3.3.3.5

Host IP Address: 10.1.1.5
Netmask: 255.255.255.255
Host Virtual Router Name: trust-vr

CLI
1. Tunnel Interface
set interface tunnel.3 zone Untrust-Tun
set interface tunnel.3 ip 3.3.3.3/24
2. MIP
set interface tunnel.3 mip 3.3.3.5 host 10.1.1.5
save

Configuring Security Zones and Tunnel Zones

For best performance, always save your changes after creating a zone. The
processes for creating, modifying, and deleting Layer 3 or Layer 2 security zones
and tunnel zones are quite similar.

NOTE: You cannot delete predefined security zones or the predefined tunnel zone,
although you can edit them.

Creating a Zone
To create a Layer 3 or Layer 2 security zone, or to create a tunnel zone, use either
the WebUI or CLI.

WebUI
Network > Zones > New: Enter the following, then click OK:

Zone Name: Type a name for the zone.

Virtual Router Name: Select the virtual router in whose routing domain
you want to place the zone.

30  Configuring Security Zones and Tunnel Zones

 Chapter 2: Zones

Zone Type:

Select Layer 3 to create a zone to which you can bind interfaces in NAT
or Route mode.

Select Layer 2 to create a zone to which you can bind interfaces in

Transparent mode.

Select Tunnel Out Zone when creating a tunnel zone and binding it to
a carrier zone, then select a specific carrier zone from the drop-down
list.

Block Intra-Zone Traffic: Select this option to block traffic between hosts
within the same security zone. By default, intra-zone blocking is disabled.

NOTE: The name of a Layer 2 security zone must begin with “L2-”; for example,
“L2-Corp” or “L2-XNet.”

CLI
set zone name zone [ l2 vlan_id_num | tunnel sec_zone ]
set zone zone block
set zone zone vrouter name_str
save

NOTE: When creating a Layer 2 security zone, the VLAN ID number must be 1 (for
VLAN1).

Modifying a Zone
To modify the name of a security zone or tunnel zone, or to change the carrier zone
for a tunnel zone, you must first delete the zone and then create it again with the
changes. You can change the intra-zone blocking option and the virtual router on an
existing zone.

NOTE: Before you can remove a zone, you must first unbind all interfaces bound to it.

Before you can change the virtual router for a zone, you must first remove any
interfaces bound to it.

WebUI
1. Modifying the Zone Name
Network > Zones: Click Remove (for the security zone or tunnel zone whose
name you want to change or for the tunnel zone whose carrier zone you want
to change).

When the prompt appears, asking for confirmation of the removal, click
Yes.

Network > Zones > New: Enter the zone settings with your changes, then click
OK.

Configuring Security Zones and Tunnel Zones  31

 Concepts & Examples ScreenOS Reference Guide

2. Changing the Intra-Zone Blocking Option or Virtual Router

Network > Zones > Edit (for the zone that you want to modify): Enter the
following, then click OK:

Virtual Router Name: From the drop-down list, select the virtual router into
whose routing domain you want to move the zone.

Block Intra-Zone Traffic: To enable, select the check box. To disable, clear it.

CLI
1. Modifying the Zone Name
unset zone zone
set zone name zone [ l2 vlan_id_num | tunnel sec_zone ]
2. Changing the Intra-Zone Blocking Option or Virtual Router
{ set | unset } zone zone block
set zone zone vrouter name_str
save

Deleting a Zone
For best performance, always save your changes and reboot after deleting a zone.
To delete a security zone or tunnel zone, do either of the following:

WebUI
Network > Zones: Click Remove (for the zone you want to delete).

When the prompt appears, asking for confirmation of the removal, click Yes.

CLI
unset zone zone
save

NOTE: Before you can remove a zone, you must first unbind all interfaces bound to it. To
unbind an interface from a zone, see “Binding an Interface to a Security Zone” on
page 44.

32  Configuring Security Zones and Tunnel Zones

 Chapter 2: Zones

Function Zones
The five function zones are Null, MGT, HA, Self, and VLAN. Each zone exists for a
single purpose, as explained in Table 3.

Table 3: Function Zones

Zone Description
Null Zone This zone serves as temporary storage for any interfaces that are not bound to
any other zone.
MGT Zone This zone hosts the out-of-band management interface, MGT. You can set firewall
options on this zone to protect the management interface from different types of
attacks. For more information about firewall options, see Volume 4:
Attack Detection and Defense Mechanisms.
HA Zone This zone hosts the high availability interfaces, HA1 and HA2. Although you can
set interfaces for the HA zone, the zone itself cannot be configured.
Self Zone This zone hosts the interface for remote management connections. When you
connect to the security device via HTTP, SCS, or Telnet, you connect to the Self
zone.
VLAN Zone This zone hosts the VLAN1 interface, which you use to manage the device and
terminate VPN traffic when the device is in Transparent mode. You can also set
firewall options on this zone to protect the VLAN1 interface from various attacks.

Function Zones  33
 Concepts & Examples ScreenOS Reference Guide

34  Function Zones
Chapter 3
Interfaces

Physical interfaces and subinterfaces allow traffic to enter and exit a security zone.
To allow network traffic to flow in and out of a security zone, you must bind an
interface to that zone and, if it is a Layer 3 zone, assign it an IP address. Then, you
must configure policies to allow traffic to pass from interface to interface between
zones. You can assign multiple interfaces to a zone, but you cannot assign a single
interface to multiple zones.

This chapter contains the following sections:

 “Interface Types” on page 36

 “Viewing Interfaces” on page 43

 “Configuring Security Zone Interfaces” on page 44

 “Creating a Secondary IP Address” on page 51

 “Backup System Interfaces” on page 52

 “Loopback Interfaces” on page 58

 “Interface State Changes” on page 61

 35
 Concepts & Examples ScreenOS Reference Guide

Interface Types
This section describes logical interfaces, function zone interfaces, and tunnel
interfaces. For information about viewing a table of all these interfaces, see
“Viewing Interfaces” on page 43.

Logical Interfaces
The purpose of logical interfaces is to provide an opening through which network
traffic can pass between zones. ScreenOS supports the following types of logical
Interfaces:

 Physical Interfaces

 Wireless Interfaces

 Bridge Group Interfaces

 Subinterfaces

 Aggregate Interfaces

 Redundant Interfaces

 Virtual Security Interfaces

Physical Interfaces
The name of a physical interface is composed of the media type, slot number (for
some devices), and index number, for example, ethernet3/2, ethernet0/2, wireless2,
wireless0/2, bgroup2, serial0/0, serial0/2, bri0/0, or adsl0/2. You can bind a physical
interface to any security zone where it acts as a doorway through which traffic
enters and exits the zone. Without an interface, no traffic can enter or leave the
zone.

On security devices that support changes to interface-to-zone bindings, three of the

physical ethernet interfaces are prebound to specific Layer 3 security zones—Trust,
Untrust, and DMZ. Which interface is bound to which zone is specific to each
platform. (For more information about security zones, see “Configuring Security
Zone Interfaces” on page 44.)

Wireless Interfaces
A wireless interface, like a physical interface, acts as a doorway through which
traffic enters and exits a security zone. Each wireless security device allows up to
four wireless interfaces (wireless0/0 — wireless0/3) to be active simultaneously.

A wireless interface cannot be bound to the Untrust security zone. (For more
information, see “Wireless Local Area Network” on page 12-125.)

36  Interface Types
 Chapter 3: Interfaces

Bridge Group Interfaces

Some security devices support bridge groups (bgroups). Bgroups let you group
multiple Ethernet and wireless interfaces together. Each bgroup constitutes its own
broadcast domain and provides high-speed Ethernet switching between interfaces
within the group. You can assign a single IP address to each bgroup interface. You
can bind a bgroup interface to any zone.

For devices that are preconfigured with bridge groups, there are two different bridge
group numbering systems. On some devices, the preconfigured bgroup interfaces
are identified as bgroup0 through bgroup3. On other devices the preconfigured
bgroup interfaces are identified as bgroup0/0 through bgroup0/2.

On some devices that support field-installable modules such as PIMs or mini-PIMs,

you can create bgroups containing some or all of the Ethernet ports on the module.
On these devices, you create bgroups identified as bgroupx/y, where x is the slot
number for the module containing the grouped ports and y is a number you assign
when creating the bridge group.

You can bind a bridge group interface to any zone. (For more information, see
“Binding an Interface to a Security Zone” on page 44.)

Subinterfaces
A subinterface, like a physical interface, acts as a doorway through which traffic
enters and exits a security zone. You can logically divide a physical interface into
several virtual subinterfaces. Each virtual subinterface borrows the bandwidth it
needs from the physical interface from which it stems, thus its name is an
extension of the physical interface name, for example, ethernet3/2.1 or ethernet0/2.1

You can bind a subinterface to any Layer 3 zone. You can bind a subinterface to the
same zone as its physical interface, or you can bind it to a different zone. (For more
information, see “Binding an Interface to a Security Zone” on page 44.)

Aggregate Interfaces
Some security devices support aggregate interfaces. An aggregate interface is the
accumulation of two or more physical interfaces that share the traffic load directed
to the IP address of the aggregate interface equally among themselves. By using an
aggregate interface, you can increase the amount of bandwidth available to a single
IP address. Also, if one member of an aggregate interface fails, the other member
or members can continue processing traffic—although with less bandwidth than
previously available.

NOTE: For more information about aggregate interfaces, see “Interface Redundancy and
Failover” on page 11-49.

Redundant Interfaces
You can bind two physical interfaces together to create one redundant interface,
which you can then bind to a security zone. One of the two physical interfaces acts
as the primary interface and handles all the traffic directed to the redundant
interface. The other physical interface acts as the secondary interface and stands by

Interface Types  37
 Concepts & Examples ScreenOS Reference Guide

in case the active interface experiences a failure. If that occurs, traffic to the
redundant interface fails over to the secondary interface, which becomes the new
primary interface. The use of redundant interfaces provides a first line of
redundancy before escalating a failover to the device level.

NOTE: For more information about redundant interfaces, see “Interface Redundancy and
Failover” on page 11-49.

Virtual Security Interfaces

Virtual security interfaces (VSIs) are the virtual interfaces that two security devices
forming a virtual security device (VSD) share when operating in HA mode. Network
and VPN traffic use the IP address and virtual MAC address of a VSI. The VSD then
maps the traffic to the physical interface, subinterface, or redundant interface to
which you have previously bound the VSI. When two security devices are operating
in HA mode, you must bind security zone interfaces that you want to provide
uninterrupted service in the event of a device failover to one or more virtual
security devices (VSDs). When you bind an interface to a VSD, the result is a virtual
security interface (VSI).

NOTE: For more information about VSIs and how they function with VSDs in an HA
cluster, see Volume 11: High Availability.

Function Zone Interfaces

Function zone interfaces, such as Management and HA, serve a special purpose.

Management Interfaces
On some security devices, you can manage the device through a separate physical
interface—the Management (MGT) interface—moving administrative traffic outside
the regular network user traffic. Separating administrative traffic from network user
traffic greatly increases security and ensures constant management bandwidth.

NOTE: For information about configuring the device for administration, see
“Administration” on page 3-1.

High Availability Interfaces

The high availability (HA) interface is a physical port used exclusively for HA
functions. In a redundant group, one unit serves as the primary device—performing
network firewall, VPN, and traffic-shaping functions—while the other unit serves as
the backup device, waiting to take over the firewall functions when the primary unit
fails. This is an Active/Passive configuration. You can also set up both members of
the cluster to be primary and backup for each other. This is an Active/Active
configuration. Both configurations are explained fully in Volume 11: High Availability.

38  Interface Types
 Chapter 3: Interfaces

Virtual HA Interfaces
On security devices without a dedicated HA interface, a virtual HA interface
provides the same functionality. Because there is no separate physical port used
exclusively for HA traffic, you must bind the virtual HA interface to one of the
physical ethernet ports. You use the same procedure for binding a network interface
to the HA zone as you do for binding a network interface to a security zone.

Tunnel Interfaces
A tunnel interface acts as a doorway to a VPN tunnel. Traffic enters and exits a VPN
tunnel via a tunnel interface.

When you bind a tunnel interface to a VPN tunnel, you can reference that tunnel
interface in a route to a specific destination and then reference that destination in
one or more policies. With this approach, you can finely control the flow of traffic
through the tunnel. It also provides dynamic routing support for VPN traffic. When
there is no tunnel interface bound to a VPN tunnel, you must specify the tunnel in
the policy itself and choose tunnel as the action. Because the action tunnel implies
permission, you cannot specifically deny traffic from a VPN tunnel.

You can perform policy-based NAT on outgoing or incoming traffic using a pool of
dynamic IP (DIP) addresses in the same subnet as the tunnel interface. A typical
reason for using policy-based NAT on a tunnel interface is to avoid IP address
conflicts between the two sites on either end of the VPN tunnel.

You must bind a route-based VPN tunnel to a tunnel interface so that the security
device can route traffic to and from it. You can bind a route-based VPN tunnel to a
tunnel interface that is either numbered (with IP address/netmask) or unnumbered
(without IP address/netmask). If the tunnel interface is unnumbered, you must
specify an interface from which the tunnel interface borrows an IP address. The
security device only uses the borrowed IP address as a source address when the
security device itself initiates traffic—such as OSPF messages—through the tunnel.
The tunnel interface can borrow the IP address from an interface in the same
security zone or from an interface in a different one as long as both zones are in the
same routing domain.

You can achieve very secure control of VPN traffic routing by binding all the
unnumbered tunnel interfaces to one zone, which is in its own virtual routing
domain, and borrowing the IP address from a loopback interface bound to the same
zone. For example, you can bind all the unnumbered tunnel interfaces to a
user-defined zone named “VPN” and configure them to borrow an IP address from
the loopback.1 interface, also bound to the VPN zone. The VPN zone is in a
user-defined routing domain named “vpn-vr.” You put all destination addresses to
which the tunnels lead in the VPN zone. Your routes to these addresses point to the
tunnel interfaces, and your policies control VPN traffic between other zones and the
VPN zone, see Figure 17.

Interface Types  39
 Concepts & Examples ScreenOS Reference Guide

Figure 17: Unnumbered Tunnel Interface Bindings

set vrouter name vpn-vr
set zone name vpn vrouter vpn-vr
set interface loopback.1 zone vpn
set interface loopback.1 ip 172.16.1.1/24 ethernet0/1 ethernet0/3
set interface tunnel.1 zone vpn 10.1.1.1/24 1.1.1.1/24
set interface tunnel.1 ip unnumbered loopback.1 Trust Zone Untrust Zone
trust-vr
External router
Configure addresses for src-1 and dst-1. 1.1.1.250
Configure a VPN tunnel and bind it to tunnel.1. src- 10.1.1.5

set vrouter trust-vr route 10.2.2.5/32 vrouter vpn-vr

set vrouter trust-vr route 0.0.0.0/0 interface ethernet0/3
gateway 1.1.1.250
set vrouter vpn-vr route 10.2.2.5 interface tunnel.1
tunnel.1 dst-1 10.2.2.5
unnumbered loopback.1
set policy from trust to vpn scr-1 dst-1 any permit 172.16.1.1/24
VPN Zone
The security device sends traffic destined for 10.2.2.5/32 from the trust-vr
to the vpn-vr. If tunnel.1 becomes disabled, the device drops the packet. vpn-vr
Because the default route (to 0.0.0.0/0) is only in the trust-vr, the device
does not attempt to send the packet in plain text out ethernet0/3.

Putting all the tunnel interfaces in such a zone is very secure because there is no
chance for the failure of a VPN, which causes the route to the associated tunnel
interface to become inactive, to redirect traffic intended for tunneling to use a
non-tunneled route—such as the default route. (For several suggestions about how
to avoid such a problem, see “Route-Based Virtual Private Network Security
Considerations” on page 5-81.)

You can also bind a tunnel interface to a tunnel zone. When you do, it must have an
IP address. The purpose of binding a tunnel interface to a tunnel zone is to make
NAT services available for policy-based VPN tunnels. See Figure 18 on page 41.

NOTE: Network Address Translation (NAT) services include dynamic IP (DIP) pools and
mapped IP (MIP) addresses defined in the same subnet as an interface.

40  Interface Types
 Chapter 3: Interfaces

Figure 18: Tunnel Interface to Zone Binding

Tunnel Security Zone
Interfaces Interfaces

When a tunnel interface is in a security zone, you must bind a VPN tunnel to the tunnel interface.
Numbered or Security Doing so allows you to create a route-based VPN configuration. The tunnel interface can be
VPN Tunnel numbered or unnumbered. If it is unnumbered, the tunnel interface borrows the IP address from
Unnumbered
the default interface of the security zone in which you created it.
Zone
Note: Only a tunnel interface with an IP address and netmask can support policy-based NAT.

Security When a numbered tunnel interface is in a security zone and is the only interface in that zone, you
VPN Tunnel
Numbered do not need to create a security zone interface. In this case, the security zone supports VPN
Zone traffic, but no other kind of traffic, via the tunnel interface.

Tunnel VPN Tunnel When a tunnel interface is bound to a tunnel zone, the tunnel interface must have an IP address
Numbered and netmask. This allows you to define DIP pools and MIP addresses on that interface. If you bind
a VPN tunnel to a tunnel zone, you cannot also bind it to a tunnel interface. In such cases, you
Zone must create a policy-based VPN configuration.

Conceptually, you can view VPN tunnels as pipes that you have laid. They extend
from the local device to remote gateways, and the tunnel interfaces are the
openings to these pipes. The pipes are always there, available for use whenever the
routing engine directs traffic to one of their interfaces.

Generally, assign an IP address to a tunnel interface if you want the interface to

support one or more dynamic IP (DIP) pools for source address translation (NAT-src)
and mapped IP (MIP) addresses for destination address translation (NAT-dst). For
more information about VPNs and address translation, see “VPN Sites with
Overlapping Addresses” on page 5-150. You can create a tunnel interface with an IP
address and netmask in either a security or tunnel zone.

If the tunnel interface does not need to support address translation, and your
configuration does not require the tunnel interface to be bound to a tunnel zone,
you can specify the interface as unnumbered. You must bind an unnumbered
tunnel interface to a security zone; you cannot bind it to a tunnel zone. You must
also specify an interface with an IP address that is in the same virtual routing
domain as the security zone to which the unnumbered interface is bound. The
unnumbered tunnel interface borrows the IP address from that interface.

NOTE: For examples showing how to bind a tunnel interface to a tunnel, see the
route-based VPN examples in “Site-to-Site VPN Configurations” on page 5-90 and
“Dialup Virtual Private Networks” on page 5-169.

If you are transmitting multicast packets through a VPN tunnel, you can enable
Generic Routing Encapsulation (GRE) on the tunnel interfaces to encapsulate
multicast packets in unicast packets. Juniper Networks security devices support
GREv1 for encapsulating IP packets in IPv4 unicast packets. For additional
information about GRE, see “Configuring Generic Routing Encapsulation on Tunnel
Interfaces” on page 7-149.

Interface Types  41
 Concepts & Examples ScreenOS Reference Guide

Deleting Tunnel Interfaces

You cannot immediately delete a tunnel interface that hosts mapped IP addresses
(MIPs) or dynamic IP (DIP) address pools. Before you delete a tunnel interface
hosting any of these features, you must first delete any policies that reference them.
Then you must delete the MIPs and DIP pools on the tunnel interface. Also, if a
route-based VPN configuration references a tunnel interface, you must first delete
the VPN configuration before you can delete the tunnel interface.

In this example, tunnel interface tunnel.2 is linked to DIP pool 8. DIP pool 8 is
referenced in a policy (ID 10) for VPN traffic from the Trust zone to the Untrust zone
through a VPN tunnel named vpn1. To remove the tunnel interface, you must first
delete the policy (or remove the reference to DIP pool 8 from the policy), and then
the DIP pool. Then, you must unbind tunnel.2 from vpn1. After removing all the
configurations that depend on the tunnel interface, you can then delete it.

WebUI
1. Deleting Policy 10, Which References DIP Pool 8
Policy > Policies (From: Trust, To: Untrust): Click Remove for Policy ID 10.

2. Deleting DIP Pool 8, Which Is Linked to tunnel.2

Network > Interfaces > Edit (for tunnel.2) > DIP: Click Remove for DIP ID 8.

3. Unbinding tunnel.2 from vpn1

VPNs > AutoKey IKE > Edit (for vpn1) > Advanced: Select None in the Bind
to: Tunnel Interface drop-down list, click Return, and then click OK.

4. Deleting tunnel.2
Network > Interfaces: Click Remove for tunnel.2.

CLI
1. Deleting Policy 10, Which References DIP Pool 8
unset policy 10
2. Deleting DIP Pool 8, Which Is Linked to tunnel.2
unset interface tunnel.2 dip 8
3. Unbinding tunnel.2 from vpn1
unset vpn vpn1 bind interface
4. Deleting tunnel.2
unset interface tunnel.2
save

42  Interface Types
 Chapter 3: Interfaces

Viewing Interfaces
You can view a table that lists all interfaces on your security device. Because they
are predefined, physical interfaces are listed regardless of whether or not you
configure them. Subinterfaces and tunnel interfaces are only listed once you create
and configure them.

To view the interface table in the WebUI, click Network > Interfaces. You can
specify the types of interfaces to display from the List Interfaces drop-down list.

To view the interface table in the CLI, use the get interface command.

The interface table displays the following information about each interface:

 Name: This field identifies the name of the interface.

 IP/Netmask: This field identifies the IP address and netmask address of the
interface.

 Zone: This field identifies the zone to which the interface is bound.

 Type: This field indicates the interface type: Layer 2, Layer 3, tunnel,
redundant, aggregate, VSI.

 Link: This field identifies whether the interface is active (up) or inactive (down).

 Configure: This field allows you modify or remove interfaces.

Figure 19: WebUI Interface Table

Viewing Interfaces  43
 Concepts & Examples ScreenOS Reference Guide

Figure 20: CLI Interface Table

Configuring Security Zone Interfaces

This section describes how to configure the following aspects of security zone
interfaces:

 Binding and unbinding an interface to a security zone

 Assigning an address to a Layer 3 (L3) security zone interface

 Modifying physical interfaces and subinterfaces

 Creating subinterfaces

 Deleting subinterfaces

NOTE: For information about setting traffic bandwidth for an interface, see “Traffic
Shaping” on page 193. For more information about the management and other
services options available per interface, see “Controlling Administrative Traffic” on
page 3-28.

Binding an Interface to a Security Zone

You can bind some physical interfaces to either an L2 or L3 security zone. WAN
interfaces, except for ADSL, cannot be bound to L2 security zones. You can bind a
subinterface only to an L3 security zone because a subinterface requires an IP
address. You can only assign an IP address to an interface after you have bound it to
an L3 security zone. Wireless interfaces cannot be bound to the Untrust security
zone.

Some security devices allow you to group multiple interfaces. Before adding an
interface to a group, the interface must be set to the Null security zone. After
interfaces are added to a group, the group interface must be assigned to a security
zone for connection to be established.

44  Configuring Security Zone Interfaces

 Chapter 3: Interfaces

You can configure Layer 3 interfaces that are bound to security zones to accept or
reject gratuitous ARP (G-ARP) requests and replies. Such interfaces include physical
Ethernet interfaces, subinterfaces, redundant interfaces, aggregate interfaces,
bgroup interfaces, and management (MGT) interfaces. This setting is not supported
on loopback interface, tunnel interface, all serial interfaces (including serial
interface,dialer interface, multilink interface on wan interface), dsl interface, wan
interface (including t1 e1 isdn interface) and wlan interface.

You can, similarly, configure Layer 2 zones such as V1-Trust, V1-Untrust, V1-DMZ or
some user-defined L2-zone and VLANx interface to accept or reject G-ARP requests
and replies.

Gratuitous ARP is used to update the ARP cache of interfaces in a network. In

addition, G-ARP helps detect IP conflicts. When an interface receives an ARP
request containing a source IP that matches its own, it indicates an IP conflict. Also,
frequent G-ARP transmissions could indicate bad Ethernet cabling or hardware.

You can configure an interface to reject G-ARP requests and replies based on your
security concerns. Accepting gratuitous ARP requests and replies might make the
network vulnerable to ARP spoofing attacks. However, you should enable G-ARP in
HA environments where the next upstream or downstream device is also in an HA
configuration and does not use virtual MAC addresses.

If the connected HA device fails, the virtual IP (VIP) shifts to the backup device.
Because the backup device uses its own actual MAC instead of a shared virtual MAC,
to ensure proper forwarding of traffic you should accept G-ARP request from the
connected HA device to understand the change in the network.

In this example, you bind ethernet0/5 to the Trust zone.

WebUI
Network > Interfaces > Edit (for ethernet0/5): Select Trust from the Zone
Name drop-down list, then click Apply.

CLI
set interface ethernet0/5 zone trust
save

In this example, you set ethernet0/3 and ethernet0/4 to be in the Null security zone,
group the interfaces in bgroup1, then bind the group to the DMZ security zone:

WebUI
Network > Interfaces > Edit (for ethernet0/3): Select Null from the Zone Name
drop-down list, then click Apply.

Network > Interfaces > Edit (for ethernet0/4): Select Null from the Zone Name
drop-down list, then click Apply.

Network > Interfaces > Edit (for bgroup1): Select DMZ from the Zone Name
drop-down list, then click Apply.

Network > Interfaces > Edit (for bgroup1): Check ethernet0/3 and
ethernet0/4 in the Bind to Current Bgroup column, then click Apply.

Configuring Security Zone Interfaces  45

 Concepts & Examples ScreenOS Reference Guide

CLI
set interface ethernet0/3 zone null
set interface ehternet0/4 zone null
set interface bgroup1 port ethernet0/3
set interface bgroup1 port ethernet0/4
set interface bgroup1 zone DMZ
save

Unbinding an Interface from a Security Zone

If an interface is unnumbered, you can unbind it from one security zone and bind it
to another. If an interface is numbered, you first must set its IP address and
netmask to 0.0.0.0. Then, you can unbind it from one security zone and bind it to
another one, and (optionally) reassign it an IP address/netmask.

In this example, ethernet0/3 has the IP address 210.1.1.1/24 and is bound to the
Untrust zone. You set its IP address and netmask to 0.0.0.0/0 and bind it to the Null
zone.

WebUI
Network > Interfaces > Edit (for ethernet0/3): Enter the following, then click
OK:

Zone Name: Null

IP Address/Netmask: 0.0.0.0/0

CLI
set interface ethernet0/3 ip 0.0.0.0/0
set interface ethernet0/3 zone null
save

To unbind an interface from a group and reassign it to a different security zone, the
interface must be released from the bgroup. Releasing the interface from the
bgroup puts the interface in the Null security zone. Once in the Null security zone,
the interface can be bound to any security zone then configured with an IP address.

WebUI
Network > Interfaces > Edit (for bgroup1) > Bind Port: Deselect ethernet0/3
in the Bind to Current Bgroup column, then click Apply.

Network > Interfaces > Edit (for ethernet0/3): Select Trust from the Zone
Name drop-down list, then click Apply.

CLI
unset interface bgroup1 port ethernet0/3
set interface ethernet0/3 zone trust
save

46  Configuring Security Zone Interfaces

 Chapter 3: Interfaces

Addressing an L3 Security Zone Interface

When defining a Layer 3 (L3) security zone interface or subinterface, you must
assign it an IP address and a netmask. If you bind the interface to a zone in the
trust-vr, you can also specify the interface mode as NAT or Route. (If the zone to
which you bind the interface is in the untrust-vr, the interface is always in Route
mode.)

NOTE: For examples of NAT and Route mode configurations, see “Interface Modes” on
page 79.

The two basic types of IP addresses to be considered when making interface

address assignments are as follows:

 Public addresses, which Internet service providers (ISPs) supply for use on a
public network like the Internet and which must be unique

 Private addresses, which a local network administrator assigns for use on a

private network and which other administrators can assign for use on other
private networks as well

NOTE: When you add an IP address to an interface, the security device checks via an ARP
request to make sure that the IP address does not already exist on the local
network. (The physical link must be up at the time.) If the IP address already
exists, a warning is displayed.

Public IP Addresses
If an interface connects to a public network, it must have a public IP address. Also,
if an L3 security zone in the untrust-vr connects to a public network and the
interfaces of zones in the trust-vr are in Route mode, then all the addresses in the
zones in the trust-vr—for interfaces and for hosts—must also be public addresses.
Public IP addresses fall into three classes, A, B, and C, as shown in Table 4.

Table 4: Public Address Ranges

Address Class Address Range Excluded Address Range

A 0.0.0.0 – 127.255.255.255 10.0.0.0 – 10.255.255.255, 127.0.0.0 – 127.255.255.255
B 128.0.0.0 – 191.255.255.255 172.16.0.0 – 172.31.255.255
C 192.0.0.0 – 223.255.255.255 192.168.0.0 – 192.168.255.255

NOTE: There are also D and E class addresses, which are reserved for special purposes.

An IP address is composed of four octets, each octet being 8 bits long. In a class A
address, the first 8 bits indicate the network ID, and the final 24 bits indicate the
host ID (nnn.hhh.hhh.hhh). In a class B address, the first 16 bits indicate the
network ID, and the final 16 bits indicate the host ID (nnn.nnn.hhh.hhh). In a class
C address, the first 24 bits indicate the network ID, and the final 8 bits indicate the
host ID (nnn.nnn.nnn.hhh).

Configuring Security Zone Interfaces  47

 Concepts & Examples ScreenOS Reference Guide

Through the application of subnet masks (or netmasks), you can further divide
networks. A netmask essentially masks part of the host ID so that the masked part
becomes a subnet of the network ID. For example, the 24-bit mask in the address
10.2.3.4/24 indicates that the first 8 bits (that is, the first octet—010) identify the
network portion of this private class A address, the next 16 bits (that is, the second
and third octets—002.003) identify the subnetwork portion of the address, and the
last 8 bits (the last octet—004) identify the host portion of the address. Using
subnets to narrow large network address spaces into smaller subdivisions greatly
increases the efficient delivery of IP data grams.

NOTE: The dotted-decimal equivalent of a 24-bit mask is 255.255.255.0

Private IP Addresses
If an interface connects to a private network, a local network administrator can
assign it any address, although it is conventional to use an address from the range
of addresses reserved for private use—10.0.0.0/8, 172.16.0.0 – 172.31.255.255,
192.168.0.0/16— as defined in RFC 1918, Address Allocation for Private Internets.

If an L3 security zone in the untrust-vr connects to a public network and the

interfaces bound to zones in the trust-vr are in NAT mode, then all the addresses in
the zones in the trust-vr—for interfaces and for hosts—can be private addresses.

Addressing an Interface
In this example, you assign ethernet0/5 the IP address 210.1.1.1/24 and give it the
Manage IP address 210.1.1.5. (Note that the Manage IP address must be in the
same subnet as the security zone interface IP address.) Finally, you set the interface
in NAT mode, which translates all internal IP addresses to the default interfaces
bound to the other security zones.

NOTE: The default interface in a security zone is the first interface bound to the zone. To
learn which interface is the default interface for a zone, see the Default IF column
on Network > Zones in the WebUI, or the Default-If column in the output from the
get zone command in the CLI.

WebUI
Network > Interfaces > Edit (for ethernet0/5): Enter the following, then click
OK:

IP Address/Netmask: 210.1.1.1/24
Manage IP: 210.1.1.5

CLI
set interface ethernet0/5 ip 210.1.1.1/24
set interface ethernet0/5 manage-ip 210.1.1.5
save

48  Configuring Security Zone Interfaces

 Chapter 3: Interfaces

Modifying Interface Settings

After you have configured a physical interface, a subinterface, a redundant
interface, an aggregate interface, or a Virtual Security Interface (VSI), you can later
change any of the following settings should the need arise:

 IP address and netmask.

 Manage IP address.

 (L3 zone interfaces) Management and network services.

 (Subinterface) Subinterface ID number and VLAN tag number.

 (Interfaces bound to L3 security zones in the trust-vr) Interface mode—NAT or

Route.

 (Physical interface) Traffic bandwidth settings (see “Traffic Shaping” on

page 193).

 (Physical, redundant, and aggregate interfaces) Maximum Transmission Unit

(MTU) size.

 (L3 interfaces) Block traffic from coming in and going out the same interface,
including traffic between a primary and secondary subnet or between
secondary subnets (this is done using the CLI set interface command with the
route-deny option).

For physical interfaces on some security devices, you can force the physical state of
the link to be down or up. By forcing the physical state of the link to be down, you
can simulate a disconnect of the cable from the interface port. (This is done with
the CLI set interface command with the phy link-down option.)

In this example, you make some modifications to ethernet0/1, an interface bound

to the Trust zone. You change the Manage IP address from 10.1.1.2 to 10.1.1.12. To
enforce tighter security of administrative traffic, you also change the management
services options, enabling SCS and SSL and disabling Telnet and WebUI.

WebUI
Network > Interfaces > Edit (for ethernet0/1): Make the following
modifications, then click OK:

Manage IP: 10.1.1.12

Management Services: (select) SSH, SSL; (clear) Telnet, WebUI

CLI
set interface ethernet0/1 manage-ip 10.1.1.12
set interface ethernet0/1 manage ssh
set interface ethernet0/1 manage ssl
unset interface ethernet0/1 manage telnet
unset interface ethernet0/1 manage web
save

Configuring Security Zone Interfaces  49

 Concepts & Examples ScreenOS Reference Guide

Creating a Subinterface in the Root System

You can create a subinterface on any physical interface in the root system or virtual
system. A subinterface makes use of VLAN tagging to distinguish traffic bound for it
from traffic bound for other interfaces. Note that although a subinterface stems
from a physical interface, from which it borrows the bandwidth it needs, you can
bind a subinterface to any zone, not necessarily that to which its “parent” interface
is bound. Additionally, the IP address of a subinterface must be in a different subnet
from the IP addresses of all other physical interfaces and subinterfaces.

NOTE: You can also configure subinterfaces on redundant interfaces and VSIs. For an
example that includes the configuration of a subinterface on a redundant
interface, see “Virtual System Failover” on page 11-96.

In this example, you create a subinterface for the Trust zone in the root system. You
configure the subinterface on ethernet0/1, which is bound to the Trust zone. You
bind the subinterface to a user-defined zone named “accounting,” which is in the
trust-vr. You assign it subinterface ID 3, IP address 10.2.1.1/24, and VLAN tag ID 3.
The interface mode is NAT.

WebUI
Network > Interfaces > New Sub-IF: Enter the following, then click OK:

Interface Name: ethernet0/1.3

Zone Name: accounting
IP Address/Netmask: 10.2.1.1/24
VLAN Tag: 3

CLI
set interface ethernet0/1.3 zone accounting
set interface ethernet0/1.3 ip 10.2.1.1/24 tag 3
save

Deleting a Subinterface
You cannot immediately delete a subinterface that hosts mapped IP addresses
(MIPs), virtual IP addresses (VIPs), or dynamic IP (DIP) address pools. Before you
delete a subinterface hosting any of these features, you must first delete any
policies or IKE gateways that reference them. Then you must delete the MIPs, VIPs,
and DIP pools on the subinterface.

In this example, you delete the subinterface ethernet0/1.1.

WebUI
Network > Interfaces: Click Remove for ethernet0/1.1.

A system message prompts you to confirm the removal.

Click Yes to delete the subinterface.

CLI
unset interface ethernet0/1.1
save

50  Configuring Security Zone Interfaces

 Chapter 3: Interfaces

Creating a Secondary IP Address

Each ScreenOS interface has a single, unique primary IP address. However, some
situations demand that an interface have multiple IP addresses. For example, an
organization might have additional IP address assignments and might not wish to
add a router to accommodate them. In addition, an organization might have more
network devices than its subnet can handle, as when there are more than 254 hosts
connected to a LAN. To solve such problems, you can add secondary IP addresses to
an interface in the Trust, DMZ, or user-defined zone.

NOTE: You cannot set multiple secondary IP addresses for interfaces in the Untrust zone.

Secondary addresses have certain properties that affect how you can implement
such addresses. These properties are as follows:

 There can be no subnet address overlap between any two secondary IP

addresses. In addition, there can be no subnet address overlap between a
secondary IP and any existing subnet on the security device.

 When you manage a security device through a secondary IP address, the

address always has the same management properties as the primary IP
address. Consequently, you cannot specify a separate management
configuration for the secondary IP address.

 You cannot configure a gateway for a secondary IP address.

 Whenever you create a new secondary IP address, the security device

automatically creates a corresponding routing table entry. When you delete a
secondary IP address, the device automatically deletes its routing table entry.

Enabling or disabling routing between two secondary IP addresses causes no

change in the routing table. For example, if you disable routing between two such
addresses, the security device drops any packets directed from one interface to the
other, but no change occurs in the routing table.

In this example, you set up a secondary IP address—192.168.2.1/24—for

ethernet0/1, an interface that has IP address 10.1.1.1/24 and is bound to the Trust
zone.

WebUI
Network > Interfaces > Edit (for ethernet0/1) > Secondary IP: Enter the
following, then click Add:

IP Address/Netmask: 192.168.2.1/24

CLI
set interface ethernet0/1 ip 192.168.2.1/24 secondary
save

Creating a Secondary IP Address  51

 Concepts & Examples ScreenOS Reference Guide

Backup System Interfaces

The interface backup feature allows you to configure a backup interface that can
take over traffic from a configured primary interface. You can back up any type of
interface with any other type of interface supported on the platform. The only
requirement is that both interfaces must be in the untrust zone.

You set a backup interface so that the security device can switch traffic over to it in
the event that the primary interface goes down (is unplugged, or fails), destinations
on the primary interface become unreachable, or the tunnel bound to the primary
interface becomes inactive. When the connection through the primary interface is
restored, ScreenOS automatically switches traffic from the backup interface to the
primary. The interface backup feature also provides a way for you manually to force
the primary interface to switch over to the backup, and to force the backup to
switch over to the primary. Each primary interface can have only one backup
interface, and each backup interface can have only one primary.

You can configure the security device to switch over to the backup interface when
any of the following conditions are met on the primary interface:

 Certain IP addresses become unreachable through the interface.

 Certain VPN tunnels on the interface become unreachable.

 A preconfigured route becomes unreachable through the interface.

For the security device to switch traffic over to a backup interface for any of these
reasons, you must first configure the primary interface for that purpose, then
configure the backup interface accordingly. You must also configure two default
routes, one for the primary interface and one for the backup interface. You can
configure the backup interface feature through the WebUI or at the CLI.

Configuring a Backup Interface

ScreenOS determines when to switch over to a backup interface by tracking or
monitoring activity on the primary interface. You can configure the following types
of backup interfaces:

 IP Tracking

 Tunnel-if tracking

 Route monitoring

Configuring an IP Tracking Backup Interface

In this example, you configure ScreenOS to track IP address 10.1.1.1 on the
primary interface (ethernet0/0), and to switch over to the backup interface (dialer1),
in the event that this address becomes unreachable. For a discussion of how IP
tracking works, see “Interface Failover with IP Tracking” on page 11-56.

52  Backup System Interfaces

 Chapter 3: Interfaces

WebUI
1. Configure Interfaces
Network > Interfaces > (for ethernet0/0) Edit > Monitor > Add: Enter the
following, then click Apply:

Track IP: 10.1.1.1

Weight: 200
Interval: 2
Threshold: 5

Network > Interfaces > Backup: Enter the following, then click Apply:

Primary interface (select): ethernet0/0

Backup Interface (select): dialer1
2. Configure Routes
Network > Routing > Destination > trust-tr New: Enter the following, then
click Apply:

IP Address/Netmask: 0.0.0.0/0
Interface (select): ethernet0/0

Network > Routing > Destination > trust-tr New: Enter the following, then
click Apply:

IP Address/Netmask: 0.0.0.0/0
Interface (select): dialer1

CLI
1. Configure Interfaces
set interface ethernet0/0 monitor track-ip
set interface ethernet0/0 monitor track-ip threshold 100
set interface ethernet0/0 monitor trackip ip 10.1.1.1 interval 2
set interface ethernet0/0 monitor trackip ip 10.1.1.1 threshold 5
set interface ethernet0/0 monitor trackip ip 10.1.1.1 weight 200
set interface ethernet0/0 backup interface dialer1 type track-ip
2. Configure Routes
set route 0.0.0.0/0 interface ether0/0
set route 0.0.0.0/0 interface dialer1
save

Configuring a Tunnel-if Backup Interface

In this example, you configure a pair of unidirectional VPN tunnels on
ethernet0/0—one on Router-1 and one on Router-2—and you configure dialer1 as
the backup interface on Route-1. The tunnels connect hosts in the Trust zone at a
branch site to an SMTP server in the Trust zone at the corporate site. The zones at
each site are in the trust-vr routing domain.

You configure both tunnels with the primary Untrust zone interface (ethernet0/0) as
the outgoing interface, and the backup VPN tunnel with the backup Untrust zone
interface (dialer1) as the outgoing interface. The security device monitors the
primary VPN tunnels to determine when to switch over to the backup. It does this
by comparing the backup weight with the VPN monitor threshold. You set the

Backup System Interfaces  53

 Concepts & Examples ScreenOS Reference Guide

threshold to 100 (set vpnmonitor threshold 100) and the backup weight to 200 (set
vpn vpn backup-weight 200). When the primary interface becomes inactive for
any reason, ScreenOS compares the VPN monitor threshold with the backup
weight, and if the backup weight is greater than the threshold, it switches the device
to the backup.

You also enable the VPN monitor rekey feature. In the event of a failover, this
feature enables the security device to revert traffic from the backup interface to the
primary if the accumulated weight of the VPN tunnels on the primary interface
becomes greater than the VPN monitor threshold.

The security device in the branch site receives its Untrust zone interfaces address,
default gateway, and DNS server addresses dynamically from two different ISPs.
Each ISP uses a different protocol. ISP-1 uses DHCP to assign an address to
ethernet0/0, and ISP-2 uses PPP to assign an address to dialer1. The security device
at the corporate site has a static IP address (2.2.2.2). The IP address of its default
gateway is 2.2.2.250.

The destination address for VPN monitoring is not the default—the remote gateway
IP address (2.2.2.2)—but the addresses of the server (10.2.2.10). If you use the
remote gateway IP address and it becomes unreachable, the primary tunnel always
switches over to the backup.

NOTE: Because this example is extensive, only the CLI configuration is included in its
entirety. The WebUI section lists the navigational paths to the pages where you can
set the various elements of the configuration. You can see what you need to set by
referring to the CLI commands.

WebUI (for Router-1)

1. Configure Interfaces
Network > Interfaces > Edit (for ethernet0/0)

Network > Interfaces > Edit (for bri1/0)

Network > Interfaces > New Tunnel IF

2. Configure VPN
VPNs > AutoKey IKE> New

VPNs > AutoKey Advanced > Gateway > New

3. Configure Asymmetric VPN

Network > Zones > Edit (for Trust)

4. Configure Backup Interface

Network > Interfaces > Backup

5. Configure Routes
Network > Routing > Destination > trust-vr

54  Backup System Interfaces

 Chapter 3: Interfaces

CLI (for Router-1)

1. Configure Interfaces
set interface ethernet0/0 zone untrust
set interface ethernet0/0 dhcp client

set interface bri2/0 isdn switch-type etsi

set interface dialer1 zone untrust
set dialer pool name pool-1
set interface bri2/0 dialer-pool-member pool-1
set interface dialer1 dialer-pool pool-1

set ppp profile isdn-ppp

set ppp profile isdn-ppp auth type chap
set ppp profile isdn-ppp auth local-name juniper
set ppp profile isdn-ppp auth secret juniper
set ppp profile isdn-ppp passive
set ppp dialer1 ppp profile isdn-ppp

set interface tunnel.1 untrust

set interface tunnel.1 ip unnumbered interface bgroup0
set interface tunnel.2 untrust
set interface tunnel.2 ip unnumbered interface bgroup0
2. Configure VPN
set ike gateway corp1 address 2.2.2.2 aggressive local-id ssg5ssg20-e0
outgoing-interface ethernet0/0 preshare juniper1 sec-level basic
set ike gateway corp1 address 2.2.2.2 aggressive local-id ssg5ssg20-dialer
outgoing-interface dialer1 preshare juniper2 sec-level basic

set vpn vpn1 gateway corp1 sec-level basic

set vpn vpn1 bind interface tunnel.1
set vpn vpn1 proxy-id local-ip 0.0.0.0/0 remote-ip 0.0.0.0/0 smtp
set vpn vpn1 monitor source-interface bgroup0 destination-ip 10.2.2.10 rekey
set vpn vpn1 backup-weight 200

set vpn vpn2 gateway corp2 sec-level basic

set vpn vpn2 bind interface tunnel.2
set vpn vpn2 proxy-id local-ip 0.0.0.0/0 remote-ip 0.0.0.0/0 smtp
set vpn vpn2 monitor source-interface bgroup0 destination-ip 10.2.2.10 rekey
3. Configure Asymmetric VPN
set zone trust asymmetric-vpn
4. Configure Backup Interface
set interface ethernet0/0 backup interface dialer1 type tunnel-if
set vpnmonitor threshold 100
5. Configure Routes
set route 10.2.2.10/32 interface tunnel.1
set route 10.2.2.10/32 interface tunnel.2
set route 0.0.0.0/0 interface ethernet0/0
save

Backup System Interfaces  55

 Concepts & Examples ScreenOS Reference Guide

WebUI (for Router-2)

1. Configure Interfaces
Network > Interfaces > Edit (for bgroup1)

Network > Interfaces > Edit (for ethernet0/0)

Network > Interfaces > New Tunnel IF

2. Configure Addresses
Policy > Policy Elements > Addresses > List > New

3. Configure VPN
VPNs > AutoKey IKE> New

VPNs > AutoKey Advanced > Gateway > New

4. Configure Asymmetric VPN

Network > Zones > Edit (for Trust)

Network > Interfaces > Edit (for ethernet0/0)

5. Configure Route
Network > Routing > Destination > trust-vr

6. Configure Policy
Policy > Policies (From Untrust to trust) > New

CLI (for Router-2)

1. Configure Interfaces
set interface bgroup zone trust
set interface bgroup ip 10.2.2.1/24
set interface bgroup nat
set interface ethernet0/0 zone untrust
set interface ethernet0/0 ip 2.2.2.2/24
set interface tunnel.1 zone trust
set interface tunnel.1 ip unnumbered interface bgroup0
set interface tunnel.2 zone untrust
set interface tunnel.2 ip unnumbered interface bgroup0
2. Configure Addresses
set address untrust branch 10.1.1.0/24
set address trust smtp-1 10.2.2.10/24
set address trust http-1 10.2.2.15/32
set group address trust servers add smtp-1
set group service vpn-srv add smtp
3. Configure VPN
set ike gateway branch1 dynamic ssg5ssg20-e0 aggressive outgoing-interface
ethernet0/0 preshare juniper1 sec-level basic
set ike gateway branch2 dynamic ssg5ssg20-dialer aggressive outgoing-interface
ethernet0/0 preshare juniper2 sec-level basic

set vpn vpn1 gateway branch1 sec-level basic

set vpn vpn1 gind interface tunnel.1
set vpn pvn1 proxy-id local-ip 0.0.0.0/0 remote-ip 0.0.0.0/0 smtp

56  Backup System Interfaces

 Chapter 3: Interfaces

set vpn vpn2 gateway branch2 sec-level basic

set vpn vpn2 bind interface tunnel.2
set vpn vpn2 proxy-id local-ip 0.0.0.0/0 remote-ip 0.0.0.0/0 smtp
4. Configure Asymmetric VPN
set zone trust asymmetric-vpn
5. Configure Route
set vrouter trust-vr route 0.0.0.0/0 interface ethernet 0/0 gateway 2.2.2.250
6. Configure Policy
set policy from untrust to trust branch servers vpn-srv permit
save

Configuring a Route Monitoring Backup Interface

In this example, on the primary interface (ethernet0/0) you configure a route to the
network segment 5.5.5.0/24 using gateway 10.10.10.1; and you configure dialer1
as the backup interface, with a route to the same network segment. You then
configure a default route for the primary interface to the same gateway (10.10.10.1),
and a default route for the dialer1 interface.

WebUI
1. Configure Interfaces
Network > Routing > Destination > trust-vr > New: Enter the following, then
click Apply:

IP Address/Netmask: 5.5.5.0/24
Gateway: (select)
Interface: (select) ethernet0/0
Gateway IP Address: 10.10.10.1

Network > Interfaces > Backup: Enter the following, then click Apply:

Primary Interface: (select) ethernet0/0

Backup Interface: (select) dialer1
Type: (select) route vrouter: (select) trust-vr
IP Address/Netmask: 5.5.5.0/24
2. Configure Route
Network > Routing > Source Interface (for ethernet0/0) > New: Enter the
following, then click Okay:

Gateway: 10.10.10.1

Network > Routing > Destination (for trust-vr) > New: Enter the following,
then click OK:

Interface (select): Null

CLI
set vrouter trust-vr route 5.5.5.0/24 interface ethernet0/0 gateway 10.10.10.1
set interface ethernet0/0 backup interface dialer1 type route vrouter trust-vr
5.5.5.0/24
set route 0.0.0.0/0 interface ethernet0/0 gateway 10.10.10.1
set route 0.0.0.0/0 interface dialer1
save

Backup System Interfaces  57

 Concepts & Examples ScreenOS Reference Guide

Loopback Interfaces
A loopback interface is a logical interface that emulates a physical interface on the
security device. However, unlike a physical interface, a loopback interface is always
in the up state as long as the device on which it resides is up. Loopback interfaces
are named loopback.id_num, where id_num is a number greater than or equal to 1
and denotes a unique loopback interface on the device. Like a physical interface,
you must assign an IP address to a loopback interface and bind it to a security zone.

NOTE: The maximum id_num value you can specify is platform-specific.

After defining a loopback interface, you can then define other interfaces as
members of its group. Traffic can reach a loopback interface if it arrives through one
of the interfaces in its group. Any interface type can be a member of a loopback
interface group—physical interface, subinterface, tunnel interface, redundant
interface, or VSI.

After creating a loopback interface, you can use it in many of the same ways as a
physical interface:

 Setting the Loopback Interface for Management

 Setting BGP on a Loopback Interface

 Setting VSIs on a Loopback Interface

 Setting the Loopback Interface as a Source Interface

NOTE: You cannot bind a loopback interface to an HA zone, nor can you configure a
loopback interface for Layer 2 operation or as a redundant/aggregate interface.
You cannot configure the following features on loopback interfaces: NTP, DNS, VIP,
secondary IP, track IP, or WebAuth.

When a loopback interface is used as the outgoing Interface in a VPN

configuration, then the loopback interface must be in the same zone as the
outgoing physical interface.

You can define a MIP on a loopback interface. This allows the MIP to be accessed by
a group of interfaces; this capability is unique to loopback interfaces. For
information about using the loopback interface with MIPs, see “MIP and the
Loopback Interface” on page 8-73.

You can manage the security device using either the IP address of a loopback
interface or the manage IP address that you assign to a loopback interface.

58  Loopback Interfaces
 Chapter 3: Interfaces

Creating a Loopback Interface

In the following example, you create the loopback interface loopback.1, bind it to
the Untrust zone, and assign the IP address 1.1.1.27/24 to it.

WebUI
Network > Interfaces > New Loopback IF: Enter the following, then click OK:

Interface Name: loopback.1

Zone: Untrust (select)
IP Address/Netmask: 1.1.1.27/24

CLI
set interface loopback.1 zone untrust
set interface loopback.1 ip 1.1.1.27
save

NOTE: The loopback interface is not directly accessible from networks or hosts that
reside in other zones. You must define a policy to permit traffic to and from the
interface.

Setting the Loopback Interface for Management

In the following example, you configure the previously defined loopback.1 interface
as a management interface for the device.

WebUI
Network > Interfaces > loopback.1 > Edit: Select all the management
options, then click OK:

CLI
set interface loopback.1 manage
save

Setting BGP on a Loopback Interface

The loopback interface can support the BGP dynamic routing protocol on the
security device. In the following example, you enable BGP on the loopback.1
interface.

NOTE: To enable BGP on the loopback interface, you must first create a BGP instance for
the virtual router in which you plan to bind the interface. For information about
configuring BGP on Juniper Networks security devices, See Volume 7: Routing.

WebUI
Network > Interfaces > loopback.1 > Edit: Select Protocol BGP, then click
OK:

CLI
set interface loopback.1 protocol bgp
save

Loopback Interfaces  59
 Concepts & Examples ScreenOS Reference Guide

Setting VSIs on a Loopback Interface

You can configure Virtual Security Interfaces (VSIs) for NSRP on a loopback
interface. The physical state of the VSI on the loopback interface is always up. The
interface can be active or not, depending upon the state of the VSD group to which
the interface belongs.

WebUI
Network > Interfaces > New VSI IF: Enter the following, then click OK:

Interface Name: VSI Base: loopback.1

VSD Group: 1
IP Address/Netmask: 1.1.1.1/24

CLI
set interface loopback.1:1 ip 1.1.1.1/24
save

Setting the Loopback Interface as a Source Interface

You can use a loopback interface as a source interface for certain traffic that
originates from the security device. (When you define a source interface for an
application, the specified source interface address is used instead of the outbound
interface address to communicate with an external device.) In the following
example, you specify that the security device uses the previously defined
loopback.1 interface for sending syslog packets.

WebUI
Configuration > Report Settings > Syslog: Enter the following, then click
Apply:

Enable Syslog Messages: (select)

Source interface: loopback.1 (select)
Syslog Servers:
No.: 1 (select)
IP/Hostname: 10.1.1.1
Traffic Log: (select)
Event Log: (select)

CLI
set syslog config 10.1.1.1 log all
set syslog src-interface loopback.1
set syslog enable
save

60  Loopback Interfaces
 Chapter 3: Interfaces

Interface State Changes

An interface can be in one of the states described in Table 5.

Table 5: Interface States

State Description
Physically Up For physical ethernet interfaces operating at either Layer 2 (Transparent
mode) or Layer 3 (Route Mode) in the Open Systems Interconnection (OSI)
model. An interface is physically up when it is cabled to another network
device and can establish a link to that device.
Logically Up For both physical interfaces and logical interfaces (subinterfaces, redundant
interfaces, and aggregate interfaces). An interface is logically up when traffic
passing through that interface is able to reach specified devices (at tracked
IP addresses) on a network.
Physically Down An interface is physically down when it is not cabled to another network
device or when it is cabled but cannot establish a link. You can also force an
interface to be physically down with the following CLI command: set
interface interface phy link-down.
Logically Down An interface is logically down when traffic passing through that interface
cannot reach specified devices (at tracked IP addresses) on a network.

The physical state of an interface takes precedence over its logical state. An
interface can be physically up and—at the same time—be either logically up or
logically down. If an interface is physically down, its logical state becomes
irrelevant.

When the state of an interface is up, all routes that make use of that interface
remain active and usable. When the state of an interface is down, the security
device deactivates all routes using that interface—although, depending on whether
the interface is physically or logically down, traffic might still flow through an
interface whose state is down (see “Down Interfaces and Traffic Flow” on page 74).
To compensate for the loss of routes caused by the loss of an interface, you can
configure alternate routes using an alternate interface.

Depending on how you set up the action that an observed interface state change
can cause, a state change from up to down in a monitored interface can cause the
monitoring interface to change its state from down to up. To configure this behavior,
you can use the following CLI command:

set interface interface monitor threshold number action up { logically | physically }

When you enter the above command, the security device automatically forces the
monitoring interface into a down state. If the monitored object (tracked IP address,
interface, zone) fails, then the state of the monitoring interface becomes up—either
logically or physically, per your configuration.

Interface State Changes  61

 Concepts & Examples ScreenOS Reference Guide

An interface can monitor objects for one or more of the following events. See
Figure 21 on page 62. Each of these events by itself or in combination can cause
the state of the monitoring interface to change from up to down and from down to
up:

 Physical disconnection/reconnection

 IP tracking failure/success

 Failure/success of a monitored interface

 Failure/success of a monitored security zone

Figure 21: Interface State Monitoring

f A monitored object fails … ...and the weight for that object is
greater than or equal to the
monitor failure threshold…

Physical
Disconnection

...and the action is set to down…

Interface becomes disconnected.

IP Tracking
Failure
...then the monitoring
interface goes down.

No Replies to ICMP Echo Requests.

Monitored
Interface Failure

Monitoring
Interface
IP Tracking failures exceed threshold.

Security Zone
Monitored Zone
Failure

All interfaces in the same zone go down.

If, after failing, a monitored object succeeds (the interface is reconnected or IP

tracking again succeeds), then the monitoring interface comes back up. There is
approximately a one-second delay between the monitored object succeeding and
the monitoring interface reactivating.

Each of the above events is presented in the following sections:

62  Interface State Changes

 Chapter 3: Interfaces

Physical Connection Monitoring

All physical interfaces on a security device monitor the state of their physical
connection to other network devices. When an interface is connected to and has
established a link with another network device, its state is physically up, and all
routes that use that interface are active.

You can see the state of an interface in the State column in the output of the get
interface command and in the Link column on Network > Interfaces in the WebUI.
It can be up or down.

You can see the state of a route in the status field of the get route id number
command and on Network > Routing > Destination in the WebUI. If there is an
asterisk, the route is active. If there is no asterisk, it is inactive.

Tracking IP Addresses
The security device can track specified IP addresses through an interface so that
when one or more of them become unreachable, the security device can deactivate
all routes associated with that interface, even if the physical link is still active. A
deactivated route becomes active again after the security device regains contact
with those IP addresses.

NOTE: For some ScreenOS appliances, this action also causes a failover to the backup
interface that is bound to the same zone as the interface on which IP tracking is
configured (see “Interface Failover with IP Tracking” on page 11-56).

ScreenOS uses Layer 3 path monitoring, or IP tracking, similar to that used for
NSRP, to monitor the reachability of specified IP addresses through an interface. For
example, if an interface connects directly to a router, you can track the next-hop
address on the interface to determine if the router is still reachable. When you
configure IP tracking on an interface, the security device sends ping requests on the
interface to up to four target IP addresses at user-defined intervals. The security
device monitors these targets to determine if it receives a response. If there is no
response from a target for a specified number of times, that IP address is deemed to
be unreachable. Failure to elicit a response from one or more targets can cause the
security device to deactivate routes associated with that interface. If another route
to the same destination is available, the security device then redirects traffic to use
the new route.

You can define IP tracking on the following interfaces for which you have
configured a manage IP address:

 Physical interface bound to a security zone (not the HA or MGT function zones)

NOTE: The interface can operate at Layer 2 (Transparent mode) or Layer 3 (Route mode).

 Subinterface

 Redundant interface

 Aggregate interface

Interface State Changes  63

 Concepts & Examples ScreenOS Reference Guide

NOTE: Although the interface can be a redundant interface or an aggregate interface, it

cannot be a member of a redundant or aggregate interface.

On devices that support virtual systems, the interface on which you set IP tracking
can belong to the root system or to a virtual system (vsys). However, to set IP
tracking on a shared interface, you can only set it at the root level.

NOTE: From a vsys, you can set interface monitoring to monitor a shared interface from
an interface that belongs to the vsys. However, from within a vsys, you cannot set
interface monitoring from a shared interface. For more information, see “Interface
Monitoring” on page 68.

For each interface, you can configure up to four IP addresses for the security device
to track. On a single device, you can configure up to 64 track IP addresses. That
total includes all track IP addresses whether they are for interface-based IP tracking,
for NSRP-based IP tracking, at the root level, or at the vsys level.

The tracked IP addresses do not have to be in the same subnetwork as the interface.
For each IP address to be tracked, you can specify the following:

 Interval, in seconds, at which the pings are sent to the specified IP address.

 Number of consecutive unsuccessful ping attempts before the connection to the

IP address is considered failed.

 Weight of the failed IP connection (once the sum of the weights of all failed IP
connections crosses a specified threshold, routes that are associated with the
interface are deactivated).

You can also configure the security device to track the default gateway for an
interface that is a PPPoE or DHCP client. To do that, use the “Dynamic” option:
(CLI) set interface interface monitor dynamic or (WebUI) Network > Interfaces >
Edit (for the DHCP or PPPoE client interface) > Monitor > Track IP > Add: Select
Dynamic.

NOTE: When you configure an IP address for the security device to track, the security
device does not add a host route for that IP address to the routing table.

There are two types of thresholds in configuring tracking IP addresses:

 Failure threshold for a specific tracked IP address — The number of consecutive

failures to elicit a ping response from a specific IP address that constitutes a
failure in reaching the IP address. Not exceeding the threshold indicates an
acceptable level of connectivity with the address; exceeding the threshold
indicates an unacceptable level. You set this threshold for each IP address at
any value between 1 and 200. The default value is 3.

64  Interface State Changes

 Chapter 3: Interfaces

 Failure threshold for IP tracking on the interface — The total weight of the
cumulative failed attempts to reach IP addresses on the interface that causes
routes associated with the interface to be deactivated. You can set this
threshold at any value between 1 and 255. The default value is 1, which means
a failure to reach any configured tracked IP address causes routes associated
with the interface to be deactivated.

By applying a weight, or a value, to a tracked IP address, you can adjust the

importance of connectivity to that address in relation to reaching other tracked
addresses. You can assign comparatively greater weights to relatively more
important addresses, and less weight to relatively less important addresses. Note
that the assigned weights only come into play when the failure threshold for a
specific tracked IP address is reached. For example, if the failure threshold for IP
tracking on an interface is 3, failure of a single tracked IP address with a weight of 3
meets the failure threshold for IP tracking on the interface, which causes routes
associated with the interface to be deactivated. The failure of a single tracked IP
address with a weight of 1 would not meet the failure threshold for IP tracking on
the interface and routes associated with the interface would remain active.

In the following example, the interface ethernet0/1 is bound to the Trust zone and
assigned the network address 10.1.1.1/24. The interfaces ethernet0/3 and
ethernet0/4 are bound to the Untrust zone. The ethernet0/3 interface is assigned
the network address 1.1.1.1/24 and is connected to the router at 1.1.1.250. The
ethernet0/4 interface is assigned the network address 2.2.2.1/24 and is connected
to the router at 2.2.2.250. See Figure 22.

Figure 22: Interface IP Tracking

Router 1.1.1.250
ethernet0/1
10.1.1.1/24 ethernet0/3 1.1.1.1/24

Trust Zone Untrust Zone

10.1.1.0/24 Internet

ethernet0/4 2.2.2.1/24

Router 2.2.2.250

There are two default routes configured: one uses ethernet0/3 as the outbound
interface with the router address 1.1.1.250 as the gateway; the other uses
ethernet0/4 as the outbound interface with the router address 2.2.2.250 as the
gateway and is configured with a metric value of 10. The default route that uses
ethernet0/3 is the preferred route since it has a lower metric (the default metric
value for static routes is 1). The following output from the get route command
shows four active routes for the trust-vr (active routes are denoted with an asterisk).
The default route through ethernet0/3 is active, while the default route through
ethernet0/4 is not active since it is less preferred.

Interface State Changes  65

 Concepts & Examples ScreenOS Reference Guide

Figure 23: Get Route Output

device-> get route
untrust-vr (0 entries)
------------------------------------------------------------------------
C - Connected, S - Static, A - Auto-Exported, I - Imported, R - RIP
iB - IBGP, eB - EBGP, O - OSPF, E1 - OSPF external type 1
E2 - OSPF external type 2
trust-vr (4 entries)
------------------------------------------------------------------------
ID IP-Prefix InterfaceGateway P Pref Mtr Vsys
------------------------------------------------------------------------
* 4 0.0.0.0/0 eth0/3 1.1.1.250 S 20 1 Root
* 2 1.1.1.0/24 eth0/3 0.0.0.0 C 0 0 Root
3 0.0.0.0/0 eth0/4 2.2.2.250 S 20 10 Root
* 6 2.2.2.0/24 eth0/4 0.0.0.0 C 0 1 Root
* 5 10.1.1.0/24 eth0/1 0.0.0.0 C 20 1 Root

If the route through ethernet0/3 becomes unavailable, the default route through
ethernet0/4 becomes active. You enable and configure IP tracking on the
ethernet0/3 interface to monitor the router address 1.1.1.250. If IP tracking fails to
reach 1.1.1.250, all routes associated with the ethernet0/3 interface become
inactive on the security device. As a result, the default route through ethernet0/4
becomes active. When IP tracking is again able to reach 1.1.1.250, the default route
through ethernet0/3 becomes active and, at the same time, the default route
through ethernet0/4 becomes inactive, because it is less preferred than the default
route through ethernet0/3.

The following enables IP tracking with an interface failure threshold of 5 and

configures IP tracking on the ethernet0/3 interface to monitor the router IP address
1.1.1.250, which is assigned a weight of 10.

WebUI
Network > Interfaces > Edit (for ethernet0/3) > Monitor: Enter the following,
then click Apply:

Enable Track IP: (select)

Threshold: 5
> Monitor Track IP ADD: Enter the following, then click Add:
Static: (select)
Track IP: 1.1.1.250
Weight: 10

CLI
set interface ethernet0/3 monitor track-ip ip 1.1.1.250 weight 10
set interface ethernet0/3 monitor track-ip threshold 5
set interface ethernet0/3 monitor track-ip
save

In the example, the failure threshold for the target address is set to the default value
of 3. That is, if the target does not return a response to three consecutive pings, a
weight of 10 is applied toward the failure threshold for IP tracking on the interface.
Because the failure threshold for IP tracking on the interface is 5, a weight of 10
causes routes associated with the interface to be deactivated on the security device.

66  Interface State Changes

 Chapter 3: Interfaces

You can verify the status of the IP tracking on the interface by issuing the CLI
command get interface ethernet0/3 track-ip, as shown in Figure 24.

Figure 24: Get Interface Output

device-> get interface ethernet0/3 track-ip
ip address interval threshold wei gateway fail-count success-rate
1.1.1.250 1 1 10 0.0.0.0 343 46%
threshold: 5, failed: 1 ip(s) failed, weighted sum = 10

The get route command shows that the default route through ethernet0/4 is now
active, while all routes through ethernet0/3 are no longer active.

Figure 25: Get Route Output With Activated Interfaces

device-> get route
untrust-vr (0 entries)
----------------------------------------------------------------------
C - Connected, S - Static, A - Auto-Exported, I - Imported, R - RIP
iB - IBGP, eB - EBGP, O - OSPF, E1 - OSPF external type 1
E2 - OSPF external type 2
trust-vr (4 entries)
----------------------------------------------------------------------
ID IP-Prefix Interface Gateway P Pref Mtr Vsys
----------------------------------------------------------------------
4 0.0.0.0/0 eth0/3 1.1.1.250 S 20 1 Root
2 1.1.1.0/24 eth0/3 0.0.0.0 C 0 0 Root
* 3 0.0.0.0/0 eth0/4 2.2.2.250 S 20 10 Root
* 6 2.2.2.0/24 eth0/4 0.0.0.0 C 0 1 Root
* 5 10.1.1.0/24 eth0/1 0.0.0.0 C 20 1 Root

Note that even though the routes through ethernet0/3 are no longer active, IP
tracking uses the routes associated with ethernet0/3 to continue sending ping
requests to the target IP address. When IP tracking is again able to reach 1.1.1.250,
the default route through ethernet0/3 again becomes active on the security device.
At the same time, the default route through ethernet0/4 becomes inactive, since it is
less preferred than the default route through ethernet0/3.

Interface State Changes  67

 Concepts & Examples ScreenOS Reference Guide

Interface Monitoring
A security device can monitor the physical and logical state of interfaces and then
take action based on observed changes, see Figure 26. For example, if the state of a
monitored interface changes from up to down, the following can occur, as shown in
Table 6.

Table 6: Monitored Interface

If: Then:
The physical state of an The state change might trigger another interface that is monitoring
interface changes from the one that just went down to also go down. You can specify whether
up to down you want the second interface to be physically or logically down.
The state change of either interface going physically down, or the
combined weight of both going physically down together, might
trigger an NSRP failover. An NSRP device or a VSD group failover can
only occur as a result of a change to the physical state of an interface.
The logical state of an The state change might trigger another interface that is monitoring
interface changes from the one that just went down to also go down. Although the first
up to down as the result interface is down logically, you can specify whether you want the
of an IP tracking failure down state of the second interface to be logical or physical.

Figure 26: Ethernet0/2 and Ethernet0/3 Interface Monitoring

One Interface Monitoring Another Interface

Using IP tracking, ethernet0/3

monitors the router at 1.1.1.250.

Using interface monitoring,

ethernet0/2 monitors ethernet0/3.

ethernet0/3 ethernet0/2
IP 1.1.1.1 IP 2.1.1.1

To set interface monitoring, do either of the following:

WebUI
Network > Interfaces > Edit (for the interface you want to do the monitoring)
> Monitor > Edit Interface: Enter the following, then click Apply:

Interface Name: Select the interface that you want to be monitored.

Weight: Enter a weight between 1 and 255.

CLI
set interface interface1 monitor interface interface2 [ weight number ]
save

If you do not set a weight, the security device applies the default value, 255.

68  Interface State Changes

 Chapter 3: Interfaces

If two interfaces monitor each other, they form a loop. In that case, if either
interface changes state, the other interface in the loop also changes state. See
Figure 27 on page 69.

NOTE: An interface can only be in one loop at a time. We do not support configurations in
which one interface belongs to multiple loops.

Figure 27: Loop Monitoring

First State Change If: Second State Change If:
Loop - Two Interfaces Monitoring Each Other
• The number of unsuccessful ping • The weight of the failure of the
Using IP tracking, both attempts to either router exceeds the first interface is greater than or
interfaces monitor routers. failure threshold for that tracked IP equal to the monitor failure
address. threshold of the second
Using interface monitoring, interface.
• The weight of the failed track IP is
they also monitor each greater than or equal to the track
other. • The failure action is a change
object failure threshold. from up to down.
• The track object weight is greater
than or equal to the monitor failure
threshold. Then:
• The failure action is a change from The second interface also changes
up to down. its state from up to down.

ethernet0/3 ethernet0/2 Then:

IP 1.1.1.1 IP 2.1.1.1
The second interface also changes
its state from up to down.

Monitoring Two Interfaces

In this example, you configure ethernet0/3 to monitor two interfaces—ethernet0/1
and ethernet0/2. Because the weight for each monitored interface (8 + 8) equals
the monitor failure threshold (16), both ethernet0/1 and ethernet0/2 must fail (and
change their state from up to down) concurrently to cause ethernet0/3 to fail (and
change its state from up to down). See Figure 28.

NOTE: This example omits the configuration of IP tracking on the ethernet0/1 and
ethernet0/2 interfaces (see “Tracking IP Addresses” on page 63). Without IP
tracking, the only way that ethernet0/1 and ethernet0/2 might fail is if they
become physically disconnected from other network devices or if they cannot
maintain links with those devices.

If you set the monitor failure threshold to 8—or leave it at 16 and set the weight of
each monitored interface to 16—the failure of either ethernet0/1 or ethernet0/2
can cause ethernet0/3 to fail.

Interface State Changes  69

 Concepts & Examples ScreenOS Reference Guide

Figure 28: Two-Loop Interface Monitoring

ethernet0/3 monitors ethernet0/1 and ethernet0/2. Because the monitor
failure threshold (F-T) = the weights (W) of both interfaces combined, both
of the monitored interfaces must fail to cause ethernet0/3 to fail.

Security Device Interfaces

ethernet0/1 – ethernet0/8
1 2 3 4 5 6 7 8

W=8 W=8 F-T: 16

Monitored Interfaces:
ethernet0/1, weight 8
ethernet0/2, weight 8
Monitor Failure Threshold: 16

WebUI
Network > Interfaces > Edit (for ethernet0/3) > Monitor > Edit Interface:
Enter the following, then click Apply:

ethernet0/1: (select); Weight: 8

ethernet0/2: (select); Weight: 8

Network > Interfaces > Edit (for ethernet0/3) > Monitor: Enter 16 in the
Monitor Threshold field, then click Apply.

CLI
set interface ethernet0/3 monitor interface ethernet0/1 weight 8
set interface ethernet0/3 monitor interface ethernet0/2 weight 8
set interface ethernet0/3 monitor threshold 16
save

Monitoring an Interface Loop

In this example, you first configure IP tracking for two interfaces—ethernet0/1 and
ethernet0/3. Then you configure these interfaces to monitor each other so that if
one changes its state, the other does likewise. Finally, you define two sets of routes.
The first set forwards traffic through ethernet0/1 and ethernet0/3. The second set
has the same destination addresses, but these routes have lower ranked metrics
and use different egress interfaces (ethernet0/2 and ethernet0/4) and different
gateways from the first set. With this configuration, if the first set of interfaces fails,
the security device can reroute all traffic through the second set. All zones are in the
trust-vr routing domain.

70  Interface State Changes

 Chapter 3: Interfaces

Figure 29: Four-Interface Loop Monitoring

To Trust Zone To the ethernet0/1 and ethernet0/3 perform IP tracking.
Hosts Internet ethernet0/1 tracks the internal router at 10.1.1.250.
ethernet0/3 tracks the external router at 1.1.1.250.
Internal Router External Router
10.1.1.250 Track IP Failure Threshold: 10
1.1.1.250 Track IP Weight: 8
10.1.2.250 1.1.2.250 Track Object Weight: 8
Monitor Failure Threshold: 8
1.1.1.1/24
10.1.1.1/24 10.1.2.1/24 Untrust 1.1.2.1/24
Trust Zone Trust Zone Zone Untrust Zone

Security Device Interfaces

ethernet0/1 – ethernet0/8
1 2 3 4 5 6 7 8

ethernet0/1 and If ethernet0/1 and ethernet0/3 go down, the routes referencing

ethernet0/3 monitor each those interfaces become inactive. The security device then uses
other. Because the Monitoring Interface Loop: routes forwarding traffic through ethernet0/2 and ethernet0/4.
monitored interface weight
equals the monitor-failure ethernet0/1 and ethernet0/3
threshold, the failure of Routes
either interface causes the Monitored Interface Weight: 8
other to fail as well. Monitor Failure Threshold: 8 set vrouter trust-vr route 10.1.0.0/16 interface ethernet0/1 gateway 10.1.1.250 metric 10
set vrouter trust-vr route 10.1.0.0/16 interface ethernet0/2 gateway 10.1.2.250 metric 12
set vrouter trust-vr route 0.0.0.0/0 interface ethernet0/3 gateway 1.1.1.250 metric 10
set vrouter trust-vr route 0.0.0.0/0 interface ethernet0/4 gateway 1.1.2.250 metric 12

WebUI
1. IP Tracking
Network > Interfaces > Edit (for ethernet0/1) > Monitor: Enter the following,
then click Apply:

Enable Track IP: (select)

Monitor Threshold: 8
Track IP Option: Threshold: 8
Weight: 8

NOTE: To control whether the state of an interface becomes logically or physically down
(or up), you must use the CLI command set interface interface monitor threshold
number action { down | up } { logically | physically }. Only physical interfaces
bound to any security zone other than the Null zone can be physically up or down.

> Monitor Track IP ADD: Enter the following, then click Add:

Static: (select)
Track IP: 10.1.1.250
Weight: 8
Interval: 3 Seconds
Threshold: 10

Network > Interfaces > Edit (for ethernet0/3) > Monitor: Enter the following,
then click Apply:

Enable Track IP: (select)

Monitor Threshold: 8
Track IP Option: Threshold: 8
Weight: 8

Interface State Changes  71

 Concepts & Examples ScreenOS Reference Guide

> Monitor Track IP ADD: Enter the following, then click Add:

Static: (select)
Track IP: 1.1.1.250
Weight: 8
Interval: 3 Seconds
Threshold: 10
2. Interface Monitoring
Network > Interfaces > Edit (for ethernet0/1) > Monitor > Edit Interface:
Enter the following, then click Apply:

ethernet0/3: (select); Weight: 8

Network > Interfaces > Edit (for ethernet0/3) > Monitor > Edit Interface:
Enter the following, then click Apply:

ethernet0/1: (select); Weight: 8

3. Routes
Network > Routing > Destination > trust-vr New: Enter the following, then
click OK:

Network Address/Netmask: 10.1.0.0/16

Gateway: (select)
Interface: ethernet0/1
Gateway IP Address: 10.1.1.250
Metric: 10

Network > Routing > Destination > trust-vr New: Enter the following, then
click OK:

Network Address/Netmask: 10.1.0.0/16

Gateway: (select)
Interface: ethernet0/2
Gateway IP Address: 10.1.2.250
Metric: 12

Network > Routing > Destination > trust-vr New: Enter the following, then
click OK:

Network Address/Netmask: 0.0.0.0/0

Gateway: (select)
Interface: ethernet0/3
Gateway IP Address: 1.1.1.250
Metric: 10

Network > Routing > Destination > trust-vr New: Enter the following, then
click OK:

Network Address/Netmask: 0.0.0.0/0

Gateway: (select)
Interface: ethernet0/4
Gateway IP Address: 1.1.2.250
Metric: 12

72  Interface State Changes

 Chapter 3: Interfaces

CLI
1. IP Tracking
set interface ethernet0/1 track-ip ip 10.1.1.250 weight 8
set interface ethernet0/1 track-ip threshold 8
set interface ethernet0/1 track-ip weight 8
set interface ethernet0/1 track-ip
set interface ethernet0/3 track-ip ip 1.1.1.250 weight 8
set interface ethernet0/3 track-ip threshold 8
set interface ethernet0/3 track-ip weight 8
set interface ethernet0/3 track-ip
2. Interface Monitoring
set interface ethernet0/1 monitor interface ethernet0/3 weight 8
set interface ethernet0/1 monitor threshold 8 action down physically
set interface ethernet0/3 monitor interface ethernet0/1 weight 8
set interface ethernet0/3 monitor threshold 8 action down physically
3. Routes
set vrouter trust-vr route 10.1.0.0/16 interface ethernet0/1 gateway 10.1.1.250
metric 10
set vrouter trust-vr route 10.1.0.0/16 interface ethernet0/2 gateway 10.1.2.250
metric 12
set vrouter trust-vr route 0.0.0.0/0 interface ethernet0/3 gateway 1.1.1.250
metric 10
set vrouter trust-vr route 0.0.0.0/0 interface ethernet0/4 gateway 1.1.2.250
metric 12
save

Security Zone Monitoring

In addition to monitoring individual interfaces, an interface can monitor all the
interfaces in a security zone—any security zone other than its own. For an entire
security zone to fail, every interface bound to that zone must fail. As long as one
interface bound to a monitored zone is up, the security device considers the entire
zone to be up.

To configure an interface to monitor a security zone, do either of the following:

WebUI
Network > Interfaces > Edit (for the interface you want to do the monitoring)
> Monitor > Edit Zone: Enter the following, then click Apply:

Zone Name: Select the zone that you want to be monitored.

Weight: Enter a weight between 1 and 255.

CLI
set interface interface monitor zone zone [ weight number ]

If you do not set a weight, the security device applies the default value, 255.

Interface State Changes  73

 Concepts & Examples ScreenOS Reference Guide

Down Interfaces and Traffic Flow

Configuring IP tracking on an interface allows the security device to reroute
outgoing traffic through a different interface if certain IP addresses become
unreachable through the first interface. However, while the security device might
deactivate routes associated with an interface because of an IP tracking failure, the
interface can remain physically active and still send and receive traffic. For
example, the security device continues to process incoming traffic for an existing
session that might arrive on the original interface on which IP tracking failed. Also,
the security device continues to use the interface to send ping requests to target IP
addresses to determine if the targets again become reachable. In these situations,
traffic still passes through an interface on which IP tracking has failed and for which
the security device has deactivated routes.

How the security device handles session traffic on such an interface depends upon
the following:

 If the interface on which you configure IP tracking functions as an egress

interface for a session, session replies might continue to arrive at the interface
and the security device still processes them.

 If the interface on which you configure IP tracking functions as an ingress

interface for a session, applying the set arp always-on-dest command causes
the security device to reroute session replies to another interface. If you do not
set this command, the security device forwards session replies through the
interface on which IP tracking failed even though the security device has
deactivated routes using that interface. (By default, this command is unset.)

By default, a security device caches a session initiator’s MAC address when it

receives the initial packet for a new session. If you enter the CLI command set
arp always-on-dest, the security device does not cache a session initiator’s
MAC address. Instead, the security device performs an ARP lookup when
processing the reply to that initial packet. If the initiator’s MAC address is in the
ARP table, the security device uses that. If the MAC address is not in the ARP
table, the security device sends an ARP request for the destination MAC address
and then adds the MAC address it receives to its ARP table. The security device
performs another ARP lookup whenever a route change occurs.

“Failure on the Egress Interface” describes separate scenarios in which IP tracking

fails on the egress interface and on the ingress interface; and, in the case of the
latter, what occurs when you use the command set arp always-on-dest.

NOTE: “Failure on the Egress Interface” describes how IP tracking triggers routing
changes and how those changes can affect the packet flow through all Juniper
Networks security devices.

74  Interface State Changes

 Chapter 3: Interfaces

Failure on the Egress Interface

In the following scenario, you configure IP tracking on ethernet0/2, which is the
egress interface for sessions from Host A to Host B. Host A initiates the session by
sending a packet to Host B, as shown in Figure 30.

NOTE: You must first create two routes to Host B, and both the egress interfaces must be
in the same zone so that the same policy applies to traffic before and after the
rerouting occurs.

Figure 30: Host A and Host B IP Tracking

Traffic Flow from Host A to Host B – Request (Session Initiation)
First Egress Interface ethernet0/2 IP tracking is enabled
Ingress Interface ethernet0/1 1.1.1.1/24 from ethernet0/2
10.1.1.1/24

2
Untrust Zone
Trust Zone Session Route Policy
Lookup Lookup Lookup
10.1.1.1/24 3 Host B
10.1.1.0/24
4
1
Host A Responder
10.1.1.5 Initiator

Second Egress Interface Gateways:

ethernet0/3 1.1.1.254
1.1.2.1/24 1.1.2.254

When Host B replies to Host A, the return traffic follows a similar path back through
the security device, as shown in Figure 31.

Figure 31: Host B to Host A Egress Traffic Flow

Traffic Flow from Host A to Host B – Reply

Ingress Interface ethernet0/1 First Egress Interface ethernet0/2 IP tracking from

10.1.1.1/24 1.1.1.1/24 ethernet0/2 succeeds

3 Untrust Zone
Trust Zone Session
Update
10.1.1.1/24
10.1.1.0/24
2 Host B
2.2.2.2
1
4
Host A Responder
10.1.1.5 Initiator

Second Egress Interface Gateways:

ethernet0/3 1.1.1.254
1.1.2.1/24 1.1.2.254

Interface State Changes  75

 Concepts & Examples ScreenOS Reference Guide

If IP tracking on ethernet0/2 fails, the security device deactivates routes that use
ethernet0/2 and uses ethernet0/3 for outbound traffic to Host B. However, replies
from Host B to Host A can arrive through either ethernet0/2 or ethernet0/3 and the
security device forwards them through ethernet0/1 to Host A. See Figure 32.

Figure 32: Egress IP Tracking Failure

Traffic Flow from Host B to Host A – IP Tracking Failure Triggers Rerouting
First Egress Interface IP tracking from
Ingress Interface ethernet0/1 ethernet0/2
10.1.1.1/24 ethernet0/2 fails
1.1.1.1/24

1
Untrust Zone
Trust Zone Route Session
Change Update
10.1.1.1/24 3
10.1.1.0/24 4 Host B
2.2.2.2

2
Responder
Host A
10.1.1.5 Initiator
Gateways:
Second Egress Interface 1.1.1.254
ethernet0/3 1.1.2.254
1.1.2.1/24

Failure on the Ingress Interface

In the following scenario, you again configure IP tracking on ethernet0/2, but this
time ethernet0/2 is the ingress interface on the security device for sessions from
Host B to Host A. Host B initiates the session by sending a packet to Host A, as
shown in Figure 33.

Figure 33: Host B to Host A Ingress Traffic Flow

Traffic Flow from Host B to Host A – Request (Session Initiation)
Egress Interface First Ingress Interface
ethernet0/1 ethernet0/2 IP tracking is enabled
10.1.1.1/24 1.1.1.1/24 from ethernet0/2

Untrust Zone
Trust Zone Policy Route Session
Lookup Lookup Lookup
10.1.1.1/24 Host B
10.1.1.0/24
1 2.2.2.2

3
Host A Initiator
10.1.1.5 Responder
Gateways:
1.1.1.254
Second Ingress Interface 1.1.2.254
ethernet0/3
1.1.2.1/24

76  Interface State Changes

 Chapter 3: Interfaces

When Host A replies to Host B, the return traffic follows a similar path back through
the security device, as shown in Figure 34.

Figure 34: Ingress Host A to Host B Traffic Flow

Traffic Flow from Host B to Host A – Reply
Egress Interface First Ingress Interface
ethernet0/1 ethernet0/2 IP tracking from
10.1.1.1/24 1.1.1.1/24 ethernet0/2 succeeds

2 Untrust Zone
Trust Zone Session
Lookup
10.1.1.1/24 3 Host B
10.1.1.0/24
4 2.2.2.2

1
Host A Initiator
10.1.1.5
Responder

Second Ingress Interface Gateways:

ethernet0/3 1.1.1.254
1.1.2.1/24 1.1.2.254
1. Host A at 10.1.1.5 sends a reply packet destined for Host B (2.2.2.2) to ethernet0/1 at 10.1.1.1.
2. The security device performs a session lookup. Because this is a reply, the device matches it with an existing session and refreshes
the session table entry.
3. By using the cached MAC address for the gateway at 1.1.1.254, or by doing an ARP lookup to discover its MAC address, the device
forwards the packet through ethernet0/2 to the gateway.

4. When the gateway at 1.1.1.254 receives the reply, it forwards it to its next hop. Routing continues until Host B receives it.

If IP tracking on ethernet0/2 fails, the security device deactivates routes that use
ethernet0/2 and uses ethernet0/3 for outbound traffic to Host B. However, requests
from Host B to Host A can still arrive through ethernet0/2 and the security device
still forwards them to Host A through ethernet0/1. The data flow for requests from
Host B to Host A looks the same after an IP tracking failure as it did before.
However, the replies from Host A can take one of two different paths, depending on
the application of the set arp always-on-dest command.

If you set the command set arp always-on-dest, the security device sends an ARP
request for the destination MAC address when processing the reply to the first
packet in a session or when a route change occurs. (When this command is unset,
the security device caches the session initiator’s MAC address and uses that when
processing replies. By default, this command is unset).

When IP tracking on ethernet0/2 fails, the security device first deactivates all routes
using ethernet0/2 and then does a route lookup. It finds another route to reach
Host B through ethernet0/3 and the gateway at 1.1.2.254. It then scans its session
table and redirects all sessions to the new route. If you have the set arp
always-on-dest command enabled, the security device does an ARP lookup when it
receives the next packet from Host A because it is in a session affected by the route
change. Despite the ingress interface on which packets from Host B arrive, the
security device sends all further replies from Host A through ethernet0/3 to the
gateway at 1.1.2.254. See Figure 35 on page 78.

Interface State Changes  77

 Concepts & Examples ScreenOS Reference Guide

Figure 35: Ingress IP Tracking Failure with Traffic Rerouting

Traffic Flow from Host B to Host A – IP Tracking Failure Triggers Rerouting

Egress Interface ethernet0/1 First Ingress Interface IP tracking from

10.1.1.1/24 ethernet0/2 ethernet0/2 fails
1.1.1.1/24

1 2
Untrust Zone
Trust Zone Route Session
Change Update
10.1.1.1/24 Host B
10.1.1.0/24 2.2.2.2

3
Host A Initiator
10.1.1.5 Responder
Gateways:
1.1.1.254
Second Ingress Interface 1.1.2.254
ethernet0/3
1.1.2.1/24

If you have set the command unset arp always-on-dest (which is the default
configuration), the security device uses the MAC address for the gateway at 1.1.1.1
that it cached when Host B sent the initial session packet. The security device
continues to send session replies through ethernet0/2. In this case, the IP tracking
failure caused no change in the flow of data through the security device.

Figure 36: Ingress IP Tracking Failure with No Rerouting

Traffic Flow from Host B to Host A – IP Tracking Failure Triggers No Rerouting
First Ingress Interface
Egress Interface ethernet0/2 IP tracking from
ethernet0/1 1.1.1.1/24 ethernet0/2 fails
10.1.1.1/24

2
Untrust Zone
Trust Zone Session
Update
10.1.1.1/24 3
10.1.1.0/24 4 Host B
2.2.2.2
Second Ingress Interface
1 ethernet0/3
1.1.2.1/24
Host A
10.1.1.5 Responder Gateways:
Initiator 1.1.1.254
1.1.2.254

78  Interface State Changes

Chapter 4
Interface Modes

Interfaces can operate in three different modes: Network Address Translation (NAT),
Route, and Transparent. If an interface bound to a Layer 3 zone has an IP address,
you can define the operational mode for that interface as either NAT or Route. An
interface bound to a Layer 2 zone (such as the predefined v1-trust, v1-untrust, and
v1-dmz zones, or a user-defined Layer 2 zone) must be in Transparent mode. You
select an operational mode when you configure an interface.

NOTE: Although you can define the operational mode for an interface bound to any
Layer 3 zone as NAT, the security device only performs NAT on traffic passing
through that interface en route to the Untrust zone. ScreenOS does not perform
NAT on traffic destined for any zone other than the Untrust zone. Also, note that
ScreenOS allows you to set an Untrust zone interface in NAT mode, but doing so
activates no NAT operations.

This chapter contains the following sections:

 “Transparent Mode” on page 80

 “NAT Mode” on page 92

 “Route Mode” on page 98

 79
 Concepts & Examples ScreenOS Reference Guide

Transparent Mode
When an interface is in Transparent mode, the security device filters packets
traversing the firewall without modifying any of the source or destination
information in the IP packet header. All interfaces behave as though they are part of
the same network, with the security device acting much like a Layer 2 switch or
bridge. In Transparent mode, the IP addresses of interfaces are set at 0.0.0.0,
making the presence of the security device transparent (invisible) to users. See
Figure 37.

Figure 37: Transparent Mode

209.122.30.3
209.122.30.2
209.122.30.2 209.122.30.4

209.122.30.1
209.122.30.5
Trust Zone

Switch

Public
Address
Space

Untrust Zone

External Router

To Internet

Transparent mode is a convenient means for protecting webservers or any other

kind of server that mainly receives traffic from untrusted sources. Using
Transparent mode offers the following benefits:

 No need to reconfigure the IP settings of routers or protected servers

 No need to create mapped or virtual IP addresses for incoming traffic to reach

protected servers

80  Transparent Mode
 Chapter 4: Interface Modes

Zone Settings
By default, ScreenOS creates one function zone, the VLAN zone, and three L2
security zones: V1-Trust, V1-Untrust, and V1-DMZ.

VLAN Zone
The VLAN zone hosts the VLAN1 interface, which has the same configuration and
management abilities as a physical interface. When the security device is in
Transparent mode, you use the VLAN1 interface for managing the device and
terminating VPN traffic. You can configure the VLAN1 interface to permit hosts in
the L2 security zones to manage the device. To do that, you must set the VLAN1
interface IP address in the same subnet as the hosts in the L2 security zones.

For management traffic, the VLAN1 Manage IP takes precedence over the VLAN1
interface IP. You can set the VLAN1 Manage IP for management traffic and dedicate
the VLAN1 interface IP solely for VPN tunnel termination.

Predefined Layer 2 Zones

ScreenOS provides three L2 security zones by default: V1-Trust, V1-Untrust, and
V1-DMZ. These three zones share the same L2 domain. When you configure an
interface in one of the zones, it gets added to the L2 domain shared by all interfaces
in all the L2 zones. All hosts in the L2 zones must be on the same subnet to
communicate.

As stated in the previous section, when the device is in transparent mode, you use
the VLAN1 interface to manage the device. For management traffic to reach the
VLAN1 interface, you must enable the management options on the VLAN1 interface
and on the zone(s) through which the management traffic passes. By default, all
management options are enabled in the V1-Trust zone. To enable hosts in other
zones to manage the device, you must set those options on the zones to which they
belong.

NOTE: To see which physical interfaces are prebound to the L2 zones for each Juniper
Networks security platform, refer to the installation and configuration guide for
that platform.

Traffic Forwarding
A security device operating at Layer 2 (L2) does not permit any inter-zone traffic
unless there is a policy configured on the device. For more information about
setting policies, see “Policies” on page 2-159. After you configure a policy on the
security device, it does the following:

 Allows or denies the traffic specified in the policy.

 Allows ARP and L2 non-IP multicast and broadcast traffic. The security device
can then receive and pass L2 broadcast traffic for the spanning tree protocol.

 Continues to block all non-IP and non-ARP unicast traffic and IPSec traffic.

You can change the forwarding behavior of the device as follows:

Transparent Mode  81
 Concepts & Examples ScreenOS Reference Guide

 To block all L2 non-IP and non-ARP traffic, including multicast and broadcast
traffic, enter the unset interface vlan1 bypass-non-ip-all command.

 To allow all L2 non-IP traffic to pass through the device, enter the set interface
vlan1 bypass-non-ip command.

 To revert to the default behavior of the device, which is to block all non-IP and
non-ARP unicast traffic, enter the unset interface vlan1 bypass-non-ip
command.

Note that the unset interface vlan1 bypass-non-ip-all command always

overwrites the unset interface vlan1 bypass-non-ip command when both
commands are in the configuration file. Therefore, if you had previously
entered the unset interface vlan1 bypass-non-ip-all command, and you now
want the device to revert to its default behavior of blocking only the non-IP and
non-ARP unicast traffic, you should first enter the set interface vlan1
bypass-non-ip command to allow all non-IP and non-ARP traffic, including
multicast, unicast, and broadcast traffic to pass through the device. Then you
must enter the unset interface vlan1 bypass-non-ip command to block only
the non-IP, non-ARP unicast traffic.

 To allow a security device to pass IPSec traffic without attempting to terminate

it, use the set interface vlan1 bypass-others-ipsec command. The security
device then allows the IPSec traffic to pass through to other VPN termination
points.

NOTE: A security device with interfaces in Transparent mode requires routes for two
purposes: to direct self-initiated traffic, such as SNMP traps, and to forward VPN
traffic after encapsulating or decapsulating it.

Unknown Unicast Options

When a host or any kind of network device does not know the MAC address
associated with the IP address of another device, it uses the Address Resolution
Protocol (ARP) to obtain it. The requestor broadcasts an ARP query (arp-q) to all the
other devices on the same subnet. The arp-q requests the device at the specified
destination IP address to send back an ARP reply (arp-r), which provides the
requestor with the MAC address of the replier. When all the other devices on the
subnet receive the arp-q, they check the destination IP address and, because it is
not their IP address, drop the packet. Only the device with the specified IP address
returns an arp-r. After a device matches an IP address with a MAC address, it stores
the information in its ARP cache.

As ARP traffic passes through a security device in Transparent mode, the device
notes the source MAC address in each packet and learns which interface leads to
that MAC address. In fact, the security device learns which interface leads to which
MAC address by noting the source MAC addresses in all packets it receives. It then
stores this information in its forwarding table.

82  Transparent Mode
 Chapter 4: Interface Modes

NOTE: A security device in Transparent mode does not permit any traffic between zones
unless there is a policy configured on the device. For more information about how
the device forwards traffic when it is in Transparent mode, see “Traffic
Forwarding” on page 81.

The situation can arise when a device sends a unicast packet with a destination
MAC address, which it has in its ARP cache, but which the security device does not
have in its forwarding table. For example, the security device clears its forwarding
table every time it reboots. (You can also clear the forwarding table with the CLI
command clear arp.) When a security device in Transparent mode receives a
unicast packet for which it has no entry in its forwarding table, it can follow one of
two courses:

 After doing a policy lookup to determine the zones to which traffic from the
source address is permitted, flood the initial packet out the interfaces bound to
those zones, and then continue using whichever interface receives a reply. This
is the Flood option, which is enabled by default.

 Drop the initial packet, flood ARP queries (and, optionally, trace-route packets,
which are ICMP echo requests with the time-to-live value set to 1) out all
interfaces (except the interface at which the packet arrived), and then send
subsequent packets through whichever interface receives an ARP (or
trace-route) reply from the router or host whose MAC address matches the
destination MAC address in the initial packet. The trace-route option allows the
security device to discover the destination MAC address when the destination
IP address is in a nonadjacent subnet.

NOTE: Of the two methods—flood and ARP/trace-route—ARP/trace-route is more secure

because the security device floods ARP queries and trace-route packets—not the
initial packet—out all interfaces.

Flood Method
The flood method forwards packets in the same manner as most Layer 2 switches.
A switch maintains a forwarding table that contains MAC addresses and associated
ports for each Layer 2 domain. The table also contains the corresponding interface
through which the switch can forward traffic to each device. Every time a packet
arrives with a new source MAC address in its frame header, the switch adds the
MAC address to its forwarding table. It also tracks the interface at which the packet
arrived. If the destination MAC address is unknown to the switch, the switch
duplicates the packet and floods it out all interfaces (other than the interface at
which the packet arrived). It learns the previously unknown MAC address and its
corresponding interface when a reply with that MAC address arrives at one of its
interfaces.

When you enable the flood method and the security device receives an ethernet
frame with a destination MAC address that is not listed in the security device MAC
table, it floods the packet out all interfaces.

Transparent Mode  83
 Concepts & Examples ScreenOS Reference Guide

Figure 38: Flood Method

ethernet0/1 ethernet0/4
IP 0.0.0.0/0 IP 0.0.0.0/0

Packet arrives at
ethernet0/1. V1-DMZ
Router Zone
V1-Trust Zone

Common address space

ethernet0/2 ethernet0/3
IP 0.0.0.0/0 IP 0.0.0.0/0

L2-Finance V1-Untrust Zone

Zone

Router Router Untrust found

The security device floods the packet out ethernet0/2 but receives no reply.

To enable the flood method for handling unknown unicast packets, do either of the
following:

WebUI
Network > Interfaces > Edit (for VLAN1): For the broadcast options, select
Flood, then click OK:

CLI
set interface vlan1 broadcast flood
save

ARP/Trace-Route Method
When you enable the ARP method with the trace-route option and the security
device receives an ethernet frame with a destination MAC address that is not listed
in its MAC table, the security device performs the following series of actions:

NOTE: When you enable the ARP method, the trace-route option is enabled by default.
You can also enable the ARP method without the trace-route option. However, this
method only allows the security device to discover the destination MAC address
for a unicast packet if the destination IP address is in the same subnet as the
ingress IP address. (For more information about the ingress IP address, see the
following Note.)

1. The security device notes the destination MAC address in the initial packet
(and, if it is not already there, adds the source MAC address and its
corresponding interface to its forwarding table).

84  Transparent Mode
 Chapter 4: Interface Modes

2. The security device drops the initial packet.

3. The security device generates two packets—ARP query (arp-q) and a trace-route
(an ICMP echo request, or PING) with a time-to-live (TTL) field of 1—and floods
those packets out all interfaces except the interface at which the initial packet
arrived. For the arp-q packets and ICMP echo requests, the security device uses
the source and destination IP addresses from the initial packet. For arp-q
packets, the security device replaces the source MAC address from the initial
packet with the MAC address for VLAN1, and it replaces the destination MAC
address from the initial packet with ffff.ffff.ffff. For the trace-route option, the
security device uses the source and destination MAC addresses from the initial
packet in the ICMP echo requests that it broadcasts.

If the destination IP address belongs to a device in the same subnet as the

ingress IP address, the host returns an ARP reply (arp-r) with its MAC address,
thus indicating the interface through which the security device must forward
traffic destined for that address. (See Figure 39 on page 86.)

NOTE: The ingress IP address refers to the IP address of the last device to send the packet
to the security device. This device might be the source that sent the packet or a
router forwarding the packet.

If the destination IP address belongs to a device in a subnet beyond that of the

ingress IP address, the trace-route returns the IP and MAC addresses of the
router leading to the destination, and more significantly, indicates the interface
through which the security device must forward traffic destined for that MAC
address. (See Figure 40 on page 87.)

NOTE: Actually, the trace-route returns the IP and MAC addresses of all the routers in the
subnet. The security device then matches the destination MAC address from the
initial packet with the source MAC address on the arp-r packets to determine
which router to target, and consequently, which interface to use to reach that
target.

4. Combining the destination MAC address gleaned from the initial packet with
the interface leading to that MAC address, the security device adds a new entry
to its forwarding table.

5. The security device forwards all subsequent packets it receives out the correct
interface to the destination.

To enable the ARP/trace-route method for handling unknown unicast packets, do

either of the following:

WebUI
Network > Interfaces > Edit (for VLAN1): For the broadcast options, select
ARP, then click OK:

CLI
set interface vlan1 broadcast arp
save

Transparent Mode  85
 Concepts & Examples ScreenOS Reference Guide

NOTE: The trace-route option is enabled by default. If you want to use ARP without the
trace-route option, enter the following command: unset interface vlan1
broadcast arp trace-route. This command unsets the trace-route option but does
not unset ARP as the method for handling unknown unicast packets.

Figure 39 shows how the ARP method can locate the destination MAC when the
destination IP address is in an adjacent subnet.

Figure 39: ARP Method

Note: Only the relevant elements of the VLAN1
packet header and the last four digits in 210.1.1.1/24
the MAC addresses are shown below. 0010.db15.39ce
PC A ethernet0/1 ethernet0/4 Router A
If the following packet: 210.1.1.5 0.0.0.0/0 0.0.0.0/0 210.1.1.100
00aa.11aa.11aa 0010.db15.39ce 0010.db15.39ce 00cc.11cc.11cc
Ethernet Frame IP Datagram
dst src type src dst
11bb 11aa 0800 210.1.1.5 210.1.1.75
V1-DMZ
Zone
arrives at ethernet0/1 and the forwarding V1-Trust Zone Router
table does not have an entry for MAC
address 00bb.11bb.11bb, the security
device floods the following arp-q packet: Common
Ethernet Frame ARM Message Address
Space
dst src type src dst
ethernet0/2 ethernet0/3
ffff 39ce 0806 210.1.1.5 210.1.1.75 0.0.0.0/0 0.0.0.0/0
0010.db15.39ce 0010.db15.39ce
When the device receives the following arp-r
at ethernet0/2: L2-Finance
V1-Untrust
Zone
Ethernet Frame ARM Message Zone

dst src type src dst

39ce 11bb 0806 210.1.1.75 210.1.1.5 PC B found Router B
PC B
210.1.1.200
210.1.1.75
00dd.11dd.11dd
It can now associate the MAC address with the 00bb.11bb.11bb
interface leading to it.

86  Transparent Mode
 Chapter 4: Interface Modes

Figure 40 shows how the trace-route option can locate the destination MAC when
the destination IP address is in a nonadjacent subnet.

Figure 40: Trace-Route

Note: Only the relevant elements of the VLAN1

packet header and the last four digits in 210.1.1.1/24
the MAC addresses are shown below. 0010.db15.39ce
PC A ethernet0/1 ethernet0/4 Router A
If the following packet: 210.1.1.5 0.0.0.0/0 0.0.0.0/0 210.1.1.100
00aa.11aa.11aa 0010.db15.39ce 0010.db15.39ce 00cc.11cc.11cc
Ethernet Frame IP Datagram

dst src type src dst

11dd 11aa 0800 210.1.1.5 195.1.1.5 V1-DMZ

Zone
arrives at ethernet0/1 and the forwarding V1-Trust Zone
table does not have an entry for MAC
address 00dd.11dd.11dd, the security
device floods the following trace-route packet out
ethernet0/2, ethernet0/3, and ethernet0/4: Common
Address
Space
Ethernet Frame ICMP Message ethernet0/3
ethernet0/2
0.0.0.0/0 0.0.0.0/0
dst src type src dst TTL 0010.db15.39ce 0010.db15.39ce Untrust
11dd 11aa 0800 210.1.1.5 195.1.1.5 1 found
V1-Untrust
When the device receives the following response L2-Finance Zone
at ethernet0/3: Zone

Ethernet Frame ICMP Message

PC B Router B
210.1.1.75 210.1.1.200 Server C
dst src type src dst msg 00bb.11bb.11bb 00dd.11dd.11dd 195.1.1.5
00dd.22dd.22dd
11aa 11dd 0800 210.1.1.200 210.1.1.5 Time
Exceeded

It can now associate the MAC address

with the interface leading to it.

Configuring VLAN1 Interface for Management

In this example, you configure the security device for management to its VLAN1
interface as follows:

 Assign the VLAN1 interface an IP address of 1.1.1.1/24.

 Enable Web, Telnet, SSH, and Ping on both the VLAN1 interface and the
V1-Trust security zone.

NOTE: By default, ScreenOS enables the management options for the VLAN1 interface
and V1-Trust security zone. Enabling these options is included in this example for
illustrative purposes only. Unless you have previously disabled them, you really do
not need to enable them manually.

To manage the device from a Layer 2 security zone, you must set the same
management options for both the VLAN1 interface and the Layer 2 security zone.

Transparent Mode  87
 Concepts & Examples ScreenOS Reference Guide

 Add a route in the trust virtual router (all Layer 2 security zones are in the
trust-vr routing domain) to enable management traffic to flow between the
security device and an administrative workstation beyond the immediate
subnet of the security device. All security zones are in the trust-vr routing
domain.

Figure 41: Transparent VLAN

1.1.2.0/24 Internal Router 1.1.1.0/24 External Router
Subnet 1.1.1.251 Subnet 1.1.1.250
1.1.2.250

Internet

VLAN1 IP
V1-Trust Zone 1.1.1.1/24 V1-Untrust Zone

Admin Workstation V1-Trust Interface V1-Untrust Interface

1.1.2.5 ethernet0/1 ethernet0/3
0.0.0.0/0 0.0.0.0/0

WebUI
1. VLAN1 Interface
Network > Interfaces > Edit (for VLAN1): Enter the following, then click OK:

IP Address/Netmask: 1.1.1.1/24
Management Services: WebUI, Telnet, SSH (select)
Other Services: Ping (select)
2. V1-Trust Zone
Network > Zones > Edit (for V1-Trust): Select the following, then click OK:

Management Services: WebUI, Telnet, SSH

Other Services: Ping
3. Route
Network > Routing > Destination > trust-vr New: Enter the following, then
click OK:

Network Address/Netmask: 1.1.2.0/24

Gateway: (select)
Interface: vlan1(trust-vr)
Gateway IP Address: 1.1.1.251
Metric: 1

CLI
1. VLAN1 Interface
set interface vlan1 ip 1.1.1.1/24
set interface vlan1 manage web
set interface vlan1 manage telnet
set interface vlan1 manage ssh
set interface vlan1 manage ping

88  Transparent Mode
 Chapter 4: Interface Modes

2. V1-Trust Zone
set zone v1-trust manage web
set zone v1-trust manage telnet
set zone v1-trust manage ssh
set zone v1-trust manage ping
3. Route
set vrouter trust-vr route 1.1.2.0/24 interface vlan1 gateway 1.1.1.251 metric 1
save

Configuring Transparent Mode

The following example illustrates a basic configuration for a single LAN protected by
a security device in Transparent mode. Policies permit outgoing traffic for all hosts
in the V1-Trust zone, incoming SMTP services for the mail server, and incoming
FTP-GET services for the FTP server.

To increase the security of management traffic, you change the HTTP port number
for WebUI management from 80 to 5555, and the Telnet port number for CLI
management from 23 to 4646. You use the VLAN1 IP address—1.1.1.1/24—to
manage the security device from the V1-Trust security zone. You define addresses
for the FTP and mail servers. You also configure a default route to the external
router at 1.1.1.250, so that the security device can send outbound VPN traffic to it.
(The default gateway on all hosts in the V1-Trust zone is also 1.1.1.250.)

NOTE: For an example of configuring a VPN tunnel for a security device with interfaces in
Transparent mode, see “Transparent Mode VPN” on page 5-161.

Figure 42: Basic Transparent Mode

FTP_Server Mail_Server External Router
1.1.1.5 1.1.1.10 1.1.1.250

1.1.1.0/24
Address space

Internet

VLAN1 IP
V1-Trust Zone 1.1.1.1/24 V1-Untrust Zone

V1-Trust Interface V1-Untrust Interface

ethernet0/1 ethernet0/3
0.0.0.0/0 0.0.0.0/0

Transparent Mode  89
 Concepts & Examples ScreenOS Reference Guide

WebUI
1. VLAN1 Interface
Network > Interfaces > Edit (for the VLAN1 interface): Enter the following,
then click OK:

IP Address/Netmask: 1.1.1.1/24
Management Services: WebUI, Telnet (select)
Other Services: Ping (select)
2. HTTP Port
Configuration > Admin > Management: In the HTTP Port field, type 5555 and
then click Apply.

NOTE: The default port number is 80. Changing this to any number between 1024 and
32,767 is advised for discouraging unauthorized access to the configuration.
When logging in to manage the device later, enter the following in the URL field of
your browser: http://1.1.1.1:5555.

3. Interfaces
Network > Interfaces > Edit (for ethernet0/1): Enter the following, then click
OK:

Zone Name: V1-Trust

IP Address/Netmask: 0.0.0.0/0

Network > Interfaces > Edit (for ethernet0/3): Enter the following, then click
OK:

Zone Name: V1-Untrust

IP Address/Netmask: 0.0.0.0/0
4. V1-Trust Zone
Network > Zones > Edit (for v1-trust): Select the following, then click OK:

Management Services: WebUI, Telnet

Other Services: Ping
5. Addresses
Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: FTP_Server

IP Address/Domain Name:
IP/Netmask: (select), 1.1.1.5/32
Zone: V1-Trust

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: Mail_Server

IP Address/Domain Name:
IP/Netmask: (select), 1.1.1.10/32
Zone: V1-Trust

90  Transparent Mode
 Chapter 4: Interface Modes

6. Route
Network > Routing > Destination > trust-vr New: Enter the following, then
click OK:

Network Address/Netmask: 0.0.0.0/0

Gateway: (select)
Interface: vlan1(trust-vr)
Gateway IP Address: 1.1.1.250
Metric: 1
7. Policies
Policy > Policies > (From: V1-Trust, To: V1-Untrust) New: Enter the following,
then click OK:

Source Address:
Address Book Entry: (select), Any
Destination Address:
Address Book Entry: (select), Any
Service: Any
Action: Permit

Policy > Policies > (From: V1-Untrust, To: V1-Trust) New: Enter the following,
then click OK:

Source Address:
Address Book Entry: (select), Any
Destination Address:
Address Book Entry: (select), Mail_Server
Service: Mail
Action: Permit

Policy > Policies > (From: V1-Untrust, To: V1-Trust) New: Enter the following,
then click OK:

Source Address:
Address Book Entry: (select), Any
Destination Address:
Address Book Entry: (select), FTP_Server
Service: FTP-GET
Action: Permit

CLI
1. VLAN1
set interface vlan1 ip 1.1.1.1/24
set interface vlan1 manage web
set interface vlan1 manage telnet
set interface vlan1 manage ping
2. Telnet
set admin telnet port 4646

NOTE: The default port number for Telnet is 23. Changing this to any number between
1024 and 32,767 is advised for discouraging unauthorized access to the
configuration. When logging in to manage the device later via Telnet, enter the
following address: 1.1.1.1 4646.

Transparent Mode  91
 Concepts & Examples ScreenOS Reference Guide

3. Interfaces
set interface ethernet0/1 ip 0.0.0.0/0
set interface ethernet0/1 zone v1-trust
set interface ethernet0/3 ip 0.0.0.0/0
set interface ethernet0/3 zone v1-untrust
4. V1-Trust Zone
set zone v1-trust manage web
set zone v1-trust manage telnet
set zone v1-trust manage ping
5. Addresses
set address v1-trust FTP_Server 1.1.1.5/32
set address v1-trust Mail_Server 1.1.1.10/32
6. Route
set vrouter trust-vr route 0.0.0.0/0 interface vlan1 gateway 1.1.1.250 metric 1
7. Policies
set policy from v1-trust to v1-untrust any any any permit
set policy from v1-untrust to v1-trust any Mail_Server mail permit
set policy from v1-untrust to v1-trust any FTP_Server ftp-get permit
save

NAT Mode
When an ingress interface is in Network Address Translation (NAT) mode, the
security device, acting like a Layer 3 switch (or router), translates two components
in the header of an outgoing IP packet destined for the Untrust zone: its source IP
address and source port number. The security device replaces the source IP address
of the originating host with the IP address of the Untrust zone interface. Also, it
replaces the source port number with another random port number generated by
the security device.

92  NAT Mode
 Chapter 4: Interface Modes

Figure 43: NAT Topology

10.1.1.15
10.1.1.10 10.1.1.20

10.1.1.5
10.1.1.25
Trust Zone

Private Address Trust Zone

Space Interface
10.1.1.1/24

Untrust Zone
Public Address Interface
Space 1.1.1.1/24
External Router
1.1.1.250
Untrust Zone

Internet

When the reply packet arrives at the security device, the device translates two
components in the IP header of the incoming packet: the destination address and
port number, which are translated back to the original numbers. The security device
then forwards the packet to its destination.

NAT adds a level of security not provided in Transparent mode: The addresses of
hosts sending traffic through an ingress interface in NAT mode (such as a Trust zone
interface) are never exposed to hosts in the egress zone (such as the Untrust zone)
unless the two zones are in the same virtual routing domain and the security device
is advertising routes to peers through a dynamic routing protocol (DRP). Even then,
the Trust zone addresses are only reachable if you have a policy permitting inbound
traffic to them. (If you want to keep the Trust zone addresses hidden while using a
DRP, then put the Untrust zone in the untrust-vr and the Trust zone in the trust-vr,
and do not export routes for internal addresses in the trust-vr to the untrust-vr.)

If the security device uses static routing and just one virtual router, the internal
addresses remain hidden when traffic is outbound, due to interface-based NAT. The
policies you configure control inbound traffic. If you use only mapped IP (MIP) and
virtual IP (VIP) addresses as the destinations in your inbound policies, the internal
addresses still remain hidden.

NAT Mode  93
 Concepts & Examples ScreenOS Reference Guide

Also, NAT preserves the use of public IP addresses. In many environments,

resources are not available to provide public IP addresses for all devices on the
network. NAT services allow many private IP addresses to have access to Internet
resources through one or a few public IP addresses. The following IP address ranges
are reserved for private IP networks and must not get routed on the Internet:

 10.0.0.0 – 10.255.255.255

 172.16.0.0 – 172.31.255.255

 192.168.0.0 – 192.168.255.255

Inbound and Outbound NAT Traffic

A host in a zone sending traffic through an interface in NAT mode can initiate traffic
to the Untrust zone—assuming that a policy permits it. In releases prior to
ScreenOS 5.0.0, a host behind an interface in NAT mode was unable to receive
traffic from the Untrust zone unless a mapped IP (MIP), virtual IP (VIP), or VPN
tunnel was set up for it. However, in ScreenOS 5.0.0, traffic to a zone with a
NAT-enabled interface from any zone—including the Untrust zone—does not need
to use a MIP, VIP, or VPN. If you want to preserve the privacy of addresses or if you
are using private addresses that do not occur on a public network such as the
Internet, you can still define a MIP, VIP, or VPN for traffic to reach them. However, if
issues of privacy and private IP addresses are not a concern, traffic from the Untrust
zone can reach hosts behind an interface in NAT mode directly, without the use of a
MIP, VIP, or VPN.

NOTE: You can define a virtual IP (VIP) address only on an interface bound to the Untrust
zone.

Figure 44: NAT Traffic Flow

1. Interface-based NAT on traffic from the Trust ethernet0/3

zone to the Untrust zone. Untrust Zone 1.1.1.1/24
Route Mode
2. Interface-based NAT on traffic from the MIP 1.1.1.10 to 10.1.1.10
User-Defined zone to the Untrust zone. MIP 1.1.1.20 to 10.1.2.20
1 2
(Note: This is possible only if the User-Defined
and Untrust zones are in different virtual routing NAT NAT
domains.)

3. No interface-based NAT on traffic between the

Trust and User-Defined zones.
ethernet0/1 MIPs are optional ethernet0/2
4 and 5. You can use MIPs, VIPs, or VPNs for 10.1.1.1/24 10.1.2.1/24
traffic from the Untrust zone to reach the Trust NAT Mode 4 5 NAT Mode
zone or the User-Defined zone, but they are not
required.
3 No NAT User-Defined
Trust Zone Zone
MIPs are
optional 6

NOTE: For more information about MIPs, see “Mapped IP Addresses” on page 8-63. For
more about VIPs, see “Virtual IP Addresses” on page 8-80.

94  NAT Mode
 Chapter 4: Interface Modes

Interface Settings
For NAT mode, define the following interface settings, where ip_addr1 and ip_addr2
represent numbers in an IP address, mask represents the numbers in a netmask,
vlan_id_num represents the number of a VLAN tag, zone represents the name of a
zone, and number represents the bandwidth size in kbps:

Zone Interfaces Settings Zone Subinterfaces

Trust, DMZ, and user-defined IP: ip_addr1 IP: ip_addr1
zones using NAT Netmask: mask Netmask: mask
Manage IP1: ip_addr2 VLAN Tag: vlan_id_num
Traffic Bandwidth2: number Zone Name: zone
NAT3: (select) NAT†: (select)
Untrust4 IP: ip_addr1 IP: ip_addr1
Netmask: mask Netmask: mask
Manage IP*: ip_addr2 VLAN Tag: vlan_id_num
Traffic Bandwidth†: number Zone Name: zone

1.You can set the manage IP address for each interface. Its primary purpose is to provide an IP
address for administrative traffic separate from network traffic. You can also use the manage IP
address for accessing a specific device when it is in a high availability configuration.
2.Optional setting for traffic shaping.
3.Selecting NAT defines the interface mode as NAT. Selecting Route defines the interface mode as
Route.
4.Although you are able to select NAT as the interface mode on an interface bound to the Untrust
zone, the security device does not perform any NAT operations on that interface.

NOTE: In NAT mode, you can manage a security device from any interface—and from
multiple interfaces—using the system IP address, interface IP addresses, manage
IP addresses, or the MGT IP address.

Configuring NAT Mode

The following example illustrates a simple configuration for a LAN with a single
subnet in the Trust zone. The LAN is protected by a security device in NAT mode.
Policies permit outgoing traffic for all hosts in the Trust zone and incoming mail for
the mail server. The incoming mail is routed to the mail server through a virtual IP
address. Both the Trust and Untrust zones are in the trust-vr routing domain.

NOTE: Compare Figure 45 with that for Route mode in Figure 47, “Device in Route
Mode,” on page 99.

Figure 45: Device in NAT Mode

External Router
1.1.1.250

Mail Server
Internet
VIP 1.1.1.5 ->
10.1.1.5
ethernet0/1 ethernet0/3
Trust Zone Untrust Zone
10.1.1.1/24 1.1.1.1/24
NAT Mode Route Mode

NAT Mode  95
 Concepts & Examples ScreenOS Reference Guide

WebUI
1. Interfaces
Network > Interfaces > Edit (for ethernet0/1): Enter the following, then click
Apply:

Zone Name: Trust

Static IP: (select this option when present)
IP Address/Netmask: 10.1.1.1/24
Enter the following, then click OK:
Interface Mode: NAT

NOTE: By default, any interface that you bind to the Trust zone is in NAT mode.
Consequently, this option is already enabled for interfaces bound to the Trust
zone.

Network > Interfaces > Edit (for ethernet0/3): Enter the following, then click
OK:

Zone Name: Untrust

Static IP: (select this option when present)
IP Address/Netmask: 1.1.1.1/24
Interface Mode: Route

NOTE: If the IP address in the Untrust zone on the security device is dynamically
assigned by an ISP, leave the IP address and netmask fields empty and select
Obtain IP using DHCP. If the ISP uses Point-to-Point Protocol over Ethernet, select
Obtain IP using PPPoE, click the Create new PPPoE settings link, and enter the
name and password.

2. VIP
Network > Interfaces > Edit (for ethernet0/3) > VIP: Enter the following, then
click Add:

Virtual IP Address: 1.1.1.5

Network > Interfaces > Edit (for ethernet0/3) > VIP > New VIP Service: Enter
the following, then click OK:

Virtual Port: 25
Map to Service: Mail
Map to IP: 10.1.1.5

NOTE: For information about virtual IP (VIP) addresses, see “Virtual IP Addresses” on
page 8-80.

3. Route
Network > Routing > Destination > trust-vr New: Enter the following, then
click OK:

Network Address/Netmask: 0.0.0.0/0

Gateway: (select)
Interface: ethernet0/3
Gateway IP Address: 1.1.1.250

96  NAT Mode
 Chapter 4: Interface Modes

4. Policies
Policy > Policies > (From: Trust, To: Untrust) New: Enter the following, then
click OK:

Source Address:
Address Book Entry: (select), Any
Destination Address:
Address Book Entry: (select), Any
Service: ANY
Action: Permit

Policy > Policies > (From: Untrust, To: Global) New: Enter the following, then
click OK:

Source Address:
Address Book Entry: (select), Any
Destination Address:
Address Book Entry: (select), VIP(1.1.1.5)
Service: MAIL
Action: Permit

CLI
1. Interfaces
set interface ethernet0/1 zone trust
set interface ethernet0/1 ip 10.1.1.1/24
set interface ethernet0/1 nat
set interface ethernet0/3 zone untrust
set interface ethernet0/3 ip 1.1.1.1/24
set interface ethernet0/3 route

NOTE: The set interface ethernetn nat command determines that the security device
operates in NAT mode.

If the IP address in the Untrust zone on the security device is dynamically

assigned by an ISP, use the following command: set interface untrust dhcp. If the
ISP uses Point-to-Point Protocol over Ethernet, use the set pppoe and exec pppoe
commands. For more information, refer to the ScreenOS CLI Reference Guide: IPv4
Command Descriptions.

2. VIP
set interface ethernet0/3 vip 1.1.1.5 25 mail 10.1.1.5
3. Route
set vrouter trust-vr route 0.0.0.0/0 interface ethernet0/3 gateway 1.1.1.250
4. Policies
set policy from trust to untrust any any any permit
set policy from untrust to global any vip(1.1.1.5) mail permit
save

NAT Mode  97
 Concepts & Examples ScreenOS Reference Guide

Route Mode
When an interface is in Route mode, the security device routes traffic between
different zones without performing source NAT (NAT-src); that is, the source address
and port number in the IP packet header remain unchanged as it traverses the
security device. Unlike NAT-src, you do not need to establish mapped IP (MIP) and
virtual IP (VIP) addresses to allow inbound traffic to reach hosts when the
destination zone interface is in Route mode. Unlike Transparent mode, the
interfaces in each zone are on different subnets.

Figure 46: NAT Topology

1.1.1.15
1.1.1.10 1.1.1.20

1.1.1.5
1.1.1.25
Trust Zone

Public Address
Space Trust Zone
Interface
1.1.1.1/24

Untrust Zone
Public Address Interface
Space 2.2.2.2/24
External Router
2.2.2.250
Untrust Zone

Internet

You do not have to apply Source Network Address Translation (NAT-src) at the
interface level so that all source addresses initiating outgoing traffic get translated to
the IP address of the destination zone interface. Instead, you can perform NAT-src
selectively at the policy level. You can determine which traffic to route and on
which traffic to perform NAT-src by creating policies that enable NAT-src for
specified source addresses on either incoming or outgoing traffic. For network
traffic, NAT can use the IP address or addresses of the destination zone interface
from a dynamic IP (DIP) pool, which is in the same subnet as the destination zone
interface. For VPN traffic, NAT can use a tunnel interface IP address or an address
from its associated DIP pool.

NOTE: For more information about configuring policy-based NAT-src, see “Source
Network Address Translation” on page 8-13.

98  Route Mode
 Chapter 4: Interface Modes

Interface Settings
For Route mode, define the following interface settings, where ip_addr1 and
ip_addr2 represent numbers in an IP address, mask represents the numbers in a
netmask, vlan_id_num represents the number of a VLAN tag, zone represents the
name of a zone, and number represents the bandwidth size in kbps:

Table 7: Interface Settings

I
Zone Interfaces Settings Zone Subinterfaces
Trust, Untrust, DMZ, and IP: ip_addr1 IP: ip_addr1
user-defined zones Netmask: mask Netmask: mask
Manage IP1: ip_addr2 VLAN Tag: vlan_id_num
Traffic Bandwidth2: number Zone Name: zone
Route3: (select) Route†: (select)

1.You can set the manage IP address for each interface. Its primary purpose is to provide an IP
address for administrative traffic separate from network traffic. You can also use the manage IP
address for accessing a specific device when it is in a high availability configuration.
2.Optional setting for traffic shaping.
3.Selecting Route defines the interface mode as Route. Selecting NAT defines the interface mode
as NAT.

Configuring Route Mode

In “Configuring NAT Mode” on page 95, the hosts in the Trust zone LAN have
private IP addresses and a mapped IP for the mail server. In the following example
of the same network protected by a security device operating in Route mode, note
that the hosts have public IP addresses and that a MIP is unnecessary for the mail
server. Both security zones are in the trust-vr routing domain.

Figure 47: Device in Route Mode

External Router
1.1.1.250

Mail Server Internet

1.2.2.5

Trust Zone ethernet0/1 ethernet0/3 Untrust Zone

1.2.2.1/24 1.1.1.1/24
Route Mode Route Mode

WebUI
1. Interfaces
Network > Interfaces > Edit (for ethernet0/1): Enter the following, then click
Apply:

Zone Name: Trust

Static IP: (select this option when present)
IP Address/Netmask: 1.2.2.1/24
Enter the following, then click OK:
Interface Mode: Route

Route Mode  99
 Concepts & Examples ScreenOS Reference Guide

Network > Interfaces > Edit (for ethernet0/3): Enter the following, then click
OK:

Zone Name: Untrust

Static IP: (select this option when present)
IP Address/Netmask: 1.1.1.1/24

NOTE: Selecting Route determines that the security device operates in Route mode,
without performing NAT on traffic entering or exiting the Trust zone.

If the IP address in the Untrust zone on the security device is dynamically

assigned by an ISP, leave the IP address and netmask fields empty and select
Obtain IP using DHCP. If the ISP uses Point-to-Point Protocol over Ethernet, select
Obtain IP using PPPoE, click the Create new PPPoE settings link, and then enter
the name and password.

2. Address
Policy > Policy Elements > Addresses > List > New: Enter the following and
then click OK:

Address Name: Mail Server

IP Address/Domain Name:
IP/Netmask: (select), 1.2.2.5/32
Zone: Trust
3. Route
Network > Routing > Destination > trust-vr New: Enter the following, then
click OK:

Network Address/Netmask: 0.0.0.0/0

Gateway: (select)
Interface: ethernet0/3
Gateway IP Address: 1.1.1.250
4. Policies
Policy > Policies > (From: Trust, To: Untrust) New: Enter the following, then
click OK:

Source Address:
Address Book Entry: (select), Any
Destination Address:
Address Book Entry: (select), Any
Service: ANY
Action: Permit

Policy > Policies > (From: Untrust, To: Trust) New: Enter the following, then
click OK:

Source Address:
Address Book Entry: (select), Any
Destination Address:
Address Book Entry: (select), Mail Server
Service: MAIL
Action: Permit

100  Route Mode

 Chapter 4: Interface Modes

CLI
1. Interfaces
set interface ethernet0/1 zone trust
set interface ethernet0/1 ip 1.2.2.1/24
set interface ethernet0/1 route
set interface ethernet0/3 zone untrust
set interface ethernet0/3 ip 1.1.1.1/24
set interface ethernet0/3 route

NOTE: The set interface ethernet number route command determines that the security
device operates in Route mode.

2. Address
set address trust mail_server 1.2.2.5/24
3. Route
set vrouter trust-vr route 0.0.0.0/0 interface ethernet0/3 gateway 1.1.1.250
4. Policies
set policy from trust to untrust any any any permit
set policy from untrust to trust any mail_server mail permit
save

Route Mode  101

 Concepts & Examples ScreenOS Reference Guide

102  Route Mode

Chapter 5
Building Blocks for Policies

This chapter discusses the components, or building blocks, that you can reference
in policies. It contains the following sections:

 “Addresses” on page 103

 “Services” on page 108

 “Dynamic IP Pools” on page 141

 “Setting a Recurring Schedule” on page 157

NOTE: For information about user authentication, see Volume 9: User Authentication.

Addresses
ScreenOS classifies the addresses of all other devices by location and by netmask.
Each zone possesses its own list of addresses and address groups.

Because an individual host has a single IP address defined, it must have a netmask
setting of 255.255.255.255 (which masks out all but this host). Subnets have an IP
address and a netmask (for example, 255.255.255.0 or 255.255.0.0).

A wildcard address contains a range of address, enabling you to reduce the number
of policies that you create. A wildcard address has an IP address and a wildcard
mask (for example, 0.0.255.0). For more information on wildcard addresses, see
“Wildcard Addresses” on page 166.

Before you can configure policies to permit, deny, or tunnel traffic to and from
individual hosts and subnets, you must make entries for them in ScreenOS address
lists, which are organized by zones.

NOTE: You do not have to make address entries for “Any.” This term automatically
applies to all devices physically located within their respective zones.

Addresses  103
 Concepts & Examples ScreenOS Reference Guide

Address Entries
Before you can set up many of the Juniper Networks firewall, VPN, and traffic
shaping features, you need to define addresses in one or more address lists. The
address list for a security zone contains the IP addresses or domain names of hosts
or subnets whose traffic is either allowed, blocked, encrypted, or
user-authenticated.

NOTE: Before you can use domain names for address entries, you must configure the
security device for Domain Name System (DNS) services. For information about
DNS configuration, see “Domain Name System Support” on page 217.

For information regarding ScreenOS naming conventions—which apply to the

names you create for addresses—see “Naming Conventions and Character Types”
on page xi.

Adding an Address
In this example, you add the subnet “Sunnyvale_Eng” with the IP address
10.1.10.0/24 as an address in the Trust zone, and the address www.juniper.net as an
address in the Untrust zone.

WebUI
Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: Sunnyvale_Eng

IP Address/Domain Name:
IP/Netmask: (select), 10.1.10.0/24
Zone: Trust

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: Juniper

IP Address/Domain Name:
Domain Name: (select), www.juniper.net
Zone: Untrust

CLI
set address trust Sunnyvale_Eng 10.1.10.0/24
set address untrust Juniper www.juniper.net
save

104  Addresses
 Chapter 5: Building Blocks for Policies

Modifying an Address
In this example, you change the address entry for the address “Sunnyvale_Eng” to
reflect that this department is specifically for software engineering and has a
different IP address—10.1.40.0/24.

WebUI
Policy > Policy Elements > Addresses > List > Edit (for Sunnyvale_Eng):
Change the name and IP address to the following, then click OK:

Address Name: Sunnyvale_SW_Eng

IP Address/Domain Name:
IP/Netmask: (select), 10.1.40.0/24
Zone: Trust

CLI
unset address trust Sunnyvale_Eng
set address trust Sunnyvale_SW_Eng 10.1.40.0/24
save

NOTE: After you define an address—or an address group—and associate it with a policy,
you cannot change the address location to another zone (such as from Trust to
Untrust). To change its location, you must first disassociate it from the underlying
policy.

Deleting an Address
In this example, you remove the address entry for the address
“Sunnyvale_SW_Eng”.

WebUI
Policy > Policy Elements > Addresses > List: Click Remove in the Configure
column for Sunnyvale_SW_Eng.

CLI
unset address trust “Sunnyvale_SW_Eng”
save

Address Groups
“Address Entries” on page 104 explained how you create, modify, and delete
address book entries for individual hosts and subnets. As you add addresses to an
address list, it becomes difficult to manage how policies affect each address entry.
ScreenOS allows you to create groups of addresses. Rather than manage a large
number of address entries, you can manage a small number of groups. Changes
you make to the group are applied to each address entry in the group.

Addresses  105
 Concepts & Examples ScreenOS Reference Guide

Figure 48: Address Groups

1 Policy per Address 1 Policy per Address Group

Name Access
Address Policy

Name Access
Access Name
Address Policy
Name Name
Address
Address Policy Address

Name Access
Address Policy

The address group option has the following features:

 You can create address groups in any zone.

 You can create address groups with existing users, or you can create empty
address groups and later fill them with users.

 An address group can be a member of another address group.

NOTE: To ensure that a group does not accidentally contain itself as a member, the
security device performs a sanity check when you add one group to another. For
example, if you add group A as a member to group B, the security device
automatically checks that A does not already contain B as its member.

 You can reference an address group entry in a policy like an individual address
book entry.

 ScreenOS applies policies to each member of the group by internally creating

individual policies for each group member. While you only have to create one
policy for a group, ScreenOS actually creates an internal policy for each
member in the group (as well as for each service configured for each user).

NOTE: The automatic nature by which the security device applies policies to each address
group member saves you from having to create them individually for each
address. Furthermore, ScreenOS writes these policies to the application-specific
integrated circuit (ASIC), which speeds up lookups.

106  Addresses
 Chapter 5: Building Blocks for Policies

 When you delete an individual address book entry from the address book, the
security device automatically removes it from all groups to which it belonged.

The following constraints apply to address groups:

 Address groups can only contain addresses that belong to the same zone.

 Address names cannot be the same as group names. If the name “Paris” is used
for an individual address entry, it cannot be used for a group name.

 If an address group is referenced in a policy, the group cannot be removed. It

can, however, be edited.

 When a single policy is assigned to an address group, it is applied to each group

member individually, and the security device makes an entry for each member
in the access control list (ACL). If you are not vigilant, it is possible to exceed the
number of available policy resources, especially if both the source and
destination addresses are address groups and the specified service is a service
group.

 You cannot add the predefined addresses: “Any,” “All Virtual IPs,” and “Dial-Up
VPN” to groups.

Creating an Address Group

In the following example, you create a group named “HQ 2nd Floor” that includes
“Santa Clara Eng” and “Tech Pubs,” two addresses that you have already entered in
the address book for the Trust zone.

WebUI
Policy > Policy Elements > Addresses > Groups > (for Zone: Trust) New:
Enter the following group name, move the following addresses, then click OK:

Group Name: HQ 2nd Floor

Select Santa Clara Eng and use the << button to move the address from
the Available Members column to the Group Members column.

Select Tech Pubs and use the << button to move the address from the
Available Members column to the Group Members column.

CLI
set group address trust “HQ 2nd Floor” add “Santa Clara Eng”
set group address trust “HQ 2nd Floor” add “Tech Pubs”
save

Addresses  107
 Concepts & Examples ScreenOS Reference Guide

Editing an Address Group Entry

In this example, you add “Support” (an address that you have already entered in the
address book) to the “HQ 2nd Floor” address group.

WebUI
Policy > Policy Elements > Addresses > Groups > (for Zone: Trust) Edit (for
HQ 2nd Floor): Move the following address, then click OK:

Select Support and use the << button to move the address from the
Available Members column to the Group Members column.

CLI
set group address trust “HQ 2nd Floor” add Support
save

Removing a Member and a Group

In this example, you remove the member “Support” from the HQ 2nd Floor address
group, and delete “Sales,” an address group that you had previously created.

WebUI
Policy > Policy Elements > Addresses > Groups > (for Zone: Trust) Edit (HQ
2nd Floor): Move the following address, then click OK:

Select Support and use the >> button to move the address from the
Group Members column to the Available Members column.

Policy > Policy Elements > Addresses > Groups > (Zone: Trust): Click
Remove in the Configure column for Sales.

CLI
unset group address trust “HQ 2nd Floor” remove Support
unset group address trust Sales
save

NOTE: The security device does not automatically delete a group from which you have
removed all names.

Services
Services are types of traffic for which protocol standards exist. Each service has a
transport protocol and destination port number(s) associated with it, such as
TCP/port 21 for FTP and TCP/port 23 for Telnet. When you create a policy, you must
specify a service for it. You can select one of the predefined services from the
service book, or a custom service or service group that you created. You can see
which service you can use in a policy by viewing the Service drop-down list on the
Policy Configuration page (WebUI) or by using the get service command (CLI).

Predefined Services
You can view the list of predefined or custom services or service groups on the
security device using the WebUI or the CLI.

108  Services
 Chapter 5: Building Blocks for Policies

 Using the WebUI:

 Policy > Policy Elements > Services > Predefined

 Policy > Policy Elements > Services > Custom

 Policy > Policy Elements > Services > Groups

 Using the CLI:

get service [ group | predefined | user ]

NOTE: Each predefined service has a source port range of 1-65535, which includes the
entire set of valid port numbers. This prevents potential attackers from gaining
access by using a source port outside of the range. If you need to use a different
source port range for any predefined service, create a custom service. For
information, see “Custom Services” on page 120.

This section contains information about the following predefined services:

 “Internet Control Messaging Protocol” on page 110

 “Internet-Related Predefined Services” on page 113

 “Microsoft Remote Procedure Call Services” on page 114

 “Dynamic Routing Protocols” on page 116

 “Streaming Video” on page 116

 “Sun Remote Procedure Call Services” on page 117

 “Security and Tunnel Services” on page 117

 “IP-Related Services” on page 118

 “Instant Messaging Services” on page 118

 “Management Services” on page 118

 “Mail Services” on page 119

 “UNIX Services” on page 119

 “Miscellaneous Services” on page 120

You can find more detailed information about some of these listed on the following
pages:

 “Defining a Custom Internet Control Message Protocol Service” on page 125

 “Remote Shell Application Layer Gateway” on page 126

 “Sun Remote Procedure Call Application Layer Gateway” on page 126

Services  109
 Concepts & Examples ScreenOS Reference Guide

 “Customizing Microsoft Remote Procedure Call Application Layer Gateway” on

page 127

 “Real-Time Streaming Protocol Application Layer Gateway” on page 129

 “Stream Control Transmission Protocol Application Layer Gateway” on

page 137

 “Point-to-Point Tunneling Protocol Application Layer Gateway” on page 137

Internet Control Messaging Protocol

Internet Control Messaging Protocol (ICMP) is a part of IP and provides a way to
query a network (ICMP Query messages) and to receive feedback from the network
for error patterns (ICMP Error messages). ICMP does not, however, guarantee error
message delivery or report all lost datagrams; for these reasons it is not considered
a reliable protocol. ICMP codes and types describe ICMP Query messages and ICMP
Error messages.

You can choose to permit or deny any or specific types of ICMP messages to
improve network security. Some types of ICMP messages can be exploited to gain
information about your network that might compromise security. For example,
ICMP, TCP, or UDP packets can be constructed to return ICMP error messages that
contain information about a network, such as its topology, and access list filtering
characteristics. Table 8 on page 110 lists ICMP message names, the corresponding
code, type, and description.

Table 8: ICMP Information (page 1 of 3)

ICMP Message Name Type Code Description

ICMP-ANY all all ICMP-ANY affects any protocol using ICMP.
Denying ICMP-ANY impairs any attempt to ping or monitor a network using ICMP.
Permitting ICMP-ANY allows all ICMP messages.
ICMP-ADDRESS-MASK ICMP Address Mask Query is used for systems that need the local subnet mask from
 Request 17 0 a bootstrap server.
Denying ICMP Address Mask request messages can adversely affect diskless
 Reply 18 0
systems.
Permitting ICMP Address Mask request messages might allow others to fingerprint
the operating system of a host in your network.
ICMP-DEST-UNREACH 3 0 ICMP Destination Unreachable Error message indicates that the destination host is
configured to reject the packets.
Codes 0, 1, 4, or 5 can be from a gateway. Codes 2 or 3 from a host (RFC 792).
Denying ICMP Destination Unreachable Error messages can remove the assumption
that a host is up and running behind a security device.
Permitting ICMP Destination Unreachable Error messages can allow some
assumptions, such as security filtering, to be made about the network.
ICMP Fragment Needed 3 4 ICMP Fragmentation Error message indicates that fragmentation is needed but the
don’t fragment flag is set.
Denying these messages from the Internet (untrust) to the trusted network is
recommended.

110  Services
 Chapter 5: Building Blocks for Policies

Table 8: ICMP Information (page 2 of 3)

ICMP Message Name Type Code Description

ICMP Fragment 11 1 ICMP Fragment Reassembly Time Exceeded Error indicates that a host
Reassembly reassembling a fragmented message ran out of time and dropped the packet. This
message is sometimes sent.
Denying these messages from the Internet (untrust) to the trusted network is
recommended.
ICMP-HOST- 3 1 ICMP Host Unreachable Error messages indicate that routing table entries do not list
UNREACH or list as infinity a particular host. Sometimes this error is sent by gateways that
cannot fragment when a packet requiring fragmentation is received.
Denying these messages from the Internet (untrust) to the trusted network is
recommended.
Permitting these messages allows others to be able to determine your internal hosts
IP addresses by a process of elimination or make assumptions about gateways and
fragmentation.
ICMP-INFO ICMP-INFO Query messages allow diskless host systems to query the network and
 Request 15 0 self-configure.
Denying ICMP Address Mask request messages can adversely affect diskless
 Reply 16 0
systems.
Permitting ICMP Address Mask request messages might allow others to broadcast
information queries to a network segment to determine computer type.
ICMP-PARAMETER- 12 0 ICMP Parameter Problem Error messages notify you when incorrect header
PROBLEM parameters are present and caused a packet to be discarded
Denying these messages from the Internet (untrust) to a trusted network is
recommended.
Permitting ICMP Parameter Problem error messages allows others to make
assumptions about your network.
ICMP-PORT-UNREACH 3 3 ICMP Port Unreachable Error messages indicate that gateways processing data
grams requesting certain ports are unavailable or unsupported in the network.
Denying these messages from the Internet (untrust) to the trusted network is
recommended.
Permitting ICMP Port Unreachable Error messages can allow others to determine
which ports you use for certain protocols.
ICMP-PROTOCOL- 3 2 ICMP Protocol Unreachable Error messages indicate that gateways processing data
UNREACH grams requesting certain protocols are unavailable or unsupported in the network.
Denying these messages from the Internet (untrust) to the trusted network is
recommended.
Permitting ICMP Protocol Unreachable Error messages can allow others to
determine what protocols your network is running.
ICMP-REDIRECT 5 0 ICMP Redirect Network Error messages are sent by routers.
Denying these messages from the Internet (untrust) to the trusted network is
recommended.
ICMP-REDIRECT-HOST 5 1 ICMP redirect messages indicate data grams destined for the specified host to be
sent along another path.
ICMP-REDIRECT-TOS- 5 3 ICMP Redirect Type of Service (TOS) and Host Error is a type of message.
HOST
ICMP-REDIRECT-TOS- 5 2 ICMP Redirect TOS and Network Error is a type of message.
NET

Services  111
 Concepts & Examples ScreenOS Reference Guide

Table 8: ICMP Information (page 3 of 3)

ICMP Message Name Type Code Description

ICMP-SOURCE- 4 0 ICMP Source Quench Error message indicates that a router does not have the buffer
QUENCH space available to accept, queue, and send the packets on to the next hop.
Denying these messages will not help or impair internal network performance.
Permitting these messages can allow others to know that a router is congested
making it a viable attack target.
ICMP-SOURCE-ROUTE- 3 5 ICMP Source Route Failed Error message
FAIL Denying these messages from the Internet (untrust) is recommended.
ICMP-TIME-EXCEEDED 11 0 ICMP Time to Live (TTL) Exceeded Error message indicates that a packet’s TTL
setting reached zero before the packet reached its destination. This ensures that
older packets are discarded before resent ones are processed.
Denying these messages from a trusted network out to the Internet is
recommended.
ICMP-TIMESTAMP ICMP-TIMESTAMP Query messages provide the mechanism to synchronize time and
 Request 13 0 coordinate time distribution in a large, diverse network.

 Reply 14 0
Ping (ICMP ECHO) 8 0 Packet Internet Groper is a utility to determine whether a specific host is accessible
by its IP address.0/0 echo reply.
Denying ping functionality removes your ability to check to see if a host is active.
Permitting ping can allow others to execute a denial of service (DoS) or Smurf
attack.
ICMP-ECHO- 11 1 ICMP Fragment Echo Reassembly Time Expired error message indicates that the
FRAGMENT-ASSEMBLY- reassembly time was exceeded.
EXPIRE Denying these messages is recommended.
Traceroute Traceroute is a utility to indicate the path to access a specific host.
 Forward 30 0 Denying this utility from the Internet (untrust) to your internal network (trust) is
recommended.
 Discard 30 1

Handling ICMP Unreachable Errors

For different levels of security, the default behavior for ICMP unreachable errors
from downstream routers is handled as follows:

 Sessions do not close for ICMP type 3 code 4 messages.

ICMP messages pass through without dropping sessions. Packets are however,
dropped per session.

 Sessions do not close on receiving any kind of ICMP unreachable messages.

 Sessions store ICMP unreachable message, thereby restricting the number of

messages flowing through to 1.

One ICMP unreachable message is generated globally per device. The

remaining ICMP unreachable errors are dropped.

112  Services
 Chapter 5: Building Blocks for Policies

Internet-Related Predefined Services

Table 9 lists Internet-related predefined services. Depending on your network
requirements, you can choose to permit or deny any or all of these services. Each
entry lists the service name, default receiving port, and service description.

Table 9: Predefined Services

Service Name Port(s) Service Description

AOL 5190-5193 America Online Internet Service Provider (ISP) provides Internet, chat, and instant
messaging services.
DHCP-Relay 67 (default) Dynamic Host Configuration.
DHCP 68 (client) Dynamic Host Configuration Protocol allocates network addresses and delivers
67 (server) configuration parameters from server to hosts.

DNS 53 Domain Name System translates domain names into IP addresses.

FTP File Transfer Protocol (FTP) allows the sending and receiving of files between
 FTP-Get 20 (data) machines. You can choose to deny or permit ANY (GET or PUT) or to selectively
permit or deny either GET or PUT. GET receives files from another machine and PUT
 FTP-Put 21 (control) sends files to another machine.
We recommend denying FTP services from untrusted sources (Internet).
Gopher 70 Gopher organizes and displays Internet servers’ contents as a hierarchically
structured list of files.
We recommend denying Gopher access to avoid exposing your network structure.
HTTP 8080 HyperText Transfer Protocol is the underlying protocol used by the World Wide Web
(WWW).
Denying HTTP service disables your users from viewing the Internet.
Permitting HTTP service allows your trusted hosts to view the Internet.
HTTP-EXT — Hypertext Transfer Protocol with extended non-standard ports
HTTPS 443 Hypertext Transfer Protocol with Secure Socket Layer (SSL) is a protocol for
transmitting private documents through the Internet.
Denying HTTPS disables your users from shopping on the Internet and from
accessing certain online resources that require secure password exchange.
Permitting HTTPS allows your trusted hosts to participate in password exchange,
shop online and visit various protected online resources that require user login.
Internet Locator Service — Internet Locator Service includes LDAP, User Locator Service, and LDAP over TSL/SSL.
IRC 6665-6669 Internet Relay Chat (IRC) allows people connected to the Internet to join live
discussions.
LDAP 389 Lightweight Directory Access Protocol is a set of protocols used to access information
directories.
PC-Anywhere — PC-Anywhere is a remote control and file transfer software.
TFTP 69 TFTP is a protocol for simple file transfer.
WAIS — Wide Area Information Server is a program that finds documents on the Internet.

Services  113
 Concepts & Examples ScreenOS Reference Guide

Microsoft Remote Procedure Call Services

Table 10 lists predefined Microsoft services, parameters associated with each
service, and a brief description of each service. Parameters include Universal
Unique Identifiers (UUIDs) and TCP/UDP source and destination ports. A UUID is a
128-bit unique number generated from a hardware address, a timestamp, and seed
values.

Table 10: Microsoft Services (page 1 of 3)

Service Parameter/UUID Description

MS-RPC-EPM 135 Microsoft Remote Procedure Call (RPC) Endpoint
e1af8308-5d1f-11c9-91a4-08002b14a0fa Mapper (EPM) Protocol

MS-RPC-ANY — Any Microsoft Remote Procedure Call (RPC)

Services
MS-AD 4 members Microsoft Active Directory Service Group includes:
 MS-AD-BR
 MS-AD-DRSUAPI
 MS-AD-DSROLE
 MS-AD-DSSETUP

MS-EXCHANGE 6 members Microsoft Exchange Service Group includes:

 MS-EXCHANGE-DATABASE
 MS-EXCHANGE-DIRECTORY
 MS-EXCHANGE-INFO-STORE
 MS-EXCHANGE-MTA
 MS-EXCHANGE-STORE
 MS-EXCHANGE-SYSATD

MS-IIS 6 members Microsoft IIS Server Service Group includes:

 MS-IIS-COM
 MS-IIS-IMAP4
 MS-IIS-INETINFO
 MS-IIS-NNTP
 MS-IIS-POP3
 MS-IIS-SMTP

MS-AD-BR ecec0d70-a603-11d0-96b1-00a0c91ece30 Microsoft Active Directory Backup and Restore

16e0cf3a-a604-11d0-96b1-00a0c91ece30 Services

MS-AD-DRSUAPI e3514235-4b06-11d1-ab04-00c04fc2dcd2 Microsoft Active Directory Replication Service

MS-AD-DSROLE 1cbcad78-df0b-4934-b558-87839ea501c9 Microsoft Active Directory DSROLE Service
MS-AD-DSSETUP 3919286a-b10c-11d0-9ba8-00c04fd92ef5 Microsoft Active Directory Setup Service
MS-DTC 906b0ce0-c70b-1067-b317-00dd010662da Microsoft Distributed Transaction Coordinator
Service
MS-EXCHANGE-DATABASE 1a190310-bb9c-11cd-90f8-00aa00466520 Microsoft Exchange Database Service
MS-EXCHANGE-DIRECTORY f5cc5a18-4264-101a-8c59-08002b2f8426 Microsoft Exchange Directory Service
f5cc5a7c-4264-101a-8c59-08002b2f8426
f5cc59b4-4264-101a-8c59-08002b2f8426

114  Services
 Chapter 5: Building Blocks for Policies

Table 10: Microsoft Services (page 2 of 3)

Service Parameter/UUID Description

MS-EXCHANGE-INFO-STORE 0e4a0156-dd5d-11d2-8c2f-00c04fb6bcde Microsoft Exchange Information Store Service
1453c42c-0fa6-11d2-a910-00c04f990f3b
10f24e8e-0fa6-11d2-a910-00c04f990f3b
1544f5e0-613c-11d1-93df-00c04fd7bd09
MS-EXCHANGE-MTA 9e8ee830-4459-11ce-979b-00aa005ffebe Microsoft Exchange MTA Service
38a94e72-a9bc-11d2-8faf-00c04fa378ff
MS-EXCHANGE-STORE 99e66040-b032-11d0-97a4-00c04fd6551d Microsoft Exchange Store Service
89742ace-a9ed-11cf-9c0c-08002be7ae86
a4f1db00-ca47-1067-b31e-00dd010662da
a4f1db00-ca47-1067-b31f-00dd010662da
MS-EXCHANGE-SYSATD 67df7c70-0f04-11ce-b13f-00aa003bac6c Microsoft Exchange System Attendant Service
f930c514-1215-11d3-99a5-00a0c9b61b04
83d72bf0-0d89-11ce-b13f-00aa003bac6c
469d6ec0-0d87-11ce-b13f-00aa003bac6c
06ed1d30-d3d3-11cd-b80e-00aa004b9c30
MS-FRS f5cc59b4-4264-101a-8c59-08002b2f8426 Microsoft File Replication Service
d049b186-814f-11d1-9a3c-00c04fc9b232
a00c021c-2be2-11d2-b678-0000f87a8f8e
MS-IIS-COM 70b51430-b6ca-11d0-b9b9-00a0c922e750 Microsoft Internet Information Server COM
a9e69612-b80d-11d0-b9b9-00a0c922e70 GUID/UUID Service

MS-IIS-IMAP4 2465e9e0-a873-11d0-930b-00a0c90ab17c Microsoft Internet Information Server IMAP4

Service
MS-IIS-INETINFO 82ad4280-036b-11cf-972c-00aa006887b0 Microsoft Internet Information Server
Administration Service
MS-IIS-NNTP 4f82f460-0e21-11cf-909e-00805f48a135 Microsoft Internet Information Server NNTP
Service
MS-IIS-POP3 1be617c0-31a5-11cf-a7d8-00805f48a135 Microsoft Internet Information Server POP3
Service
MS-IIS-SMTP 8cfb5d70-31a4-11cf-a7d8-00805f48a135 Microsoft Internet Information Server STMP
Service
MS-ISMSERV 68dcd486-669e-11d1-ab0c-00c04fc2dcd2 Microsoft Inter-site Messaging Service
130ceefb-e466-11d1-b78b-00c04fa32883
MS-MESSENGER 17fdd703-1827-4e34-79d4-24a55c53bb37 Microsoft Messenger Service
5a7b91f8-ff00-11d0-a9b2-00c04fb6e6fc
MS-MQQM fdb3a030-065f-11d1-bb9b-00a024ea5525 Microsoft Windows Message Queue Management
76d12b80-3467-11d3-91ff-0090272f9ea3 Service

1088a980-eae5-11d0-8d9b-00a02453c33
5b5b3580-b0e0-11d1-b92d-0060081e87f0
41208ee0-e970-11d1-9b9e-00e02c064c39
MS-NETLOGON 12345678-1234-abcd-ef00-01234567cffb Microsoft Netlogon Service

Services  115
 Concepts & Examples ScreenOS Reference Guide

Table 10: Microsoft Services (page 3 of 3)

Service Parameter/UUID Description

MS-SCHEDULER 1ff70682-0a51-30e8-076d-740be8cee98b Microsoft Scheduler Service
378e52b0-c0a9-11cf-822d-00aa0051e40f
0a74ef1c-41a4-4e06-83ae-dc74fb1cdd53
MS-WIN-DNS 50abc2a4-574d-40b3-9d66-ee4fd5fba076 Microsoft Windows DNS Server
MS-WINS 45f52c28-7f9f-101a-b52b-08002b2efabe Microsoft WINS Service
811109bf-a4e1-11d1-ab54-00a0c91e9b45

Dynamic Routing Protocols

Depending on your network requirements, you can choose to permit or deny
messages generated from and packets of these dynamic routing protocols. Table 11
lists each supported dynamic routing protocol by name, port, and description.

Table 11: Dynamic Routing Protocols

Dynamic Routing Protocol Port Description

RIP 520 RIP is a common distance-vector routing protocol.
OSPF 89 OSPF is a common link-state routing protocol.
BGP 179 BGP is an exterior/interdomain routing protocol.

Streaming Video
Table 12 lists each supported streaming video service by name and includes the
default port and description. Depending on your network requirements, you can
choose to permit or deny any or all of these services.

Table 12: Streaming Video Services

Service Port Description

H.323 TCP source 1-65535; TCP destination 1720, H.323 is a standard approved by the International
1503, 389, 522, 1731 Telecommunication Union (ITU) that defines how audiovisual
UDP source 1-65535; UDP source 1719 conference data is transmitted across networks.

NetMeeting TCP source 1-65535; TCP destination 1720, Microsoft NetMeeting uses TCP to provide teleconferencing (video
1503, 389, 522 and audio) services over the Internet.
UDP source 1719
Real media TCP source 1-65535; TCP destination 7070 Real Media is streaming video and audio technology.
RTSP 554 Real Time Streaming Protocol (RTSP) for streaming media
applications
SIP 5056 Session Initiation Protocol (SIP) is an Application Layer control
protocol for creating, modifying, and terminating sessions.
VDO Live TCP source 1-65535; TCP destination VDOLive is a scalable, video streaming technology.
7000-7010

116  Services
 Chapter 5: Building Blocks for Policies

Sun Remote Procedure Call Services

Table 13 lists each Sun Remote Procedure Call Application Layer Gateway (RPC ALG)
service name, program numbers, and full name.

Table 13: Remote Procedure Call Application Layer Gateway Services

Program
Service Numbers Full Name
SUN-RPC-PORTMAPPER 111 Sun RPC Portmapper Protocol
100000
SUN-RPC-ANY ANY Any Sun RPC services
SUN-RPC-PROGRAM-MOUNTD 100005 Sun RPC Mount Daemon
SUN-RPC-PROGRAM-NFS 100003 Sun RPC Network File System
100227
SUN-RPC-PROGRAM-NLOCKMGR 100021 Sun RPC Network Lock Manager
SUN-RPC-PROGRAM-RQUOTAD 100011 Sun RPC Remote Quota Daemon
SUN-RPC-PROGRAM-RSTATD 100001 Sun RPC Remote Status Daemon
SUN-RPC-PROGRAM-RUSERD 100002 Sun RPC Remote User Daemon
SUN-RPC-PROGRAM-SADMIND 100232 Sun RPC System Administration Daemon
SUN-RPC-PROGRAM-SPRAYD 100012 Sun RPC SPRAY Daemon
SUN-RPC-PROGRAM-STATUS 100024 Sun RPC STATUS
SUN-RPC-PROGRAM-WALLD 100008 Sun RPC WALL Daemon
SUN-RPC-PROGRAM-YPBIND 100007 SUN RPC Yellow Page Bind Service

Security and Tunnel Services

Table 14 lists each supported service and gives the default port(s) and a description
of each entry.

Table 14: Supported Protocol Services

Service Port Description

IKE UDP source 1-65535; UDP IKE is a protocol to obtain authenticated keying
destination 500 material for use with ISAKMP for.
4500 (used for NAT traversal) When configuring auto IKE, you can choose from
three predefined Phase 1 or Phase 2 proposals:
 Standard: AES and 3DES
 Basic: DES and two different types of
authentication algorithms
 Compatible: four commonly used authentication
and encryption algorithms
L2TP 1723 L2TP combines PPTP with Layer 2 Forwarding (L2F)
for remote access.
PPTP — Point-to-Point Tunneling Protocol allows
corporations to extend their own private network
through private tunnels over the public Internet.

Services  117
 Concepts & Examples ScreenOS Reference Guide

IP-Related Services
Table 15 lists the predefined IP-related services. Each entry includes the default port
and a description of the service.

Table 15: IP-Related Services

Service Port Description

Any — Any service
TCP-ANY 1-65535 Any protocol using the Transport Control Protocol
TCPMUX port 1
UDP-ANY 137 Any protocol using the User Datagram Protocol

Instant Messaging Services

Table 16 lists predefined Internet-messaging services. Each entry includes the name
of the service, the default or assigned port, and a description of the service.

Table 16: Internet-Messaging Services

Service Port Description

Gnutella 6346 Gnutella File Sharing Protocol is a public domain file sharing protocol
(default) that operates over a distributed network. You can assign any port, but
the default is 6346.
MSN 1863 Microsoft Network Messenger is a utility that allows you to send instant
messages and talk online.
NNTP 119 Network News Transport Protocol is a protocol used to post, distribute,
and retrieve USENET messages.
SMB 445 Server Message Block (SMB) Protocol over IP allows you to read and
write files to a server on a network.
YMSG 5010 Yahoo! Messenger is a utility that allows you to check when others are
online, send instant messages, and talk online.

Management Services
Table 17 lists the predefined management services. Each entry includes the name
of the service, the default or assigned port, and a description of the service.

Table 17: Management Services (page 1 of 2)

Service Port Description

NBNAME 137 NetBIOS Name Service displays all NetBIOS name packets sent on UDP port 137.
NDBDS 138 NetBIOS Datagram Service, published by IBM, provides connectionless (datagram) services to PCs
connected with a broadcast medium to locate resources, initiate sessions and terminate sessions.
It is unreliable and the packets are not sequenced.
NFS — Network File System uses UDP to allow network users to access shared files stored on computers
of different types. SUN RPC is a building block of NFS.
NS Global — NS-Global is the central management protocol for Juniper Networks Firewall/VPN devices.
NS Global PRO — NS Global-PRO is the scalable monitoring system for the Juniper Networks Firewall/VPN device
family.
NSM — NetScreen-Security Manager
NTP 123 Network Time Protocol provides a way for computers to synchronize to a time referent.

118  Services
 Chapter 5: Building Blocks for Policies

Table 17: Management Services (page 2 of 2)

Service Port Description

RLOGIN 513 RLOGIN starts a terminal session on a remote host.
RSH 514 RSH executes a shell command on a remote host.
SNMP 161 Simple Network Management Protocol is a set of protocols for managing complex networks.
SQL*Net V1 66 SQL*Net Version 1 is a database language that allows for the creation, access, modification, and
protection of data.
SQL*Net V2 66 SQL*Net Version 2 is a database language that allows for the creation, access, modification, and
protection of data.
MSSQL 1433 Microsoft SQL is a proprietary database server tool that allows for the creation, access,
(default modification, and protection of data.
instance)
SSH 22 Secure Shell is a program to log into another computer over a network through strong
authentication and secure communications on an unsecure channel.
SYSLOG 514 Syslog is a UNIX program that sends messages to the system logger.
Talk 517-518 Talk is a visual communication program that copies lines from your terminal to that of another
user.
Telnet 23 Telnet is a UNIX program that provides a standard method of interfacing terminal devices and
terminal-oriented processes to each other.
WinFrame — WinFrame is a technology that allows users on non-Windows machines to run Windows
applications.
X-Windows — X-Windows is the windowing and graphics system that Motif and OpenLook are based on.

Mail Services
Table 18 lists the predefined mail services. Each includes the name of the service,
the default or assigned port number, and a description of the service.

Table 18: Mail Services

Service Port Description

IMAP 143 Internet Message Access Protocol is a protocol used for retrieving messages.
Mail (SMTP) 25 Simple Mail Transfer Protocol is a protocol for sending messages between servers.
POP3 110 Post office protocol is a protocol used for retrieving email.

UNIX Services
Table 19 lists the predefined UNIX services. Each entry includes the name of the
service, the default or assigned port, and a description of the service.

Table 19: UNIX Services

Service Port Description

FINGER 79 Finger is a UNIX program that provides information about the users.
UUCP 117 Unix-to-Unix Copy Protocol (UUCP) is a UNIX utility that enables file transfers between two
computers over a direct serial or modem connection.

Services  119
 Concepts & Examples ScreenOS Reference Guide

Miscellaneous Services
Table 20 lists predefined miscellaneous services. Each entry includes the service
name, default or assigned port, and a description of the service.

Table 20: Miscellaneous Services

Service Port Description

CHARGEN 19 Character Generator Protocol is a UDP or TCP-based debugging and measurement tool.
DISCARD 9 Discard Protocol is an application layer protocol that describes a process for discarding TCP or
UDP data sent to port 9.
IDENT 113 Identification Protocol is a TCP/IP application layer protocol used for TCP client authentication.
LPR 515 listen; Line Printer Daemon Protocol is a TCP-based protocol used for printing services.
721-731 source
range (inclusive)
RADIUS 1812 Remote Authentication Dial-In User Service is a server program used for authentication and
accounting purposes.
SQLMON 1434 (SQL SQL monitor (Microsoft)
Monitor Port)
VNC 5800 Virtual Network Computing facilitates viewing and interacting with another computer or
mobile device connected to the Internet.
WHOIS 43 Network Directory Service Protocol is a way to look up domain names.
IPSEC-NAT — IPSEC-NAT allows Network Address Translation for ISAKMP and ESP packets.
SCCP 2000 Cisco Station Call Control Protocol uses the signaling connection control port (SCCP) to provide
high availability and flow control.
VOIP — Voice over IP Service Group provides voice services over the Internet and includes H.323 and
Session Initiation Protocol (SIP).

Custom Services
Instead of using predefined services, you can easily create custom services. You can
assign each custom service the following attributes:

 Name

 Transport protocol

 Source and destination port numbers for services using TCP or UDP

 Type and code values for services using ICMP

 Timeout value

120  Services
 Chapter 5: Building Blocks for Policies

If you create a custom service in a virtual system (vsys) that has the same name as
a previously defined custom service in the root system, the service in the vsys takes
the default timeout for the specified transport protocol (TCP, UDP, or ICMP). To
define a custom timeout for a service in a vsys that is different from the default
when a custom service with the same name in the root system has its own timeout,
create the custom service in the vsys and root system in the following order:

1. First, create the custom service with a custom timeout in the vsys.

2. Then create another custom service with the same name but a different
timeout in the root system.

The following examples describe how to add, modify, and remove a custom service.

NOTE: For information regarding ScreenOS naming conventions—which apply to the

names you create for custom services—see “Naming Conventions and Character
Types” on page xi.

Adding a Custom Service

To add a custom service to the service book, you need the following information:

 A name for the service: in this example “cust-telnet.”

 A range of source port numbers: 1 – 65535.

 A range of destination port numbers to receive the service request: for

example: 23000 – 23000.

 Whether the service uses TCP or UDP protocol, or some other protocol as
defined by the Internet specifications. In this example, the protocol is TCP.

WebUI
Policy > Policy Elements > Services > Custom > New: Enter the following,
then click OK:

Service Name: cust-telnet

Service Timeout: Custom (select), 30 (type)
Transport Protocol: TCP (select)
Source Port Low: 1
Source Port High: 65535
Destination Port Low: 23000
Destination Port High: 23000

CLI
set service cust-telnet protocol tcp src-port 1-65535 dst-port 23000-23000
set service cust-telnet timeout 30
save

NOTE: The timeout value is in minutes. If you do not set it, the timeout value of a custom
service is 180 minutes. If you do not want a service to time out, enter never.

Services  121
 Concepts & Examples ScreenOS Reference Guide

Modifying a Custom Service

In this example, you modify the custom service “cust-telnet” by changing the
destination port range to 23230-23230.

Use the set service service_name clear command to remove the definition of a
custom service without removing the service from the service book:

WebUI
Policy > Policy Elements > Services > Custom > Edit (for cust-telnet): Enter
the following, then click OK:

Destination Port Low: 23230

Destination Port High: 23230

CLI
set service cust-telnet clear
set service cust-telnet + tcp src-port 1-65535 dst-port 23230-23230
save

Removing a Custom Service

In this example, you remove the custom service “cust-telnet”.

WebUI
Policy > Policy Elements > Services > Custom: Click Remove in the Configure
column for “cust-telnet”.

CLI
unset service cust-telnet
save

Setting a Service Timeout

The timeout value you set for a service determines the session timeout. You can set
the timeout for a predefined or custom service; you can use the service default
timeout, specify a custom timeout, or use no timeout at all. Service timeout
behavior is the same in virtual systems (vsys) security domains as at the root level.

Service Timeout Configuration and Lookup

Service timeout values are stored in the service entry database and in the
corresponding vsys TCP and UDP port-based timeout tables. When you set a service
timeout value, the security device updates these tables with the new value. There
are also default timeout values in the services entry database, which are taken from
predefined services. You can set a timeout but you cannot alter the default values.

Services with multiple rule entries share the same timeout value. If multiple services
share the same protocol and destination port range, all services share the last
timeout value configured.

122  Services
 Chapter 5: Building Blocks for Policies

For single service entries, service timeout lookup proceeds as follows:

1. The specified timeout in the service entry database, if set.

2. The default timeout in the service entry database, if specified in the predefined
service.

3. The protocol-based default timeout table.

Table 21: Protocol-Based Default Timeout Table

Protocol Default Timeout (minutes)

TCP 30
UDP 1
ICMP 1
OSPF 1
Other 30

For service groups, including hidden groups created in multi-cell policy

configurations, and for the predefined service “ANY” (if timeout is not set), service
timeout lookup proceeds as follows:

1. The vsys TCP and UDP port-based timeout table, if a timeout is set.

2. The protocol-based default timeout table.

Contingencies
When setting timeouts, be aware of the following:

 If a service contains several service rule entries, all rule entries share the same
timeout. The timeout table is updated for each rule entry that matches the
protocol (for UDP and TCP—other protocols use the default). You need define
the service timeout only once. For example, if you create a service with two
rules, the following commands will set the timeout to 20 minutes for both rules:

set service test protocol tcp dst-port 1035-1035 timeout 20

set service test + udp src-port 1-65535 dst-port 1111-1111

 If multiple services are configured with the same protocol and overlapping
destination ports, the latest service timeout configured overrides the others in
the port-based table. For example:

set service ftp-1 protocol tcp src 0-65535 dst 2121-2121 timeout 10
set service telnet-1 protocol tcp src 0-65535 dst 2100-2148 timeout 20

With this configuration, the security device applies the 20-minute timeout for
destination port 2121 in a service group, because the destination port numbers
for telnet-1 (2100-2148) overlap those for ftp-1 (2121), and you defined telnet-1
after you defined ftp-1.

To modify a service timeout when multiple services use the same protocol and
an overlapping destination port range, you must unset the service and reset it
with the new timeout value. This is because, during reboot, services are loaded
according to creation time, not modification time.

Services  123
 Concepts & Examples ScreenOS Reference Guide

To avoid the unintended application of the wrong timeout to a service, do not

create services with overlapping destination port numbers.

 If you unset a service timeout, the default protocol-based timeout in the service
entry database is used, and the timeout values in both the service entry and
port-based timeout tables are updated with the default value.

If the modified service has overlapping destination ports with other services,
the default protocol-based timeout might not be the desired value. In that case,
reboot the security device, or set the service timeout again for the desired
timeout to take effect.

 When you modify a predefined service and reboot, the modified service might
not be the last one in the configuration. This is because predefined services are
loaded before custom services, and any change made to a custom service, even
if made earlier, will show as the later than the predefined service change when
you reboot.

For example, if you create the following service:

set service my_service protocol tcp dst-port 179-179 timeout 60

and later modify the timeout of the predefine service BGP as follows:

set service bgp timeout 75

the BGP service will use the 75-minute timeout value, because it is now written
to the service entry database. But the timeout for port 179, the port BGP uses, is
also changed to 75 in the TCP port-based timeout table. After you reboot, the
BGP service will continue to use the 75-minute timeout which, as a single
service, it gets from the service entry database. But the timeout in the TCP
port-based table for port 179 will now be 60. You can verify this by entering the
get service bgp command.

This has no effect on single services. But if you add BGP or my_service to a
service group, the 60-minute timeout value will be used for destination port
179. This is because service group timeout is taken from the port-based
timeout table, if one is set.

To ensure predictability when you modify a predefine service timeout,

therefore, you can create a similar service, for example:

set service my-bgp protocol tcp dst-port 179-179 timeout 75

Example
In the following example, you change the timeout threshold for the FTP
predefined service to 75 minutes:

WebUI
Policy > Policy Elements > Services > Predefined > Edit (FTP): Enter the
following, then click OK:

Service Timeout: Custom (select), 75 (type)

124  Services
 Chapter 5: Building Blocks for Policies

CLI
set service FTP timeout 75
save

Defining a Custom Internet Control Message Protocol Service

ScreenOS supports Internet Control Message Protocol (ICMP) as well as several
ICMP messages, as predefined or custom services. When configuring a custom
ICMP service, you must define a type and code. There are different message types
within ICMP. For example:

type 0 = Echo Request message

type 3 = Destination Unreachable message

NOTE: For more information about ICMP types and codes, refer to RFC 792, Internet
Control Message Protocol.

An ICMP message type can also have a message code. The code provides more
specific information about the message, as shown in Table 22.

Table 22: Message Descriptions

Message Type Message Code

5 = Redirect 0 = Redirect Datagram for the Network (or subnet)
1 = Redirect Datagram for the Host
2 = Redirect Datagram for the Type of Service and Network
3 = Redirect Datagram for the Type of Service and Host

11 = Time Exceeded Codes 0 =Time to Live exceeded in Transit

1 = Fragment Reassembly Time Exceeded

ScreenOS supports any type or code within the 0–255 range.

In this example, you define a custom service named “host-unreachable” using ICMP
as the transport protocol. The type is 3 (for Destination Unreachable) and the code
is 1 (for Host Unreachable). You set the timeout value at 2 minutes.

WebUI
Policy > Policy Elements > Services > Custom: Enter the following, then click
OK:

Service Name: host-unreachable

Service Timeout: Custom (select), 2 (type)
Transport Protocol: ICMP (select)
ICMP Type: 3
ICMP Code: 1

Services  125
 Concepts & Examples ScreenOS Reference Guide

CLI
set service host-unreachable protocol icmp type 5 code 0
set service host-unreachable timeout 2
save

Remote Shell Application Layer Gateway

Remote Shell Application Layer Gateway (RSH ALG) allows authenticated users to
run shell commands on remote hosts. Juniper Networks security devices support
the RSH service in Transparent (Layer 2), Route (Layer 3), and Network Address
Translation (NAT) modes, but the devices do not support port translation of RSH
traffic.

Sun Remote Procedure Call Application Layer Gateway

Sun remote procedure call (RPC)—also known as Open Network Computing (ONC)
RPC—provides a way for a program running on one host to call procedures in a
program running on another host. Because of the large number of RPC services the
transport address of an RPC service is dynamically negotiated based on the
service's program number and version number. Several binding protocols are
defined for mapping the RPC program number and version number to a transport
address.

Juniper Networks security devices support Sun RPC as a predefined service and
allow traffic based on a policy you configure. The Application Layer Gateway (ALG)
provides the functionality for security devices to handle the dynamic transport
address negotiation mechanism of Sun RPC and to ensure program number-based
firewall policy enforcement. You can define a firewall policy to permit all RPC
requests, or permit by a specific program number.

Although the ALG for IPv4 supports Route and NAT modes for incoming and
outgoing requests, the IPv6 ALG does not support NAT, NAT-Protocol Translation
(NAT-PT), or Transparent mode. In addition, a TCP segment in a Sun RPC stream
might be fragmented, so it might not include an intact Sun RPC protocol data unit
(PDU). Such fragmentation occurs in the RPC layer; so the security device does not
support parsing a fragmented packet coming through a Sun RPC ALG over IPv4 and
IPv6. In addition, the IPv6 ALG does not support multicast CALLIT packets, or the
NetScreen Redundancy Protocol (NSRP).

Typical RPC Call Scenario

When a client calls a remote service, it needs to find the transport address of the
service—in the case of TCP/UDP, this is a port number. A typical procedure for this
case is as follows:

1. The client sends the GETPORT message to the RPCBIND service on the remote
machine. The GETPORT message contains the program number, and version
and procedure number of the remote service it wants to call.

2. The RPCBIND service replies with a port number.

3. The client calls the remote service using the port number returned.

4. The remote service replies to the client.

126  Services
 Chapter 5: Building Blocks for Policies

A client also can use the CALLIT message to call the remote service directly, without
knowing the port number of the service. In this case, the procedure is as follows:

1. The client sends a CALLIT message to the RPCBIND service on the remote
machine. The CALLIT message contains the program number, and the version
and procedure number of the remote service it wants to call.

2. RPCBIND calls the service for the client.

3. RCPBIND replies to the client if the call has been successful. The reply contains
the call result and the services’s port number.

Customizing Sun RPC Services

Because Sun RPC services use dynamically negotiated ports, you cannot use regular
service objects based on fixed TCP/UDP ports to permit them in a security policy.
Instead, you must create Sun RPC service objects using program numbers. For
example, the Sun RPC network file system (NFS) uses two program numbers:
100003 and 100227. The corresponding TCP/UDP ports are dynamic. In order to
permit the program numbers, you create a sun-rpc-nfs service object that contains
these two numbers. The ALG maps the program numbers into dynamically
negotiated TCP/UDP ports and permits or denies the service based on a policy you
configure.

In this example, you create a service object called my-sunrpc-nfs to use the Sun RPC
NFS, which is identified by two program IDs: 100003 and 100227.

WebUI
Policy > Policy Elements > Services > Sun RPC Services > New: Enter the
following, then click Apply:

Service Name: my-sunrpc-nfs

Service Timeout: (select)
Program ID Low: 100003
Program ID High: 100003
Program ID Low: 100227
Program ID High: 100227

CLI
set service my-sunrpc-nfs protocol sun-rpc program 100003-100003
set service my-sunrpc-nfs + sun-rpc program 100227-100227
save

Customizing Microsoft Remote Procedure Call Application Layer Gateway

Microsoft remote procedure call (MS RPC) is the Microsoft implementation of the
Distributed Computing Environment (DCE) RPC. Like the Sun RPC (see “Sun
Remote Procedure Call Application Layer Gateway” on page 126), MS RPC provides
a way for a program running on one host to call procedures in a program running
on another host. Because of the large number of RPC services, the transport
address of an RPC service is dynamically negotiated based on the service program's
Universal Unique IDentifier (UUID). The Endpoint Mapper (EPM) binding protocol is
defined in ScreenOS to map the specific UUID to a transport address.

Services  127
 Concepts & Examples ScreenOS Reference Guide

Juniper Networks security devices support MS RPC as a predefined service; they

allow traffic based on a policy you configure. The ALG provides the functionality for
security devices to handle the dynamic transport address negotiation mechanism of
MS RPC, and to ensure UUID-based firewall policy enforcement. You can define a
firewall policy to permit all RPC requests, or to permit by specific UUID number.
While the ALG for IPv4 supports Route and NAT modes for incoming and outgoing
requests, the IPv6 ALG does not support NAT, NAT-PT, or Transparent mode.

In addition, because a TCP segment in an MS RPC stream might be fragmented, it

might not include an intact MS RPC PDU. Such fragmentation occurs in the RPC
layer; so the security device does not support parsing a fragmented packet coming
through an MS RPC ALG over IPv4 and IPv6.

The MS RPC ALG for IPv6 does not support the Endpoint Mapper protocol over UDP.
In addition, the IPv6 ALG does not support NSRP.

Because MS RPC services use dynamically negotiated ports, you cannot use regular
service objects based on fixed TCP/UDP ports to permit them in a security policy.
Instead, you must create MS RPC service objects using UUIDs. The MS Exchange
Info Store service, for example, uses the following four UUIDs:

 0e4a0156-dd5d-11d2-8c2f-00c04fb6bcde

 1453c42c-0fa6-11d2-a910-00c04f990f3b

 10f24e8e-0fa6-11d2-a910-00c04f990f3b

 1544f5e0-613c-11d1-93df-00c04fd7bd09

The corresponding TCP/UDP ports are dynamic. To permit them, you create an
ms-exchange-info-store service object that contains these four UUIDs. The ALG
maps the program numbers into dynamically negotiated TCP/UDP ports based on
these four UUIDs and permits or denies the service based on a policy you configure.

In this example, you create a service object called my-ex-info-store that includes
the UUIDs for the MS Exchange Info Store service.

WebUI
Policy > Policy Elements > Services > MS RPC: Enter the following, then click
Apply:

Service Name: my-ex-info-store

UUID: 0e4a0156-dd5d-11d2-8c2f-00c04fb6bcde
UUID: 1453c42c-0fa6-11d2-a910-00c04f990f3b
UUID: 10f24e8e-0fa6-11d2-a910-00c04f990f3b
UUID: 1544f5e0-613c-11d1-93df-00c04fd7bd09

CLI
set service my-ex-info-store protocol ms-rpc uuid
0e4a0156-dd5d-11d2-8c2f-00c04fb6bcde
set service my-ex-info-store + ms-rpc uuid
1453c42c-0fa6-11d2-a910-00c04f990f3b
set service my-ex-info-store + ms-rpc uuid
10f24e8e-0fa6-11d2-a910-00c04f990f3b

128  Services
 Chapter 5: Building Blocks for Policies

set service my-ex-info-store + ms-rpc uuid

1544f5e0-613c-11d1-93df-00c04fd7bd09
save

Real-Time Streaming Protocol Application Layer Gateway

Real-Time Streaming Protocol (RTSP) is an application layer protocol used to control
delivery of one or more synchronized streams of multimedia, such as audio and
video. Although RTSP is capable of delivering the data streams itself—interleaving
continuous media streams with the control stream—it is more typically used as a
kind of network remote control for multimedia servers. The protocol was designed
as a means for selecting delivery channels, such as User Datagram Protocol (UDP),
multicast UDP, and TCP, and for selecting a delivery mechanism based on
Real-Time Protocol (RTP). RTSP may also use the Session Description Protocol (SDP)
as a means of providing information to the client for aggregate control of a
presentation consisting of streams from one or more servers, and non-aggregate
control of a presentation consisting of multiple streams from a single server. The
data sources can be live feeds or stored clips.

Juniper Networks security devices support RTSP as a service and allow or deny
RTSP traffic based on the policy you configure. The RTSP Application Layer Gateway
(ALG) is needed because RTSP uses dynamically assigned port numbers that are
conveyed in the packet payload when endpoints establish a control connection. The
ALG keeps track of the dynamically assigned port numbers and opens pinholes on
the security device accordingly. In Network Address Translation (NAT) mode, the
ALG translates IP addresses and ports as necessary. Security devices support RTSP
in Route and Transparent modes, and in both interface-based and policy-based NAT
mode.

Figure 49 on page 130 illustrates a typical RTSP session. The client initiates the
session (when the user clicks the Play button in a RealPlayer application, for
example) and establishes a TCP connection to the RTSP server on port 554, then
sends the OPTIONS message (messages are also called methods), to find out what
audio and video features the server supports. The server responds to the OPTIONS
message by specifying the name and version of the server, and a session identifier,
for example, 24256-1. (For more information about methods, see “SIP Request
Methods” on page 6-16, and refer to RFC 2326, Section 11.)

The client then sends the DESCRIBE message with the URL of the actual media file
the client wants. The server responds to the DESCRIBE message with a description
of the media in SDP format. The client then sends the SETUP message, which
specifies the transport mechanisms acceptable to the client for streamed media, for
example RTP/RTCP or RDT, and the ports on which it receives the media. When
using NAT, the RTSP ALG keeps track of these ports and translates them as
necessary. The server responds to the SETUP message and selects one of the
transport protocols, and, in this way, both client and server agree on a mechanism
for media transport. The client then sends the PLAY message, and the server begins
streaming the media to the client.

Services  129
 Concepts & Examples ScreenOS Reference Guide

Figure 49: Typical RTSP Session

RealPlayer Client Security Device Real Media Server

Port 3408 Port 554

Dual-Stack Environment
You enable the RTSP ALG by using the set alg rtsp enable command. When you use
this command to enable ALG in a dual-stack environment, the IPv4 and IPv6 RTSP
ALGs are enabled at the same time. This feature has the following limitations:

 The ALG does not support NAT for IPv6.

 The ALG does not support Transparent mode for IPv6.

 The ALG does not support NetScreen Redundancy Protocol (NSRP) for IPv6.

RTSP Request Methods

Table 23 on page 131 lists methods that can be performed on a resource (media
object), the direction or directions in which information flows, and whether the
method is required, recommended, or optional. Presentation refers to information
such as network addresses, encoding, and content about a set of one or more
streams presented to the client as a complete media feed. A Stream is a single
media instance, for example audio or video, as well as all packets created by a
source within the session.

130  Services
 Chapter 5: Building Blocks for Policies

Table 23: RTSP Request Methods (page 1 of 2)

Method Direction Object Requirement Description

OPTIONS Client to Presentation, Client to Server Client queries the server about what audio or video
Server Stream required features it supports, as well as such things as the name
and version of the server, and session ID.
Server to Presentation, Server to Client
Client Stream optional
DESCRIBE Client to Presentation, Recommended For exchange of media initialization information, such
Server Stream as clock rates, color tables, and any
transport-independent information the client needs for
playback of the media stream. Typically the client sends
the URL of the of file it is requesting, and the server
responds with a description of the media in SDP format.
ANNOUNCE Client to Presentation, Optional Client uses this method to post a description of the
Server Stream presentation or media object identified by the request
URL. The server uses this method to update the session
Server to Presentation,
description in real-time.
Client Stream
SETUP Client to Stream Required Client specifies acceptable transport mechanisms to be
Server used, such as the ports on which it will receive the
media stream, and the transport protocol.
GET_PARAMETER Client to Presentation, Optional Retrieves the value of a presentation or stream
Server Stream parameter specified in the URL. This method can be
used with no entity body to test client or server
Server to
aliveness. Ping can also be used to test for aliveness.
Client
SET_PARAMETER Client to Presentation, Optional Client uses this method to set the value of a parameter
Server Stream for a presentation or stream specified by the URI. Due
to firewall considerations, this method cannot be used
Server to
to set transport parameters.
Client
PLAY Client to Presentation, Required Instructs the server to begin sending data using the
Server Stream mechanism specified in SETUP. The Client does not
issue PLAY requests until all SETUP requests are
successful. The server queues PLAY requests in order,
and delays executing any new PLAY request until an
active PLAY request is completed. PLAY requests may or
may not contain a specified range. The range may
contain a time parameter—specified in Coordinated
Universal Time (UTC)—for start of playback, which can
also be used to synchronize streams from different
sources.
PAUSE Client to Presentation, Recommended Temporarily halts delivery of an active presentation. If
Server Stream the request URL specifies a particular stream, for
example audio, this is equivalent to muting.
Synchronization of tracks is maintained when playback
or recording is resumed, although servers may close the
session if PAUSE is for the duration specified in the
timeout parameter in SETUP. A PAUSE request discards
all queued PLAY requests.

Services  131
 Concepts & Examples ScreenOS Reference Guide

Table 23: RTSP Request Methods (page 2 of 2)

Method Direction Object Requirement Description

RECORD Client to Presentation, Optional Initiates recording a range of media defined in the
Server Stream presentation description. A UTC timestamp indicates
start and end times, otherwise the server uses the start
and end times in the presentation description.
REDIRECT Server to Presentation, Optional Informs the client it must connect to a different server,
Client Stream and contains location information and possibly a range
parameter for that new URL. To continue to receive
media for this URL, the client must issue a TEARDOWN
request for the current session and a SETUP for the new
session.
TEARDOWN Client to Presentation, Required Stops stream delivery for the given URI and frees the
Server Stream resources associated with it. Unless all transport
parameters are defined by the session description, a
SETUP request must be issued before the session can be
played again.

RTSP Status Codes

RTSP uses status codes to provide information about client and server requests.
Status codes include a machine-readable three digit result code, and a
human-readable reason phrase. It is at the client’s discretion whether to display the
reason phrase. Status codes are described in Table 24.

Table 24: RSTP Status Codes

Code Number Description

Informational 100 to 199 Request has been received and is being processed
Success 200 to 299 Action has been received successfully, understood, and
accepted
Redirection 300 to 399 Further action is necessary to complete the request
Client Error 400 to 499 Request contains bad syntax and cannot be fulfilled
Server Error 500 to 599 Server failed to fulfill an apparently valid request

Table 25 lists all status codes defined for RTSP 1.0, and recommended reason
phrases. Reason phrases can be revised or redefined without affecting the operation
of the protocol.

Table 25: RTSP 1.0 Status Codes (page 1 of 2)

Status Code Reason Phrase Status Code Reason Phrase

100 Continue 414 Request-URI Too Large
200 OK 415 Unsupported Media Type
201 Created 451 Unsupported Media Type
250 Low on Storage Space 452 Conference Not Found
300 Multiple Choices 453 Not Enough Bandwidth
301 Moved Permanently 454 Session Not Found
303 See Other 455 Method Not Valid in This State
304 Not Modified 456 Header Field Not Valid for Resource

132  Services
 Chapter 5: Building Blocks for Policies

Table 25: RTSP 1.0 Status Codes (page 2 of 2)

Status Code Reason Phrase Status Code Reason Phrase

305 Use Proxy 457 Invalid Range
400 Bad Request 458 Parameter is Read-Only
401 Unauthorized 459 Aggregate operation not allowed
402 Payment Required 460 Only aggregate operation allowed
403 Forbidden 461 Unsupported transport
404 Not Found 462 Destination unreachable
405 Method Not Allowed 500 Internal Server Error
406 Not Acceptable 501 Not Implemented
407 Proxy Authentication 502 Bad Gateway
Required
408 Request Time-out 503 Service Unavailable
410 Gone 504 Gateway Time-out
411 Length Required 505 RTSP Version not supported
412 Precondition Failed 551 Option not supported
413 Request Entity Too Large

NOTE: For complete definitions of status codes, refer to RFC 2326, Real Time Streaming
Protocol (RTSP).

Configuring a Media Server in a Private Domain

In this example, the media server is in the Trust zone and the client is in the Untrust
zone. You put a MIP on the ethernet0/3 interface to the media server in the Trust
zone, then create a policy to allow RTSP traffic to flow from the client in the Untrust
zone to the media server in the Trust zone.

Figure 50: RTSP Private Domain

ethernet0/1 ethernet0/3
10.1.1.1 1.1.1.1

Trust Zone Untrust Zone

Security Device
LAN LAN

Media Server Virtual Device

MIP on ethernet0/3 Client1.1.1.5
10.1.1.3
1.1.1.3 -> 10.1.1.3

WebUI
1. Interfaces
Network > Interfaces > Edit (for ethernet0/1): Enter the following, then click
Apply:

Services  133
 Concepts & Examples ScreenOS Reference Guide

Zone Name: Trust

Static IP: (select this option when present)
IP Address/Netmask: 10.1.1.1/24
Manage IP: 10.1.1.2

Network > Interfaces > Edit (for ethernet0/3): Enter the following, then click
Apply:

Zone Name: Untrust

Static IP: (select this option when present)
IP Address/Netmask: 1.1.1.1/24
Manage IP: 1.1.1.2
2. Addresses
Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: media_server

IP Address/Domain Name:
IP/Netmask: (select), 10.1.1.3/24
Zone: Trust

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: client

IP Address/Domain Name:
IP/Netmask: (select), 1.1.1.5/24
Zone: Untrust
3. MIP
Network > Interfaces > Edit (for ethernet0/3) > MIP > New: Enter the
following, then click OK:

Mapped IP: 1.1.1.3

Host IP Address: 10.1.1.5
4. Policy
Policy > Policies > (From: Untrust, To: Trust) > New: Enter the following, then
click OK:

Source Address:
Address Book Entry: (select), client
Destination Address:
Address Book Entry: (select), MIP(1.1.1.3)
Service: RTSP
Action: Permit

CLI
1. Interfaces
set interface ethernet0/1 trust
set interface ethernet0/1 ip 10.1.1.1
set interface ethernet0/3 untrust
set interface ethernet0/3 ip 1.1.1.1
2. Addresses
set address trust media_server 10.1.1.3/24

134  Services
 Chapter 5: Building Blocks for Policies

set address untrust client 1.1.1.5

3. MIP
set interface ethernet0/3 mip (1.1.1.3) host 10.1.1.3
4. Policy
set policy from untrust to trust client mip(1.1.1.3) rtsp permit
save

Configuring a Media Server in a Public Domain

In this example, the media server is in the Untrust zone and the client is in the Trust
zone. You put a DIP pool on the ethernet0/3 interface to do NAT when the media
server to responds to the client from the Untrust zone, then create a policy to allow
RTSP traffic to flow from the Trust to the Untrust zone.

Figure 51: RTSP Public Domain

ethernet0/1 ethernet0/3
Trust Zone 10.1.1.1 1.1.1.1 Untrust Zone

Security Device
LAN LAN

DIP Pool
Client on ethernet0/3 Media Server
10.1.1.3 1.1.1.5 to 1.1.1.50 1.1.1.3

WebUI
1. Interface
Network > Interfaces > Edit (for ethernet0/1): Enter the following, then click
Apply:

Zone Name: Trust

Static IP: (select this option when present)
IP Address/Netmask: 10.1.1.1/24
Manage IP: 10.1.1.2

Network > Interfaces > Edit (for ethernet0/3): Enter the following, then click
Apply:

Zone Name: Untrust

Static IP: (select this option when present)
IP Address/Netmask: 1.1.1.1/24
Manage IP: 1.1.1.2
2. Addresses
Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: client

IP Address/Domain Name:
IP/Netmask: (select), 10.1.1.3/24
Zone: Trust

Services  135
 Concepts & Examples ScreenOS Reference Guide

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: media_server

IP Address/Domain Name:
IP/Netmask: (select), 1.1.1.3/24
Zone: Untrust
3. DIP Pool
Network > Interfaces > Edit (for ethernet0/3) > DIP > New: Enter the
following, then click OK:

ID: 5
IP Address Range: (select) 1.1.1.5 ~ 1.1.1.50
Port Translation: (select)
4. Policy
Policy > Policies > (From: Trust, To: Untrust) > New: Enter the following, then
click OK:

Source Address:
Address Book Entry (select): client
Destination Address:
Address Book Entry (select): media_server
Service: RTSP
Action: Permit

> Advanced: Enter the following, then click OK:

NAT:
Source Translation: (select)
(DIP on): 5 (1.1.1.5-1.1.1.50)/port-xlate

CLI
1. Interface
set interface ethernet0/1 zone trust
set interface ethernet0/1 ip 10.1.1.1
set interface ethernet0/3 zone untrust
set interface ethernet0/3 ip 1.1.1.1/24
2. Addresses
set address trust client ip 10.1.1.3/24
set address untrust media_server ip 1.1.1.3/24
3. DIP Pool
set interface ethernet0/3 dip 5 1.1.5 1.1.1.50
4. Policy
set policy from trust to untrust client media_server rtsp nat dip 5 permit
save

136  Services
 Chapter 5: Building Blocks for Policies

Stream Control Transmission Protocol Application Layer Gateway

Stream Control Transmission Protocol (SCTP) is a Transport Layer protocol. It
provides a reliable transport service that supports data transfer across the network,
in sequence and without errors. In transporting signaling messages to and from
Signaling System 7 (SS7) gateways, SCTP provides advantages over the following
network-protocol configurations:

 Transport Control Protocol (TCP) for SS7 for 3G mobile networks

 Session Initiation Protocol (SIP) for Voice-over-Internet Protocol (VoIP) networks

SCTP is effective when used as the transport protocol for applications that require
monitoring and session-loss detection. For such applications, the SCTP path/session
failure-detection mechanisms, especially the heartbeat, actively monitor the
connectivity of the session. SCTP differs from TCP in having multi-homing
capabilities at either or both ends and several streams within a connection, typically
referred to an association. A TCP stream represents a sequence of bytes; an SCTP
stream represents a sequence of messages.

You can configure the security device to perform stateful inspection on all SCTP
traffic without performing Deep Inspection (DI). If you enable stateful inspection of
SCTP traffic, the SCTP ALG drops any anomalous SCTP packets.

Point-to-Point Tunneling Protocol Application Layer Gateway

Juniper Networks security devices support port address translation (PAT) for
Point-to-Point Tunneling Protocol (PPTP) traffic. PPTP provides IP security at the
Network Layer. PPTP consists of a control connection and a data tunnel—the
control connection runs over TCP and helps in establishing and disconnecting calls,
and the data tunnel handles encapsulated Point-to-Point Protocol (PPP) packets
carried over IP.

PPTP uses TCP port 1723 for its control connection and Generic Routing
Encapsulation (GRE - IP protocol 47) for tunneling the encapsulated PPP data. The
GRE traffic carries no port number, making it difficult for the security device to
distinguish between two clients with the same public IP. PPTP uses the source IP
address and the Call ID field in the GRE header to identify a tunnel. When multiple
clients sharing the same public IP address establish tunnels with the same PPTP
server, they may get the same Call ID. You can translate the Call ID value in both the
control message and the data traffic, but only when the client is in a private
network and the server is in a public network.

PPTP clients can either directly connect to the Internet or dial into a network access
server (ISP) to reach the Internet. The security device that protects the PPTP clients
can translate the clients’ private IP addresses to a pool of public IP addresses using
Network Address Translation-Port Translation (NAT-PT). Because the GRE traffic
carries no port number for address translation, the PPTP ALG treats the Call ID field
as a port number as a way of distinguishing multiple clients.

After the PPTP client establishes a TCP connection with the PPTP server, the client
sends a Start Control Connection Request message to establish a control connection
with the server. The server replies with a Start Control Connection Reply message.
The client then sends a request to establish a call and sends an Outgoing Call
Request message. The security device assigns a Call ID (bytes 12-13 of the control

Services  137
 Concepts & Examples ScreenOS Reference Guide

message) that is unique to the tunnel. The server replies with an Outgoing Call
Reply message, which carries its own Call ID (bytes 12-13) and the client’s Call ID
(bytes 14-15). The PPTP ALG parses the control connection messages for the Call ID
to identify the call to which a particular PPP packet belongs. The ALG identifies an
Outgoing Call Request message using the Control Message Type field (bytes 8-9)
with the value 7. When the ALG receives this message, it parses the control message
for the Call ID field (bytes 12-13). The security device translates the Call ID so that it
is unique across multiple calls from the same translated client IP. After receiving
Outgoing Call Response message, the ALG holds this message and opens a pinhole
in order to accept GRE traffic that the PPTP server sends. An Outgoing Call Request
message contains the following elements:

 Protocol used for the outgoing call request message (GRE)

 Source IP address (PPTP server IP)

 Destination IP address (translated client IP)

 Destination port number (translated client Call ID)

The ALG identifies an Outgoing Call Reply message using the Control Message Type
field (bytes 8-9) with the value 8. The ALG parses these control messages for the Call
ID field (bytes 12-13) and the client’s Call ID (bytes 14-15). The ALG then uses the
client’s Call ID value to find the mapping created for the other direction, and then
opens a pinhole to accept the GRE traffic that the client sends. An Outgoing Call
Reply message contains the following elements:

 Protocol used for the outgoing call reply message (GRE)

 Source IP address (PPTP client IP)

 Destination IP address (PPTP server IP)

 Destination port number (PPTP server Call ID)

Each pinhole that the ALG opens creates a session for data traffic arriving in that
direction. The ALG opens two data sessions for each tunnel:

 Traffic from the PPTP client to the server, using the server’s Call ID as the
destination port

 Traffic from the PPTP server to the client, using the client’s translated Call ID as
the destination port

The default timeout value of the control connection is 30 minutes. The ALG closes
the pinhole when the data session exceeds the timeout value or is idle for long time.
When you close the control session through the ALG, the security device closes all
control connections and data sessions.

138  Services
 Chapter 5: Building Blocks for Policies

NOTE: Because the PPTP ALG requires Port Address Translation (PAT), you cannot create a
hardware session for the data traffic that uses GRE, because the hardware does
not support encapsulation using GRE. On such Juniper Networks security devices,
ScreenOS must handle both the control traffic and the data traffic in software
path.

Call ID translation is not required when the client is on the public network and the
server is on the private side. In this case, no PAT is involved and the Call ID value
between any client–server pair is unique.

Configuring the PPTP ALG

You can enable the PPTP ALG using the WebUI or the CLI.

WebUI
Security > ALG > Basic: Select the PPTP check box, then click OK.

CLI
set alg pptp enable

Service Groups
A service group is a set of services that you have gathered together under one
name. After you create a group containing several services, you can then apply
services at the group level to policies, thus simplifying administration.

The ScreenOS service group option has the following features:

 Each service book entry can be referenced by one or more service groups.

 Each service group can contain predefined and user-defined service book
entries.

Service groups are subject to the following limitations:

 Service groups cannot have the same names as services; therefore, if you have
a service named “FTP,” you cannot have a service group named “FTP.”

 If a service group is referenced in a policy, you can edit the group but you
cannot remove it until you have first removed the reference to it in the policy.

 If a custom service book entry is deleted from the service book, the entry is
also removed from all the groups in which it was referenced.

 One service group cannot contain another service group as a member.

 The all-inclusive service term “ANY” cannot be added to groups.

 A service can be part of only one group at a time.

Creating a Service Group

In this example, you create a service group named grp1 that includes IKE, FTP, and
LDAP services.

Services  139
 Concepts & Examples ScreenOS Reference Guide

WebUI
Policy > Policy Elements > Services > Groups > New: Enter the following
group name, move the following services, then click OK:

Group Name: grp1

Select IKE and use the << button to move the service from the Available
Members column to the Group Members column.
Select FTP and use the << button to move the service from the Available
Members column to the Group Members column.
Select LDAP and use the << button to move the service from the Available
Members column to the Group Members column.

CLI
set group service grp1
set group service grp1 add ike
set group service grp1 add ftp
set group service grp1 add ldap
save

NOTE: If you try to add a service to a service group that does not exist, the security device
creates the group. Also, ensure that groups referencing other groups do not
include themselves in the reference list.

Modifying a Service Group

In this example, you change the members in the service group named grp1 that you
created in “Creating a Service Group” on page 139. You remove IKE, FTP, and LDAP
services, and add HTTP, FINGER, and IMAP.

WebUI
Policy > Policy Elements > Services > Groups > Edit (for grp1): Move the
following services, then click OK:
Select IKE and use the >> button to move the service from the Group
Members column to the Available Members column.
Select FTP and use the >> button to move the service from the Group
Members column to the Available Members column.
Select LDAP and use the >> button to move the service from the Group
Members column to the Available Members column.
Select HTTP and use the << button to move the service from the Available
Members column to the Group Members column.
Select Finger and use the << button to move the service from the
Available Members column to the Group Members column.
Select IMAP and use the << button to move the service from the Available
Members column to the Group Members column.

140  Services
 Chapter 5: Building Blocks for Policies

CLI
unset group service grp1 clear
set group service grp1 add http
set group service grp1 add finger
set group service grp1 add imap
save

Removing a Service Group

In this example, you delete the service group named “grp1”.

WebUI
Policy > Policy Elements > Services > Groups: Click Remove (for grp1).

CLI
unset group service grp1
save

NOTE: The security device does not automatically delete a group from which you have
removed all members.

Dynamic IP Pools
A dynamic IP (DIP) pool is a range of IP addresses from which the security device
can dynamically or deterministically take addresses to use when performing
Network Address Translation on the source IP address (NAT-src) in IP packet
headers. (For information about deterministic source address translation, see
“NAT-Src from a DIP Pool with Address Shifting” on page 8-20.) If the range of
addresses in a DIP pool is in the same subnet as the interface IP address, the pool
must exclude the interface IP address, router IP addresses, and any mapped IP
(MIP) or virtual IP (VIP) addresses that might also be in that subnet. If the range of
addresses is in the subnet of an extended interface, the pool must exclude the
extended interface IP address.

There are three kinds of interfaces that you can link to dynamic IP (DIP) pools:
physical interfaces and subinterfaces for network and VPN traffic, and tunnel
interfaces for VPN tunnels only.

Dynamic IP Pools  141

 Concepts & Examples ScreenOS Reference Guide

Figure 52: DIP Interfaces

To DMZ Zone

To Untrust Zone

VPN Tunnels

To Trust Zone

Firewall

10.10.1.2– 210.10.1.2– 220.10.1.2– 10.20.1.2– 10.30.1.2–

10.10.1.20 210.10.1.20 220.10.1.20 10.20.1.20 10.30.1.20

DIP Pools

ethernet0/1 ethernet0/2 ethernet0/3 Tunnel Tunnel

Interfaces

10.10.1.1/24 210.10.1.1/24 220.10.1.1/24 10.20.1.1/24 10.30.1.1/24

The physical interfaces The tunnel interfaces

lead to networks or VPN lead only to VPN
tunnels. tunnels.

Port Address Translation

Using Port Address Translation (PAT), multiple hosts can share the same IP address,
the security device maintaining a list of assigned port numbers to distinguish which
session belongs to which host. With PAT enabled, up to ~64,500 hosts can share a
single IP address.

Some applications, such as NetBIOS Extended User Interface (NetBEUI) and

Windows Internet Naming Service (WINS), require specific port numbers and
cannot function properly if PAT is applied to them. For such applications, you can
specify not to perform PAT (that is, to use a fixed port) when applying DIP. For
fixed-port DIP, the security device hashes the original host IP address and saves it in
its host hash table, thus allowing the security device to associate the right session
with each host.

142  Dynamic IP Pools

 Chapter 5: Building Blocks for Policies

Creating a DIP Pool with PAT

In this example, you want to create a VPN tunnel for users at the local site to reach
an FTP server at a remote site. However, the internal networks at both sites use the
same private address space of 10.1.1.0/24. To solve the problem of overlapping
addresses, you create a tunnel interface in the Untrust zone on the local security
device, assign it IP address 10.10.1.1/24, and associate it with a DIP pool with a
range of one address (10.10.1.2–10.10.1.2) and Port Address Translation enabled.

The admin at the remote site, must also create a tunnel interface with an IP address
in a neutral address space, such as 10.20.2.1/24, and set up a mapped IP (MIP)
address to its FTP server, such as 10.20.2.5 to host 10.1.1.5.

NOTE: This example includes only the configuration of the tunnel interface and its
accompanying DIP pool. For a complete example showing all the configuration
steps necessary for this scenario, see “VPN Sites with Overlapping Addresses” on
page 5-150.

WebUI
Network > Interfaces > New Tunnel IF: Enter the following, then click OK:

Tunnel Interface Name: tunnel.1

Zone (VR): Untrust (trust-vr)
Fixed IP: (select)
IP Address / Netmask: 10.10.1.1/24

Network > Interfaces > Edit (for tunnel.1) > DIP > New: Enter the following,
then click OK:

ID: 5
IP Address Range: 10.10.1.2 ~ 10.10.1.2
Port Translation: (select)
In the same subnet as the interface IP or its secondary IPs: (select)

NOTE: You can use the ID number displayed, which is the next available number
sequentially, or enter a different number.

CLI
set interface tunnel.1 zone untrust-tun
set interface tunnel.1 ip 10.10.1.1/24
set interface tunnel.1 dip 5 10.10.1.2 10.10.1.2
save

Dynamic IP Pools  143

 Concepts & Examples ScreenOS Reference Guide

NOTE: Because PAT is enabled by default, there is no argument for enabling it. To create
the same DIP pool as defined above but without PAT (that is, with fixed port
numbers), do the following:

(WebUI) Network > Interfaces > Edit (for tunnel.1) > DIP > New: Clear the Port
Translation check box, then click OK.

(CLI) set interface tunnel.1 dip 5 10.10.1.2 10.10.1.2 fix-port

You can add a maximum of three IP address ranges for a fixed-port DIP pool. The
IP address ranges should not overlap. When the first address range is exhausted,
the security device attempts to process the NAT request using the second address
range. When the second address range is exhausted, the security device attempts
to process the NAT request using the third address range. Note that the total range
of all IP addresses defined in the fixed-port DIP pool must not exceed the
permitted address scope of the subnet.

Modifying a DIP Pool

In this example, you change the range of addresses in an existing DIP pool (ID 5)
from 10.20.1.2 – 10.20.1.2 to 10.20.1.2 – 10.20.1.10. This DIP pool is associated
with tunnel.1. Note that to change the DIP pool range through the CLI, you must
first remove (or unset) the existing DIP pool and then create a new pool.

NOTE: There are no policies using this particular DIP pool. If a policy uses a DIP pool, you
must first delete the policy or modify it to not use the DIP pool before you can
modify the DIP pool.

WebUI
Network > Interfaces > Edit (for tunnel.1) > DIP > Edit (for ID 5): Enter the
following, then click OK:

IP Address Range: 10.20.1.2 ~ 10.20.1.10

CLI
unset interface tunnel.1 dip 5
set interface tunnel.1 dip 5 10.20.1.2 10.20.1.10
save

Sticky DIP Addresses

When a host initiates several sessions that match a policy requiring Network
Address Translation (NAT) and is assigned an address from a DIP pool with port
translation enabled, the security device assigns a different source IP address for
each session. Such random address assignment can be problematic for services
that create multiple sessions that require the same source IP address for each
session.

NOTE: For DIP pools that do not perform port translation, the security device assigns one
IP address for all concurrent sessions from the same host.

144  Dynamic IP Pools

 Chapter 5: Building Blocks for Policies

For example, it is important to have the same IP address for multiple sessions when
using the AOL Instant Messaging (AIM) client. You create one session when you log
in, and another for each chat. For the AIM server to verify that a new chat belongs
to an authenticated user, it must match the source IP address of the login session
with that of the chat session. If they are different—possibly because they were
randomly assigned from a DIP pool during the NAT process—the AIM server rejects
the chat session.

To ensure that the security device assigns the same IP address from a DIP pool to a
host for multiple concurrent sessions, you can enable the “sticky” DIP address
feature by entering the CLI command set dip sticky.

Using DIP in a Different Subnet

If circumstances require that the source IP address in outbound firewall traffic be
translated to an address in a different subnet from that of the egress interface, you
can use the extended interface option. This option allows you to graft a second IP
address and an accompanying DIP pool onto an interface that is in a different
subnet. You can then enable NAT for individual policies and specify the DIP pool
built on the extended interface for the translation.

In this example, two branch offices have leased lines to a central office. The central
office requires them to use only the authorized IP addresses it has assigned them.
However, the offices receive different IP addresses from their ISPs for Internet
traffic. For communication with the central office, you use the extended interface
option to configure the security device in each branch office to translate the source
IP address in packets it sends to the central office to the authorized address. The
authorized and assigned IP addresses for branch offices A and B are as follows:

Table 26: Authorized Office IP Addresses

Assigned IP Address (from ISP) Authorized IP Address (from Central Office)

Used for Untrust Zone Physical Used for Untrust Zone Extended Interface
Interface DIP
Office A 195.1.1.1/24 211.10.1.1/24
Office B 201.1.1.1/24 211.20.1.1/24

The security devices at both sites have a Trust zone and an Untrust zone. All
security zones are in the trust-vr routing domain. You bind ethernet0/1 to the Trust
zone and assign it IP address 10.1.1.1/24. You bind ethernet0/3 to the Untrust zone
and give it the IP address assigned by the ISPs: 195.1.1.1/24 for Office A and
201.1.1.1/24 for Office B. You then create an extended interface with a DIP pool
containing the authorized IP address on ethernet0/3:

 Office A: extended interface IP 211.10.1.10/24; DIP pool 211.10.1.1 –

211.10.1.1; PAT enabled

 Office B: extended interface IP 211.20.1.10/24; DIP pool 211.20.1.1 –

211.20.1.1; PAT enabled

You set the Trust zone interface in NAT mode. It uses the Untrust zone interface IP
address as its source address in all outbound traffic except for traffic sent to the
central office. You configure a policy to the central office that translates the source
address to an address in the DIP pool in the extended interface. (The DIP pool ID

Dynamic IP Pools  145

 Concepts & Examples ScreenOS Reference Guide

number is 5. It contains one IP address, which, with Port Address Translation (PAT),
can handle sessions for ~64,500 hosts.) The MIP address that the central office
uses for inbound traffic is 200.1.1.1, which you enter as “HQ” in the Untrust zone
address book on each security device.

Figure 53: DIP Under Another Subnet

Central Office
(HQ)
Note: Leased lines connect branch offices A and B
directly to the central office.
200.1.1.1 Untrust Zone
Untrust Zone
ISP
Leased
Leased Line
Line
Internet
Untrust Zone, ethernet0/3 Untrust Zone, ethernet0/3
ISP assigns 195.1.1.1/24 ISP assigns 201.1.1.1/24
(physical interface) ISP ISP (physical interface)
HQ authorizes 211.10.1.1 /24 HQ authorizes 211.20.1.1/24
(extended interface) (extended interface)
Default Gateway 195.1.1.254 Default Gateway 201.1.1.254

Trust Zone, ethernet0/1 Office A Office B Trust Zone, ethernet0/1

10.1.1.1/24 10.1.1.1/24
Trust Zone Untrust Zone

NOTE: Each ISP must set up a route for traffic destined to a site at the end of a leased line
to use that leased line. The ISPs route any other traffic they receive from a local
security device to the Internet.

WebUI (Branch Office A)

1. Interfaces
Network > Interfaces > Edit (for ethernet0/1): Enter the following, then click
OK:

Zone Name: Trust

Static IP: (select this option when present)
IP Address/Netmask: 10.1.1.1/24
Interface Mode: NAT

Network > Interfaces > Edit (for ethernet0/3): Enter the following, then click
OK:

Zone Name: Untrust

Static IP: (select this option when present)
IP Address/Netmask: 195.1.1.1/24
Interface Mode: Route

Network > Interfaces > Edit (for ethernet0/3) > DIP > New: Enter the
following, then click OK:

ID: 5
IP Address Range: 211.10.1.1 ~ 211.10.1.1
Port Translation: (select)
Extended IP/Netmask: 211.10.1.10/255.255.255.0

146  Dynamic IP Pools

 Chapter 5: Building Blocks for Policies

2. Address
Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: HQ
IP Address/Domain Name:
IP/Netmask: (select), 200.1.1.1/32
Zone: Untrust
3. Route
Network > Routing > Destination > trust-vr New: Enter the following, then
click OK:

Network Address/Netmask: 0.0.0.0/0

Gateway: (select)
Interface: ethernet0/3
Gateway IP address: 195.1.1.254
4. Policies
Policy > Policies > (From: Trust, To: Untrust) New: Enter the following, then
click OK:

Source Address:
Address Book Entry: (select), Any
Destination Address:
Address Book Entry: (select), Any
Service: ANY
Action: Permit

Policy > Policies > (From: Trust, To: Untrust) New: Enter the following, then
click OK:

Source Address:
Address Book Entry: (select), Any
Destination Address:
Address Book Entry: (select), HQ
Service: ANY
Action: Permit
Position at Top: (select)

> Advanced: Enter the following, then click Return to set the advanced
options and return to the basic configuration page:

NAT:
Source Translation: (select)
(DIP on): 5 (211.10.1.1-211.10.1.1)/X-late

Dynamic IP Pools  147

 Concepts & Examples ScreenOS Reference Guide

WebUI (Branch Office B)

1. Interfaces
Network > Interfaces > Edit (for ethernet0/1): Enter the following, then click
OK:

Zone Name: Trust

Static IP: (select this option when present)
IP Address/Netmask: 10.1.1.1/24
Interface Mode: NAT

Network > Interfaces > Edit (for ethernet0/3): Enter the following, then click
OK:

Zone Name: Untrust

Static IP: (select this option when present)
IP Address/Netmask: 201.1.1.1/24
Interface Mode: Route

Network > Interfaces > Edit (for ethernet0/3) > DIP > New: Enter the
following, then click OK:

ID: 5
IP Address Range: 211.20.1.1 ~ 211.20.1.1
Port Translation: (select)
Extended IP/Netmask: 211.20.1.10/255.255.255.0
2. Address
Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: HQ
IP Address/Domain Name:
IP/Netmask: (select), 200.1.1.1/32
Zone: Untrust
3. Route
Network > Routing > Destination > trust-vr New: Enter the following, then
click OK:

Network Address/Netmask: 0.0.0.0/0

Gateway: (select)
Interface: ethernet0/3
Gateway IP address: 201.1.1.254
4. Policies
Policy > Policies > (From: Trust, To: Untrust) New: Enter the following, then
click OK:

Source Address:
Address Book Entry: (select), Any
Destination Address:
Address Book Entry: (select), Any
Service: ANY
Action: Permit

148  Dynamic IP Pools

 Chapter 5: Building Blocks for Policies

Policy > Policies > (From: Trust, To: Untrust) New: Enter the following, then
click OK:
Source Address:
Address Book Entry: (select), Any
Destination Address:
Address Book Entry: (select), HQ
Service: ANY
Action: Permit
Position at Top: (select)
> Advanced: Enter the following, then click Return to set the advanced options
and return to the basic configuration page:
NAT:
Source Translation: (select)
DIP On: (select), 5 (211.20.1.1-211.20.1.1)/X-late

CLI (Branch Office A)

1. Interfaces
set interface ethernet0/1 zone trust
set interface ethernet0/1 ip 10.1.1.1/24
set interface ethernet0/1 nat
set interface ethernet0/3 zone untrust
set interface ethernet0/3 ip 195.1.1.1/24
set interface ethernet0/3 route
set interface ethernet0/3 ext ip 211.10.1.10 255.255.255.0 dip 5 211.10.1.1
2. Address
set address untrust hq 200.1.1.1/32
3. Route
set vrouter trust-vr route 0.0.0.0/0 interface ethernet0/3 gateway 195.1.1.254
4. Policies
set policy from trust to untrust any any any permit
set policy top from trust to untrust any hq any nat src dip 5 permit
save

CLI (Branch Office B)

1. Interfaces
set interface ethernet0/1 zone trust
set interface ethernet0/1 ip 10.1.1.1/24
set interface ethernet0/1 nat
set interface ethernet0/3 zone untrust
set interface ethernet0/3 ip 201.1.1.1/24
set interface ethernet0/3 route
set interface ethernet0/3 ext ip 211.20.1.10 255.255.255.0 dip 5 211.20.1.1
2. Address
set address untrust hq 200.1.1.1/32
3. Route
set vrouter trust-vr route 0.0.0.0/0 interface ethernet0/3 gateway 201.1.1.254
4. Policies
set policy from trust to untrust any any any permit
set policy top from trust to untrust any hq any nat src dip 5 permit
save

Dynamic IP Pools  149

 Concepts & Examples ScreenOS Reference Guide

Using a DIP on a Loopback Interface

A loopback interface is a logical interface that is always in the up state as long as the
device on which it resides is up. You can create a pool of dynamic IP (DIP)
addresses on a loopback interface so that it can be accessed by the group of
interfaces belonging to its associated loopback interface group when performing
source address translation. The addresses that the security device draws from such
a DIP pool are in the same subnet as the loopback interface IP address, not in the
subnet of any of the member interfaces. (Note that the addresses in the DIP pool
must not overlap with the interface IP address or any MIP addresses also defined on
the loopback interface.)

NOTE: For information about loopback interfaces, see “Loopback Interfaces” on page 58.

The primary application for putting a DIP pool on a loopback interface is to

translate source addresses to the same address or range of addresses although
different packets might use different egress interfaces.

Figure 54: Loopback DIP

Source Address Translation Using a
DIP Pool on a Loopback Interface
Source IP Destination IP Source IP Destination IP
DATA 1.3.3.2 DATA
1.3.3.2 2.2.2.2 2.2.2.2
ethernet0/2 ethernet0/3
1.1.1.1/24 1.2.2.1/24

Loopback Interface
Regardless of the egress loopback 1 DIP Pool
interface, the security device 1.3.3.1/30 1.3.3.2 - 1.3.3.2
translates the source IP
addresses to the address in Security Device
the DIP pool defined on the
loopback.1 interface. ethernet0/1
10.1.1.1/24

Host A Host B
Source IP Destination IP Source IP Destination IP
DATA 10.1.1.5 10.1.1.6 10.1.1.6 DATA
10.1.1.5 2.2.2.2 2.2.2.2

In this example, the security device receives the following IP addresses for two
Untrust zone interfaces from different Internet service providers (ISPs): ISP-1 and
ISP-2:

 ethernet0/2, 1.1.1.1/24, ISP-1

 ethernet0/3, 1.2.2.1/24, ISP-2

You bind these interfaces to the Untrust zone and then assign them the above IP
addresses. You also bind ethernet0/1 to the Trust zone and assign it IP address
10.1.1.1/24.

150  Dynamic IP Pools

 Chapter 5: Building Blocks for Policies

You want the security device to translate the source address in outbound traffic
from the Trust zone to a remote office in the Untrust zone. The translated address
must be the same IP address (1.3.3.2) because the remote office has a policy
permitting inbound traffic only from that IP address. You have previously obtained
the public IP addresses 1.3.3.1 and 1.3.3.2 and have notified both ISPs that you are
using these addresses in addition to the addresses that they assign the device.

You configure a loopback interface loopback.1 with the IP address 1.3.3.1/30 and a
DIP pool of 1.3.3.2 – 1.3.3.2 on that interface. The DIP pool has ID number 10. You
then make ethernet0/1 and ethernet0/2 members of the loopback group for
loopback.1.

You define an address for the remote office named “r-office” with IP address
2.2.2.2/32. You also define default routes for both ethernet0/1 and ethernet0/2
interfaces pointing to the routers for ISP-1 and ISP-2, respectively.

You define routes to two gateways for outbound traffic to use. Because you do not
prefer one route over the other, you do not include any metrics in the routes.
Outbound traffic might follow either route.

NOTE: To indicate a route preference, include metrics in both routes, giving your
preferred route a higher metric—that is, a value closer to 1.

Finally, you create a policy applying Source Network Address Translation (NAT-src)
to outbound traffic to the remote office. The policy references DIP pool ID 10.

Figure 55: Loopback DIP Policy

r-office
2.2.2.2
Source IP Destination IP DATA
1.3.3.2 2.2.2.2

ISP-1 Untrust ISP-2

Zone

ethernet0/2, 1.1.1.1/24 ethernet0/3, 1.2.2.1/24

gateway 1.1.1.250 gateway 1.2.2.250
The security
device translates
DIP Pool ID 10
all source IP
(on Loopback.1)
addresses in
1.3.3.2 – 1.3.3.2
packets destined
for 2.2.2.2 from ethernet0/1, 10.1.1.1/24 Loopback.1
10.1.1.X to 1.3.3.2, NAT Mode Untrust Zone
regardless of the 1.3.3.1/30
egress interface. Trust
10.1.1.0/24 Zone

Source IP Destination IP DATA

10.1.1.X 2.2.2.2

Dynamic IP Pools  151

 Concepts & Examples ScreenOS Reference Guide

WebUI
1. Interfaces
Network > Interfaces > New Loopback IF: Enter the following, then click OK:

Interface Name: loopback.1

Zone: Untrust (trust-vr)
IP Address/Netmask: 1.3.3.1/30

Network > Interfaces > Edit (for ethernet0/1): Enter the following, then click
OK:

As member of loopback group: loopback.1

Zone Name: Trust
Static IP: (select this option when present)
IP Address/Netmask: 10.1.1.1/24
Interface Mode: NAT

Network > Interfaces > Edit (for ethernet0/2): Enter the following, then click
OK:

As member of loopback group: loopback.1

Zone Name: Untrust
Static IP: (select this option when present)
IP Address/Netmask: 1.1.1.1/24
Interface Mode: Route

Network > Interfaces > Edit (for ethernet0/3): Enter the following, then click
OK:

Zone Name: Untrust

Static IP: (select this option when present)
IP Address/Netmask: 1.2.2.1/24
Interface Mode: Route
2. DIP Pool
Network > Interfaces > Edit (for loopback.1) > DIP > New: Enter the
following, then click OK:

ID: 5
IP Address Range: 1.3.3.2 ~ 1.3.3.2
Port Translation: (select)
3. Address
Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: r-office

IP Address/Domain Name:
IP/Netmask: (select), 2.2.2.2/32
Zone: Untrust

152  Dynamic IP Pools

 Chapter 5: Building Blocks for Policies

4. Routes
Network > Routing > Destination > trust-vr New: Enter the following, then
click OK:

Network Address/Netmask: 0.0.0.0/0

Gateway: (select)
Interface: ethernet0/2
Gateway IP address: 1.1.1.250

Network > Routing > Destination > trust-vr New: Enter the following, then
click OK:

Network Address/Netmask: 0.0.0.0/0

Gateway: (select)
Interface: ethernet0/3
Gateway IP address: 1.2.2.250
5. Policy
Policy > Policies > (From: Trust, To: Untrust) New: Enter the following, then
click OK:

Source Address:
Address Book Entry: (select), Any
Destination Address:
Address Book Entry: (select), r-office
Service: ANY
Action: Permit

> Advanced: Enter the following, then click Return to set the advanced
options and return to the basic configuration page:

NAT:
Source Translation: (select)
DIP On: (select), 10 (1.3.3.2-1.3.3.2)/port-xlate

CLI
1. Interfaces
set interface loopback.1 zone untrust
set interface loopback.1 ip 1.3.3.1/30
set interface ethernet0/1 zone trust
set interface ethernet0/1 ip 10.1.1.1/24
set interface ethernet0/1 nat
set interface ethernet0/2 zone untrust
set interface ethernet0/2 ip 1.1.1.1/24
set interface ethernet0/2 loopback-group loopback.1
set interface ethernet0/3 zone untrust
set interface ethernet0/3 ip 1.2.2.1/24
set interface ethernet0/3 loopback-group loopback.1

Dynamic IP Pools  153

 Concepts & Examples ScreenOS Reference Guide

2. DIP Pool
set interface loopback.1 dip 10 1.3.3.2 1.3.3.2
3. Address
set address untrust r-office 2.2.2.2/32
4. Routes
set vrouter trust-vr route 0.0.0.0/0 interface ethernet0/2 gateway 1.1.1.250
set vrouter trust-vr route 0.0.0.0/0 interface ethernet0/3 gateway 1.2.2.250
5. Policy
set policy from trust to untrust any r-office any nat src dip-id 10 permit
save

Creating a DIP Group

When you group two security devices into a redundant cluster to provide high
availability (HA) services in an Active/Active configuration, both devices share the
same configuration and both process traffic simultaneously. A problem can arise
when you define a policy to perform Network Address Translation (NAT) using a
dynamic IP (DIP) pool located on one VSI. Because that VSI is active only on the
security device acting as the primary of the VSD group to which the VSI is bound,
any traffic sent to the other security device—the one acting as the backup of that
VSD group—cannot use that DIP pool and is dropped.

Figure 56: DIP Problems with NAT with One VSI

Problematic use of a DIP pool in a policy when in an NSRP cluster:
set policy name out-nat from trust to untrust any any any nat src dip-id 7 permit

Untrust Zone VSIs Untrust Zone

DIP Pool ID 7
1.1.1.101 – 1.1.1.150

ethernet0/2 ethernet0/3:1
1.1.1.1/24 1.1.1.2/24

Master Device A Backup

VSD 0 VSD 1
NSRP Cluster VSD Group: 0 VSD Group: 1

Backup Master
VSD 0 Device B VSD 1

ethernet0/1 ethernet0/1:1
10.1.1.1/24 10.1.1.2/24

Because the DIP pool is located in the Untrust zone

VSI for VSD group 1 (of which Device B is the
master), Device A (the backup of VSD group 1) Trust Zone Trust Zone VSIs
drops traffic that it receives at ethernet0/1
(10.1.1.1/24) matching policy “out-nat”.

154  Dynamic IP Pools

 Chapter 5: Building Blocks for Policies

To solve this problem, you can create two DIP pools—one on the Untrust zone VSI
for each VSD group—and combine the two DIP pools into one DIP group, which you
reference in the policy. Each VSI uses its own VSD pool even though the policy
specifies the DIP group.

Figure 57: Creating Two DIP Pools in One DIP Group

Recommended use of a DIP group in a policy when in an NSRP cluster:
set policy name out-nat from trust to untrust any any any nat dip-id 9 permit

Untrust Zone
DIP Pool ID 8 DIP Pool ID 7
1.1.1.151 – 1.1.1.200 1.1.1.101 – 1.1.1.150

ethernet0/3 ethernet0/3:1
Untrust Zone VSIs 1.1.1.1/24 1.1.1.2/24
DIP Group 9

Master Backup
Device A VSD 1
VSD 0
NSRP Cluster VSD Group: 0 VSD Group: 1

Backup Master
VSD 0 Device B VSD 1

Trust Zone VSIs

ethernet0/1 ethernet0/1:1
10.1.1.1/24 10.1.1.2/24
By combining the DIP pools located on both Untrust
zone VSIs (for VSD groups 0 and 1) into one DIP
group, Devices A and B can both process traffic
Trust Zone
matching policy “out-nat”, which references not an
interface-specific DIP pool but the shared DIP group.

NOTE: For more information about setting up security devices for HA, see Volume 11:
High Availability.

In this example, you provide NAT services on two security devices (Devices A and B)
in an Active/Active HA pair.

You create two DIP pools—DIP 5 (1.1.1.20 – 1.1.1.29) on ethernet0/3 and DIP 6
(1.1.1.30 – 1.1.1.39) on ethernet0/3:1. You then combine them into a DIP group
identified as DIP 7, which you reference in a policy.

The VSIs for VSD groups 0 and 1 are as follows:

 Untrust zone VSI ethernet0/3 1.1.1.1/24 (VSD group 0)

 Untrust zone VSI ethernet0/3:1 1.1.1.2/24 (VSD group 1)

 Trust zone VSI ethernet0/1 10.1.1.1/24 (VSD group 0)

 Trust zone VSI ethernet0/1:1 10.1.1.2/24 (VSD group 1)

Dynamic IP Pools  155

 Concepts & Examples ScreenOS Reference Guide

Let’s assume that you have already set up Devices A and B in an NSRP cluster,
created VSD group 1 (ScreenOS automatically creates VSD group 0 when you put a
device in an NSRP cluster), and configured the above interfaces. (For information
about configuring security devices for NSRP, see Volume 11: High Availability.)

WebUI
1. DIP Pools
Network > Interfaces > Edit (for ethernet0/3) > DIP > New: Enter the
following, then click OK:

ID: 5
IP Address Range: 1.1.1.20 – 1.1.1.29
Port Translation: (select)

Network > Interfaces > Edit (for ethernet0/3:1) > DIP > New: Enter the
following, then click OK:

ID: 6
IP Address Range: 1.1.1.30 – 1.1.1.39
Port Translation: (select)

NOTE: At the time of this release, you can only define a DIP group through the CLI.

2. Policy
Policy > Policies > (From: Trust, To: Untrust) New: Enter the following, then
click OK:

Source Address:
Address Book Entry: (select), Any
Destination Address:
Address Book Entry: (select), Any
Service: ANY
Action: Permit

> Advanced: Enter the following, then click Return to set the advanced
options and return to the basic configuration page:

NAT:
Source Translation: (select)
DIP On: (select), 7

CLI
1. DIP Pools
set interface ethernet0/3 dip 5 1.1.1.20 1.1.1.29
set interface ethernet0/3:1 dip 6 1.1.1.30 1.1.1.39
2. DIP Groups
set dip group 7 member 5
set dip group 7 member 6
3. Policy
set policy from trust to untrust any any any nat src dip-id 7 permit
save

156  Dynamic IP Pools

 Chapter 5: Building Blocks for Policies

Setting a Recurring Schedule

A schedule is a configurable object that you can associate with one or more policies
to define when they are in effect. Through the application of schedules, you can
control network traffic flow and enforce network security.

When you define a schedule, enter values for the following parameters:

 Schedule Name: The name that appears in the Schedule drop-down list in the
Policy Configuration dialog box. Choose a descriptive name to help you identify
the schedule. The name must be unique and is limited to 19 characters.

 Comment: Any additional information that you want to add.

 Recurring: Enable this when you want the schedule to repeat weekly.

Start and End Times: You must configure both a start time and an end time.
You can specify up to two time periods within the same day.

 Once: Enable this when you want the schedule to start and end only once.

mm/dd/yyyy hh:mm: You must enter both start and stop dates and times.

In this example, there is a short-term employee named Tom who is using the
company’s Internet access for personal pursuits after work. You create a schedule
for non-business hours that you can then associate with a policy to deny outbound
TCP/IP traffic from that worker’s computer (10.1.1.5/32) outside of regular business
hours.

WebUI
1. Schedule
Policy > Policy Elements > Schedules > New: Enter the following, then click
OK:

Schedule Name: After Hours

Comment: For non-business hours
Recurring: (select)
Period 1:

Weekday Start Time End Time

Sunday 00:00 23:59
Monday 00:00 06:00
Tuesday 00:00 06:00
Wednesday 00:00 06:00
Thursday 00:00 06:00
Friday 00:00 06:00
Saturday 00:00 23:59

Setting a Recurring Schedule  157

 Concepts & Examples ScreenOS Reference Guide

Period 2:

Weekday Start Time End Time

Sunday 17:00 23:59
Monday 17:00 23:59
Tuesday 17:00 23:59
Wednesday 17:00 23:59
Thursday 17:00 23:59
Friday 17:00 23:59
Saturday 17:00 23:59

2. Address
Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:
Address Name: Tom
Comment: Temp
IP Address/Domain Name:
IP/Netmask: (select), 10.1.1.5/32
Zone: Trust
3. Policy
Policy > Policies > (From: Trust, To: Untrust) New: Enter the following, then
click OK:

Name: No Net
Source Address:
Address Book Entry: (select), Tom
Destination Address:
Address Book Entry: (select), Any
Service: HTTP
Action: Deny
Schedule: After Hours

CLI
1. Schedule
set schedule “after hours” recurrent sunday start 00:00 stop 23:59
set schedule “after hours” recurrent monday start 00:00 stop 06:00 start 17:00
stop 23:59
set schedule “after hours” recurrent tuesday start 00:00 stop 06:00 start 17:00
stop 23:59
set schedule “after hours” recurrent wednesday start 00:00 stop 06:00 start
17:00 stop 23:59
set schedule “after hours” recurrent thursday start 00:00 stop 06:00 start 17:00
stop 23:59
set schedule “after hours” recurrent friday start 00:00 stop 06:00 start 17:00
stop 23:59
set schedule “after hours” recurrent saturday start 00:00 stop 23:59 comment
“for non-business hours”
2. Address
set address trust tom 10.1.1.5/32 “temp”
3. Policy
set policy from trust to untrust tom any http deny schedule “after hours”
save

158  Setting a Recurring Schedule

Chapter 6
Policies

The default behavior of a security device is to deny all traffic between security
zones (interzone traffic) and—except for traffic within the Untrust zone—allow all
traffic between interfaces bound to the same zone (intrazone traffic). To permit
selected interzone traffic to cross a security device you must create interzone
policies that override the default behavior. Similarly, to prevent selected intrazone
traffic from crossing a security device, you must create intrazone policies.

This chapter describes what policies do and how the various elements that
comprise a policy are related. It contains the following sections:

 “Basic Elements” on page 160

 “Three Types of Policies” on page 161

 “Policy Set Lists” on page 163

 “Policies Defined” on page 164

 “Policies Applied” on page 175

NOTE: If you configure multicast routing on a security device, you might have to
configure multicast policies. For information about multicast policies, see
“Multicast Policies” on page 7-135.

 159
 Concepts & Examples ScreenOS Reference Guide

Basic Elements
A policy permits, denies, or tunnels specified types of traffic unidirectionally
between two points. The type of traffic (or “service”), the location of the two
endpoints, and the invoked action compose the basic elements of a policy. Although
there can be other components, the required elements, which together constitute
the core section of a policy, are described in Table 27.

Table 27: Basic Policy Elements

Element Description
Direction The direction of traffic between two security zones (from a source zone to
a destination zone)
Source Address The address from which traffic initiates
Destination Address The address to which traffic is sent
Service The type of traffic transmitted
Action The action that the security device performs when it receives traffic
meeting the first four criteria: deny, permit, reject, or tunnel
Note: The “tunnel” action—(VPN or L2TP tunnel)—contains the concept
of “permit” implicitly.

For example, the policy stated in the following CLI command permits FTP traffic
from any address in the Trust zone to an FTP server named “server1” in the DMZ
zone:

set policy from trust to untrust any server1 ftp permit

 Direction: from trust to untrust (that is, from the Trust zone to the Untrust
zone)

 Source Address: any (that is, any address in the Trust zone. The term “any”
stands for a predefined address that applies to any address in a zone)

 Destination Address: server1 (a user-defined address in the Untrust zone

address book)

 Service: ftp (File Transfer Protocol)

 Action: permit (that security device permits this traffic to traverse its firewall)

160  Basic Elements

 Chapter 6: Policies

Three Types of Policies

You control the flow of traffic with the following three types of policies:

 Interzone Policies—Let you regulate the kind of traffic allowed to pass from
one security zone to another.

 Intrazone Policies— Let you regulate the kind of traffic allowed to cross
interfaces bound to the same zone.

 Global Policies—Let you regulate traffic between addresses, regardless of their

security zones.

Interzone Policies
Interzone policies provide traffic control between security zones. You can set
interzone policies to deny, permit, reject, or tunnel traffic from one zone to another.
Using stateful inspection techniques, a security device maintains a table of active
TCP sessions and active UDP “pseudo” sessions so that it can allow replies to
service requests. For example, if you have a policy allowing HTTP requests from
host A in the Trust zone to server B in the Untrust zone, when the security device
receives HTTP replies from server B to host A, the security device checks the
received packet against its table. Finding the packet to be a reply to an approved
HTTP request, the security device allows the packet from server B in the Untrust
zone to cross the firewall to host A in the Trust zone. To permit traffic initiated by
server B to host A (not just replies to traffic initiated by host A), you must create a
second policy from server B in the Untrust zone to host A in the Trust zone.

Figure 58: Interzone Policy

set policy from trust to untrust “host A” “server B” http permit

Host A Server B
Trust Zone Untrust Zone
Security Device
HTTP request
HTTP reply
HTTP request

Note: The security device rejects the HTTP request from server B because there is no policy permitting

Intrazone Policies
Intrazone policies provide traffic control between interfaces bound to the same
security zone. The source and destination addresses are in the same security zone
but are reached via different interfaces on the security device. Like interzone
policies, intrazone policies control traffic flowing unidirectionally. To allow traffic
initiated at either end of a data path, you must create two policies—one policy for
each direction.

Three Types of Policies  161

 Concepts & Examples ScreenOS Reference Guide

Figure 59: Intrazone Policy

set policy from trust to trust “host A” “server B” any permit ethernet0/1 ethernet0/4
set policy from trust to trust “server B” “host A” any permit 10.1.1.1/24 10.1.2.1/24

Layer 2 Switches

Host A Server B
10.1.1.5 LAN 1 LAN
10.1.1.0/24 10.1.2.0/24 10.1.2.30

Trust Zone

Intrazone policies do not support VPN tunnels or Source Network Address

Translation (NAT-src) when it is set at the interface level (set interface interface nat).
However, intrazone policies do support policy-based NAT-src and NAT-dst. They also
support destination address translation when the policy references a mapped IP
(MIP) as the destination address. (For information about NAT-src, NAT-dst, and MIPs,
see Volume 8: Address Translation.)

Global Policies
Unlike interzone and intrazone policies, global policies do not reference specific
source and destination zones. Global policies reference user-defined Global zone
addresses or the predefined Global zone address “any”. These addresses can span
multiple security zones. For example, if you want to provide access to or from
multiple zones, you can create a global policy with the Global zone address “any,”
which encompasses all addresses in all zones.

NOTE: At the time of this release, global policies do not support Source Network Address
Translation (NAT-src), VPN tunnels, or Transparent mode. You can, however,
specify a MIP or VIP as the destination address in a global policy.

162  Three Types of Policies

 Chapter 6: Policies

Policy Set Lists

A security device maintains three different policy set lists, one each for interzone
policies, intrazone policies, and global policies.

When the security device receives a packet initiating a new session, the device
notes the ingress interface, and thereby learns the source zone to which that
interface is bound. The security device then performs a route lookup to determine
the egress interface, and thus determines the destination zone to which that
interface is bound. Using the source and destination zones, the security device can
perform a policy lookup, consulting the policy set lists in the following order:

1. If the source and destination zones are different, the security device performs a
policy lookup in the interzone policy set list.

(or)

If the source and destination zones are the same, the security device performs a
policy lookup in the intrazone policy set list.

2. If the security device performs the interzone or intrazone policy lookup and
does not find a match, the security device then checks the global policy set list
for a match.

3. If the security device performs the interzone and global policy lookups and
does not find a match, the security device then applies the default permit/deny
policy to the packet: unset/set policy default-permit-all.

(or)

If the security device performs the intrazone and global policy lookups and
does not find a match, the security device then applies the intrazone blocking
setting for that zone to the packet: unset/set zone zone block.

The security device searches each policy set list from top to bottom. Therefore, you
must position more specific policies above less specific policies in the list. (For
information about policy order, see “Reordering Policies” on page 190.)

Policy Set Lists  163

 Concepts & Examples ScreenOS Reference Guide

Policies Defined
A security device provides a network boundary with a single point of entry and exit.
Because all traffic must pass through this point, you can screen and direct that
traffic by implementing policy set lists—for interzone policies, intrazone policies,
and global policies.

Policies allow you to deny, permit, reject (deny and send a TCP RST or an ICMP port
unreachable message to the source host), encrypt and decrypt, authenticate,
prioritize, schedule, filter, have no hardware session, and monitor the traffic
attempting to cross from one security zone to another. You decide which users and
what data can enter and exit, and when and where they can go.

NOTE: For security devices that support virtual systems, policies set in the root system do
not affect policies set in virtual systems.

Policies and Rules

A single user-defined policy produces one or more logical rules internally, and each
logical rule consists of a set of components—source address, destination address,
and service. The components consume memory resources. The logical rules that
reference the components do not.

Depending on the use of multiple entries or groups for the source address,
destination address, and service components in a policy, the number of logical rules
can be much larger than is readily apparent from the creation of the single policy.
For example, the following policy produces 125 logical rules:

1 policy: 5 source addresses x 5 destination addresses x 5 services = 125

logical rules

However, the security device does not duplicate components for each logical rule.
The rules make use of the same set of components in various combinations. For
example, the above policy that produces 125 logical rules results in only 15
components:

5 source addresses + 5 destination addresses + 5 services = 15 components

These 15 components combine in various ways to produce the 125 logical rules
generated by the single policy. By allowing multiple logical rules to use the same set
of components in different combinations, the security device consumes far fewer
resources than if each logical rule had a one-to-one relationship with its
components.

Because the installation time of a new policy is proportional to the number of

components that the security device adds, removes, or modifies, policy installation
becomes faster with fewer components. Also, by allowing a large number of logical
rules to share a small set of components, ScreenOS allows you to create more
policies—and the security device to create more rules—than would be possible if
each rule required dedicated components.

164  Policies Defined

 Chapter 6: Policies

Anatomy of a Policy
A policy must contain the following elements:

 ID (automatically generated, but can be user-defined in the CLI)

 Zones (source and destination)

 Addresses (source and destination)

 Services

 Action (deny, permit, reject, tunnel)

A policy can also contain the following elements:

 Application

 Name

 VPN tunneling

 L2TP tunneling

 Deep inspection (DI)

 Placement at the top of the policy list

 Source Network Address Translation (NAT-src)

 Destination Network Address Translation (NAT-dst)

 No hardware session

 User authentication

 High availability session backup

 Web filtering

 Logging

 Counting

 Traffic alarm threshold

 Schedules

 Antivirus scanning

 Traffic shaping

The remainder of this section examines each of the above elements.

Policies Defined  165

 Concepts & Examples ScreenOS Reference Guide

ID
Every policy has an ID number, whether you define one or the security device
automatically assigns it. You can only define an ID number for a policy through the
set policy command in the CLI: set policy id number … After you know the ID
number, you can enter the policy context to issue further commands to modify the
policy. (For more information about policy contexts, see “Entering a Policy Context”
on page 185.)

Zones
A zone can be a segment of network space to which security measures are applied
(a security zone), a logical segment to which a VPN tunnel interface is bound (a
tunnel zone), or either a physical or logical entity that performs a specific function
(a function zone). A policy allows traffic to flow between two security zones
(interzone policy) or between two interfaces bound to the same zone (intrazone
policy). (For more information, see “Zones” on page 25, “Interzone Policies” on
page 161, and “Intrazone Policies” on page 161.)

Addresses
Addresses are objects that identify network devices such as hosts and networks by
their location in relation to the firewall—in one of the security zones. Individual
hosts are specified using the mask 255.255.255.255, indicating that all 32 bits of
the address are significant. Networks are specified using their subnet mask to
indicate which bits are significant. To create a policy for specific addresses, you
must first create entries for the relevant hosts and networks in the address book.

You can also create address groups and apply policies to them as you would to other
address book entries. When using address groups as elements of policies, be aware
that because the security device applies the policy to each address in the group, the
number of available internal logical rules and the components that comprise those
rules can become depleted more quickly than expected. This is a danger especially
when you use address groups for both the source and destination. (For more
information, see “Policies and Rules” on page 164.)

Wildcard Addresses
In addition to netmasks, Juniper Networks security devices allow you to define
wildcard masks. A wildcard mask is similar to the subnet mask, but instructs the
security device to consider the IP addresses corresponding to ‘0’s in wildcard mask.
IP address that have a wildcard mask are called wildcard addresses. Wildcard
addresses enable you to reduce the number of policies you create to control traffic.

However, a wildcard address cannot be a member of an address group or coexist

with other normal addresses in the source or destination address domains in a
policy. In addition, you can neither define a VPN policy or RPC policy with wildcard
addresses nor shift IP addresses. Because the security device must check all the
possible combinations on a matched policy during policy lookup, wildcard policies
cause a performance penalty.

NOTE: The security device considers the IP address corresponding to '1's in a netmask or
wildcard mask. However, netmask differs from wildcard mask on the rule that the
'1's in the netmask must always be continuous and in the leading place, while the
rule is not applicable for wildcard mask.

166  Policies Defined

 Chapter 6: Policies

Services
Services are objects that identify application protocols using Layer 4 information
such as standard and accepted TCP and UDP port numbers for application services
like Telnet, FTP, SMTP, and HTTP. The ScreenOS includes predefined core Internet
services. Additionally, you can define custom services.

You can define policies that specify which services are permitted, denied,
encrypted, authenticated, logged, or counted.

Action
An action is an object that describes what the firewall does to the traffic it receives.

 Deny blocks the packet from traversing the firewall.

 Permit allows the packet to pass the firewall.

 Reject blocks the packet from traversing the firewall. The security device drops
the packet and sends a TCP reset (RST) segment to the source host for TCP
traffic and an ICMP “destination unreachable, port unreachable” message (type
3, code 3) for UDP traffic. For types of traffic other than TCP and UDP, the
security device drops the packet without notifying the source host, which is also
what occurs when the action is “deny.”

NOTE: The security device sends a TCP RST after receiving (and dropping) a TCP segment
with any code bit set other than another RST.

When the ingress interface is operating at Layer 2 or 3 and the protocol is TCP, the
source IP address in the TCP RST is the destination IP address in the original
(dropped) packet. When the ingress interface is operating at Layer 2 and the
protocol is UDP, the source IP address in the ICMP message is also the destination
IP address in the original packet. However, if the ingress interface is operating at
Layer 3 and the protocol is UDP, then the source IP address in the ICMP message
is that of the ingress interface.

 Tunnel encapsulates outgoing IP packets and decapsulates incoming IP

packets. For an IPSec VPN tunnel, specify which VPN tunnel to use. For an L2TP
tunnel, specify which L2TP tunnel to use. For L2TP-over-IPSec, specify both an
IPSec VPN tunnel and an L2TP tunnel.

NOTE: For L2TP-over-IPSec, the source and destination addresses for the IPSec VPN
tunnel must be the same as those for the L2TP tunnel.

The security device applies the specified action on traffic that matches the
previously presented criteria: zones (source and destination), addresses (source and
destination), and service.

Policies Defined  167

 Concepts & Examples ScreenOS Reference Guide

Application
The application option specifies the Layer 7 application that maps to the Layer 4
service that you reference in a policy. A predefined service already has a mapping
to a Layer 7 application. However, for custom services, you must link the service to
an application explicitly, especially if you want the policy to apply an Application
Layer Gateway (ALG) or deep inspection to the custom service.

NOTE: ScreenOS supports ALGs for numerous services, including DNS, FTP, H.323, HTTP,
RSH, SIP, Telnet, and TFTP.

Applying an ALG to a custom service involves the following two steps:

 Define a custom service with a name, timeout value, transport protocol, and
source and destination ports

 When configuring a policy, reference that service and the application type for
the ALG that you want to apply

For information about applying deep inspection to a custom service, see “Mapping
Custom Services to Applications” on page 4-152.

Name
You can give a policy a descriptive name to provide a convenient means for
identifying its purpose.

NOTE: For information regarding ScreenOS naming conventions—which apply to the

names you create for policies—see “Illustration Conventions” on page xii.

VPN Tunneling
You can apply a single policy or multiple policies to any VPN tunnel that you have
configured. In the WebUI, the VPN Tunnel option provides a drop-down list of all
such tunnels. In the CLI, you can see all available tunnels with the get vpn
command. (For more information, see “Site-to-Site Virtual Private Networks” on
page 5-79 and “Dialup Virtual Private Networks” on page 5-159.)

When the VPN configurations at both ends of a VPN tunnel are using
policy-based-NAT, then the administrators of both gateway devices each need to
create an inbound and an outbound policy (four policies in total). When the VPN
policies constitute a matching pair (that is, everything in the inbound and outbound
policy configurations is the same except that the source and destination addresses
are reversed), you can configure one policy and then select the Modify matching
bidirectional VPN policy check box to create a second policy automatically for the
opposite direction. For the configuration of a new policy, the matching VPN policy
check box is cleared by default. For the modification of an existing policy that is a
member of a matching pair, the check box is selected by default, and any changes
made to one policy are propagated to the other.

168  Policies Defined

 Chapter 6: Policies

NOTE: This option is available only through the WebUI. It is not supported when there are
multiple entries for any of the following policy components: source address,
destination address, or service. In addition, you cannot use wildcard addresses in
a VPN policy.

L2TP Tunneling
You can apply a single policy or multiple policies to any Layer 2 Tunneling Protocol
(L2TP) tunnel that you have configured. In the WebUI, the L2TP option provides a
drop-down list of all such tunnels. In the CLI, you can display status of active L2TP
tunnels with the get l2tp tunn_str active command, and see all available tunnels
with the get l2tp all command. You can also combine a VPN tunnel and an L2TP
tunnel—if both have the same endpoints—to create a tunnel combining the
characteristics of each. This is called L2TP-over-IPSec.

NOTE: A security device in Transparent mode does not support L2TP.

Deep Inspection
Deep inspection (DI) is a mechanism for filtering the traffic permitted at the
Network and Transport Layers by examining not only these layers but the content
and protocol characteristics at the Application Layer. DI is designed to detect and
prevent attacks or anomalous behavior present in traffic permitted by the security
device

NOTE: In the Open Systems Interconnection (OSI) Model, the Network Layer is Layer 3,
the Transport Layer is Layer 4, and the Application Layer is Layer 7. The OSI Model
is a networking industry standard model of network protocol architecture. The OSI
Model consists of seven layers.

To configure a policy for attack protection, you must make two choices: which
attack group (or groups) to use and which attack action to take if an attack is
detected. (For more information, see “Deep Inspection” on page 4-115.)

Placement at the Top of the Policy List

By default, ScreenOS positions a newly created policy at the bottom of a policy set
list. If you need to reposition the policy, you can use either of the policy reordering
methods explained in “Reordering Policies” on page 192. To avoid the extra step of
repositioning a newly created policy to the top of a policy set list, you can select the
Position at Top option in the WebUI, or use the keyword top in the set policy
command (set policy top …) in the CLI.

Session Limiting
When you configure or modify a policy, you can define a limit to the number of
sessions from a source IP address. You can configure the device to either issue an
alarm and allow the session to continue, or drop any further traffic.

Policies Defined  169

 Concepts & Examples ScreenOS Reference Guide

When you enforce session limiting, only the new sessions will be counted against
the configured session limit for the source IP address to which the policy is applied.
Similarly, in the case of NetScreen Redundancy Protocol (NSRP) or Virtual Router
Redundancy Protocol (VRRP) clusters, the sessions that are reflected in the backup
device will not be counted against the configured session limit. When a failover
occurs, the backup device that takes over as the primary will allow any new
sessions only within the limit, or after any existing sessions age out if the sessions
count has reached the threshold.

Source Address Translation

You can apply source address translation (NAT-src) at the policy level. With NAT-src,
you can translate the source address on either incoming or outgoing network and
VPN traffic. The new source address can come from either a dynamic IP (DIP) pool
or the egress interface. NAT-src also supports source port address translation (PAT).
To learn about all the NAT-src options that are available, see “Source Network
Address Translation” on page 8-13.

NOTE: You can also perform Source Network Address Translation (NAT-src) at the
interface level, known as Network Address Translation (NAT). For information
about both interface-level NAT-src and NAT, see “NAT Mode” on page 92.

Destination Address Translation

You can apply destination address translation (NAT-dst) at the policy level. With
NAT-dst, you can translate the destination address on either incoming or outgoing
network and VPN traffic. NAT-dst can also support destination port mapping. To
learn about all the NAT-dst options that are available, see “Destination Network
Address Translation” on page 8-27.

No Hardware Session
Using this option, you can disable the security device from creating a hardware
session for a specific type of traffic. This option is useful for debugging and for
when some types of traffic, such as PPTP, cannot be handled efficiently by the
ASIC. In the CLI, use the no-hw-sess argument in the set policy command.

NOTE: Enabling or disabling this feature after a session has been created does not affect
the session.

For TCP traffic, you must create a dummy hardware session to pass the traffic to
the CPU.

User Authentication
Selecting this option requires the auth user at the source address to authenticate
his/her identity by supplying a username and password before traffic is allowed to
traverse the firewall or enter the VPN tunnel. The security device can use the local
database or an external RADIUS, SecurID, or LDAP auth server to perform the
authentication check.

170  Policies Defined

 Chapter 6: Policies

NOTE: If a policy requiring authentication applies to a subnet of IP addresses,

authentication is required for each IP address in that subnet.

If a host supports multiple auth user accounts (as with a UNIX host running
Telnet), then after the security device authenticates the first user, all other users
from that host can pass traffic through the security device without being
authenticated, having inherited the privileges of the first user.

ScreenOS provides following two authentication schemes:

 Run-time authentication, in which the security device prompts an auth user to

log on when it receives HTTP, FTP, or Telnet traffic matching a policy that has
authentication enabled

 WebAuth, in which a user must authenticate himself or herself before sending

traffic through the security device

Run-Time Authentication
The run-time authentication process proceeds as follows:

1. When the auth user sends an HTTP, an FTP, or a Telnet connection request to
the destination address, the security device intercepts the packet and buffers it.

2. The security device sends the auth user a login prompt.

3. The auth user responds to this prompt with his/her username and password.

4. The security device authenticates the auth user’s login information.

If the authentication is successful, a connection is established between the auth

user and the destination address.

For the initial connection request, a policy must include one or all of the three
following services: Telnet, HTTP, or FTP. Only a policy with one or all of these
services is capable of initiating the authentication process. You can use any of the
following services in a policy involving user authentication:

 Any (because “any” includes all three required services).

 Telnet, FTP, or HTTP.

 A service group that includes the service or services you want, plus one or more
of the three services required to initiate the authentication process (Telnet, FTP,
or HTTP). For example, you can create a custom service group named “Login”
that supports FTP, NetMeeting, and H.323 services. Then, when you create the
policy, specify Login as the service.

For any connection following a successful authentication, all services specified in

the policy are valid.

NOTE: A policy with authentication enabled does not support DNS (port 53) as the
service.

Policies Defined  171

 Concepts & Examples ScreenOS Reference Guide

Pre-Policy Check Authentication (WebAuth)

The WebAuth authentication process proceeds as follows:

1. The auth user makes an HTTP connection to the IP address of the WebAuth
server.

2. The security device sends the auth user a login prompt.

3. The auth user responds to this prompt with his/her username and password.

4. The security device or an external auth server authenticates the auth user’s
login information.

If the authentication attempt is successful, the security device permits the auth
user to initiate traffic to destinations as specified in policies that enforce
authentication via the WebAuth method.

NOTE: For more information about these two user authentication methods, see
“Referencing Auth Users in Policies” on page 9-46.

You can restrict or expand the range of auth users to which the policy applies by
selecting a specific user group, local or external user, or group expression. (For
information about group expressions, see “Group Expressions” on page 9-5.) If you
do not reference an auth user or user group in a policy (in the WebUI, select the
Allow Any option), the policy applies to all auth users in the specified auth server.

NOTE: ScreenOS links authentication privileges with the IP address of the host from
which the auth user logs on. If the security device authenticates one user from a
host behind a NAT device that uses a single IP address for all NAT assignments,
then users at other hosts behind that NAT device automatically receive the same
privileges.

HA Session Backup
When two security devices are in an NSRP cluster for high availability (HA), you can
specify which sessions to backup and which not to backup. For traffic whose
sessions you do not want backed up, apply a policy with the HA session backup
option disabled. In the WebUI, clear the HA Session Backup check box. In the CLI,
use the no-session-backup argument in the set policy command. By default,
security devices in an NSRP cluster back up sessions.

Web Filtering
Web filtering, also called URL filtering, enables you to manage Internet access and
prevent access to inappropriate web content. For more information, see “Web
Filtering” on page 4-97.

Logging
When you enable logging in a policy, the security device logs all connections to
which that particular policy applies. You can view the logs through either the WebUI
or CLI. In the WebUI, click Reports > Policies > Logging (for the policy whose log
you want to see). In the CLI, use the get log traffic policy id_num command.

172  Policies Defined

 Chapter 6: Policies

NOTE: For more information about viewing logs and graphs, see “Monitoring Security
Devices” on page 3-55.

Counting
When you enable counting in a policy, the security device counts the total number
of bytes of traffic to which this policy applies and records the information in
historical graphs. To view the historical graphs for a policy in the WebUI, click
Reports > Policies > Counting (for the policy whose traffic count you want to
see).

Traffic Alarm Threshold

You can set a threshold that triggers an alarm when the traffic permitted by the
policy exceeds a specified number of bytes per second, bytes per minute, or both.
Because the traffic alarm requires the security device to monitor the total number of
bytes, you must also enable the counting feature.

NOTE: For more information about traffic alarms, see “Traffic Alarms” on page 3-68.

Schedules
By associating a schedule to a policy, you can determine when the policy is in
effect. You can configure schedules to recur or as a one-time event. Schedules
provide a powerful tool for controlling the flow of network traffic and enforcing
network security. For an example of the latter, if you were concerned about
employees transmitting important data outside the company, you might set a policy
that blocked outbound FTP-Put and MAIL traffic after normal business hours.

In the WebUI, define schedules on the Policy > Policy Elements > Schedules
page. In the CLI, use the set schedule command.

NOTE: In the WebUI, scheduled policies appear with a gray background to indicate that
the current time is not within the defined schedule. When a scheduled policy
becomes active, it appears with a white background.

Antivirus Scanning
Some Juniper Networks security devices support an internal AV scanner that you
can configure to filter FTP, HTTP, IMAP, POP3, and SMTP traffic. If the embedded AV
scanner detects a virus, it drops the packet and sends a message reporting the virus
to the client initiating the traffic.

NOTE: For more information about antivirus scanning, see “Antivirus Scanning” on
page 173.

Traffic Shaping
You can set parameters for the control and shaping of traffic for each policy.
Table 28 describes the traffic shaping parameters.

Policies Defined  173

 Concepts & Examples ScreenOS Reference Guide

Table 28: Traffic Shaping Parameters

5 fn_bldgblck.fm

Parameter Description
Guaranteed Guaranteed throughput in kilobits per second (kbps). Traffic below this
Bandwidth threshold passes with the highest priority without being subject to any traffic
management or shaping mechanism.
Maximum Secured bandwidth available to the type of connection in kilobits per second
Bandwidth (kbps). Traffic beyond this threshold is throttled and dropped.

Note: It is advised that you do not use rates less than 10 Kbps. Rates below this
threshold lead to dropped packets and excessive retries that defeat the purpose
of traffic management.
Traffic Priority When traffic bandwidth falls between the guaranteed and maximum settings,
the security device passes higher priority traffic first, and lower priority traffic
only if there is no other higher priority traffic. There are eight priority levels.
DiffServ Differentiated Services (DiffServ) is a system for tagging (or “marking”) traffic at
Codepoint a position within a hierarchy of priority. You can map the eight ScreenOS
Marking priority levels to the DiffServ system. By default, the highest priority (priority 0)
in the ScreenOS system maps to the first three bits (111) in the DiffServ field
(see RFC 2474), or the IP precedence field in the TOS byte (see RFC 1349), in
the IP packet header. The lowest priority (priority 7) in ScreenOS maps to (000)
in the TOS DiffServ system. When you enable DSCP, ScreenOS overwrites the
first 3 bits in the ToS byte with the IP precedence priority. When you enable
DSCP and set a dscp-byte value, ScreenOS overwrites the first 6 bits of the ToS
byte with the DSCP value.

Note: Some devices require that you explicitly enable DSCP marking by setting
a system-wide environmental variable. Refer to the installation and
configuration manual for your device to find out if it requires that you explicitly
enable DSCP marking before using it in policies. If your device requires it, use
the following command to enable DSCP marking system wide: set envar
ipsec-dscp-mark=yes. This variable cannot be set using the WebUI. Use the
unset envar ipsec-dscp-mark to disable DSCP marking system wide.

NOTE: For a more detailed discussion of traffic management and shaping, see “Traffic
Shaping” on page 193.

To change the mapping between the ScreenOS priority levels and the DiffServ
system, use the following CLI command:

set traffic-shaping ip_precedence number0 number1 number2 number3 number4

number5 number6 number7

where number0 is the mapping for priority 0 (the highest priority in the TOS
DiffServ system), number1 is the mapping for priority 1, and so on.

To subsume IP precedence into class selector codepoints—that is, to zero out the
second three bits in the DiffServ field and thus insure that priority levels you set
with ip_precedence are preserved and handled correctly by downstream
routers—use the following CLI command:

set traffic-shaping dscp-class-selector

174  Policies Defined

 Chapter 6: Policies

Policies Applied
This section describes the management of policies: viewing, creating, modifying,
ordering and reordering, and removing policies.

Viewing Policies
To view policies through the WebUI, click Policies. You can sort the displayed
policies by source and destination zones by choosing zone names from the From
and To drop-down lists and then clicking Go. In the CLI, use the get policy [ all |
from zone to zone | global | id number ] command.

Creating Policies
To allow traffic to flow between two zones, you create policies to deny, permit,
reject, or tunnel traffic between those zones. You can also create policies to control
traffic within the same zone if the security device is the only network device that
can route the intrazone traffic between the source and destination addresses
referenced in the policy. You can also create global policies, which make use of
source and destination addresses in the Global zone address book.

To allow bidirectional traffic between two zones—for example, between the Trust
and Untrust zones—you need to create a policy that goes from Trust to Untrust, and
then create a second policy from Untrust to Trust. Depending on your needs, the
policies can use the same or different IP addresses, only the source and destination
addresses are reversed.

You can define policies between any zones that are located within the same
system—root or virtual. To define a policy between the root system and a vsys, one
of the zones must be a shared zone. (For information about shared zones in relation
to virtual systems, see Volume 10: Virtual Systems.)

Creating Interzone Policies Mail Service

In this example, you create three policies to control the flow of email traffic.

The first policy allows internal users in the Trust zone to send and retrieve email
from a local mail server in the DMZ zone. This policy permits the services MAIL
(that is, SMTP) and POP3 originating from the internal users to traverse the Juniper
Networks firewall to reach the local mail server.

The second and third policies permit the service MAIL to traverse the firewall
between the local mail server in the DMZ zone and a remote mail server in the
Untrust zone.

However, before creating policies to control traffic between different security zones,
you must first design the environment in which to apply those policies. First, you
first bind interfaces to zones and assign the interfaces IP addresses:

 Bind ethernet0/1 to the Trust zone and assign it IP address 10.1.1.1/24.

 Bind ethernet0/2 to the DMZ zone and assign it IP address 1.2.2.1/24.

 Bind ethernet0/3 to the Untrust zone and assign it IP address 1.1.1.1/24.

Policies Applied  175

 Concepts & Examples ScreenOS Reference Guide

All security zones are in the trust-vr routing domain.

Second, you create addresses for use in the policies:

 Define an address in the Trust zone named “corp_net” and assign it IP address
10.1.1.0/24.

 Define an address in the DMZ zone named “mail_svr” and assign it IP address
1.2.2.5/32.

 Define an address in the Untrust zone named “r-mail_svr” and assign it IP

address 2.2.2.5/32.

Third, you create a service group named “MAIL-POP3” containing the two
predefined services MAIL and POP3.

Fourth, you configure a default route in the trust-vr routing domain pointing to the
external router at 1.1.1.250 through ethernet0/3.

After completing steps 1 through 4, you can then create the policies necessary to
permit the transmission, retrieval, and delivery of email in and out of your
protected network.

WebUI
1. Interfaces
Network > Interfaces > Edit (for ethernet0/1): Enter the following, then click
Apply:

Zone Name: Trust

Static IP: (select this option when present)
IP Address/Netmask: 10.1.1.1/24
Enter the following, then click OK:
Interface Mode: NAT

Network > Interfaces > Edit (for ethernet0/2): Enter the following, then click
OK:

Zone Name: DMZ

Static IP: (select this option when present)
IP Address/Netmask: 1.2.2.1/24

176  Policies Applied

 Chapter 6: Policies

Network > Interfaces > Edit (for ethernet0/3): Enter the following, then click
OK:

Zone Name: Untrust

Static IP: (select this option when present)
IP Address/Netmask: 1.1.1.1/24
2. Addresses
Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: corp_net

IP Address/Domain Name:
IP/Netmask: (select), 10.1.1.0/24
Zone: Trust

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: mail_svr

IP Address/Domain Name:
IP/Netmask: (select), 1.2.2.5/32
Zone: DMZ

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: r-mail_svr

IP Address/Domain Name:
IP/Netmask: (select), 2.2.2.5/32
Zone: Untrust
3. Service Group
Policy > Policy Elements > Services > Groups: Enter the following group
name, move the following services, then click OK:

Group Name: MAIL-POP3

Select MAIL and use the << button to move the service from the Available
Members column to the Group Members column.

Select POP3 and use the << button to move the service from the Available
Members column to the Group Members column.

4. Route
Network > Routing > Destination > trust-vr New: Enter the following, then
click OK:

Network Address/Netmask: 0.0.0.0/0

Gateway: (select)
Interface: ethernet0/3
Gateway IP Address: 1.1.1.250

Policies Applied  177

 Concepts & Examples ScreenOS Reference Guide

5. Policies
Policy > Policies > (From: Trust, To: DMZ) > New: Enter the following, then
click OK:

Source Address:
Address Book Entry: (select), corp_net
Destination Address:
Address Book Entry: (select), mail_svr
Service: Mail-POP3
Action: Permit

Policy > Policies > (From: DMZ, To: Untrust) New: Enter the following, then
click OK:

Source Address:
Address Book Entry: (select), mail_svr
Destination Address:
Address Book Entry: (select), r-mail_svr
Service: MAIL
Action: Permit

Policy > Policies > (From: Untrust, To: DMZ) New: Enter the following, then
click OK:

Source Address:
Address Book Entry: (select), r-mail_svr
Destination Address:
Address Book Entry: (select), mail_svr
Service: MAIL
Action: Permit

CLI
1. Interfaces
set interface ethernet0/1 zone trust
set interface ethernet0/1 ip 10.1.1.1/24
set interface ethernet0/2 zone dmz
set interface ethernet0/2 ip 1.2.2.1/24
set interface ethernet0/3 zone untrust
set interface ethernet0/3 ip 1.1.1.1/24
2. Addresses
set address trust corp_net 10.1.1.0/24
set address dmz mail_svr 1.2.2.5/32
set address untrust r-mail_svr 2.2.2.5/32
3. Service Group
set group service MAIL-POP3
set group service MAIL-POP3 add mail
set group service MAIL-POP3 add pop3
4. Route
set vrouter trust-vr route 0.0.0.0/0 interface ethernet0/3 gateway 1.1.1.250
5. Policies
set policy from trust to dmz corp_net mail_svr MAIL-POP3 permit
set policy from dmz to untrust mail_svr r-mail_svr MAIL permit
set policy from untrust to dmz r-mail_svr mail_svr MAIL permit
save

178  Policies Applied

 Chapter 6: Policies

Creating an Interzone Policy Set

A small software firm, ABC Design, has divided its internal network into two
subnets, and both are in the Trust zone. These two subnets are:

 Engineering (with the defined address “Eng”)

 The rest of the company (with the defined address “Office”)

ABC Design also has a DMZ zone for its web and mail servers.

The following example presents a typical set of policies for the following users:

 “Eng” can use all the services for outbound traffic except FTP-Put, IMAP, MAIL,
and POP3.

 “Office” can use email and access the Internet, provided they authenticate
themselves via WebAuth. (For information about WebAuth user authentication,
see “Authentication Users” on page 9-45.)

 Everyone in the Trust zone can access the Web and mail servers in the DMZ
zone.

 A remote mail server in the Untrust zone can access the local mail server in the
DMZ zone.

 There is also a group of system administrators (with the user-defined address

“sys-admins”) who have complete user and administrative access to the servers
in the DMZ zone.

Policies Applied  179

 Concepts & Examples ScreenOS Reference Guide

Figure 60: Interzone Policy Set

Untrust Zone

Internet
www.abc.com

mail.abc.com

External Router

Security Device

Internal Router
DMZ Zone

Office LAN Eng. LAN

Trust Zone

It is assumed that you have already configured the interfaces, addresses, service
groups, and routes that must be in place. For more information about configuring
these, see “Interfaces” on page 35, “Addresses” on page 103, “Service Groups” on
page 138, and Volume 7: Routing.

Table 29: Configured Policies

From Zone - Src Addr To Zone - Dest Addr Service Action

Trust - Any Untrust - Any Com (service group: FTP-Put, Reject
IMAP, MAIL, POP3)
Trust - Eng Untrust - Any Any Permit
Trust - Office Untrust - Any Internet (service group: Permit (+WebAuth)
FTP-Get, HTTP, HTTPS)
Untrust - Any DMZ - mail.abc.com MAIL Permit
Untrust - Any DMZ - www.abc.com Web (service group: HTTP, Permit
HTTPS)
Trust - Any DMZ - mail.abc.com Email (service group: IMAP, Permit
MAIL, POP3)
Trust - Any DMZ - www.abc.com Internet (service group: Permit
FTP-Get, HTTP, HTTPS)
Trust - sys-admins DMZ - Any Any Permit
DMZ - mail.abc.com Untrust - Any MAIL Permit

NOTE: The default policy is to deny all.

180  Policies Applied

 Chapter 6: Policies

WebUI
1. From Trust to Untrust
Policy > Policies > (From: Trust, To: Untrust) New: Enter the following, then
click OK:

Source Address:
Address Book Entry: (select), Eng
Destination Address:
Address Book Entry: (select), Any
Service: ANY
Action: Permit

Policy > Policies > (From: Trust, To: Untrust) New: Enter the following, then
click OK:

Source Address:
Address Book Entry: (select), Office
Destination Address:
Address Book Entry: (select), Any
Service: Internet
Action: Permit

> Advanced: Enter the following, then click Return to set the advanced
options and return to the basic configuration page:

Authentication: (select)
WebAuth: (select)

NOTE: “Internet” is a service group with the following members: FTP-Get, HTTP, and
HTTPS.

Policy > Policies > (From: Trust, To: Untrust) New: Enter the following, then
click OK:

Source Address:
Address Book Entry: (select), Any
Destination Address:
Address Book Entry: (select), Any
Service: Com
Action: Reject
Position at Top: (select)

NOTE: “Com” is a service group with the following members: FTP-Put, MAIL, IMAP, and
POP3.

For traffic from the Untrust zone to the Trust zone, the default deny policy denies
everything.

Policies Applied  181

 Concepts & Examples ScreenOS Reference Guide

2. From Untrust to DMZ

Policy > Policies > (From: Untrust, To: DMZ) New: Enter the following, then
click OK:

Source Address:
Address Book Entry: (select), Any
Destination Address:
Address Book Entry: (select), mail.abc.com
Service: MAIL
Action: Permit

Policy > Policies > (From: Untrust, To: DMZ) New: Enter the following, then
click OK:

Source Address:
Address Book Entry: (select), Any
Destination Address:
Address Book Entry: (select), www.abc.com
Service: Web
Action: Permit

NOTE: “Web” is a service group with the following members: HTTP and HTTPS.

3. From Trust to DMZ

Policy > Policies > (From: Trust, To: DMZ) New: Enter the following, then click
OK:

Source Address:
Address Book Entry: (select), Any
Destination Address:
Address Book Entry: (select), mail.abc.com
Service: e-mail
Action: Permit

NOTE: “e-mail” is a service group with the following members: MAIL, IMAP, and POP3.

Policy > Policies > (From: Trust, To: DMZ) New: Enter the following, then click
OK:

Source Address:
Address Book Entry: (select), Any
Destination Address:
Address Book Entry: (select), www.abc.com
Service: Internet
Action: Permit

Policy > Policies > (From: Trust, To: DMZ) New: Enter the following, then click
OK:

Source Address:
Address Book Entry: (select), sys-admins
Destination Address:
Address Book Entry: (select), Any
Service: ANY
Action: Permit

182  Policies Applied

 Chapter 6: Policies

4. From DMZ to Untrust

Policy > Policies > (From: DMZ, To: Untrust) New: Enter the following, then
click OK:

Source Address:
Address Book Entry: (select), mail.abc.com
Destination Address:
Address Book Entry: (select), Any
Service: MAIL
Action: Permit

CLI
1. From Trust to Untrust
set policy from trust to untrust eng any any permit
set policy from trust to untrust office any Internet permit webauth
set policy top from trust to untrust any any Com reject

NOTE: “Internet” is a service group with the following members: FTP-Get, HTTP, and
HTTPS.

“Com” is a service group with the following members: FTP-Put, MAIL, IMAP, and
POP3.

2. From Untrust to DMZ

set policy from untrust to dmz any mail.abc.com mail permit
set policy from untrust to dmz any www.abc.com Web permit

NOTE: “Web” is a service group with the following members: HTTP and HTTPS.

3. From Trust to DMZ

set policy from trust to dmz any mail.abc.com e-mail permit
set policy from trust to dmz any www.abc.com Internet permit
set policy from trust to dmz sys-admins any any permit

NOTE: “e-mail” is a service group with the following members: MAIL, IMAP, and POP3.

“Internet” is a service group with the following members: FTP-Get, HTTP, and
HTTPS.

4. From DMZ to Untrust

set policy from dmz to untrust mail.abc.com any mail permit
save

Creating Intrazone Policies

In this example, you create an intrazone policy to permit a group of accountants
access to a confidential server on the corporate LAN in the Trust zone. You first bind
ethernet0/1 to the Trust zone and give it IP address 10.1.1.1/24. You then bind
ethernet0/2 to the Trust zone and assign it IP address 10.1.5.1/24. You enable
intrazone blocking in the Trust zone. Next, you define two addresses—one for a
server on which the company stores its financial records (10.1.1.100/32) and
another for the subnet on which hosts for the accounting department are located
(10.1.5.0/24). You then create an intrazone policy to permit access to the server
from those hosts.

Policies Applied  183

 Concepts & Examples ScreenOS Reference Guide

WebUI
1. Trust Zone—Interfaces and Blocking
Network > Interfaces > Edit (for ethernet0/1): Enter the following, then click
Apply:

Zone Name: Trust

Static IP: (select this option when present)
IP Address/Netmask: 10.1.1.1/24
Select the following, then click OK:
Interface Mode: NAT

Network > Interfaces > Edit (for ethernet0/1): Enter the following, then click
Apply:

Zone Name: Trust

Static IP: (select this option when present)
IP Address/Netmask: 10.1.5.1/24
Select the following, then click OK:
Interface Mode: NAT

Network > Zones > Edit (for Trust): Enter the following, then click OK:

Block Intra-Zone Traffic: (select)

2. Addresses
Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: Hamilton

IP Address/Domain Name:
IP/Netmask: (select), 10.1.1.100/32
Zone: Trust

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: accounting

IP Address/Domain Name:
IP/Netmask: (select), 10.1.5.0/24
Zone: Trust
3. Policy
Policy > Policies > (From: Trust, To: Trust) > New: Enter the following, then
click OK:

Source Address:
Address Book Entry: (select), accounting
Destination Address:
Address Book Entry: (select), Hamilton
Service: ANY
Action: Permit

CLI
1. Trust Zone—Interfaces and Blocking
set interface ethernet0/1 zone trust
set interface ethernet0/1 ip 10.1.1.1/24

184  Policies Applied

 Chapter 6: Policies

set interface ethernet0/1 nat

set interface ethernet0/2 zone trust
set interface ethernet0/2 ip 10.1.5.1/24
set interface ethernet0/2 nat
set zone trust block
2. Addresses
set address trust Hamilton 10.1.1.100/32
set address trust accounting 10.1.5.0/24
3. Policy
set policy from trust to trust accounting Hamilton any permit
save

Creating a Global Policy

In this example, you create a global policy so that every host in every zone can
access the company website, which is www.juniper.net. Using a global policy is a
convenient shortcut when there are many security zones. In this example, one
global policy accomplishes what n interzone policies would have accomplished
(where n = number of zones).

NOTE: To use a domain name instead of an IP address, be sure to have DNS service
configured on the security device.

WebUI
1. Global Address
Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: server1

IP Address/Domain Name:
Domain Name: (select), www.juniper.net
Zone: Global
2. Policy
Policy > Policies > (From: Global, To: Global) > New: Enter the following, then
click OK:

Source Address:
Address Book Entry: (select), Any
Destination Address:
Address Book Entry: (select), server1
Service: HTTP
Action: Permit

CLI
1. Global Address
set address global server1 www.juniper.net
2. Policy
set policy global any server1 http permit
save

Policies Applied  185

 Concepts & Examples ScreenOS Reference Guide

Entering a Policy Context

When configuring a policy through the CLI, after you first create a policy, you can
then enter the context of the policy to make additions and modifications. For
example, perhaps you first create the following policy:

set policy id 1 from trust to untrust host1 server1 HTTP permit attack
HIGH:HTTP:SIGS action close

If you want to make some changes to the policy, such as adding another source or
destination address, another service, or another attack group, you can enter the
context for policy 1 and then enter the pertinent commands:

set policy id 1
device(policy:1)-> set src-address host2
device(policy:1)-> set dst-address server2
device(policy:1)-> set service FTP
device(policy:1)-> set attack CRITICAL:HTTP:SIGS
You can also remove multiple items for a single policy component as long as you do
not remove them all. For example, you can remove server2 from the above
configuration, but not server2 and server1 because then no destination address
would remain.

Multiple Items per Policy Component

ScreenOS allows you to add multiple items to the following components of a policy:

 Source address

 Destination address

 Service

 Attack group

In ScreenOS releases prior to 5.0.0, the only way to have multiple source and
destination addresses or services is to first create an address or service group with
multiple members and then reference that group in a policy. You can still use
address and service groups in policies in ScreenOS 5.0.0. In addition, you can
simply add extra items directly to a policy component.

NOTE: If the first address or service referenced in a policy is “Any,” you cannot logically
add anything else to it. ScreenOS prevents this kind of misconfiguration and
displays an error message should it occur.

186  Policies Applied

 Chapter 6: Policies

To add multiple items to a policy component, do either of the following:

WebUI
To add more addresses and services, click the Multiple button next to the
component to which you want to add more items. To add more attack groups,
click the Attack Protection button. Select an item in the “Available Members”
column, and then use the << key to move it to the “Active Members” column.
You can repeat this action with other items. When finished, click OK to return
to the policy configuration page.

CLI
Enter the policy context with the following command:

set policy id number

Then use one of the following commands as appropriate:

device(policy:number)-> set src-address string

device(policy:number)-> set dst-address string
device(policy:number)-> set service string
device(policy:number)-> set attack string

Setting Address Negation

You can configure a policy so that it applies to all addresses except the one specified
as either the source or destination. For example, you might want to create a policy
that permits Internet access to everyone except the “P-T_contractors” address
group. To accomplish this, you can use the address negation option.

In the WebUI, this option is available on the pop-up that appears when you click
Multiple next to either Source Address or Destination Address on the policy
configuration page.

In the CLI, you insert an exclamation point ( ! ) immediately before source or

destination address.

NOTE: Address negation occurs at the policy component level, applying to all items in the
negated component. However, you cannot enforce address negation with a
wildcard address.

In this example, you create an intrazone policy that allows all addresses in the Trust
zone access to all FTP servers except to an FTP server named “vulcan”, which
engineering uses to post functional specifications for one another.

However, before creating the policy, you must first design the environment in which
to apply it. First, you enable intrazone blocking for the Trust zone. Intrazone
blocking requires a policy lookup before the security device passes traffic between
two interfaces bound to the same zone.

Policies Applied  187

 Concepts & Examples ScreenOS Reference Guide

Second, you bind two interfaces to the Trust zone and assign them IP addresses:

 You bind ethernet0/1 to the Trust zone and assign it IP address 10.1.1.1/24.

 You bind ethernet0/4 to the Trust zone and assign it IP address 10.1.2.1/24.

Third, you create an address (10.1.2.5/32) for the FTP server named “vulcan” in the
Trust zone.

After completing these two steps, you can then create the intrazone policies.

NOTE: You do not have to create a policy for the engineering department to reach their
FTP server because the engineers are also in the 10.1.2.0/24 subnet and do not
have to cross the Juniper Networks firewall to reach their own server.

Figure 61: Intrazone Policies Negation

ethernet0/1 ethernet0/4
10.1.1.1/24 10.1.2.1/24

Internal Switches

10.1.1.0/24 10.1.2.0/24
(Rest of Corporate) (Engineering)

Trust Zone
Intrazone Blocking Enabled FTP Server
“vulcan”
10.1.2.5

WebUI
1. Intrazone Blocking
Network > Zones > Edit (for Trust): Enter the following, then click OK:

Virtual Router Name: trust-vr

Block Intra-Zone Traffic: (select)
2. Trust Zone Interfaces
Network > Interfaces > Edit (for ethernet0/1): Enter the following, then click
Apply:

Zone Name: Trust

Static IP: (select this option when present)
IP Address/Netmask: 10.1.1.1/24
Select the following, then click OK:
Interface Mode: NAT

188  Policies Applied

 Chapter 6: Policies

Network > Interfaces > Edit (for ethernet0/4): Enter the following, then click
Apply:

Zone Name: Trust

Static IP: (select this option when present)
IP Address/Netmask: 10.1.2.1/24
Select the following, then click OK:
Interface Mode: NAT
3. Address
Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: vulcan

IP Address/Domain Name:
IP/Netmask: (select), 10.1.2.5/32
Zone: Trust
4. Policy
Policy > Policies > (From: Trust, To: Trust) New: Enter the following, then click
OK:

Source Address:
Address Book Entry: (select), Any
Destination Address:
Address Book Entry: (select), vulcan

> Click Multiple, select Negate Following, then click OK to return to the
basic policy configuration page.

Service: FTP
Action: Permit

CLI
1. Intrazone Blocking
set zone trust block
2. Trust Zone Interfaces
set interface ethernet0/1 zone trust
set interface ethernet0/1 ip 10.1.1.1/24
set interface ethernet0/1 nat
set interface ethernet0/4 zone trust
set interface ethernet0/4 ip 10.1.2.1/24
set interface ethernet0/1 nat
3. Address
set address trust vulcan 10.1.2.5/32
4. Policy
set policy from trust to trust any !vulcan ftp permit
save

Policies Applied  189

 Concepts & Examples ScreenOS Reference Guide

Modifying and Disabling Policies

After you create a policy, you can always return to it to make modifications. In the
WebUI, click the Edit link in the Configure column for the policy that you want to
change. In the Policy configuration page that appears for that policy, make your
changes, then click OK. In the CLI, use the set policy command.

ScreenOS also provides a means for enabling and disabling policies. By default, a
policy is enabled. To disable it, do the following:

WebUI
Policies: Clear the Enable check box in the Configure column for the policy that
you want to disable.

The row of text for a disabled policy appears as grey.

CLI
set policy id id_num disable
save

NOTE: To enable the policy again, select Enable in the Configure column for the policy
that you want to enable (WebUI), or type unset policy id id_num disable (CLI).

Policy Verification
ScreenOS offers a tool for verifying that the order of policies in the policy list is
valid. It is possible for one policy to eclipse, or “shadow,” another policy. Consider
the following example:

set policy id 1 from trust to untrust any any HTTP permit

set policy id 2 from trust to untrust any dst-A HTTP deny

Because the security device performs a policy lookup starting from the top of the
list, when it finds a match for traffic received, it does not look any lower in the
policy list. In the above example, the security device never reaches policy 2 because
the destination address “any” in policy 1 includes the more specific “dst-A” address
in policy 2. When an HTTP packet arrives at the security device from an address in
the Trust zone bound for dst-A in the Untrust zone, the security device always first
finds a match with policy 1.

To correct the above example, you can simply reverse the order of the policies,
putting the more specific one first:

set policy id 2 from trust to untrust any dst-A HTTP deny

set policy id 1 from trust to untrust any any HTTP permit

Of course, this example is purposefully simple to illustrate the basic concept. In

cases where there are dozens or hundreds of policies, the eclipsing of one policy by
another might not be so easy to spot. To check if there is any policy shadowing in
your policy list, you can use the following CLI command:

exec policy verify

This command reports the shadowing and shadowed policies. It is then the admin’s
responsibility to correct the situation.

190  Policies Applied

 Chapter 6: Policies

NOTE: The concept of policy shadowing refers to the situation where a policy higher in
the policy list always takes effect before a subsequent policy. Because the policy
lookup always uses the first policy it finds that matches the five-part tuple of
source and destination zone, source and destination address, and service type, if
another policy applies to the same tuple (or a subset of the tuple), the policy
lookup uses the first policy in the list and never reaches the second one.

The policy verification tool cannot detect the case where a combination of policies
shadows another policy. In the following example, no single policy shadows
policy 3; however, policies 1 and 2 together do shadow it:

set group address trust grp1 add host1

set group address trust grp1 add host2
set policy id 1 from trust to untrust host1 server1 HTTP permit
set policy id 2 from trust to untrust host2 server1 HTTP permit
set policy id 3 from trust to untrust grp1 server1 HTTP deny

Reordering Policies
The security device checks all attempts to traverse the firewall against policies,
beginning with the first one listed in the policy set for the appropriate list (see
“Policy Set Lists” on page 163) and moving through the list. Because the security
device applies the action specified in the policy to the first matching policy in the
list, you must arrange them from the most specific to the most general. (Whereas a
specific policy does not preclude the application of a more general policy located
down the list, a general policy appearing before a specific one does.)

By default, a newly created policy appears at the bottom of a policy set list. There is
an option that allows you to position a policy at the top of the list instead. In the
Policy configuration page in the WebUI, select Position at Top. In the CLI, add the
key word top to the set policy command: set policy top …

To move a policy to a different position in the list, do either of the following:

WebUI
There are two ways to reorder policies in the WebUI: by clicking the circular
arrows or by clicking the single arrow in the Configure column for the policy
you want to move.

If you click the circular arrows:

A User Prompt dialog box appears.

To move the policy to the very end of the list, enter <-1>. To move it up in
the list, enter the ID number of the policy above which you want to move
the policy in question.

Click OK to execute the move.

Policies Applied  191

 Concepts & Examples ScreenOS Reference Guide

If you click the single arrow:

A Policy Move page appears displaying the policy you want to move and a
table displaying the other policies.

In the table displaying the other policies, the first column, Move Location,
contains arrows pointing to various locations where you can move the
policy. Click the arrow that points to the location in the list where you want
to move the policy.

The Policy List page reappears with the policy you moved in its new position.

CLI
set policy move id_num { before | after } number
save

Removing a Policy
In addition to modifying and repositioning a policy, you can also delete it. In the
WebUI, click Remove in the Configure column for the policy that you want to
remove. When the system message prompts for confirmation to proceed with the
removal, click Yes. In the CLI, use the unset policy id_num command.1

192  Policies Applied

Chapter 7
Traffic Shaping

This chapter discusses the various ways you can use your Juniper Networks security
device to manage limited bandwidth without compromising quality and availability
of the network to all of your users. It contains the following sections:

 “Managing Bandwidth at the Policy Level” on page 2-193

 “Setting Traffic Shaping” on page 2-194

 “Setting Service Priorities” on page 2-197

 “Setting Priority Queuing” on page 2-199

 “Ingress Policing” on page 2-203

 “Shaping Traffic on Virtual Interfaces” on page 2-203

 “DSCP Marking and Shaping” on page 2-214

Traffic shaping is the allocation of the appropriate amount of network bandwidth to

every user and application on an interface. The appropriate amount of bandwidth is
defined as cost-effective carrying capacity at a guaranteed Quality of Service (QoS).
You use a security device to shape traffic by creating policies and by applying
appropriate rate controls to each class of traffic going through the device.

Managing Bandwidth at the Policy Level

To classify traffic, you create policies and specify the amount of guaranteed
bandwidth and maximum bandwidth, and the priority for each class of traffic.
Guaranteed bandwidth and maximum bandwidth are not strictly policy-based. With
multiple physical interfaces in the egress zone, bandwidth is based both on policy
and on total available egress physical interface bandwidth. The physical bandwidth
of every interface is allocated to the guaranteed bandwidth parameter for all
traffic-shaping policies. If there is any bandwidth left over, it is sharable by any
other traffic. In other words, each policy gets its guaranteed bandwidth and shares
whatever is left over, according to its priority (up to the limit of its maximum
bandwidth specification), with all other policies.

Managing Bandwidth at the Policy Level  193

 Concepts & Examples ScreenOS Reference Guide

The traffic-shaping function applies to traffic from all policies. If you turn off traffic
shaping for a specific policy, while traffic shaping is still turned on for other policies,
the system applies a default traffic-shaping policy to that particular policy, with the
following parameters:

 Guaranteed bandwidth 0

 Unlimited maximum bandwidth

 Priority of 7 (the lowest priority setting)

NOTE: You can enable mapping of priority levels to the Differentiated Services codepoint
(DSCP) marking system. For more information about DSCP marking, see “Traffic
Shaping” on page 173.

You can turn off traffic shaping system wide using the set traffic-shaping mode off
command. Use the set traffic-shaping mode on command to turn on shaping on
an interface. You can set traffic shaping to automatic in the WebUI: Configuration
> Advanced > Traffic Shaping. In automatic mode, if traffic shaping in enabled
on the policy, the device turns on traffic shaping when traffic hits the device and
turns off traffic shaping when no traffic hits the device.

NOTE: You cannot perform traffic-shaping on ASIC-based ISG1000, ISG2000, and NS5000
devices. ScreenOS supports traffic-shaping on non-ASIC devices.

Setting Traffic Shaping

In this example, you partition 45Mbps of bandwidth on a T3 interface among three
departments on the same subnet. The interface ethernet0/1 is bound to the Trust
zone, and ethernet0/3 is bound to the Untrust zone.

Figure 62: Traffic Shaping

Trust Zone Untrust Zone

T3–45 Mbps
Marketing: 10 Mbps In, 10 Mbps Out

Internet
Router Router
Sales: 5 Mbps In, 10 Mbps Out

DMZ for
Servers DMZ Zone
Support: 5 Mbps In, 5 Mbps Out

194  Setting Traffic Shaping

 Chapter 7: Traffic Shaping

WebUI
1. Bandwidth on Interfaces
Network > Interfaces > Edit (for ethernet0/1): Enter the following, then click
OK:

Traffic Bandwidth: 45000

NOTE: If you do not specify bandwidth settings on an interface, the security device uses
the available physical bandwidth.

Network > Interfaces > Edit (for ethernet0/3): Enter the following, then click
OK:

Traffic Bandwidth: 45000

2. Bandwidth in Policies
Policy > Policies > (From: Trust, To: Untrust) New: Enter the following, then
click OK:

Name: Marketing Traffic Shaping

Source Address:
Address Book Entry: (select), Marketing
Destination Address:
Address Book Entry: (select), Any
Service: Any
Action: Permit
VPN Tunnel: None

NOTE: You can also enable traffic shaping in policies referencing VPN tunnels.

> Advanced: Enter the following, then click Return to set the advanced
options and return to the basic configuration page:

Traffic Shaping: (select)

Guaranteed Bandwidth: 10000
Maximum Bandwidth: 15000

Policy > Policies > (From: Trust, To: Untrust) New: Enter the following, then
click OK:

Name: Sales Traffic Shaping Policy

Source Address:
Address Book Entry: (select), Sales
Destination Address:
Address Book Entry: (select), Any
Service: Any
Action: Permit

> Advanced: Enter the following, then click Return to set the advanced
options and return to the basic configuration page:

Traffic Shaping: (select)

Guaranteed Bandwidth: 10000
Maximum Bandwidth: 10000

Setting Traffic Shaping  195

 Concepts & Examples ScreenOS Reference Guide

Policy > Policies > (From: Trust, To: Untrust) New: Enter the following, then
click OK:

Name: Support Traffic Shaping Policy

Source Address:
Address Book Entry: (select), Support
Destination Address:
Address Book Entry: (select), Any
Service: Any
Action: Permit

> Advanced: Enter the following, then click Return to set the advanced
options and return to the basic configuration page:

Traffic Shaping: (select)

Guaranteed Bandwidth: 5000
Maximum Bandwidth: 10000

Policy > Policies > (From: Untrust, To: Trust) New: Enter the following, then
click OK:

Name: Allow Incoming Access to Marketing

Source Address:
Address Book Entry: (select), Any
Destination Address:
Address Book Entry: (select), Marketing
Service: Any
Action: Permit

> Advanced: Enter the following, then click Return to set the advanced
options and return to the basic configuration page:

Traffic Shaping: (select)

Guaranteed Bandwidth: 10000
Maximum Bandwidth: 10000

Policy > Policies > (From: Untrust, To: Trust) New: Enter the following, then
click OK:

Name: Allow Incoming Access to Sales

Source Address:
Address Book Entry: (select), Any
Destination Address:
Address Book Entry: (select), Sales
Service: Any
Action: Permit

> Advanced: Enter the following, then click Return to set the advanced
options and return to the basic configuration page:

Traffic Shaping: (select)

Guaranteed Bandwidth: 5000
Maximum Bandwidth: 10000

Policy > Policies > (From: Untrust, To: Trust) New: Enter the following, then
click OK:

Name: Allow Incoming Access to Support

196  Setting Traffic Shaping

 Chapter 7: Traffic Shaping

Source Address:
Address Book Entry: (select), Any
Destination Address:
Address Book Entry: (select), Support
Service: Any
Action: Permit

> Advanced: Enter the following, then click Return to set the advanced
options and return to the basic configuration page:

Traffic Shaping: (select)

Guaranteed Bandwidth: 5000
Maximum Bandwidth: 5000

CLI
To enable traffic shaping by policy, do the following:

1. Bandwidth on Interfaces
set interface ethernet0/1 bandwidth 45000
set interface ethernet0/3 bandwidth 45000

NOTE: If you do not specify bandwidth settings on an interface, the security device uses
the available physical bandwidth.

2. Bandwidth in Policies
set policy name “Marketing Traffic Shaping” from trust to untrust marketing any
any permit traffic gbw 10000 priority 0 mbw 15000
set policy name “Sales Traffic Shaping Policy” from trust to untrust sales any any
permit traffic gbw 10000 priority 0 mbw 10000
set policy name “Support Traffic Shaping Policy” from trust to untrust support any
any permit traffic gbw 5000 priority 0 mbw 10000
set policy name “Allow Incoming Access to Marketing” from untrust to trust any
marketing any permit traffic gbw 10000 priority 0 mbw 10000
set policy name “Allow Incoming Access to Sales” from untrust to trust any sales
any permit traffic gbw 5000 priority 0 mbw 10000
set policy name “Allow Incoming Access to Support” from untrust to trust any
support any permit traffic gbw 5000 priority 0 mbw 5000
save

Setting Service Priorities

The traffic-shaping feature on Juniper Networks security devices allows you to
perform priority queuing on the bandwidth that is not allocated to guaranteed
bandwidth, or unused guaranteed bandwidth. Priority queuing is a feature that
allows all your users and applications to have access to available bandwidth as they
need it, while ensuring that important traffic can get through, if necessary at the
expense of less important traffic. Queuing allows the security device to buffer traffic
in up to eight different priority queues. These eight queues are:

 High priority

 2nd priority

 3rd priority

Setting Service Priorities  197

 Concepts & Examples ScreenOS Reference Guide

 4th priority

 5th priority

 6th priority

 7th priority

 Low priority (default)

The priority setting for a policy means that the bandwidth not already guaranteed
to other policies is queued on the basis of high priority first and low priority last.
Policies with the same priority setting compete for bandwidth in a round robin
fashion. The security device processes all of the traffic from all of the policies with
high priority before processing any traffic from policies with the next lower priority
setting, and so on, until all traffic requests have been processed. If traffic requests
exceed available bandwidth, the lowest priority traffic is dropped.

CAUTION: Be careful not to allocate more bandwidth than the interface can
support. The policy configuration process does not prevent you from creating
unsupported policy configurations. You can lose data if the guaranteed bandwidth
on contending policies surpasses the traffic bandwidth set on the interface.

If you do not allocate any guaranteed bandwidth, then you can use priority queuing
to manage all of traffic on your network. That is, all high priority traffic is sent
before any 2nd priority traffic is sent, and so on. The security device processes low
priority traffic only after all other traffic has been processed.

198  Setting Service Priorities

 Chapter 7: Traffic Shaping

Setting Priority Queuing

In this example, you configure the guaranteed and maximum bandwidth (in Mbps)
for three departments—Support, Sales, and Marketing—as shown in Table 30.

Table 30: Maximum Bandwidth Configuration

Outbound Inbound Combined

Guaranteed Guaranteed Guaranteed Priority
Support 5 5 10 High
Sales 2.5 3.5 6 2
Marketing 2.5 1.5 4 3
Total 10 10 20

If all three departments send and receive traffic concurrently through the firewall,
the security device must allocate 20 Mbps of bandwidth to fulfill the guaranteed
policy requirements. The interface ethernet0/1 is bound to the Trust zone, and
ethernet0/3 is bound to the Untrust zone.

Figure 63: Priority Queuing

Trust Zone Untrust Zone

T3–45 Mbps
Support: 5Mbps Out, 5Mbps In, High Priority

Internet
Router Router
Sales: 2.5 Mbps Out, 3.5 Mbps In, 2nd Priority

DMZ for
Servers DMZ Zone
Marketing: 2.5 Mbps Out, 1.5 Mbps In, 3rd Priority

WebUI
1. Bandwidth on Interfaces
Interfaces > Edit (for ethernet0/1): Enter the following, then click OK:

Traffic Bandwidth: 40000

Interfaces > Edit (for ethernet0/3): Enter the following, then click OK:

Traffic Bandwidth: 40000

Setting Priority Queuing  199

 Concepts & Examples ScreenOS Reference Guide

2. Bandwidth in Policies
Policy > Policies > (From: Trust, To: Untrust) New: Enter the following, then
click OK:

Name: Sup-out
Source Address:
Address Book Entry: (select), Support
Destination Address:
Address Book Entry: (select), Any
Service: Any
Action: Permit

> Advanced: Enter the following, then click Return to set the advanced
options and return to the basic configuration page:

Traffic Shaping: (select)

Guaranteed Bandwidth: 5000
Maximum Bandwidth: 40000
Traffic Priority: High priority
DiffServ Codepoint Marking: (select)

NOTE: Differentiated Services (DS) is a system for tagging (or “marking”) traffic at a
position within a hierarchy of priority. DSCP marking maps the ScreenOS priority
level of the policy to the first three bits of codepoint in the DS field in the IP packet
header. For more information about DSCP marking, see “Traffic Shaping” on
page 173.

Policy > Policies > (From: Trust, To: Untrust) New: Enter the following, then
click OK:

Name: Sal-out
Source Address:
Address Book Entry: (select), Sales
Destination Address:
Address Book Entry: (select), Any
Service: Any
Action: Permit

> Advanced: Enter the following, then click Return to set the advanced
options and return to the basic configuration page:

Traffic Shaping: (select)

Guaranteed Bandwidth: 2500
Maximum Bandwidth: 40000
Traffic Priority: 2nd priority
DiffServ Codepoint Marking: Enable

200  Setting Priority Queuing

 Chapter 7: Traffic Shaping

Policy > Policies > (From: Trust, To: Untrust) New: Enter the following, then
click OK:

Name: Mar-out
Source Address:
Address Book Entry: (select), Marketing
Destination Address:
Address Book Entry: (select), Any
Service: Any
Action: Permit

> Advanced: Enter the following, then click Return to set the advanced
options and return to the basic configuration page:

Traffic Shaping: (select)

Guaranteed Bandwidth: 2500
Maximum Bandwidth: 40000
Traffic Priority: 3rd priority
DiffServ Codepoint Marking: (select)

Policy > Policies > (From: Untrust, To: Trust) New: Enter the following, then
click OK:

Name: Sup-in
Source Address:
Address Book Entry: (select), Any
Destination Address:
Address Book Entry: (select), Support
Service: Any
Action: Permit

> Advanced: Enter the following, then click Return to set the advanced
options and return to the basic configuration page:

Traffic Shaping: (select)

Guaranteed Bandwidth: 5000
Maximum Bandwidth: 40000
Traffic Priority: High priority
DiffServ Codepoint Marking: (select)

Policy > Policies > (From: Untrust, To: Trust) New: Enter the following, then
click OK:

Name: Sal-in
Source Address:
Address Book Entry: (select), Any
Destination Address:
Address Book Entry: (select), Sales
Service: Any
Action: Permit

Setting Priority Queuing  201

 Concepts & Examples ScreenOS Reference Guide

> Advanced: Enter the following, then click Return to set the advanced
options and return to the basic configuration page:

Traffic Shaping: (select)

Guaranteed Bandwidth: 3500
Maximum Bandwidth: 40000
Traffic Priority: 2nd priority
DiffServ Codepoint Marking: (select)

Policy > Policies > (From: Untrust, To: Trust) New: Enter the following, then
click OK:

Name: Mar-in
Source Address:
Address Book Entry: (select), Any
Destination Address:
Address Book Entry: (select), Marketing
Service: Any
Action: Permit

> Advanced: Enter the following, then click Return to set the advanced
options and return to the basic configuration page:

Traffic Shaping: (select)

Guaranteed Bandwidth: 1500
Maximum Bandwidth: 40000
Traffic Priority: 3rd priority
DiffServ Codepoint Marking: (select)

CLI
1. Bandwidth on Interfaces
set interface ethernet0/1 bandwidth 40000
set interface ethernet0/3 bandwidth 40000
2. Bandwidth in Policies
set policy name sup-out from trust to untrust support any any permit traffic gbw
5000 priority 0 mbw 40000 enable
set policy name sal-out from trust to untrust sales any any permit traffic gbw 2500
priority 2 mbw 40000 dscp enable

NOTE: Some devices require that you explicitly enable DSCP marking by setting a
system-wide environmental variable. Refer to the installation and configuration
manual for your device to find out if it requires that you explicitly enable DSCP
marking before using it in policies. If your device requires it, use the following
command to enable DSCP marking system wide: set envar
ipsec-dscp-mark=yes. This variable cannot be set using the WebUI. Use the
unset envar ipsec-dscp-mark to disable DSCP marking system wide.

set policy name mar-out from trust to untrust marketing any any permit traffic gbw
2500 priority 3 mbw 40000 dscp enable
set policy name sup-in from untrust to trust any support any permit traffic gbw
5000 priority 0 mbw 40000 dscp enable
set policy name sal-in from untrust to trust any sales any permit traffic gbw 3500
priority 2 mbw 40000 dscp enable
set policy name mar-in from untrust to trust any marketing any permit traffic gbw
1500 priority 3 mbw 40000 dscp enable
save

202  Setting Priority Queuing

 Chapter 7: Traffic Shaping

Ingress Policing
Ingress policing is traffic control at the ingress side of the security device. By
constraining the flow of traffic at the point of ingress, traffic exceeding your
bandwidth setting is dropped with minimal processing, conserving system
resources. You can configure ingress policing at the interface level and in security
policies.

You configure ingress policing on an interface by setting a maximum bandwidth

(the mbw keyword). The following command, for example, limits bandwidth on
ethernet0/1, the ingress interface, to 22 Mbps:

set interface ethernet0/1 bandwidth ingress mbw 22000

Incoming traffic on ethernet0/1 exceeding this bandwidth is dropped. If you set

traffic shaping at the interface, you must also set traffic-shaping mode to on (set
traffic-shaping mode on).

To apply ingress policing to a specific application, however, requires a policy. The

following command creates a policy called my_ftp that limits FTP bandwidth on the
ingress side of the security device to 10 Mbps:

set policy my_ftp from untrust to trust any any ftp permit traffic pbw 10000

Incoming FTP traffic exceeding the configured policing bandwidth (the pbw
keyword) is dropped. You can also set mbw in the policy, but at the policy level
mbw applies only to the egress side of traffic flow—traffic exceeding your
configured rate is still processed, and is dropped only at the egress side (see
Figure 65, “Traffic-Shaping Packet Flow” on page 206). You can configure mbw or
pbw in a policy, but not both.

Configuration and enforcement of ingress policing on virtual interfaces is the same

as on physical interfaces, with the one exception that you can also configure
guaranteed bandwidth (the gbw keyword) on virtual interfaces (see Policy-Level
Traffic Shaping on page 205). On physical interfaces, guaranteed bandwidth is the
same as maximum bandwidth.

NOTE: Ingress policing on tunnel interfaces is enforced after the encrypted packets are
decrypted by the VPN engine.

Shaping Traffic on Virtual Interfaces

In the context of traffic shaping, the term virtual interfaces refers only to
subinterfaces and tunnel interfaces—not to other types of virtual interfaces, such as
virtual security interfaces (VSI), or aggregate or redundant interfaces. You cannot
configure shaping parameters in policies created in a vsys. Similarly, bandwidth
cannot be shaped on interfaces owned (inherited) by a user-created vsys. See
Volume 10: Virtual Systems for more information.

Traffic shaping (as distinct from ingress policing) concerns traffic management at
the egress side of the security device. As with physical interfaces, you shape traffic
on virtual interfaces by setting bandwidth values at the interface level, and in
policies.

Ingress Policing  203

 Concepts & Examples ScreenOS Reference Guide

Interface-Level Traffic Shaping

Traffic shaping at the interface level is control of the minimum and maximum rate
of traffic flow on a specific interface. You control minimum bandwidth by specifying
a guaranteed bandwidth (gbw). This means that no matter what else happens on
the device, this minimum rate is guaranteed to the appropriate traffic. The
maximum bandwidth (mbw) you set establishes the rate traffic can never exceed.
By default, guaranteed bandwidth on a physical interface is the carrying capacity of
the interface; therefore, you cannot set guaranteed bandwidth on the physical
interface.

In the context of traffic shaping, the term virtual interfaces refers to subinterfaces
bound to physical interfaces and, by extension, tunnel interfaces bound to those
subinterfaces—creating a hierarchy of interfaces. A subinterface bound to a physical
interface is said to be the child of the physical interface, its parent. Accordingly, a
tunnel interface bound to a subinterface is the child of that subinterface, the
physical interface being its grandparent. Figure 64 illustrates these dependencies.

Figure 64: Interface Hierarchy

ethernet0/1
mbw 10000

ethernet0/1.1 ethernet0/1.2
gbw 5000 - mbw 7000 gbw 2000 - mbw 5000
Virtual Interfaces

Tunnel.1 Tunnel.2 Tunnel.3 Tunnel.4

Tunnel.1 Tunnel.2
gbw 2000 - mbw 3000 gbw 2000 - mbw 3000

When working with virtual interfaces, bear in mind the following rules of interface
hierarchy:

 Guaranteed bandwidth allocated to subinterfaces cannot be greater than the

carrying capacity of the physical interface they are bound to. In Figure 64, for
example, the combined gbw of ethernet0/1.1 and ethernet0/1.2 is 7000 Kbps,
3000 Kbps below the mbw of ethernet0/1. Note, however, that the combined
maximum bandwidth of these two subinterfaces exceeds the carrying capacity
of the physical interface they are bound to by 2000 Kbps. This is acceptable
because the mbw keyword is used only to limit traffic to a maximum rate. If
traffic falls below a maximum setting on a subinterface, that bandwidth is
available to any other subinterface bound to the same physical interface.

 Guaranteed bandwidth allocated to tunnel interfaces cannot be greater than the

guaranteed bandwidth of the subinterface they are bound to.

 If guaranteed bandwidth is not configured for the immediate parent,

bandwidth is taken from the grandparent interface.

 Total guaranteed bandwidth of children cannot exceed parent guaranteed

bandwidth.

204  Shaping Traffic on Virtual Interfaces

 Chapter 7: Traffic Shaping

 Child maximum bandwidth cannot exceed parent maximum bandwidth.

As already stated, you cannot configure guaranteed bandwidth on physical

interfaces because guaranteed bandwidth is the same as maximum bandwidth,
which is the link speed of the interface. On virtual interfaces, however, you can
configure egress gbw and mbw. You can also configure ingress mbw, which is
ingress policing at the interface level. The following command guarantees a
minimum out-going bit rate of 1000 Kbps on ethernet0/4.1, and a maximum rate,
both incoming and outgoing, of 2000 Kbps:

set interface ethernet0/4.1 bandwidth egress gbw 1000 mbw 2000 ingress mbw
2000

You set bandwidth in the WebUI on the Network > Interfaces > Edit page.

After setting bandwidth, you use the get traffic-shaping interface command to see
the actual bandwidth flowing through the security device. For example, you might
have traffic entering on ethernet0/1 and exiting on ethernet0/3. If you set ingress
bandwidth on ethernet0/1, the command get traffic-shaping interface
ethernet0/3 will show actual throughput on the device.

If you set traffic shaping at the interface, you must also set traffic-shaping mode to
on (set traffic-shaping mode on).

Policy-Level Traffic Shaping

You shape traffic at the policy level to allocate bandwidth for particular types of
traffic. The following command guarantees a minimum 1Mbps bandwidth to FTP
traffic, and drops any traffic exceeding 2 Mbps:

set policy from trust to untrust any any ftp permit traffic gbw 1000 pbw 2000
Note that this command uses the policing bandwidth (pbw) keyword. You can use
pbw or mbw in a policy, but not both. The advantage to using pbw is that traffic is
dropped at the ingress side of the security device, reducing throughput processing
and conserving system resources. (See “Ingress Policing” on page 2-203.)

In the WebUI, after creating a policy, click the Advanced button to configure
traffic-shaping parameters.

Although you must set traffic-shaping mode to on to shape traffic on interfaces, it is

not necessary to turn on traffic shaping when shaping traffic in policies. This is
because traffic-shaping mode is set to auto by default. When a session becomes
active and policy lookup discovers traffic shaping, ScreenOS turns on traffic shaping
for that session.

Shaping Traffic on Virtual Interfaces  205

 Concepts & Examples ScreenOS Reference Guide

Packet Flow
Figure 65 illustrates the part of the packet flow through the security device that is
affected by traffic shaping and policing. (See “Packet-Flow Sequence” on page 2-10
for a complete picture of packet flow.) Packets exceeding pbw (or mbw configured
at the interface) are dropped at step 9; shaping and DSCP marking occur at step 10,
and packets exceeding mbw (configured in a policy) are dropped at step 11.

Figure 65: Traffic-Shaping Packet Flow

Incoming
Packet 8 9 10 11

Create Policing Scheduler

Session (if enabled)

Session Table
d 977 vsys id 0, flag 000040/00, Ingress Interface Shape and DSCP mark Proceed through all egress
pid -1, did 0, time 180 the packet, then queue it interfaces on the device and
13 (01) 10.10.10.1/1168 -> or
at the egress interface transmit packets in the queue
211.68.1.2/80, 6, 002be0c0066b,
Policy
subif 0, tun 0

Example: Route-Based VPN with Ingress Policing

This example illustrates how to enforce ingress policing at the interface level for
encrypted traffic. Ingress policing is configured on both the subinterface
(ethernet0/2.1, maximum bandwidth:1200 Kbps) and the tunnel interface
(tunnel.1, maximum bandwidth:1000 Kbps). You set the policing rate on the
subinterface higher than on the tunnel interface bound to it to allow for the
overhead of encryption (assuming, in this example, that all traffic received on the
subinterface is meant for the tunnel interface). Policing on the subinterface is
applied to the encrypted packets, while policing on the tunnel interface is applied to
the decrypted inner packets. All encrypted traffic over 1200 Kbps on ethernet0/2.1
is dropped. And all decrypted (clear text) traffic over 1000 Kbps. on the tunnel.1
interface is dropped.

Figure 66: Route-Based VPN

San Francisco New York

Device1 ethernet0/2 ethernet0/2 Device2
ethernet2.1, ethernet0/2.1,
2.2.2.1/24 2.2.2.2/24
ethernet0/1, ethernet0/1,
10.1.1.1/24 Subinterfaces 10.2.0.2/24

tunnel.1 Tunnel Interfaces tunnel.1

Clients

Server

Trust Zone Trust Zone

206  Shaping Traffic on Virtual Interfaces

 Chapter 7: Traffic Shaping

WebUI (Configuration for Device1)

1. Interfaces
Network > Interfaces > Edit (for ethernet0/1): Enter the following, then click
OK:

IP Address/Netmask: 10.1.1.1/24
Zone: Trust

Network > Interfaces > Sub-IF > New: Enter the following, then click Apply:

Interface Name: (Select) ethernet0/2 and enter: 1

Zone: Untrust
IP Address/Netmask: 2.2.2.1/24
VLAN Tag: 128

Network > Interfaces > New Tunnel IF: Enter the following, then click Apply:

Tunnel Interface Name: 1

Zone: Untrust
Unnumbered (select) ethernet0/2.1
Interface: ethernet0/2.1
2. Route
Network > Routing > Destination > trust-vr New: Enter the following, then
click OK:

Network Address/Netmask: 10.2.0.0/24

Interface (select): Tunnel.1
3. IKE
VPNs > AutoKey Advanced > Gateway > New: Enter the following, then click
OK:

Gateway Name: device1_ike

Security Level: Standard
Remote Gateway Type:
Static IP Address: (select), IP Address/Hostname: 2.2.2.2
Preshared Key

Preshared Key: secret

Outgoing Interface: ethernet0/2.1

VPNs > AutoKey IKE New: Enter the following, then click OK:

VPN Name: device1_vpn

Gateway Name: device1_ike

> Advanced: Enter the following advanced settings, then click Return to
return to the basic AutoKey IKE configuration page:

Bind to: (Select) Tunnel Interface, (Select) tunnel.1

Shaping Traffic on Virtual Interfaces  207

 Concepts & Examples ScreenOS Reference Guide

CLI (Configuration for the Device1)

1. Interfaces
set interface ethernet0/1 zone trust
set interface ethernet0/1 ip 10.1.1.1/24
set interface ethernet0/2.1 tag 128 zone untrust
set interface tunnel.1 zone trust
set interface ethernet0/2.1 ip 2.2.2.1/24
set interface tunnel.1 ip unnumbered interface ethernet0/2.1
set route 10.2.0.0/24 int tunnel.1
2. IKE
set ike gateway device1_ike address 2.2.2.2 outgoing-interface ethernet0/2.1
preshare sec-level standard
set vpn device1_vpn gateway 208a_ike sec-level standard
set vpn device1_vpn bind interface tunnel.1
save

WebUI (Configuration for Device2)

1. Interfaces
Network > Interfaces > Edit (for ethernet0/1): Enter the following, then click
OK:

IP Address/Netmask: 10.2.0.2/24
Zone: Trust

Network > Interfaces > Sub-IF > New: Enter the following, then click Apply:

Interface Name: (Select) ethernet0/2 and enter: 1

Zone: Untrust
IP Address/Netmask: 2.2.2.2/24
VLAN Tag: 128

Network > Interfaces > Tunnel IF > New: Enter the following, then click
Apply:

Tunnel Interface Name: 1

Unnumbered: (select) ethernet0/2.1
Interface: ethernet0/2.1
2. Bandwidth on Interfaces
Network > Interfaces > Edit (for ethernet0/2.1): Enter the following, then click
OK:

Traffic Bandwidth, Ingress: 1200

Network > Interfaces > Edit (for tunnel.1): Enter the following, then click OK:

Traffic Bandwidth, Ingress: 1000

3. Route
Network > Routing > Destination > trust-vr New: Enter the following, then
click OK:

Network Address/Netmask: 10.1.1.0/24

Interface (select): Tunnel.1

208  Shaping Traffic on Virtual Interfaces

 Chapter 7: Traffic Shaping

4. IKE
VPNs > AutoKey Advanced > Gateway > New: Enter the following, then click
OK:

Gateway Name: device2_ike

Security Level: Standard
Remote Gateway Type:
Static IP Address: (select), IP Address/Hostname: 2.2.2.2
Preshared Key
Preshared Key: secret
Outgoing Interface: ethernet0/2.1

VPNs > AutoKey IKE New: Enter the following, then click OK:

VPN Name: device2_vpn

Gateway Name: device2_ike

> Advanced: Enter the following advanced settings, then click Return to
return to the basic AutoKey IKE configuration page:

Bind to: (Select) Tunnel Interface, (Select) tunnel.1

5. Policies
Policy > Policies > (From: Trust, To: Untrust) New: Enter the following, then
click OK:

Service: Any
Action: Permit

Policy > Policies > (From: Untrust, To: Trust) New: Enter the following, then
click OK:

Service: Any
Action: Permit

CLI (Configuration for the Device2)

1. Interfaces
set interface ethernet0/1 zone trust
set interface ethernet0/1 ip 10.2.0.2/24
set interface ethernet0/2.1 tag 128 zone untrust
set interface ethernet0/2.1 ip 2.2.2.2/24
set interface tunnel.1 zone untrust
set interface tunnel.1 ip unnumbered interface ethernet0/2.1
set route 10.1.1.0/24
2. Bandwidth on interfaces
set interface ethernet0/2.1 bandwidth ingress mbw 1200
set interface tunnel.1 bandwidth ingress mbw 1000
3. IKE
set ike gateway device2_ike address 2.2.2.1 preshare secret sec-level standard
set vpn device2_vpn gateway 208b_ike sec-level standard
set vpn device2_vpn bind interface tunnel.1

Shaping Traffic on Virtual Interfaces  209

 Concepts & Examples ScreenOS Reference Guide

4. Policy
set policy from trust to untrust any any any permit
set policy from untrust to trust any any any permit
save

Example: Policy-Based VPN with Ingress Policing

This example illustrates how to enforce ingress policing at both the interface level
and in policies. On the ethernet0/1 interface on Device1, you set the ingress
maximum bandwidth at 20000 Kbps. With this setting, all traffic over 20000 Kbps
from clients connected to Device1 on the ethernet0/1 interface, is dropped. Ingress
policing at the interface applies to all the traffic that arrives on that interface. For
finer granularity, you can apply ingress policing at the policy level. In this example,
you create policies to restrict all ingress FTP protocol traffic on Device1 by creating
policies between the trust and untrust zones, and set the policing bandwidth to
5000 Kbps. All FTP traffic over 5000 Kbps from the trust zone to the untrust zone is
dropped.

Figure 67: Policy-Based VPN

San Francisco New York

Device1 Device2

ethernet0/2, ethernet0/2,
ethernet0/1, 2.1.1.1 10.2.2.1 ethernet0/1,
10.1.1.1.1 1.1.1.2

Clients

Server

Trust Zone Trust Zone

WebUI (Configuration for Device1)

1. Interfaces
Network > Interfaces > Edit (for ethernet0/1): Enter the following, then click
OK:

IP Address/Netmask: 10.1.1.1/24
Zone: Trust
Interface mode: (select) NAT

Network > Interfaces > Edit (for ethernet0/2): Enter the following, then click
OK:

IP Address/Netmask: 2.1.1.1/24
Zone: Untrust
Interface mode: (select) Route

210  Shaping Traffic on Virtual Interfaces

 Chapter 7: Traffic Shaping

2. IKE VPN
VPNs > AutoKey Advanced > Gateway > New: Enter the following, then click
OK:

Gateway Name: device2_ike

Security Level: Standard
Remote Gateway Type:
Static IP Address: (select), IP Address/Hostname: 2.2.2.2

Preshared Key

Preshared Key: secret

Outgoing Interface: ethernet0/2

> Advanced: Enter the following advanced settings, then click OK to return
to basic Gateway configuration page:

Phase 1 Proposal: pre-g2-3des-sha

VPNs > AutoKey IKE New: Enter the following, then click OK:

VPN Name: device2_vpn

Gateway Name: device2_ike
3. Interface-Based Policing
Network > Interfaces > Edit (for ethernet0/1): Enter the following, then click
OK:

Traffic Bandwidth, Ingress: 20000

4. Routing
Network > Routing > Destination > New: Enter the following, then click OK:

Network IP Address/Netmask: 10.2.1.0/24

Interface: (select), ethernet0/2
Gateway IP Address: 2.2.2.2
5. Policies
Policy > Policies > (From: Trust, To: Untrust) New: Enter the following, then
click OK:

Name: 1
Service: FTP
Action: Tunnel
Tunnel VPN: (select), device2_vpn
Modify matching bidirectional VPN policy: (select)

> Advanced: Enter the following advanced settings, then click Return to
return to the basic Policies configuration page:

Traffic Shaping (select) Policing Bandwidth: 5000

Shaping Traffic on Virtual Interfaces  211

 Concepts & Examples ScreenOS Reference Guide

CLI (Configuration for Device1)

1. Interfaces
set interface ethernet0/1 zone trust
set interface ethernet0/2 zone untrust
set interface ethernet0/1 ip 10.1.1.1/24
set interface ethernet0/1 nat
set interface ethernet0/2 ip 2.1.1.1/24
set interface ethernet0/1 route
2. IKE VPN
set ike gateway device2_ike address 2.2.2.2 main outgoing interface ethernet0/2
preshare secret proposal pre-g2-3des-sha
set vpn device2_vpn gateway device2_ike no-replay tunnel idletime 0 sec-level
standard
3. Routing
set route 10.2.1.0/24 interface ethernet0/2 gateway 2.2.2.2
4. Policies
set policy from trust to untrust any any ftp tunnel vpn device2_vpn pair-policy 2
traffic pbw 5000
set policy from untrust to trust any any ftp tunnel vpn netscreeen2_vpn pair-policy
1 traffic pbw 5000
5. Interface-Based Policing
set interface ethernet0/1 bandwidth ingress mbw 20000
save

WebUI (Configuration for Device2)

1. Interfaces
Network > Interfaces > Edit (for ethernet0/1): Enter the following, then click
OK:

IP Address/Netmask: 1.1.1.1/24
Zone: Trust
Interface mode: (select) Route

Network > Interfaces > Edit (for ethernet0/2): Enter the following, then click
OK:

IP Address/Netmask: 10.2.2.1/24
Zone: Untrust
Interface mode: (select) NAT
2. IKE VPN
VPNs > AutoKey Advanced > Gateway > New: Enter the following, then click
OK:

Gateway Name: device1_ike

Security Level: Standard
Remote Gateway Type:
Static IP Address: (select), IP Address/Hostname: 2.1.1.1

212  Shaping Traffic on Virtual Interfaces

 Chapter 7: Traffic Shaping

3. Preshared Key
Preshared Key: secret
Outgoing Interface: ethernet0/2

> Advanced: Enter the following advanced settings, then click OK to return
to basic Gateway configuration page:

Phase 1 Proposal: pre-g2-3des-sha

VPNs > AutoKey IKE New: Enter the following, then click OK:

VPN Name: device1_vpn

Gateway Name: device1_ike
4. Routing
Network > Routing > Destination > New: Enter the following, then click OK:

Network IP Address/Netmask: 10.1.1.0/24

Interface: (select), ethernet0/2
Gateway IP Address: 1.1.1.1
5. Policies
Policy > Policies > (From: Trust, To: Untrust) New: Enter the following, then
click OK:

Name: 1
Service: FTP
Action: Tunnel
Tunnel VPN: (select), device1_vpn
Modify matching bidirectional VPN policy: (select)

CLI (Configuration for Device2)

1. Interfaces
set interface ethernet0/1 1.1.1.2/24
set interface ethernet0/1 route
set interface ethernet0/2 ip 10.2.2.1/24
set interface ethernet0/2 nat
2. IKE VPN
set ike gateway device1_ike address 2.1.1.1 main outgoing interface ethernet0/2
preshare secret proposal pre-g2-3des-sha
set vpn device1_vpn gateway device1_ike no-replay tunnel idletime 0 sec-level
standard
3. Routing
set route 10.1.1.0/24 interface ethernet0/1 gateway 1.1.1.1
4. Policies
set policy id 1 from trust to untrust any any ftp tunnel vpn device1_vpn pair-policy 2
set policy id 2 from untrust to trust any any ftp tunnel vpn device1_vpn pair-policy 1
save

Shaping Traffic on Virtual Interfaces  213

 Concepts & Examples ScreenOS Reference Guide

Traffic Shaping Using a Loopback Interface

Traffic shaping is not supported on loopback interfaces, because no traffic is
actually transmitted on a loopback interface. However, a loopback interface is often
used as an anchor point (for example in the case of a VPN, to derive the source IP
address), while the data is transmitted on an actual egress interface. When using a
loopback interface in a VPN, therefore, you configure traffic shaping on the
outgoing interface. ScreenOS then associates the session with the real outgoing
interface, which it deduces from the routing table, dynamically updating the
association as the routing table changes.

DSCP Marking and Shaping

As stated earlier in this chapter, Differentiated Services (DS) is a system for tagging
(or “marking”) traffic at a position within a hierarchy of priority. Differentiated
Services codepoint (DSCP) marking maps the ScreenOS priority level of the policy
to the first three bits of codepoint in the DS field in the IP packet header. (See
“Setting Service Priorities” on page 2-197 for more information).

You can shape traffic in a policy that uses DSCP marking, or you can use DSCP
marking independent of traffic shaping. Traffic shaping governs how traffic is
processed on the security device and can be configured at the interface level or in
policies. DSCP marking, which you set at the policy level, governs how traffic is
processed by downstream routers.

NOTE: Some devices require that you explicitly enable DSCP marking by setting a
system-wide environmental variable. Refer to the installation and configuration
manual for your device to find out if it requires that you explicitly enable DSCP
marking before using it in policies. If your device requires it, use the following
command to enable DSCP marking system wide: set envar
ipsec-dscp-mark=yes. This variable cannot be set using the WebUI. Use the
unset envar ipsec-dscp-mark to disable DSCP marking system wide.

The DSCP marking feature is disabled in IDP-capable security devices. For

information about IDP-capable security devices, see “Intrusion Detection and
Prevention” on page 4-171.

If you specify DSCP marking in a policy but do not set a value, ScreenOS maps the
policy priority to an equivalent IP precedence priority in the DSCP system. It does
this by overwriting the first 3 bits in the ToS byte with the IP precedence priority.
For example, if you create a policy that gives all traffic a priority of, for example, 2
(0 is the highest priority), and you enable DSCP marking, ScreenOS queues traffic
for that policy with level 2 priority at the egress interface and marks it with an
equivalent IP precedence priority. The following command creates a policy that
gives priority 2 to all traffic, and enables DSCP marking:

set policy from trust to untrust any any any permit traffic priority 2 dscp enable

214  Traffic Shaping Using a Loopback Interface

 Chapter 7: Traffic Shaping

But if you give DSCP a dscp-byte value of, for example, 46 (the highest priority), the
security device still queues traffic at the egress interface at priority 2 but overwrites
the first 6 bits of the ToS byte with the DSCP value.

set policy from trust to untrust any any any permit traffic priority 2 dscp enable
value 46

DSCP marking is supported on all platforms and can be configured with traffic
shaping or independently.

Enabling Differentiated Services Code Point

You can use the WebUI or CLI to enable Differentiated Services Code Point (DSCP)
marking and specify the DSCP value for every route-based VPN. By default DSCP
marking is disabled.

WebUI
VPNs > AutoKey IKE > Edit: Select the following options, then click Apply.

DSCP Mark: Enable(Select)

Dscp-value: Enter the DSCP value

You can disable DSCP marking by selecting the Disable option in the DSCP Mark
field.

CLI
The following command enables DSCP-marking and sets the 6-bit DSCP in the
IPSEC header to 52.

set vpn vpn1 dscp-marking 52

To disable DSCP marking, use the following command:

unset vpn vpn1 dscp-marking

Table 31 shows how DSCP marking works for clear packets in policies. Table 32
shows how DSCP marking works for clear packets in policy-based VPNs. Table 33
shows how DSCP marking works for clear packets in route-based VPNs.

Table 31: DSCP Marking for Clear-Text Traffic

Description Action
Clear packet with no marking on the policy. No marking.
Clear packet with marking on the policy. The packet is marked based on the policy.
Premarked packet with no marking on the Retain marking in the packet.
policy.
Premarked packet with marking on the policy. Overwrite marking in the packet based on the
policy.

DSCP Marking and Shaping  215

 Concepts & Examples ScreenOS Reference Guide

Table 32: DSCP Marking for Policy-Based VPNs

Description Action
Clear packet into policy-based VPN with no No marking.
marking on the policy.
Clear packet into policy-based VPN with The inner packet and IP header of the ESP are
marking on the policy. both marked, based on the policy.
Premarked packet into policy-based VPN with Copy the inner packet marking to the IP header
no marking on the policy. of the ESP, retain marking in the inner packet.
Premarked packet into policy-based VPN with Overwrite the marking in the inner packet
marking on the policy. based on the policy, and copy the inner packet
marking to the IP header of the ESP.

Table 33: DSCP Marking for Route-Based VPNs

Description Action
Clear packet into route-based VPN with no No marking.
marking on the policy.
Clear packet into route-based VPN with The inner packet and IP header of the ESP are
marking on the policy. both marked, based on the policy.
Premarked packet into route-based VPN with Copy the inner packet marking to the IP header
no marking on the policy. of the ESP, retain marking in the inner packet.
Premarked packet into route-based VPN with Overwrite the marking in the inner packet
marking on the policy. based on the policy, and copy the inner packet
marking to the IP header of the ESP.

216  DSCP Marking and Shaping

Chapter 8
System Parameters

This chapter focuses on the concepts involved in establishing system parameters

affecting the following areas of a security appliance. It contains the following
sections:

 “Domain Name System Support” on page 217

 “Dynamic Host Configuration Protocol” on page 225

 “Point-to-Point Protocol over Ethernet” on page 243

 “License Keys” on page 250

 “Registration and Activation of Subscription Services” on page 251

 “System Clock” on page 253

Domain Name System Support

The Juniper Networks security device incorporates Domain Name System (DNS)
support, which allows you to use domain names as well as IP addresses for
identifying locations. A DNS server keeps a table of the IP addresses associated with
domain names. Using DNS makes it possible to reference locations by domain
name (such as www.juniper.net) in addition to using the routable IP address, which
for www.juniper.net is 207.17.137.68. DNS translation is supported in all the
following programs:

 Address Book

 Syslog

 Email

 WebTrends

 Websense

 LDAP

 SecurID

Domain Name System Support  217

 Concepts & Examples ScreenOS Reference Guide

 RADIUS

 NetScreen-Security Manager

Before you can use DNS for domain name/address resolution, you must enter the
addresses for DNS servers in the security device.

NOTE: When enabling the security device as a Dynamic Host Configuration Protocol
(DHCP) server (see “Dynamic Host Configuration Protocol” on page 225), you
must also enter the IP addresses for DNS servers in the DHCP page on the WebUI
or through the set interface interface dhcp command in the CLI.

DNS Lookup
The security device refreshes all the entries in its DNS table by checking them with
a specified DNS server at the following times:

 After an HA failover occurs

 At a regularly scheduled time of day and at regularly scheduled intervals

throughout the day

 When you manually command the device to perform a DNS lookup

 WebUI: Network > DNS > Host: Click Refresh.

 CLI: exec dns refresh

In addition to the existing method of setting a time for a daily automatic refresh of
the DNS table, you can also define an interval of time from 4 to 24 hours.

NOTE: When you add a fully qualified domain name (FQDN) such as an address or IKE
gateway through the WebUI, the security device resolves it when you click Apply
or OK. When you type a CLI command that references an FQDN, the security
device attempts to resolve it when you enter it.

When the security device connects to the DNS server to resolve a domain
name/IP address mapping, it stores that entry in its DNS status table. The following
list contains some of the details involved in a DNS lookup:

 When a DNS lookup returns multiple entries, the address book accepts all
entries. The other programs listed on page 217 accept only the first one.

 The security device reinstalls all policies if it finds that anything in the domain
name table has changed when you refresh a lookup using the Refresh button in
the WebUI or enter the exec dns refresh CLI command.

 If a DNS server fails, the security device looks up everything again.

218  Domain Name System Support

 Chapter 8: System Parameters

 If a lookup fails, the security device removes it from the cache table.

 If the domain name lookup fails when adding addresses to the address book,
the security device displays an error message stating that you have successfully
added the address but the DNS name lookup failed.

The security device must do a new lookup once a day, which you can schedule it to
do at a specified time.

WebUI
Network > DNS > Host: Enter the following, then click Apply:

DNS refresh every day at: Select check box and enter time <hh:mm>

CLI
set dns host schedule time_str
save

DNS Status Table

The DNS status table reports all the domain names looked up, their corresponding
IP addresses, whether the lookup was successful, and when each domain name/IP
address was last resolved.

Table 34: DNS Status Table

Name IP Address Status Last Lookup

www.yahoo.com 204.71.200.74 Success 8/13/2000 16:45:33
204.71.200.75
204.71.200.67
204.71.200.68
www.hotbot.com 209.185.151.28 Success 8/13/2000 16:45:38
209.185.151.210
216.32.228.18

To view the DNS status table, do either of the following:

WebUI
Network > DNS > Host > Show DNS Lookup Table

CLI
get dns host report

Setting the DNS Server and Refresh Schedule

To implement DNS functionality, the IP addresses for the DNS servers at 24.1.64.38
and 24.0.0.3 are entered in the security device, protecting a single host in a home
office. The security device is scheduled to refresh the DNS settings stored in its DNS
status table every day at 11:00 P.M.

Domain Name System Support  219

 Concepts & Examples ScreenOS Reference Guide

Figure 68: DNS Refresh

Secondary DNS Server
24.1.64.38
Trust Zone Untrust Zone
Primary DNS Server
24.0.0.3

Internet

WebUI
Network > DNS > Host: Enter the following, then click Apply:

Primary DNS Server: 24.0.0.3

Secondary DNS Server: 24.1.64.38
DNS Refresh: (select)
Every Day at: 23:00

CLI
set dns host dns1 24.0.0.3
set dns host dns2 24.1.64.38
set dns host schedule 23:00
save

Setting a DNS Refresh Interval

In this example, you configure the security device to refresh its DNS table every four
hours beginning at 12:01 AM every day.

WebUI
Network > DNS > Host: Enter the following, then click Apply:

DNS Refresh: (select)

Every Day at: 00:01
Interval: 4

CLI
set dns host schedule 00:01 interval 4
save

Dynamic Domain Name System

Dynamic DNS (DDNS) is a mechanism that allows clients to dynamically update IP
addresses for registered domain names. This is useful when an ISP uses PPP, DHCP,
or XAuth to dynamically change the IP address for a CPE router (such as a security
device) that protects a webserver. Internet clients can reach the webserver by using
a domain name even if the IP address of the security device has previously changed
dynamically. This is made possible by a DDNS server (such as dyndns.org or
ddo.jp), which maintains a list of the dynamically changed addresses and their
associated domain names. The device updates these DDNS servers with this
information periodically or in response to IP address changes.

To use DDNS, create an account (username and password) on the DDNS server. The
server uses this account information to configure the client device.

220  Domain Name System Support

 Chapter 8: System Parameters

Figure 69: Dynamic DNS

Client Webserver
www.my_host.com

Security Device
(CPE Router)
Internet Trust Zone
DDNS Server
ethernet7

dyndns.org or ddo.jp

Figure 69 shows how the DDNS concept works. When an IP address changes, the
client can use the hostname www.my_host.com to reach the protected webserver,
through either the dyndns.org server or the ddo.jp server. However, each of these
servers requires a different configuration on the security device interface.

If you have configured the DDNS server type as dyndns.org in your security device,
you can choose the following service options:

 dyndns—You can assign a dynamic IP (DIP) address to a static hostname in a

fixed domain that dyndns.org provides. You can configure up to 5 hostnames. A
dynamic DNS entry expires if it is not updated for 35 days.

 statdns—You can configure a hostname, such as yourname.dyndns.com, to

point to your IP address.

Unlike entries from a DDNS host, static DNS entries do not expire after 35 days
without an update. However, static updates take longer to propagate through
the DNS system and support a maximum of 5 hostnames.

 custom—You can control the domain names and dynamic IP addresses over
the entire zone at the domain level, rather than at the domain-name level.

Using a custom DNS service, you can configure unlimited hostnames and
support for any domain purchased from dyndns.org. Changes you make to the
DNS are propagated instantly across the DNS network. Dynamic DNS entries
with the custom service never expire.

NOTE: Service options are available only with the dyndns.org service. For static and
custom DNS services, you can configure a higher value for the minimum update
interval than for dynamic DNS service, because the IP addresses change
infrequently.

Setting Up DDNS for a Dynamic DNS Server

In the following example, you configure a security device for DDNS operation. The
device uses the dyndns.org server to resolve changed addresses. For this server, you
specify the protected host using the Host Name setting, which explicitly binds to the
DNS interface (ethernet7).

Domain Name System Support  221

 Concepts & Examples ScreenOS Reference Guide

WebUI
Network > DNS > DDNS > New: Enter the following, then click OK:

ID: 12
Server Settings
Server Type: dyndns
Server Name: members.dyndns.org
Refresh Interval: 24
Minimum Update Interval: 15
Account Settings
Username: swordfish
Password: ad93lvb
Agent: Netscreen-6.0.0z-015608200600056
Bind to Interface: ethernet7
Host Name: www.my_host.com
Service: dyndns

NOTE: Minimum Update Interval specifies the minimum time interval (expressed in
minutes) between DDNS updates. The default is 10 minutes, and the allowable
range is 1-1440. In some cases, the device might not update the interval because
the DNS server first needs to time out the DDNS entry from its cache. In addition,
if you set the Minimum Update Interval to a low value, the security device might
lock you out. The recommended minimum value is 10 minutes.

CLI
set dns ddns
set dns ddns enable
set dns ddns id 12 server members.dyndns.org server-type dyndns refresh-interval
24 minimum-update-interval 15
set dns ddns id 12 src-interface ethernet7 host-name myhost_dynamic.dyndns.org
service dyndns
set dns ddns id 12 username swordfish password ad93lvb
save

Setting Up DDNS for a DDO Server

In the following example, you configure a security device for DDNS. The device uses
the ddo.jp server to resolve addresses. For the ddo.jp server, you specify the
protected host FQDN as the Username setting for the DDNS entry instead of
specifying the protected host using the Host Name setting. The service
automatically derives the hostname from the Username value. For example, the
ddo.jp server translates a username of my_host to my_host.ddo.jp. You need to
make sure that the registered domain name on ddo.jp matches the derived DNS.

222  Domain Name System Support

 Chapter 8: System Parameters

WebUI
Network > DNS > DDNS > New: Enter the following, then click OK:

ID: 25
Server Settings
Server Type: ddo
Server Name: juniper.net
Refresh Interval: 24
Minimum Update Interval: 15
Account Settings
Username: my_host
Password: ad93lvb
Agent: Netscreen-6.0.0z-015608200600056
Host Name: www.my_host.com
Bind to Interface: ethernet7

CLI
set dns ddns
set dns ddns enable
set dns ddns id 25 server ddo.jp server-type ddo refresh-interval 24
minimum-update-interval 15
set dns ddns id 25 src-interface ethernet7
set dns ddns id 25 username my_host password ad93lvb
save

Proxy DNS Address Splitting

The proxy DNS feature provides a transparent mechanism that allows clients to
make split DNS queries. Using this technique, the proxy selectively redirects the
DNS queries to specific DNS servers, according to partial or complete domain
names. This is useful when multiple VPN tunnels or PPPoE virtual links provide
network connectivity and it is necessary to direct some DNS queries to one network
and other queries to another network.

A DNS proxy has the following advantages:

 Domain lookups are usually more efficient. For example, DNS queries meant
for the corporate domain (such as acme.com) could go to the corporate DNS
server exclusively, while all others go to the ISP DNS server, which reduces the
load on the corporate server. This can also prevent corporate domain
information from leaking into the Internet.

 DNS proxy allows you to transmit selected DNS queries through a tunnel
interface, which prevents malicious users from learning about the internal
configuration of a network. For example, DNS queries bound for the corporate
server can pass through a tunnel interface to use security features such as
authentication, encryption, and anti-replay.

The following commands create two proxy-DNS entries that selectively forward
DNS queries to different servers.

Domain Name System Support  223

 Concepts & Examples ScreenOS Reference Guide

Figure 70: Splitting DNS Requests

juniper.net => 63.126.135.170 ISP DNS Servers

juniper.net
1.1.1.23 Internet 63.126.135.170

acme.com => acme_eng.com =>

3.1.1.2 3.1.1.5
ethernet0/3

tunnel.1
Corporate
DNS Servers

*
acme.com
2.1.1.21
2.1.1.34

acme_eng.com

 Any DNS query with a FQDN containing the domain name acme.com goes out
through tunnel interface tunnel.1, to the corporate DNS server at IP address
2.1.1.21.

For example, if a host sends a DNS query for www.acme.com, the device
automatically directs the query to this server. (Let’s assume that the server
resolves the query to IP address 3.1.1.2.)

 Any DNS query with a FQDN containing the domain name acme_eng.com goes
out through tunnel interface tunnel.1 to the DNS server at IP address 2.1.1.34.

For example, if a host sends a DNS query for intranet.acme_eng.com, the

device directs the query to this server. (Let’s assume that the server resolves the
query to IP address 3.1.1.5.)

 All other DNS queries (denoted by an asterisk) bypass the corporate servers and
go out through interface ethernet0/3 to the DNS server at IP address 1.1.1.23.

For example, if the host and domain name is www.juniper.net, the device
automatically bypasses the corporate servers and directs the query to this
server, which resolves the query to IP address 207.17.137.68.

WebUI
Network > DNS > Proxy: Enter the following, then click Apply:

Initialize DNS Proxy: Enable

Enable DNS Proxy: Enable

Network > DNS > Proxy > New: Enter the following, then click OK:

Domain Name: acme.com

Outgoing Interface: tunnel.1
Primary DNS Server: 2.1.1.21

Network > DNS > Proxy > New: Enter the following, then click OK:

Domain Name: acme_eng.com

Outgoing Interface: tunnel.1
Primary DNS Server: 2.1.1.34

224  Domain Name System Support

 Chapter 8: System Parameters

Network > DNS > Proxy > New: Enter the following, then click OK:

Domain Name: *
Outgoing Interface: ethernet0/3
Primary DNS Server: 1.1.1.23

CLI
set dns proxy
set dns proxy enable
set interface ethernet0/3 proxy dns
set dns server-select domain acme.com outgoing-interface tunnel.1 primary-server
2.1.1.21
set dns server-select domain acme_eng.com outgoing-interface tunnel.1
primary-server 2.1.1.34
set dns server-select domain * outgoing-interface ethernet0/3 primary-server
1.1.1.23
save

Dynamic Host Configuration Protocol

Dynamic Host Configuration Protocol (DHCP) was designed to reduce the demands
on network administrators by automatically assigning the TCP/IP settings for the
hosts on a network. Instead of requiring administrators to assign, configure, track,
and change (when necessary) all the TCP/IP settings for every machine on a
network, DHCP does it all automatically. Furthermore, DHCP ensures that duplicate
addresses are not used, reassigns unused addresses, and automatically assigns IP
addresses appropriate for the subnet on which a host is connected.

Different security devices support the different DHCP roles described in Table 35.

Dynamic Host Configuration Protocol  225

 Concepts & Examples ScreenOS Reference Guide

Table 35: DHCP Roles

Role Description
DHCP Client Some security devices can act as DHCP clients, receiving a dynamically
assigned IP address for any physical interface in any zone.
DHCP Server Some security devices can also act as DHCP servers, allocating dynamic IP
addresses to hosts (acting as DHCP clients) on any physical or VLAN
interface in any zone.
Note: While using the DHCP server module to assign addresses to hosts
such as workstations in a zone, you can still use fixed IP addresses for
other machines such as mail servers and WINS servers.
DHCP Relay Agent Some security devices can also act as DHCP relay agents, receiving DHCP
information from a DHCP server and relaying that information to hosts on
any physical or VLAN interface in any zone.
DHCP Some security devices can simultaneously act as a DHCP client, server, and
Client/Server/Relay relay agent. You can only configure one DHCP role on a single interface.
Agent For example, you cannot configure the DHCP client and server on the same
interface. Optionally, you can configure the DHCP client module to forward
TCP/IP settings that it receives to the DHCP server module, for use when
providing TCP settings to hosts in the Trust zone acting as DHCP clients.

DHCP consists of two components: a protocol for delivering host-specific TCP/IP

configuration settings and a mechanism for allocating IP addresses. When the
security device acts as a DHCP server, it provides the following TCP/IP settings to
each host when that host starts up:

 Default gateway IP address and netmask. If you leave these settings as

0.0.0.0/0, the DHCP server module automatically uses the IP address and
netmask of the default Trust zone interface.

NOTE: On devices that can have multiple interfaces bound to the Trust zone, the default
interface is the first interface bound to that zone and assigned an IP address.

 The IP addresses of the following servers:

 WINS servers (2): A Windows Internet Naming Service (WINS) server maps
a NetBIOS name used in a Windows NT network environment to an IP
address used on an IP-based network. The number in parentheses
indicates the number of servers supported.

 NetInfo servers (2): NetInfo is an Apple network service used for the
distribution of administrative data within a LAN.

 NetInfo tag (1): The identifying tag used by the Apple NetInfo database.

 DNS servers (3): A Domain Name System (DNS) server maps a uniform
resource locator (URL) to an IP address.

 SMTP server (1): A Simple Mail Transfer Protocol (SMTP) server delivers
SMTP messages to a mail server, such as a POP3 server, which stores the
incoming mail.

226  Dynamic Host Configuration Protocol

 Chapter 8: System Parameters

 POP3 server (1): A Post Office Protocol version 3 (POP3) server stores
incoming mail. A POP3 server must work conjointly with an SMTP server.

 News server (1): A news server receives and stores postings for news
groups.

NOTE: If a DHCP client to which the security device is passing the above parameters has
a specified IP address, that address overrides all the dynamic information received
from the DHCP server.

Configuring a DHCP Server

A security device can support up to eight DHCP servers on any physical or VLAN
interface in any zone. When acting as a DHCP server, a security device allocates IP
addresses and subnet masks in two modes:

 In Dynamic mode, the security device, acting as a DHCP server, assigns (or
“leases”) an IP address from an address pool to a host DHCP client. The IP
address is leased for a determined period of time or until the client relinquishes
the address. (To define an unlimited lease period, enter 0.)

 In Reserved mode, the security device assigns a designated IP address from an

address pool exclusively to a specific client every time that client goes online.

NOTE: An address pool is a defined range of IP addresses within the same subnet from
which the security device can draw DHCP address assignments. You can group up
to 255 IP addresses.

The DHCP server supports up to 64 entries, which can include both single IP
addresses and IP address ranges, for dynamic and reserved IP addresses.

The security device saves every IP address assigned through DHCP in flash
memory. Consequently, rebooting the security device does not affect address
assignments.

In this example, using DHCP, the 172.16.10.0/24 network in the Trust zone is
sectioned into three IP address pools.

 172.16.10.10 through 172.16.10.19

 172.16.10.120 through 172.16.10.129

 172.16.10.210 through 172.16.10.219

The DHCP server assigns all IP addresses dynamically, except for two workstations
with reserved IP addresses and four servers with static IP addresses. The interface
ethernet0/1 is bound to the Trust zone, has IP address 172.16.10.1/24, and is in
NAT mode. The domain name is dynamic.com.

Dynamic Host Configuration Protocol  227

 Concepts & Examples ScreenOS Reference Guide

Figure 71: Device as DHCP Server

DNS Servers
Fixed IPs
Trust Zone 172.16.10.240
172.16.10.241
ethernet0/1
172.16.10.1/24 (NAT)

Address Pool 172.16.10.0/24 Address Pool

172-16.10.10 – LAN 172-16.10.210 –
172.16.10.19 172.16.10.219

Address Pool
172-16.10.120 –
172.16.10.129
Reserved IP
172.16.10.11
MAC: 12:34:ab:cd:56:78

SMTP and POP3 Servers

Fixed IPs
Reserved IP 172.16.10.25 and 172.16.10.10
172.16.10.112
MAC: ab:cd:12:34:ef:gh

WebUI
1. Addresses
Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: DNS#1

Comment: Primary DNS Server
IP Address/Domain Name:
IP/Netmask: (select), 172.16.10.240/32
Zone: Trust

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: DNS#2

Comment: Secondary DNS Server
IP Address/Domain Name:
IP/Netmask: (select), 172.16.10.241/32
Zone: Trust

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: SMTP

Comment: SMTP Server
IP Address/Domain Name:
IP/Netmask: (select), 172.16.10.25/32
Zone: Trust

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: POP3

Comment: POP3 Server
IP Address/Domain Name:

228  Dynamic Host Configuration Protocol

 Chapter 8: System Parameters

IP/Netmask: (select), 172.16.10.110/32

Zone: Trust
2. DHCP Server
Network > DHCP > Edit (for ethernet0/1) > DHCP Server: Enter the following,
then click Apply:

Lease: Unlimited (select)

WINS#1: 0.0.0.0
DNS#1: 172.16.10.240

NOTE: If you leave the Gateway and Netmask fields as 0.0.0.0, the DHCP server module
sends the IP address and netmask set for ethernet0/1 to its clients (172.16.10.1
and 255.255.255.0 in this example). However, if you enable the DHCP client
module to forward TCP/IP settings to the DHCP server module (see “Propagating
TCP/IP Settings” on page 240), then you must manually enter 172.16.10.1 and
255.255.255.0 in the Gateway and Netmask fields, respectively.

> Advanced Options: Enter the following, then click OK to set the
advanced options and return to the basic configuration page:

WINS#2: 0.0.0.0
DNS#2: 172.16.10.241
DNS#3: 0.0.0.0
SMTP: 172.16.10.25
POP3: 172.16.10.110
NEWS: 0.0.0.0
NetInfo Server #1: 0.0.0.0
NetInfo Server #2: 0.0.0.0
NetInfo Tag: (leave field empty)
Domain Name: dynamic.com

> Addresses > New: Enter the following, then click OK:

Dynamic: (select)
IP Address Start: 172.16.10.10
IP Address End: 172.16.10.19

> Addresses > New: Enter the following, then click OK:

Dynamic: (select)
IP Address Start: 172.16.10.120
IP Address End: 172.16.10.129

> Addresses > New: Enter the following, then click OK:

Dynamic: (select)
IP Address Start: 172.16.10.210
IP Address End: 172.16.10.219

> Addresses > New: Enter the following, then click OK:

Reserved: (select)
IP Address: 172.16.10.11
Ethernet Address: 1234 abcd 5678

Dynamic Host Configuration Protocol  229

 Concepts & Examples ScreenOS Reference Guide

> Addresses > New: Enter the following, then click OK:

Reserved: (select)
IP Address: 172.16.10.112
Ethernet Address: abcd 1234 efgh

CLI
1. Addresses
set address trust dns1 172.16.10.240/32 “primary dns server”
set address trust dns2 172.16.10.241/32 “secondary dns server”
set address trust snmp 172.16.10.25/32 “snmp server”
set address trust pop3 172.16.10.110/32 “pop3 server”
2. DHCP Server
set interface ethernet0/1 dhcp server option domainname dynamic.com
set interface ethernet0/1 dhcp server option lease 0
set interface ethernet0/1 dhcp server option dns1 172.16.10.240
set interface ethernet0/1 dhcp server option dns2 172.16.10.241
set interface ethernet0/1 dhcp server option smtp 172.16.10.25
set interface ethernet0/1 dhcp server option pop3 172.16.10.110
set interface ethernet0/1 dhcp server ip 172.16.10.10 to 172.16.10.19
set interface ethernet0/1 dhcp server ip 172.16.10.120 to 172.16.10.129
set interface ethernet0/1 dhcp server ip 172.16.10.210 to 172.16.10.219
set interface ethernet0/1 dhcp server ip 172.16.10.11 mac 1234abcd5678
set interface ethernet0/1 dhcp server ip 172.16.10.112 mac abcd1234efgh
set interface ethernet0/1 dhcp server service
save

NOTE: If you do not set an IP address for the gateway or a netmask, the DHCP server
module sends its clients the IP address and netmask for ethernet0/1 (172.16.10.1
and 255.255.255.0 in this example). However, if you enable the DHCP client
module to forward TCP/IP settings to the DHCP server module (see “Propagating
TCP/IP Settings” on page 240), then you must manually set these options: set
interface ethernet0/1 dhcp server option gateway 172.16.10.1 and set interface
ethernet0/1 dhcp server option netmask 255.255.255.0.

Customizing DHCP Server Options

When you specify DHCP servers for an interface, you might need to specify options
that identify the servers or provide information used by the servers. For example,
you can specify the IP address of the primary and secondary DNS servers, or set the
IP address lease time.

The following are predefined DHCP services, as described in RFC 2132, DHCP
Options and BOOTP Vendor Extensions.

230  Dynamic Host Configuration Protocol

 Chapter 8: System Parameters

Table 36: Predefined DHCP Services

Terminology ScreenOS CLI Terminology Option Code

Subnet Mask netmask 1
Router Option gateway 3
Domain Name System (DNS) dns1, dns2, dns3 6
server
Domain Name domainname 15
NetBIOS over TCP/IP Name wins1, wins2 44
Server Option
IP Address Lease Time lease 51
SMTP Server Option smtp 69
POP3 Server Option pop3 70
NNTP Server Option news 71
(N/A) nis1, nis2 112
(N/A) nistag 113

In situations where the predefined server options are inadequate, you can define
custom DHCP server options. For example, for certain Voice-over IP (VoIP)
configurations, it is necessary send extra configuration information, which is not
supported by predefined server options. In such cases, you must define suitable
custom options.

In the following example, you create DHCP server definitions for IP phones which
act as DHCP clients. The phones use the following custom options:

 Option code 444, containing string “Server 4”

 Option code 66, containing IP address 1.1.1.1

 Option code 160, containing integer 2004

CLI
1. Addresses
set address trust dns1 172.16.10.240/32 “primary dns server”
set address trust dns2 172.16.10.241/32 “secondary dns server”
2. DHCP Server
set interface ethernet0/1 dhcp server option domainname dynamic.com
set interface ethernet0/1 dhcp server option lease 0
set interface ethernet0/1 dhcp server option dns1 172.16.10.240
set interface ethernet0/1 dhcp server option dns2 172.16.10.241
set interface ethernet0/1 dhcp server option custom 444 string “Server 4”
set interface ethernet0/1 dhcp server option custom 66 ip 1.1.1.1
set interface ethernet0/1 dhcp server option custom 160 integer 2004
set interface ethernet0/1 dhcp server ip 172.16.10.10 to 172.16.10.19

Dynamic Host Configuration Protocol  231

 Concepts & Examples ScreenOS Reference Guide

Placing the DHCP Server in an NSRP Cluster

When the primary unit in a redundant NSRP cluster functions as a DHCP server, all
members in the cluster maintain all DHCP configurations and IP address
assignments. In the event of a failover, the new primary unit maintains all the DHCP
assignments. However, termination of HA communication disrupts synchronization
of existing DHCP assignments among the cluster members. After restoring HA
communication, you can resynchronize the DHCP assignments by using the
following CLI command on both units in the cluster: set nsrp rto-mirror sync.

DHCP Server Detection

When a DHCP server on a security device starts up, the system can first check to
see if there is already a DHCP server on the interface. ScreenOS automatically stops
the local DHCP server process from starting if another DHCP server is detected on
the network. To detect another DHCP server, the device sends out DHCP boot
requests at two-second intervals. If the device does not receive any response to its
boot requests, it then starts its local DHCP server process.

If the security device receives a response from another DHCP server, the system
generates a message indicating that the DHCP service is enabled on the security
device but not started because another DHCP server is present on the network. The
log message includes the IP address of the existing DHCP server.

You can set one of three operational modes for DHCP server detection on an
interface: Auto, Enable, or Disable. Auto mode causes the security device to always
check for an existing DHCP server at bootup. You can configure the device to not
attempt to detect another DHCP server on an interface by setting the security DHCP
server to Enable or Disable mode. In Enable mode, the DHCP server is always on
and the device does not check if there is an existing DHCP server on the network.
In Disable mode, the DHCP server is always off.

Enabling DHCP Server Detection

In this example, you set the DHCP server on the ethernet0/1 interface to check for
an existing DHCP server on the interface first before starting up.

WebUI
Network > DHCP > Edit (for ethernet0/1) > DHCP Server: Enter the following,
then click OK:

Server Mode: Auto (select)

CLI
set interface ethernet0/1 dhcp server auto
save

Disabling DHCP Server Detection

In this example, you set the DHCP server on the ethernet0/1 interface to start up
without checking to see if there is an existing DHCP server on the network.

232  Dynamic Host Configuration Protocol

 Chapter 8: System Parameters

WebUI
Network > DHCP > Edit (for ethernet0/1) > DHCP Server: Enter the following,
then click OK:

Server Mode: Enable (select)

CLI
set interface ethernet0/1 dhcp server enable
save

NOTE: Issuing the CLI command set interface interface dhcp server service command
activates the DHCP server. If the DHCP server detection mode for the interface is
set to Auto, the DHCP server on the security device starts only if it does not find an
existing server on the network. Issuing the unset interface interface dhcp server
service command disables the DHCP server on the security device and also
deletes any existing DHCP configuration.

Assigning a Security Device as a DHCP Relay Agent

When acting as a DHCP relay agent, the security device forwards DHCP requests
and assignments between DHCP clients directly attached to one interface and one
or more DHCP servers accessible through another interface. The clients and servers
may be in the same security zone or in separate security zones.

You can configure a DHCP relay agent on one or more physical or VLAN interfaces
on a security device, but you cannot configure a DHCP relay agent and DHCP server
or client functions on the same interface.

When the security device functions as a DHCP relay agent, its interfaces must be in
either Route mode or function as a Layer 3 device. For interfaces in Layer 3 mode
(that is have IP addresses assigned to the interfaces), you must configure a security
policy (from zone to zone or intrazone) to permit the predefined service
DHCP-Relay before forwarding occurs.

You can configure up to three DHCP servers for each DHCP relay agent. The relay
agent unicasts an address request from a DHCP client to all configured DHCP
servers. The relay agent forwards to the client all DHCP packets received from all
servers. See “Forwarding All DHCP Packets” on page 237.

NOTE: When a security device acts as a DHCP relay agent, the device does not generate
DHCP allocation status reports because the remote DHCP server controls all the IP
address allocations.

ScreenOS supports DHCP relay in different vsys and for VLAN-tagged subinterfaces.

Figure 72 illustrates the process involved in using a security device as a DHCP relay
agent. To ensure security, the DHCP messages pass through a VPN tunnel when
traveling through the untrusted network.

Dynamic Host Configuration Protocol  233

 Concepts & Examples ScreenOS Reference Guide

Figure 72: DHCP Relay Agent Traffic

Trust Zone Relay Agent VPN Tunnel in
Untrust Zone
Host DHCP
Server

Request Request

Host DHCP
Server

Assignment Assignment

Host DHCP
Server

Request Request

In Figure 73, a security device receives its DHCP information from a DHCP server at
194.2.9.10 and relays it to hosts in the Trust zone. The hosts receive IP addresses
from an IP pool defined on the DHCP server. The address range is
180.10.10.2—180.10.10.254. The DHCP messages pass through a VPN tunnel
between the local security device and the DHCP server, located behind a remote
security device whose Untrust zone interface IP address is 2.2.2.2/24. The interface
ethernet0/1 is bound to the Trust zone, has the IP address 180.10.10.1/24, and is in
Route mode. The interface ethernet0/3 is bound to the Untrust zone and has the IP
address 1.1.1.1/24. All security zones are in the trust-vr routing domain.

Figure 73: Device as DHCP Relay Agent

Trust Zone Untrust Zone
ethernet0/1 ethernet0/3 DHCP
180.10.10.1/24 1.1.1.1/24 Server
194.2.9.10

Local Security Device

DHCP Relay Agent

234  Dynamic Host Configuration Protocol

 Chapter 8: System Parameters

WebUI
1. Interfaces
Interfaces > Edit (for ethernet0/1): Enter the following, then click Apply:

Zone: Trust
Static IP: (select this option when present)
IP Address/Netmask: 180.10.10.1/24

Enter the following, then click OK:

Interface Mode: Route

Interfaces > Edit (for ethernet0/3): Enter the following, then click OK:

Zone: Untrust
Static IP: (select this option when present)
IP Address/Netmask: 1.1.1.1/24
2. Address
Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: DHCP Server

IP Address/Domain Name:
IP/Netmask: (select), 194.2.9.10/32
Zone: Untrust
3. VPN
VPNs > AutoKey Advanced > Gateway > New: Enter the following, then click
OK:

Gateway Name: dhcp server

Security Level: Custom
Remote Gateway Type:
Static IP: (select), Address/Hostname: 2.2.2.2
Outgoing Interface: ethernet0/3

> Advanced: Enter the following, then click Return to set the advanced
options and return to the basic configuration page:

Security Level:
User Defined: Custom (select)
Phase 1 Proposal: rsa-g2-3des-sha
Mode (Initiator): Main (ID Protection)

VPNs > AutoKey IKE > New: Enter the following, then click OK:

VPN Name: to_dhcp

Security Level: Compatible
Remote Gateway:
Predefined: (select), to_dhcp

> Advanced: Enter the following, then click Return to set the advanced
options and return to the basic configuration page:

Bind to: None

Dynamic Host Configuration Protocol  235

 Concepts & Examples ScreenOS Reference Guide

4. DHCP Relay Agent

Network > DHCP > Edit (for ethernet0/1) > DHCP Relay Agent: Enter the
following, then click Apply:

Relay Agent Server IP or Domain Name: 194.2.9.10

Use Trust Zone Interface as Source IP for VPN: (select)
5. Route
Network > Routing > Destination > trust-vr New: Enter the following, then
click OK:

Network Address/Netmask: 0.0.0.0/0

Gateway: (select)
Interface: ethernet0/3
Gateway IP Address: 1.1.1.250

NOTE: Setting a route to the external router designated as the default gateway is essential
for both outbound VPN and network traffic. In this example, the security device
sends encapsulated VPN traffic to this router as the first hop along its route to the
remote security device. In Figure 73, the concept is presented by depicting the
tunnel passing through the router.

6. Policies
Policy > Policies > (From: Trust, To: Untrust) New: Enter the following, then
click OK:

Source Address:
Address Book Entry: (select), Any
Destination Address:
Address Book Entry: (select), DHCP Server
Service: DHCP-Relay
Action: Tunnel
Tunnel VPN: to_dhcp
Modify matching outgoing VPN policy: (select)

CLI
1. Interfaces
set interface ethernet0/1 zone trust
set interface ethernet0/1 ip 180.10.10.1/24
set interface ethernet0/1 route
set interface ethernet0/3 zone untrust
set interface ethernet0/3 ip 1.1.1.1/24
2. Address
set address untrust dhcp_server 194.2.9.10/32
3. VPN
set ike gateway “dhcp server” ip 2.2.2.2 main outgoing-interface ethernet0/3
proposal rsa-g2-3des-sha
set vpn to_dhcp gateway “dhcp server” proposal g2-esp-3des-sha
4. DHCP Relay Agent
set interface ethernet0/1 dhcp relay server-name 194.2.9.10
set interface ethernet0/1 dhcp relay vpn

236  Dynamic Host Configuration Protocol

 Chapter 8: System Parameters

5. Route
set vrouter trust-vr route 0.0.0.0/0 interface ethernet0/3 gateway 1.1.1.250
6. Policies
set policy from trust to untrust any dhcp_server dhcp-relay tunnel vpn to_dhcp
set policy from untrust to trust dhcp_server any dhcp-relay tunnel vpn to_dhcp
save

Forwarding All DHCP Packets

ScreenOS lets your security device relay all DHCP responses from multiple servers
to a client. Some environments require multiple servers to respond with identical
data and their clients only process the first-received response; other environments
have multiple servers replying with unique data and the clients process appropriate
data from each, for example in a Pre-Boot Execution Environment (PXE) scenario.

In common PXE cases (as shown in Figure 74), at least two DHCP servers serve
clients. When the DHCP servers receive a request from the DHCP client, one of the
servers, DHCP Server1, provides DHCP address information to the client while
DHCP Server 2 (such as MS RIS) provides PXE information. This release of
ScreenOS allows the security device to forward all DHCP packets to the client.

Figure 74: Relaying All DHCP Packets from Multiple DHCP Servers

ethernet0/1.5 ethernet0/2 DHCP Server 1

: 10.0.0.1 : 30.0.0.1 30.0.0.2
Trust Zone 2 IP Pool
10.0.0.10-10.0.0.20
31 DHCP Relay Agent 4
DHCP Untrust Zone
Client 6 5
DHCP Server 2
7 Relay Agent 3 40.0.0.2
ethernet0/3: IP Pool
40.0.0.1 10.0.0.50-10.0.0.60

1. The DHCP client sends out a DHCP request message.

PXE server: (MS RIS)
2. & 3. The security device relays the message to all DHCP servers.

4. & 5. The DHCP servers send a DHCP reply for the request.

6. & 7. The security device relays the replies to the DHCP client.

Typically, a PXE server provides a boot-image-server for diskless PXE clients, which
are diskless PC machine. When a PXE client powers on, it sends out a broadcast
DHCP-DISCOVER (a kind of request), which means that the client requests the IP
and boot-image path. In most cases, two kinds of servers serve the PXE: a PXE
server (like a Microsoft RIS server) and a DHCP server. Both servers receive the
DISCOVER request. The PXE server replies to the DISCOVER request with
boot-image-server information. At the same time, the DHCP server replies to the
DISCOVER request with an IP-assignment information. Both the responses from the
two servers are forwarded to the DHCP client (diskless PC).

Configuring Next-Server-IP
If a security device receives conflicting or confusing information from the DHCP
server, the device uses the IP address in the Next-Server-IP field. This DHCP
configuration parameter has traditionally been used as the address of the TFTP
server in the bootstrap process.

Dynamic Host Configuration Protocol  237

 Concepts & Examples ScreenOS Reference Guide

For example, in PXE scenarios, the first DHCP server serves the IP address, and the
second DHCP server provides OS information. The Next-Server-IP field is
configured to specify the next server in the chain. The chain and each member can
vary from site to site. However, typically, it is a DHCP server chaining to a TFTP
server. The chain is terminated either by supplying all zeroes (0.0.0.0) or by
specifying the device interface IP into this field as shown in Table 37.

This Next-Server-IP information is returned in the siaddr field of the DHCP header
and is often used to chain several bootstrap servers together, with each serving a
specific function. The siaddr field is mandatory, if available, because some DHCP
servers will place their own IP address in this field when it is not configured.

Table 37: Specifying Next-Server-IP

Next Server IP Description

None (default) siaddr = 0.0.0.0 (default)
Interface siaddr = the IP interface bound to the DHCP server
Option66 siaddr = option66
(identifies the TFTP server for supporting diskless PCs)
Input siaddr = custom IP address

If the Next-Server-IP is non-zero and not equal to this server’s address, then it is
interpreted by the client as the address of the next server in a chain that supplies
additional boot information. In the following example, the Next-Server-IP is
configured for Option66.

WebUI
Network > DHCP > Edit (DHCP Server): Select one of the following, then click
Apply:

Next Server IP: From Option66

CLI
set interface ethernet0/1 dhcp server enable
set interface ethernet0/1 dhcp server option custom 66 ip 10.10.10.1
set interface ethernet0/1 dhcp server config next-server-ip option66
save

Using a Security Device as a DHCP Client

When acting as a DHCP client, the security device receives an IP address
dynamically from a DHCP server for any physical interface in any security zone. If
multiple interfaces bound to a single security zone exist, you can configure a DHCP
client for each interface as long as each interface is not connected to the same
network segment. If you configure a DHCP client for two interfaces that are
connected to the same network segment, the first address assigned by a DHCP
server is used. (If the DHCP client receives an address update to the same IP
address, IKE is not rekeyed.)

NOTE: While some security devices can act as DHCP servers, a DHCP relay agents, or
DHCP clients at the same time, you cannot configure more than one DHCP role on
a single interface.

238  Dynamic Host Configuration Protocol

 Chapter 8: System Parameters

In this example, the interface bound to the Untrust zone has a dynamically assigned
IP address. When the security device requests its IP address from its ISP, it receives
its IP address, subnet mask, gateway IP address, and the length of its lease for the
address. The IP address of the DHCP server is 2.2.2.5.

Figure 75: Device as DHCP Client

Trust Zone

Internal LAN

1. IP address requested for

ethernet0/3 (Untrust zone)

2. IP address assigned

ISP
(DHCP Server)

2.2.2.5
Internet

Untrust Zone

NOTE: Before setting up a site for DHCP service, you must have a Digital Subscriber Line
DSL) and an account with an Internet Service Provider (ISP).

WebUI
Network > Interfaces > Edit (for ethernet0/3): Select Obtain IP using DHCP,
then click OK.

NOTE: You cannot specify the IP address of the DHCP server through the WebUI;
however, you can do so through the CLI.

CLI
set interface ethernet0/3 dhcp client
set interface ethernet0/3 dhcp settings server 2.2.2.5
save

Dynamic Host Configuration Protocol  239

 Concepts & Examples ScreenOS Reference Guide

Propagating TCP/IP Settings

Some security devices can act as a Dynamic Host Control Protocol (DHCP) client,
receiving its TCP/IP settings and the IP address for any physical interface in any
security zone from an external DHCP server. Some security devices can act as a
DHCP server, providing TCP/IP settings and IP addresses to clients in any zone.
When a security device acts both as a DHCP client and a DHCP server
simultaneously, it can transfer the TCP/IP settings learned through its DHCP client
module to its default DHCP server module.

TCP/IP settings include the IP address of the default gateway and a subnet mask,
and IP addresses for any or all of the following servers:

 DNS (3)

 WINS (2)

 NetInfo (2)

 SMTP (1)

 POP3 (1)

 News (1)

In Figure 76, the security device is both a client of the DHCP server in the Untrust
zone and a DHCP server to the clients in the Trust zone. The device takes the TCP/IP
settings that it receives as a DHCP client and forwards them as a DHCP server to the
clients in the Trust zone. The Untrust Zone Interface is the DHCP client and receives
IP addresses dynamically from an ISP.

Figure 76: DHCP Propagation

Untrust Zone
ISP

DHCP Server
TCP/IP Settings and Untrust
Zone Interface IP Address

Untrust Zone Interface: DHCP Client

Trust Zone Interface: DHCP Server

10.1.1.1/0
TCP/IP Settings
DHCP Range:
10.1.1.50 - 10.1.1.200

DHCP Clients

Trust Zone

240  Dynamic Host Configuration Protocol

 Chapter 8: System Parameters

You can configure the DHCP server module to propagate all TCP/IP settings that it
receives from the DHCP client module using the set interface interface dhcp-client
settings update-dhcpserver command. You can also override any setting with a
different one.

In this example, you configure the security device to act both as a DHCP client on
the ethernet0/3 interface and as a DHCP server on the ethernet0/1 interface. (The
default DHCP server is on the ethernet0/1 interface.)

As a DHCP client, the security device receives an IP address for the ethernet0/3
interface and its TCP/IP settings from an external DHCP server at 211.3.1.6. You
enable the DHCP client module in the security device to transfer the TCP/IP settings
it receives to the DHCP server module.

You configure the DHCP server module to do the following with the TCP/IP settings
that it receives from the DHCP client module:

 Forward the DNS IP addresses to its DHCP clients in the Trust zone.

 Override the default gateway, netmask, SMTP server, and POP3 server IP
addresses with the following:

 10.1.1.1 (this is the IP address of the ethernet0/1 interface)

 255.255.255.0 (this is the netmask for the ethernet0/1 interface)

 SMTP: 211.1.8.150

 POP3: 211.1.8.172

NOTE: If the DHCP server is already enabled on the Trust interface and has a defined pool
of IP addresses (which is default behavior for certain platforms), you must first
delete the IP address pool before you can change the default gateway and
netmask.

You also configure the DHCP server module to deliver the following TCP/IP settings
that it does not receive from the DHCP client module:

 Primary WINS server: 10.1.2.42

 Secondary WINS server: 10.1.5.90

Finally, you configure the DHCP server module to assign IP addresses from the
following IP Pool to the hosts acting as DHCP clients in the Trust zone: 10.1.1.50 –
10.1.1.200.

WebUI

NOTE: You can set this feature only through the CLI.

Dynamic Host Configuration Protocol  241

 Concepts & Examples ScreenOS Reference Guide

CLI
1. DHCP Client
set interface ethernet0/3 dhcp-client settings server 211.3.1.6
set interface ethernet0/3 dhcp-client settings update-dhcpserver
set interface ethernet0/3 dhcp-client settings autoconfig
set interface ethernet0/3 dhcp-client enable
2. DHCP Server
set interface ethernet0/1 dhcp server option gateway 10.1.1.1
set interface ethernet0/1 dhcp server option netmask 255.255.255.0
set interface ethernet0/1 dhcp server option wins1 10.1.2.42
set interface ethernet0/1 dhcp server option wins2 10.1.5.90
set interface ethernet0/1 dhcp server option pop3 211.1.8.172
set interface ethernet0/1 dhcp server option smtp 211.1.8.150
set interface ethernet0/1 dhcp server ip 10.1.1.50 to 10.1.1.200
set interface ethernet0/1 dhcp server service
save

Configuring DHCP in Virtual Systems

DHCP: ScreenOS now fully supports DHCP relay for Vsys. You can configure DHCP
relay for a specific Vsys and relay all packets from multiple DHCP servers to a client.

Setting DHCP Message Relay in Virtual Systems

ScreenOS allows you to configure Dynamic Host Configuration Protocol (DHCP)
message relay from one or multiple DHCP servers to clients within a virtual system
(vsys). You can configure DHCP message relay on an interface that is available to a
virtual system.

If you have two DHCP servers, server 1 and server 2, a security device, sitting
between the DHCP servers and a client, individually passes DHCP requests to each
DHCP server on different outgoing interfaces. As each DHCP reply is received, the
security device passes them to the root vsys and then forwards them to the
appropriate DHCP client within a vsys.

Figure 77: DHCP Relay Services Within a Vsys

DHCP Server 1

Security Device Providing DHCP Relay

DHCP Server 2

DHCP client

242  Setting DHCP Message Relay in Virtual Systems

 Chapter 8: System Parameters

To configure DHCP with vsys:

1. Create a virtual system.

2. Enable DHCP for that vsys.

3. Configure a static route to allow the DHCP server in the root system to access
the vsys.

4. Set security policies in the virtual system.

Point-to-Point Protocol over Ethernet

PPP-over-Ethernet (PPPoE) merges the Point-to-Point Protocol (PPP), which is
usually used for dialup connections, with the Ethernet protocol, which can connect
multiple users at a site to the same customer premises equipment. Many users can
share the same physical connection, but access control, billing, and type of service
are handled for each user. Some security devices support a PPPoE client, allowing
them to operate compatibly on DSL, Ethernet Direct, and cable networks run by
ISPs using PPPoE for their clients’ Internet access.

On devices that support PPPoE, you can configure a PPPoE client instance on any or
all interfaces. You configure a specific instance of PPPoE with a username,
password, and other parameters, and then you bind the instance to an interface.
When two Ethernet interfaces (a primary and a backup) are bound to the Untrust
zone, you can configure one or both interfaces for PPPoE.

Setting Up PPPoE
The following example illustrates how to define the untrusted interface of a security
device for PPPoE connections and how to initiate PPPoE service.

In this example, the security device receives a dynamically assigned IP address for
its Untrust zone interface (ethernet0/3) from the ISP, and the security device also
dynamically assigns IP addresses for the three hosts in its Trust zone. In this case,
the security device acts both as a PPPoE client and a DHCP server. The Trust zone
interface must be in either NAT or Route mode. In this example, it is in NAT mode.

Figure 78: PPPoE

Untrust (ethernet0/3): DHCP mode Trust Interface: 172.16.30.10/24

Security Device
DSL Modem
ISP
DSLAM
Hub AC Internet
DSL Line

Primary
DNS Server

DHCP Range: Secondary

172.16.30.2 - 172.16.30.5 Trust Zone Untrust Zone
DNS Server

Point-to-Point Protocol over Ethernet  243

 Concepts & Examples ScreenOS Reference Guide

Before setting up the site in this example for PPPoE service, you must have the
following:

 Digital subscriber line (DSL) modem and line

 Account with ISP

 Username and password (obtained from the ISP)

WebUI
1. Interfaces and PPPoE
Network > Interfaces > Edit (for ethernet0/1): Enter the following, then click
OK:

Zone: Trust
Static IP: (select this option when present)
IP Address/Netmask: 172.16.30.10/24

Network > Interfaces > Edit (for ethernet0/3): Enter the following, then click
OK:

Zone: Untrust
Obtain IP using PPPoE: (select)
User Name/Password: name/password

Network > Interfaces > Edit (for ethernet0/3): To test your PPPoE connection,
click Connect.

NOTE: When you initiate a PPPoE connection, your ISP automatically provides the IP
addresses for the Untrust zone interface and for the Domain Name System (DNS)
servers. When the security device receives DNS addresses by PPPoE, the new DNS
settings overwrite the local settings by default. If you do not want the new DNS
settings to replace the local settings, you can use the CLI command unset pppoe
dhcp-updateserver to disable this behavior.

If you use a static IP address for the Untrust zone interface, you must obtain the IP
addresses of the DNS servers and manually enter them on the security device and
on the hosts in the Trust zone.

2. DHCP Server
Network > Interfaces > Edit (for ethernet0/1) > DHCP: Select DHCP Server,
then click Apply.

Network > Interfaces > Edit (for ethernet0/1) > DHCP: Enter the following,
then click Apply:

Lease: 1 hour
Gateway: 0.0.0.0
Netmask: 0.0.0.0
DNS#1: 0.0.0.0

244  Point-to-Point Protocol over Ethernet

 Chapter 8: System Parameters

> Advanced: Enter the following, then click Return:

DNS#2: 0.0.0.0
Domain Name: (leave blank)

Network > Interfaces > DHCP (for ethernet0/1) > New Address: Enter the
following, then click OK:

Dynamic: (select)
IP Address Start: 172.16.30.2
IP Address End: 172.16.30.5
3. Activating PPPoE on the Security Device
1. Turn off the power to the DSL modem, the security device, and the three
workstations.

2. Turn on the DSL modem.

3. Turn on the security device.

The security device makes a PPPoE connection to the ISP and, through the ISP,
gets the IP addresses for the DNS servers.

4. Activating DHCP on the Internal Network

Turn on the workstations.

The workstations automatically receive the IP addresses for the DNS servers.
They get an IP address for themselves when they attempt a TCP/IP connection.

NOTE: When you use DHCP to assign IP addresses to hosts in the Trust zone, the security
device automatically forwards the IP addresses of the DNS servers that it receives
from the ISP to the hosts.

If the IP addresses for the hosts are not dynamically assigned through DHCP, you
must manually enter the IP addresses for the DNS servers on each host.

Every TCP/IP connection that a host in the Trust zone makes to the Untrust
zone automatically goes through the PPPoE encapsulation process.

CLI
1. Interfaces and PPPoE
set interface ethernet0/1 zone trust
set interface ethernet0/1 ip 172.16.30.10/24
set interface ethernet0/3 zone untrust
set pppoe interface ethernet0/3
set pppoe username name_str password pswd_str

To test your PPPoE connection:

exec pppoe connect

get pppoe

Point-to-Point Protocol over Ethernet  245

 Concepts & Examples ScreenOS Reference Guide

2. DHCP Server
set interface ethernet0/1 dhcp server service
set interface ethernet0/1 dhcp server ip 172.16.30.2 to 172.16.30.5
set interface ethernet0/1 dhcp server option lease 60
save
3. Activating PPPoE on the Security Device
1. Turn off the power to the DSL modem, the security device, and the three
workstations.

2. Turn on the DSL modem.

3. Turn on the security device.

4. Activating DHCP on the Internal Network

Turn on the workstations.

The workstations automatically receive the IP addresses for the DNS servers.
They get an IP address for themselves when they attempt a TCP/IP connection.

Every TCP/IP connection that a host in the Trust zone makes to the Untrust
zone automatically goes through the PPPoE encapsulation process.

Configuring PPPoE on Primary and Backup Untrust Interfaces

In the following example, you configure PPPoE for both the primary (ethernet0/3)
and backup (ethernet0/2) interfaces to the Untrust zone.

WebUI
1. PPPoE Configuration for ethernet0/3 Interface
Network > PPP > PPPoE Profile> New: Enter the following, then click OK:

PPPoE instance: eth3-pppoe

Bound to interface: ethernet0/3 (select)
Username: user1
Password: 123456
Authentication: Any (select)
Access Concentrator: ac-11
2. PPPoE Configuration for ethernet0/2 Interface
Network > PPP > PPPoE Profile > New: Enter the following, then click OK:

PPPoE instance: eth2-pppoe

Bound to interface: ethernet0/2 (select)
Username: user2
Password: 654321
Authentication: Any (select)
Access Concentrator: ac-22

CLI
1. PPPoE Configuration for ethernet0/3 Interface
set pppoe name eth3-pppoe username user1 password 123456
set pppoe name eth3-pppoe ac ac-11
set pppoe name eth3-pppoe authentication any
set pppoe name eth3-pppoe interface ethernet0/3

246  Point-to-Point Protocol over Ethernet

 Chapter 8: System Parameters

2. PPPoE Configuration for ethernet0/2 Interface

set pppoe name eth2-pppoe username user2 password 654321
set pppoe name eth2-pppoe ac ac-22
set pppoe name eth2-pppoe authentication any
set pppoe name eth2-pppoe interface ethernet0/2
save

Configuring Multiple PPPoE Sessions over a Single Interface

Some security devices support creation of multiple PPPoE subinterfaces (each with
the same MAC address) for a given physical interface. This support allows you to
establish a private network connection with one ISP and connect to the Internet
through a different ISP using the same physical interface. You can establish these
connections using different user or domain names or be connected simultaneously
to different ISPs.

The maximum number of concurrent PPPoE sessions on a physical interface is

limited only by number of subinterfaces allowed by the device. There is no
restriction on how many physical interfaces can support multiple sessions. You can
specify username, static-ip, idle-timeout, auto-connect, and other parameters
separately for each PPPoE instance or session.

To support a PPPoE session, a subinterface must be untagged. An untagged

interface uses encap (not a VLAN tag) to identify a VLAN for a subinterface. Encap
binds the subinterface to PPPoE encapsulation. By hosting multiple subinterfaces, a
single physical interface can host multiple PPPoE instances. You can configure each
instance to go to a specified Access Concentrator (AC), allowing separate entities
such as ISPs to manage the PPPoE sessions through a single interface. For more
information about VLANs and VLAN tags, see Volume 10: Virtual Systems.

Figure 79: PPPoE with Multiple Sessions

Multiple Subinterfaces Single Physical Interface (e.g. ethernet7)

isp_1 e7 isp_1ac
Three PPPoE Instances isp_2 e7.1 isp_2ac
Three PPPoE Sessions
isp_3 e7.2 isp_3ac

Trust Zone Untrust Zone isp_1ac

isp_2ac

isp_3ac

ethernet7 Access Concentrators

In the following example, you define three PPPoE instances, specify an Access
Concentrator (AC) for each, then initiate each instance.

 Instance isp_1, username user1@domain1, password swordfish, bound to

interface ethernet7. The AC is isp_1ac.

Point-to-Point Protocol over Ethernet  247

 Concepts & Examples ScreenOS Reference Guide

 Instance isp_2, username user2@domain2, password marlin, bound to

subinterface ethernet7.1. The AC is isp_2ac.

 Instance isp_3, username user3@domain3, password trout, bound to

subinterface ethernet7.2. The AC is isp_3ac.

WebUI
1. Interface and Subinterfaces
Network > Interfaces > Edit (for ethernet7):

Enter the following, then click OK:

Zone Name: Untrust

Network > Interfaces > New (Sub-IF):

Enter the following, then click OK:

Interface Name: ethernet7.1

Zone Name: Untrust

Network > Interfaces > New (Sub-IF):

Enter the following, then click OK:

Interface Name: ethernet7.2

Zone Name: Untrust
2. PPPoE Instances and AC
Network > PPP > PPPoE Profile > New:

Enter the following, then click OK:

PPPoE Instance: isp_1

Enable: Enable
Bound to Interface: ethernet7
Username: user1@domain1
Access Concentrator: isp_1ac

Network > PPP > PPPoE Profile > New:

Enter the following, then click OK:

PPPoE Instance: isp_2

Enable: Enable
Bound to Interface: ethernet7.1
Username: user2@domain2
Access Concentrator: isp_2ac

248  Point-to-Point Protocol over Ethernet

 Chapter 8: System Parameters

Network > PPP > PPPoE Profile > New:

Enter the following, then click OK:

PPPoE Instance: isp_3

Enable: Enable
Bound to Interface: ethernet7.2
Username: user3@domain3
Access Concentrator: isp_3ac
3. PPPoE Initiation
Network > PPP > PPPoE Profile > Connect (for isp_1)

Network > PPP > PPPoE Profile > Connect (for isp_2)

Network > PPP > PPPoE Profile > Connect (for isp_3)

CLI
1. Interface and Subinterfaces
set interface ethernet7 zone untrust
set interface ethernet7.1 encap pppoe zone untrust
set interface ethernet7.2 encap pppoe zone untrust
2. PPPoE Instances and ACs
set pppoe name isp_1 username user1@domain1 password swordfish
set pppoe name isp_1 interface ethernet7
set pppoe name isp_1 ac isp_1ac
set pppoe name isp_2 username user2@domain2 password marlin
set pppoe name isp_2 interface ethernet7.1
set pppoe name isp_2 ac isp_2ac
set pppoe name isp_3 username user3@domain3 password trout
set pppoe name isp_3 interface ethernet7.2
set pppoe name isp_3 ac isp_3ac
save
3. PPPoE Initiation
exec pppoe name isp_1 connect
exec pppoe name isp_2 connect
exec pppoe name isp_3 connect

PPPoE and High Availability

Two security devices that support PPPoE in Active/Active mode can handle failover
of a PPPoE connection. Upon initiation of the connection, the primary device
synchronizes its PPPoE state with the backup device. Because the passive device
uses the same IP address as the primary device, it does not have to make a new
PPPoE connection once it becomes the primary. Therefore, it can maintain
communication with the Access Concentrator after failure of the primary. This is
necessary when the PPPoE interface supports VPN connections, and these
connections must continue, using the same interface IP after failover. For more
information about HA configurations, see Volume 11: High Availability.

Point-to-Point Protocol over Ethernet  249

 Concepts & Examples ScreenOS Reference Guide

License Keys
The license key feature allows you to expand the capabilities of your Juniper
Networks security device without having to upgrade to a different device or system
image. You can purchase the following type of keys:

 Advanced

 Capacity

 Extended

 Virtualization

 GTP

 Vsys

 IDP

Each security device ships with a standard set of features enabled and might
support the activation of optional features or the increased capacity of existing
features. For information regarding which features are currently available for
upgrading, refer to the latest marketing literature from Juniper Networks.

The procedure for obtaining and applying a license key is as follows:

1. Gather your authorization code and device serial number.

Authorization Code: A pass key required to generate and activate the license
key that you or your company have purchased for your Juniper Networks
security device. Note: The Authorization Code is required to generate your
license key—it is not the actual license key.

Device Serial Number: A unique 16-character code Juniper Networks uses to

identify your particular security device when generating license keys. You can
find the device serial number at the bottom or back of the device. You can also
find the serial number in the device information section in the GUI or by
executing a “get system” command on the CLI.

2. Sign into the Juniper Networks License Management System (LMS) at

www.juniper.net/generate_license/, select Firewall/IPSec VPN and Intrusion
Prevention, then follow the instructions in the system user interface.

3. The LMS provides the license key in one of two ways:

 Download the license key to your computer.

 Receive an email that contains your license key.

250  License Keys

 Chapter 8: System Parameters

4. Install the license key in one of the following ways:

WebUI
Configuration > Update > ScreenOS/Keys > Select License Key Update
(Features) > click Browse > select the file with the license key, then click
Apply.

CLI
exec license-key key_num

Registration and Activation of Subscription Services

Before your Juniper Networks security device can receive regular subscription
service for antivirus (AV) patterns, Deep Inspection (DI) signatures, anti-spam, or
Web filtering, you must do the following:

 Purchase a subscription

 Register the subscription

 Retrieve the subscription key

Retrieving the subscription license key activates your services on the device for the
time period purchased. Your specific service-activation process depends upon
which services you purchased and the method you used to purchase them.

Trial Service
To allow you to use AV, DI, anti-spam, or Web filtering services, the security device
provides a trial period. During this period, the device can obtain temporary
services. To retrieve eligible trial license keys from the entitlement server, use the
exec license-key update trials CLI command.

 No Juniper Networks security device comes with DI already enabled. To obtain

trial DI service, you must start a WebUI session, then click Retrieve
Subscriptions Now in Configuration > Update > ScreenOS/Keys. This action
provides a one-time, one-day DI key.

 If your device has AV service bundled at the time of purchase, then the device
has preinstalled trial service. This trial service lasts up to 60 days.

 Anti-spam

 No Juniper Networks security device comes with Web filtering already enabled.
This feature does not have a trial service.

CAUTION: To avoid service interruption, you must register your Juniper Networks
security device as soon as possible after purchasing your subscription.
Registration ensures continuation of the subscription.

Registration and Activation of Subscription Services  251

 Concepts & Examples ScreenOS Reference Guide

Updating Subscription Keys

If there is any software with an expiration date installed in the security device, the
device periodically connects to the entitlement server to retrieve the subscription
keys. The device connects to the entitlement server, the LMS, under all of following
conditions:

 Key expires in two months

 Key expires in one month

 Key expires in two weeks

 Key expires

 30 days after key expires

NOTE: To delete a single license key from the key file, use the exec license-key delete
name_str CLI command.

Adding Antivirus, Web Filtering, Anti-Spam, and Deep Inspection to an Existing or a New
Device
After purchasing AV, Web filtering, anti-spam, or deep inspection (DI) subscriptions
to add to your existing Juniper Networks security device, perform the following
steps to activate the services:

1. After ordering the subscription, you should receive an authorization code, via
email, from Juniper Networks or your authorized VAR. This code is a readable
document that contains information you need to register your subscription.

2. Make sure the device is registered. If it is not currently registered, go to the

following site:

http://tools.juniper.net/subreg

3. Register the subscription authorization code to the device.

4. Confirm that your device has Internet connectivity.

5. Retrieve the subscription key on the device. You can do this in one of two ways:

 In the WebUI, click Retrieve Subscriptions Now from Configuration >

Update > ScreenOS/Keys.

 Using the CLI, run the following command:

exec license-key update

6. You must reset the device after the key has been loaded.

You can now configure the device to automatically or manually retrieve the
signature services. For instructions on configuring your security device for these
services, see the following sections:

252  Registration and Activation of Subscription Services

 Chapter 8: System Parameters

 “Fragment Reassembly” on page 4-58

 “Antivirus Scanning” on page 4-62

 “Web Filtering” on page 4-98

System Clock
It is important that your Juniper Networks security device always be set to the right
time. Among other things, the time on your device affects the set up of VPN tunnels
and the timing of schedules. First, to ensure that the device always maintains the
proper time, you must set the system clock to the current time. Next, you can
enable the daylight saving time (DST) option, and you can configure up to three
Network Time Protocol (NTP) servers (one primary and two backups) from which
the device can regularly update its system clock.

Date and Time

To set the clock to the current date and time, you can use the WebUI or the CLI.
Through the WebUI, you do this by synchronizing the system clock with the clock
on your computer:

1. Configuration > Date/Time: Click the Sync Clock with Client button.

A pop-up message prompts you to specify if you have enabled the DST option
on your computer clock.

2. Click Yes to synchronize the system clock and adjust it according to DST, or
click No to synchronize the system clock without adjusting it for DST.

Through the CLI, you set the clock by manually entering the date and time using the
following command:

set clock mm/dd/yyyy hh:mm:ss

Daylight Saving Time

Daylight saving time (DST) is a widely used system of adjusting the official local
time forward in summer months in order to save energy and allow more daylight
for work and school activities.

DST is observed differently in various countries. Accordingly, you can choose the
appropriate DST settings that apply to your country.

You can set the DST adjustment to recur on a weekday schedule (for example, the
first Sunday in April) or on a specific date. You also can set DST adjustment not to
recur, in which case you can adjust DST settings only for a single year.

Time Zone
You set the time zone by specifying the number of hours by which the local time for
the security device is behind or ahead of GMT (Greenwich Mean Time). For
example, if the local time zone for the device is Pacific Standard Time, it is 8 hours
behind GMT. Therefore, you have to set the clock to -8.

System Clock  253

 Concepts & Examples ScreenOS Reference Guide

If you set the time zone using the WebUI:

Configuration > Date/Time > Set Time Zone_hours_minutes from GMT

If you set the time zone using the CLI:

device -> set clock timezone number (a number from -12 to 12)
or

device-> set ntp timezone number (a number from -12 to 12)

Network Time Protocol

To ensure that the security device always maintains the right time, it can use
Network Time Protocol (NTP) to synchronize its system clock with that of an NTP
server over the Internet. You can do this manually or configure the device to
perform this synchronization automatically at time intervals that you specify.

Configuring Multiple NTP Servers

You can configure up to three NTP servers on a Juniper Networks security device:
one primary server and two backup servers. When you configure the security
device to synchronize its system clock automatically, it queries each configured NTP
server sequentially. The device always queries the primary NTP server first. If the
query is not successful, the device then queries the first backup NTP server and so
on until it gets a valid reply from one of the NTP servers configured on the device.
The device makes four attempts on each NTP server before it terminates the update
and logs the failure.

When you manually synchronize the system clock, and you can only do this using
the CLI, you can specify a particular NTP server or none at all. If you specify an NTP
server, the security device queries that server only. If you do not specify an NTP
server, the device queries each NTP server configured on the device sequentially.
You can specify an NTP server using its IP address or its domain name.

Configuring a Backup NTP Server

You can specify an individual interface as the source address to direct NTP requests
from the device (over a VPN tunnel to the primary NTP server) or to a backup
server. You can also select a loopback interface to perform this function.

The security device sends NTP requests from a source interface and optionally uses
an encrypted, preshared key when sending NTP requests to the NTP server. The key
provides authentication.

In the following example, you configure the primary NTP server and two backup
NTP servers by assigning an IP address to each server. Next, you set each server to
send NTP requests from the Trust interface. After that, you set the key ID and
preshared key for each server.

WebUI
Configuration > Date/Time: Enter the following, then click Apply:

Primary Server IP/Name: 1.1.1.1

Primary server Key ID: 10

254  System Clock

 Chapter 8: System Parameters

Source interface: Select Trust from the list.

Preshared Key: !2005abc
Backup Server1 IP/Name: 1.1.1.2
Primary server Key ID: 10
Source interface: Select Trust from the list.
Preshared Key: !2005abc
Backup Server2 IP/Name: 1.1.1.3
Primary server Key ID: 10
Source interface: Select Trust from the list.
Preshared Key: !2005abc

CLI
set ntp server 1.1.1.1
set ntp server backup1 1.1.1.2
set ntp server backup2 1.1.1.3
set ntp server src-interface trust
set ntp server backup1 src-interface trust
set ntp server backup2 src-interface trust
set ntp server key-id 10 pre-share-key !2005abc
set ntp server backup1 key-id 10 pre-share-key !2005abc
set ntp server backup2 key-id 10 pre-share-key !2005abc
save

Device as an NTP Server

A security device can also work as an NTP server serving NTP requests from its
subnet peers. To use this feature, you need to enable NTP service on any of the
Layer 3 interface with an IP address.

NOTE: Currently, ScreenOS supports only Unicast mode.

WebUI
Network > Interfaces > Edit (for ethernet0/0) > Basic: check the NTP Server
check box, then click Apply.

CLI
set interface interface ntp-server
save

Maximum Time Adjustment

For automatic synchronization, you can specify a maximum time adjustment value
(in seconds). The maximum time adjustment value represents the acceptable time
difference between the security device system clock and the time received from an
NTP server. The device only adjusts its clock with the NTP server time if the time
difference between its clock and the NTP server time is within the maximum time
adjustment value that you set. For example, if the maximum time adjustment value
is 3 seconds, and the time on the device system clock is 4:00:00 and the NTP server
sends 4:00:02 as the time, the difference in time between the two is acceptable and
the device can update its clock. If the time adjustment is greater than the value you
set, the device does not synchronize its clock and proceeds to try the first backup

System Clock  255

 Concepts & Examples ScreenOS Reference Guide

NTP server configured on the device. If the device does not receive a valid reply
after trying all the configured NTP servers, it generates an error message in the
event log. The default value for this feature is 3 seconds and the range is 0 (no limit)
to 3600 (one hour).

When you manually synchronize the system clock, and you can only do this using
the CLI, the security device does not verify the maximum time adjustment value.
Instead, if it receives a valid reply, the device displays a message informing you of
which NTP server it reached, what the time adjustment is, and the type of
authentication method used. The message also asks you to confirm or cancel the
system clock update.

If the security device does not receive a reply, it displays a timeout message. This
message appears only after the device unsuccessfully attempted to reach all NTP
servers configured on the device.

NOTE: When issuing requests using the CLI, you can cancel the current request by
pressing Ctrl-C on the keyboard.

NTP and NSRP

NetScreen Redundancy Protocol (NSRP) contains a mechanism for synchronizing
the system clock of NSRP cluster members. Although the resolution for
synchronization is in seconds, NTP has sub-second resolution. Because the time on
each cluster member might differ by a few seconds due to processing delays, we
recommend that you disable NSRP time synchronization when NTP is enabled on
both cluster members (meaning that each member can updates its system clock
from an NTP server). To disable the NSRP time synchronization function, enter the
set ntp no-ha-sync CLI command.

Setting a Maximum Time Adjustment Value to an NTP Server

In the following example you configure the security device to update its clock at
five-minute intervals from NTP servers at IP addresses 1.1.1.1, 1.1.1.2, and 1.1.1.3.
You also set a maximum time adjustment value of 2 seconds.

WebUI
Configuration > Date/Time: Enter the following, then click Apply:

Automatically synchronize with an Internet Time Server (NTP): (select)

Update system clock every minutes: 5
Maximum time adjustment seconds: 2
Primary Server IP/Name: 1.1.1.1
Backup Server1 IP/Name: 1.1.1.2
Backup Server2 IP/Name: 1.1.1.3

256  System Clock

 Chapter 8: System Parameters

CLI
set clock ntp
set ntp server 1.1.1.1
set ntp server backup1 1.1.1.2
set ntp server backup2 1.1.1.3
set ntp interval 5
set ntp max-adjustment 2
save

Securing NTP Servers

You can secure NTP traffic by using MD5-based checksum to provide authentication
of NTP packets. You do not need to create an IPSec tunnel. This type of
authentication ensures the integrity of NTP traffic. It does not prevent outside
parties from viewing the data, but it prevents anyone from tampering with it.

To enable the authentication of NTP traffic, you must assign a unique key ID and
preshared key to each NTP server you configure on a security device. The key ID
and preshared key serve to create a checksum with which the security device and
the NTP server can authenticate the data.

Table 38 describes the two types of authentication for NTP traffic.

Table 38: NTP Traffic Authentication

Type Description
Required When selected, the security device must include the authentication
information—key id and checksum—in every packet it sends to an NTP server and
must authenticate all NTP packets it receives from an NTP server. Before
authentication can occur between a security device and an NTP server, the
administrators of the security device and the NTP server must first exchange a key
id and a preshared key. They have to exchange these manually and can do so in
different ways such as via email or telephone.
Preferred When selected, the security device must first operate as in Required mode by
trying to authenticate all NTP traffic. If all attempts to authenticate fail, the security
device then operates as if you selected no authentication. It sends out packets to
an NTP server without including a key id and checksum. Essentially, although there
is a preference for authentication, if authentication fails, the security device still
permits NTP traffic.

System Clock  257

 Concepts & Examples ScreenOS Reference Guide

258  System Clock

Index
A users ........................................................................171
access policies
See policies B
address books bandwidth.....................................................................174
addresses guaranteed .............................................174, 193, 199
adding................................................................104 managing................................................................193
modifying ..........................................................105 maximum ...............................................174, 193, 199
removing ...........................................................108 maximum, unlimited ............................................194
entries .....................................................................104 priority
group entries, editing............................................108 default ................................................................198
groups .....................................................................105 levels ..................................................................198
See also addresses queues ...............................................................197
address groups .....................................................105, 166 bridge groups
creating ...................................................................107 logical interface .......................................................37
editing .....................................................................108 unbinding .................................................................46
entries, removing ..................................................108
options ....................................................................106 C
addresses CLI
address book entries..................................104 to 108 set arp always-on-dest ......................................74, 77
defined ...................................................................166 clock, system
in policies ...............................................................166 See system clock
IP, host and network IDs ........................................47 CPE routers ...................................................................220
negation .................................................................187 custom services............................................................120
netmasks ................................................................103 custom services, in root and vsys ..............................121
private.......................................................................48
public ........................................................................47 D
wildcards ........................................................103, 166 DDNS servers ...............................................................220
aggregate interfaces ......................................................37 DDO
alarms servers ....................................................................220
thresholds...............................................................173 servers, setting up DDNS for ...............................222
ALGs DHCP ...............................................................96, 100, 243
for custom services ...............................................168 client .......................................................................226
MS RPC ...................................................................127 HA ...........................................................................232
RTSP .......................................................................129 PXE scenario ..........................................................237
application options, in policies ..................................168 relay agent .............................................................226
ARP..................................................................................82 server ......................................................................226
gratuitous .................................................................45 DiffServ .........................................................174, 200, 214
ARP, ingress IP address .................................................84 See also DSCP marking
auth users DIP ................................................................98, 141 to 145
pre-policy auth .......................................................172 fix-port ....................................................................144
run-time authentication ........................................171 groups ..........................................................154 to 156
WebAuth ................................................................172 PAT ..................................................................142, 143
authentication pools .......................................................................170
Allow Any ...............................................................172 pools, modifying ....................................................144
policies....................................................................170 DNS ...............................................................................217

Index  IX-I
 Concepts & Examples ScreenOS Reference Guide

addresses, splitting ............................................... 224 modifying .................................................................49

dynamic ................................................................. 220 physical
lookups ................................................................... 218 in security zones ................................................36
lookups, domain ................................................... 223 policy-based NAT tunnel ........................................39
servers .................................................................... 244 redundant.................................................................37
servers, tunneling to ............................................. 223 secondary IP addresses ..........................................51
status table ............................................................. 219 state changes ...........................................................61
Domain Name System tunnel.........................................................39, 39 to 42
See DNS up, logically ..............................................................61
DSCP marking ............................................. 194, 200, 214 up, physically ...........................................................61
dual-stack environment .............................................. 130 viewing interface tables..........................................43
dynamic DNS servers.................................................. 220 virtual HA .................................................................39
VLAN1.......................................................................81
F VSI .............................................................................38
function zone interfaces ............................................... 38 zones, unbinding from ...........................................46
HA ............................................................................. 38 interfaces, monitoring ..........................................68 to 73
management ........................................................... 38 loops .........................................................................69
security zones ..........................................................73
G Internet Service Providers ..........................................223
G-ARP .............................................................................. 45 IP addresses
graphs, historical ......................................................... 173 host IDs ....................................................................47
groups interfaces, tracking on ............................................63
addresses ............................................................... 105 L3 security zones ...........................................47 to 48
services................................................................... 139 Manage .....................................................................95
network IDs .............................................................47
H ports, defining for each ........................................104
HA private ......................................................................47
See also NSRP private address ranges ...........................................48
hardware sessions ....................................................... 137 public ........................................................................47
high availability secondary .................................................................51
DHCP ...................................................................... 232 secondary, routing between ..................................51
interfaces, virtual HA .............................................. 39 IP pools
historical graphs .......................................................... 173 See DIP pools
IP tracking
I dynamic option .......................................................64
ICMP services ............................................................... 125 interfaces, shared ....................................................64
message codes ...................................................... 125 interfaces, supported ..............................................63
message types ....................................................... 125 object failure threshold ...........................................65
interfaces rerouting traffic ..............................................63 to 78
addressing ................................................................ 47 vsys ...........................................................................64
aggregate.................................................................. 37 weights .....................................................................65
binding to zone ....................................................... 44 IP tracking, failure
connections, monitoring ........................................ 63 egress interface, on ........................................75 to 76
default ...................................................................... 48 ingress interface, on ......................................76 to 78
DIP .......................................................................... 141 tracked IP threshold ................................................64
down, logically ........................................................ 61 ISP .................................................................................223
down, physically ..................................................... 61
function zone ........................................................... 38 K
HA function zone .................................................... 38 keys, license .................................................................250
interface tables, viewing ........................................ 43
IP tracking (See IP tracking) L
L3 security zones .................................................... 47 L2TP policies ................................................................169
loopback ................................................................... 58 license keys ..................................................................250
MGT .......................................................................... 38 logging ..........................................................................172

IX-II  Index
 Index

loopback interfaces .......................................................58 authentication ........................................................170

bidirectional VPNs .................................................168
M changing .................................................................190
Manage IP .......................................................................95 counting ..................................................................173
MGT interface .................................................................38 deep inspection (DI) ..............................................169
MIP ..................................................................................11 deny ........................................................................167
MIP, to zone with interface-based NAT ........................94 DIP groups..............................................................155
modes disabling .................................................................190
NAT, traffic to Untrust zone ...................................79 editing .....................................................................190
Transparent..............................................................80 enabling ..................................................................190
MS RPC ALG, defined ..................................................127 functions of ............................................................159
global ......................................................162, 175, 185
N HA session backup ................................................172
NAT mode ..............................................................92 to 97 ID .............................................................................166
interface settings .....................................................95 internal rules ..........................................................164
traffic to Untrust zone.......................................79, 94 interzone ................................................161, 175, 179
NAT-Protocol Translation .............................................126 intrazone ................................................161, 175, 183
NAT-PT ...........................................................................126 L2TP ........................................................................169
NAT-src, Route mode .....................................................98 L2TP tunnels ..........................................................169
negation, address ........................................................187 lookup sequence ....................................................163
NetInfo ..........................................................................226 management ..........................................................175
netmasks ................................................................48, 166 managing bandwidth ............................................193
netmasks, classifying device addresses by ...............103 maximum limit ......................................................107
network, bandwidth ....................................................193 multiple items per component ............................186
NSRP name .......................................................................168
DHCP ......................................................................232 NAT-dst ...................................................................170
DIP groups ..................................................154 to 156 NAT-src ...................................................................170
HA session backup ................................................172 no hardware session .............................................170
NTP synchronization ............................................256 order .......................................................................191
redundant interfaces ...............................................37 permit .....................................................................167
VSIs ...........................................................................38 policy context ........................................................186
NTP.....................................................................254 to 257 policy set lists.........................................................163
authentication types .............................................257 position at top ................................................169, 191
maximum time adjustment .................................255 reject .......................................................................167
multiple servers .....................................................254 removing ................................................................192
NSRP synchronization ..........................................256 reordering...............................................................191
secure servers ........................................................257 required elements .................................................160
servers ....................................................................254 root system ............................................................164
service ....................................................................257 schedules ................................................................173
security zones ........................................................166
P service book ...........................................................108
packet flow ............................................................10 to 12 service groups ........................................................139
PAT .........................................................................137, 142 services ...................................................................167
physical interface services in ......................................................108, 167
logical interface .......................................................36 shadowing ......................................................190, 191
Point-to-Point Tunneling Protocol (PPTP) ..................137 traffic logging .........................................................172
policies ..............................................................................3 traffic shaping ........................................................173
actions ....................................................................167 tunnel ......................................................................167
address groups ......................................................166 types ............................................................161 to 162
address negation ...................................................187 verifying..................................................................190
addresses ...............................................................166 virtual systems .......................................................164
addresses in ...........................................................166 VPN dialup user groups ........................................166
alarms .....................................................................173 VPNs........................................................................168
application, linking service to explicitly .............168 policy-based NAT, tunnel interfaces .............................39

Index  IX-III
 Concepts & Examples ScreenOS Reference Guide

Port Address Translation ScreenOS interfaces

See PAT security zones ............................................................3
port address translation (PAT) .................................... 137 subinterfaces..............................................................3
PPTP.............................................................................. 137 secondary IP addresses ................................................51
PPTP ALG ..................................................................... 137 security zones ..................................................................2
priority queuing ........................................................... 197 determination, destination zone ...........................12
private addresses ........................................................... 48 determination, source zone ...................................10
public addresses ............................................................ 47 global ..........................................................................2
PXE ................................................................................ 237 predefined ..................................................................2
PXE server .................................................................... 237 security zones, interfaces ...............................................3
physical ....................................................................36
Q servers
QoS ............................................................................... 193 DDNS ......................................................................220
DDO ........................................................................220
R setting up DDNS for DDO ....................................222
RFCs service book
0792, Internet Control Message Protocol ...........125 entries, modifying (CLI) ........................................122
1349, Type of Service in the Internet Protocol Suite .. entries, removing (CLI) .........................................122
174 service book, services
1918, Address Allocation for Private Internets .....48 adding .....................................................................121
2132, DHCP Options and BOOTP Vendor Extensions custom ....................................................................108
230 custom (CLI) ...........................................................121
2326, Real Time Streaming Protocol (RTSP).......133 preconfigured ........................................................108
2474, Definition of the Differentiated Services Field service groups ...................................................139 to 141
(DS Field) in the IPv4 and IPv6 Headers ...........174 creating...................................................................139
Route mode ......................................................... 98 to 101 deleting ...................................................................141
interface settings ..................................................... 99 modifying ...............................................................140
NAT-src ..................................................................... 98 service groups (WebUI) ...............................................139
routers, CPE.................................................................. 220 services .........................................................................108
RTSP ALG defined ...................................................................167
defined ................................................................... 129 drop-down list........................................................108
dual-stack environment........................................ 130 ICMP .......................................................................125
request methods ................................................... 130 in policies ...............................................................167
servers in private domain .................................... 133 timeout threshold ..................................................122
servers in public domain ...................................... 135 services, custom ..........................................................120
status codes ........................................................... 132 ALGs ........................................................................168
rules, derived from policies ........................................ 164 in vsys.....................................................................121
run-time authentication .............................................. 171 subinterfaces ....................................................................3
creating (root system) .............................................50
S deleting .....................................................................50
schedules .............................................................. 157, 173 subscriptions
SCREEN, MGT zone ....................................................... 28 registration and activation ........................251 to 252
ScreenOS temporary service .................................................251
function zones ......................................................... 33 Sun RPC ALG
global zone ............................................................... 28 call scenarios .........................................................126
overview ..................................................................... 1 system clock ......................................................253 to 257
packet flow ..................................................... 10 to 12 date & time ............................................................253
policies ....................................................................... 3 sync with client .....................................................253
security zones ...................................................... 2, 28 time zone ...............................................................253
security zones, global ............................................... 2 system parameters ......................................................257
security zones, predefined ....................................... 2
tunnel zones ............................................................ 29 T
virtual systems .......................................................... 9 tags, VLANs ......................................................................3
zones ............................................................... 25 to 33 time zone ......................................................................253

IX-IV  Index
 Index

trace-route ......................................................................85 Z
traffic zones ......................................................................25 to 33
counting .................................................................173 defining.....................................................................30
logging ....................................................................172 editing .......................................................................31
priority ....................................................................174 function ....................................................................33
shaping ...................................................................193 function, MGT interface ..........................................38
traffic shaping ..............................................................193 global ........................................................................28
service priorities ....................................................197 global security ............................................................2
Transparent mode ................................................80 to 92 Layer 2 ......................................................................81
ARP/trace-route .......................................................83 tunnel ........................................................................29
blocking non-ARP traffic ........................................82 VLAN ...................................................................33, 81
blocking non-IP traffic ............................................82 zones, ScreenOS ...................................................25 to 33
broadcast traffic ......................................................81 predefined ..................................................................2
flood ..........................................................................83 security interfaces .....................................................3
routes ........................................................................82 zones, security ...........................................................2, 28
unicast options ........................................................83 determination, destination zone ...........................12
tunnel interfaces ............................................................39 determination, source zone ...................................10
definition ..................................................................39 global ..........................................................................2
policy-based NAT ....................................................39 interfaces, monitoring ............................................73
interfaces, physical .................................................36
U
unknown unicast options ....................................82 to 87
ARP ..................................................................84 to 87
flood .................................................................83 to 84
trace-route ................................................................85
URL filtering
See Web filtering

V
VIP ...................................................................................11
VIP, to zone with interface-based NAT ........................94
virtual HA interfaces ......................................................39
virtual routers
See VRs
virtual systems .................................................................9
VLAN zone ......................................................................81
VLAN1
interface .............................................................81, 87
zones.........................................................................81
VLANs, tags ......................................................................3
VPNs
policies....................................................................168
to zone with interface-based NAT .........................94
tunnel zones ............................................................29
VRs
forwarding traffic between ......................................4
introduction ...............................................................4

W
Web filtering .................................................................172
WebAuth, pre-policy auth process .............................172
wildcard addresses ......................................................166
wireless interface
logical interface .......................................................36

Index  IX-V
 Concepts & Examples ScreenOS Reference Guide

IX-VI  Index
Concepts & Examples
ScreenOS Reference Guide

Volume 3:
Administration

Release 6.1.0, Rev. 02

Juniper Networks, Inc.

1194 North Mathilda Avenue
Sunnyvale, CA 94089
USA
408-745-2000
www.juniper.net
 Copyright Notice
Copyright © 2008 Juniper Networks, Inc. All rights reserved.

Juniper Networks, the Juniper Networks logo, JUNOS, NetScreen, ScreenOS, and Steel-Belted Radius are registered trademarks of Juniper Networks, Inc.
in the United States and other countries. JUNOSe is a trademark of Juniper Networks, Inc. All other trademarks, service marks, registered trademarks, or
registered service marks are the property of their respective owners.

All specifications are subject to change without notice. Juniper Networks assumes no responsibility for any inaccuracies in this document or for any
obligation to update information in this document. Juniper Networks reserves the right to change, modify, transfer, or otherwise revise this publication
without notice.

FCC Statement
The following information is for FCC compliance of Class A devices: This equipment has been tested and found to comply with the limits for a Class A
digital device, pursuant to part 15 of the FCC rules. These limits are designed to provide reasonable protection against harmful interference when the
equipment is operated in a commercial environment. The equipment generates, uses, and can radiate radio-frequency energy and, if not installed and
used in accordance with the instruction manual, may cause harmful interference to radio communications. Operation of this equipment in a residential
area is likely to cause harmful interference, in which case users will be required to correct the interference at their own expense.

The following information is for FCC compliance of Class B devices: The equipment described in this manual generates and may radiate radio-frequency
energy. If it is not installed in accordance with Juniper Networks’ installation instructions, it may cause interference with radio and television reception.
This equipment has been tested and found to comply with the limits for a Class B digital device in accordance with the specifications in part 15 of the FCC
rules. These specifications are designed to provide reasonable protection against such interference in a residential installation. However, there is no
guarantee that interference will not occur in a particular installation.

If this equipment does cause harmful interference to radio or television reception, which can be determined by turning the equipment off and on, the user
is encouraged to try to correct the interference by one or more of the following measures:

 Reorient or relocate the receiving antenna.

 Increase the separation between the equipment and receiver.

 Consult the dealer or an experienced radio/TV technician for help.

 Connect the equipment to an outlet on a circuit different from that to which the receiver is connected.

Caution: Changes or modifications to this product could void the user's warranty and authority to operate this device.

Disclaimer
THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED
WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED
WARRANTY, CONTACT YOUR JUNIPER NETWORKS REPRESENTATIVE FOR A COPY.

ii 
Table of Contents
About This Volume vii
Document Conventions.................................................................................. vii
Web User Interface Conventions ............................................................ vii
Command Line Interface Conventions ................................................... viii
Naming Conventions and Character Types ............................................ viii
Illustration Conventions ............................................................................ x
Requesting Technical Support .......................................................................... x
Self-Help Online Tools and Resources....................................................... xi
Opening a Case with JTAC ........................................................................ xi
Document Feedback ....................................................................................... xi

Chapter 1 Administration 1
Management via the Web User Interface ......................................................... 2
WebUI Help ............................................................................................... 2
Copying the Help Files to a Local Drive ............................................... 3
Pointing the WebUI to the New Help Location .................................... 3
HyperText Transfer Protocol...................................................................... 4
Session ID.................................................................................................. 4
Secure Sockets Layer ................................................................................. 5
SSL Configuration................................................................................ 7
Redirecting HTTP to SSL ..................................................................... 8
Management via the Command Line Interface................................................. 9
Telnet ........................................................................................................ 9
Securing Telnet Connections ................................................................... 10
Secure Shell ............................................................................................. 11
Client Requirements.......................................................................... 12
Basic SSH Configuration on the Device ............................................. 13
Authentication .................................................................................. 14
SSH and Vsys .................................................................................... 16
Host Key ........................................................................................... 16
Example: SSHv1 with PKA for Automated Logins ............................. 17
Secure Copy ............................................................................................ 18
Serial Console.......................................................................................... 19
Remote Console ...................................................................................... 20
Remote Console Using V.92 Modem Port.......................................... 20
Remote Console Using an AUX Port.................................................. 21
Modem Port ............................................................................................ 22
Management via NetScreen-Security Manager ............................................... 22
Initiating Connectivity Between NSM Agent and the MGT System ........... 23
Enabling, Disabling, and Unsetting NSM Agent........................................ 24
Setting the Primary Server IP Address of the Management System ......... 25
Setting Alarm and Statistics Reporting..................................................... 25
Configuration Synchronization ................................................................ 26

Table of Contents  iii

 Concepts & Examples ScreenOS Reference Guide

Example: Viewing the Configuration State ........................................ 27

Example: Retrieving the Configuration Hash..................................... 27
Retrieving the Configuration Timestamp ................................................. 27
Controlling Administrative Traffic .................................................................. 28
MGT and VLAN1 Interfaces...................................................................... 29
Example: Administration Through the MGT Interface .......................29
Example: Administration Through the VLAN1 Interface .................... 29
Setting Administrative Interface Options ................................................. 30
Setting Manage IPs for Multiple Interfaces ............................................... 31
Levels of Administration ................................................................................ 33
Root Administrator .................................................................................. 33
Read/Write Administrator........................................................................ 34
Read-Only Administrator......................................................................... 34
Virtual System Administrator................................................................... 34
Virtual System Read-Only Administrator ................................................. 35
Defining Admin Users .................................................................................... 35
Example: Adding a Read-Only Admin ..................................................... 35
Example: Modifying an Admin ................................................................ 35
Example: Deleting an Admin ................................................................... 36
Example: Configuring Admin Accounts for Dialup Connections............... 36
Example: Clearing an Admin’s Sessions .................................................. 37
Securing Administrative Traffic ...................................................................... 37
Changing the Port Number ...................................................................... 38
Changing the Admin Login Name and Password ..................................... 39
Example: Changing an Admin User’s Login Name and Password ..... 40
Example: Changing Your Own Password .......................................... 40
Setting the Minimum Length of the Root Admin Password ............... 41
Resetting the Device to the Factory Default Settings................................ 41
Restricting Administrative Access ............................................................ 42
Example: Restricting Administration to a Single Workstation............ 42
Example: Restricting Administration to a Subnet .............................. 42
Restricting the Root Admin to Console Access .................................. 42
VPN Tunnels for Administrative Traffic....................................................43
Administration Through a Route-Based Manual Key VPN Tunnel ...... 44
Administration Through a Policy-Based Manual Key VPN Tunnel...... 47
Password Policy ............................................................................................. 51
Setting a Password Policy ........................................................................ 51
Removing a Password Policy ................................................................... 52
Viewing a Password Policy ...................................................................... 52
Recovering from a Rejected Default Admin Password ............................. 52
Creating a Login Banner................................................................................. 53

Chapter 2 Monitoring Security Devices 55

Storing Log Information ................................................................................. 55
Event Log ....................................................................................................... 57
Viewing the Event Log by Severity Level and Keyword............................ 58
Sorting and Filtering the Event Log.......................................................... 59
Downloading the Event Log..................................................................... 60
Example: Downloading the Entire Event Log .................................... 60
Example: Downloading the Event Log for Critical Events .................. 60
Traffic Log...................................................................................................... 61
Viewing the Traffic Log ............................................................................ 62
Example: Viewing Traffic Log Entries................................................ 62
Sorting and Filtering the Traffic Log .................................................. 62

iv  Table of Contents
 Table of Contents

Example: Sorting the Traffic Log by Time ......................................... 63

Removing the Reason for Close Field ...................................................... 64
Self Log .......................................................................................................... 66
Viewing the Self Log ................................................................................ 66
Sorting and Filtering the Self Log ...................................................... 66
Example: Filtering the Self Log by Time ............................................ 67
Downloading the Self Log ........................................................................ 67
Downloading the Asset Recovery Log ............................................................ 68
Traffic Alarms ................................................................................................ 68
Example: Policy-Based Intrusion Detection.............................................. 69
Example: Compromised System Notification........................................... 70
Example: Sending Email Alerts................................................................ 71
Syslog ............................................................................................................ 71
Example: Enabling Multiple Syslog Servers.............................................. 72
Enabling WebTrends for Notification Events ........................................... 72
Simple Network Management Protocol .......................................................... 74
Implementation Overview ....................................................................... 76
Defining a Read/Write SNMP Community ............................................... 77
VPN Tunnels for Self-Initiated Traffic ............................................................. 78
Example: Self-Generated Traffic Through a Route-Based Tunnel.............. 79
Example: Self-Generated Traffic Through a Policy-Based Tunnel ............. 86
Viewing Screen Counters ............................................................................... 92

Index..........................................................................................................................IX-I

Table of Contents  v
 Concepts & Examples ScreenOS Reference Guide

vi  Table of Contents
About This Volume

Juniper Networks security devices provide different ways for you to manage the
devices, either locally or remotely. Volume 3: Administration contains the following
chapters:

 Chapter 1, “Administration,” explains the different means available for

managing a security device both locally and remotely. This chapter also
explains the privileges pertaining to each of the four levels of network
administrators that can be defined.

 Chapter 2, “Monitoring Security Devices,” explains various monitoring methods

and provides guidance in interpreting monitoring output.

Document Conventions
This document uses the conventions described in the following sections:

 “Web User Interface Conventions” on page vii

 “Command Line Interface Conventions” on page viii

 “Naming Conventions and Character Types” on page viii

 “Illustration Conventions” on page x

Web User Interface Conventions

The Web user interface (WebUI) contains a navigational path and configuration
settings. To enter configuration settings, begin by clicking a menu item in the
navigation tree on the left side of the screen. As you proceed, your navigation path
appears at the top of the screen, with each page separated by angle brackets.

The following example shows the WebUI path and parameters for defining an
address:

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: addr_1

IP Address/Domain Name:
IP/Netmask: (select), 10.2.2.5/32
Zone: Untrust

Document Conventions  vii

 Concepts & Examples ScreenOS Reference Guide

To open Online Help for configuration settings, click the question mark (?) in the
upper left of the screen.

The navigation tree also provides a Help > Config Guide configuration page to help
you configure security policies and Internet Protocol Security (IPSec). Select an
option from the list, and follow the instructions on the page. Click the ? character in
the upper left for Online Help on the Config Guide.

Command Line Interface Conventions

The following conventions are used to present the syntax of command line
interface (CLI) commands in text and examples.

In text, commands are in boldface type and variables are in italic type.

In examples:

 Variables are in italic type.

 Anything inside square brackets [ ] is optional.

 Anything inside braces { } is required.

 If there is more than one choice, each choice is separated by a pipe ( | ). For
example, the following command means “set the management options for the
ethernet1, the ethernet2, or the ethernet3 interface”:

set interface { ethernet1 | ethernet2 | ethernet3 } manage

NOTE: When entering a keyword, you only have to type enough letters to identify the
word uniquely. Typing set adm u whee j12fmt54 will enter the command set
admin user wheezer j12fmt54. However, all the commands documented in this
guide are presented in their entirety.

Naming Conventions and Character Types

ScreenOS employs the following conventions regarding the names of objects—such
as addresses, admin users, auth servers, IKE gateways, virtual systems, VPN
tunnels, and zones—defined in ScreenOS configurations:

 If a name string includes one or more spaces, the entire string must be
enclosed within double quotes; for example:

set address trust “local LAN” 10.1.1.0/24

 Any leading spaces or trailing text within a set of double quotes are trimmed;
for example, “ local LAN ” becomes “local LAN”.

 Multiple consecutive spaces are treated as a single space.

 Name strings are case-sensitive, although many CLI keywords are

case-insensitive. For example, “local LAN” is different from “local lan”.

ScreenOS supports the following character types:

viii  Document Conventions

 About This Volume

 Single-byte character sets (SBCS) and multiple-byte character sets (MBCS).

Examples of SBCS are ASCII, European, and Hebrew. Examples of MBCS—also
referred to as double-byte character sets (DBCS)—are Chinese, Korean, and
Japanese.

 ASCII characters from 32 (0x20 in hexadecimals) to 255 (0xff), except double

quotes ( “ ), which have special significance as an indicator of the beginning or
end of a name string that includes spaces.

NOTE: A console connection only supports SBCS. The WebUI supports both SBCS and
MBCS, depending on the character sets that your browser supports.

Document Conventions  ix
 Concepts & Examples ScreenOS Reference Guide

Illustration Conventions
Figure 1 shows the basic set of images used in illustrations throughout this volume.

Figure 1: Images in Illustrations

Autonomous System Local Area Network (LAN)
or with a Single Subnet
Virtual Routing Domain or
Security Zone

Dynamic IP (DIP) Pool

Internet

Policy Engine
Security Zone Interfaces:
White = Protected Zone Interface
(example = Trust Zone)
Black = Outside Zone Interface
(example = Untrust Zone)
Generic Network Device

Tunnel Interface

Server

VPN Tunnel

Router

Juniper Networks
Switch Security Devices

Hub

Requesting Technical Support

Technical product support is available through the Juniper Networks Technical
Assistance Center (JTAC). If you are a customer with an active J-Care or JNASC
support contract, or are covered under warranty, and need postsales technical
support, you can access our tools and resources online or open a case with JTAC.

 JTAC policies—For a complete understanding of our JTAC procedures and

policies, review the JTAC User Guide located at
http://www.juniper.net/customers/support/downloads/710059.pdf.

 Product warranties—For product warranty information, visit

http://www.juniper.net/support/warranty/.

 JTAC hours of operation—The JTAC centers have resources available 24 hours a

day, 7 days a week, 365 days a year.

x  Requesting Technical Support

 About This Volume

Self-Help Online Tools and Resources

For quick and easy problem resolution, Juniper Networks has designed an online
self-service portal called the Customer Support Center (CSC) that provides you with
the following features:

 Find CSC offerings—http://www.juniper.net/customers/support/

 Find product documentation—http://www.juniper.net/techpubs/

 Find solutions and answer questions using our Knowledge Base—

http://kb.juniper.net/

 Download the latest versions of software and review your release notes—
http://www.juniper.net/customers/csc/software/

 Search technical bulletins for relevant hardware and software notifications—

http://www.juniper.net/alerts/

 Join and participate in the Juniper Networks Community Forum—

http://www.juniper.net/company/communities/

 Open a case online in the CSC Case Manager—

http://www.juniper.net/customers/cm/

 To verify service entitlement by product serial number, use our Serial Number
Entitlement (SNE) Tool—
https://tools.juniper.net/SerialNumberEntitlementSearch/

Opening a Case with JTAC

You can open a case with JTAC on the Web or by telephone.

 Use the Case Manager tool in the CSC at http://www.juniper.net/customers/cm/.

 Call 1-888-314-JTAC (1-888-314-5822—toll free in USA, Canada, and Mexico).

For international or direct-dial options in countries without toll-free numbers, visit

us at http://www.juniper.net/customers/support/requesting-support/.

Document Feedback
If you find any errors or omissions in this document, contact Juniper Networks at
[email protected].

Document Feedback  xi
 Concepts & Examples ScreenOS Reference Guide

xii  Document Feedback

Chapter 1
Administration

This chapter describes management methods and tools, methods for securing
administrative traffic, and the administrative privilege levels that you can assign to
admin users. This chapter contains the following sections:

 “Management via the Web User Interface” on page 2

 “Management via the Command Line Interface” on page 9

 “Management via NetScreen-Security Manager” on page 22

 “Controlling Administrative Traffic” on page 28

 “Levels of Administration” on page 33

 “Defining Admin Users” on page 35

 “Securing Administrative Traffic” on page 37

 “Password Policy” on page 51

 “Creating a Login Banner” on page 53

 1
 Concepts & Examples ScreenOS Reference Guide

Management via the Web User Interface

You can use the Web user interface (WebUI) to configure and manage the software
for Juniper Networks security devices. Figure 2 shows the WebUI window. The left
pane contains the navigation menu, and the right pane displays the navigation
window.

Figure 2: WebUI

To use the WebUI, you must have the following application and connection:

 Microsoft Internet Explorer (version 5.5 or later) or Netscape Communicator

(version 4.7 or later)

 TCP/IP network connection to the security device

WebUI Help
You can view Help files for the WebUI at
http://help.juniper.net/help/english/screenos_version/filename.htm
(for example, http://help.juniper.net/help/english/6.1.0/610_Help.htm).

You also have the option of relocating the Help files. You might want to store them
locally and point the WebUI to either the administrator’s workstation or a secured
server on the local network. In case you do not have Internet access, storing the
Help files locally provides accessibility to them you otherwise would not have.

2  Management via the Web User Interface

 Chapter 1: Administration

Copying the Help Files to a Local Drive

The Help files are available on the documentation CD. You can modify the WebUI to
point to the Help files on the CD in your local CD drive. You can also copy the files
from the CD to a server on your local network or to another drive on your
workstation and configure the WebUI to invoke the Help files from that location.

NOTE: If you want to run the Help files directly from the documentation CD, you can skip
this procedure. Proceed to “Pointing the WebUI to the New Help Location” on
page 3-3.

1. Load the documentation CD in the CD drive of your workstation.

2. Navigate to the CD drive and copy the directory named help.

3. Navigate to the location where you want to store the Help directory and paste
the Help directory there.

Pointing the WebUI to the New Help Location

You must now redirect the WebUI to point to the new location of the Help directory.
Change the default URL to the new file path, where path is the specific path to the
Help directory from the administrator’s workstation.

1. Configuration > Admin > Management: In the Help Link Path field, replace the
default URL:

http://help.juniper.net/help/english/screenos_version/filename.htm

with

(for local drive) file://path…/help

or

(for local server) http://server_name…/path/help

2. Click Apply.

When you click the help link in the upper right corner of the WebUI, the device
now uses the new path that you specified in the Help Link Path field to locate
the appropriate Help file.

Management via the Web User Interface  3

 Concepts & Examples ScreenOS Reference Guide

HyperText Transfer Protocol

With a standard browser, you can access, monitor, and control your network
security configurations remotely using HyperText Transfer Protocol (HTTP).

You can secure HTTP administrative traffic by encapsulating it in a virtual private

network (VPN) tunnel or by using the Secure Sockets Layer (SSL) protocol. You can
further secure administrative traffic by completely separating it from network user
traffic. To do this, you can run all administrative traffic through the MGT
interface—available on some security devices—or bind an interface to the MGT
zone and devote it exclusively to administrative traffic.

NOTE: For more information, see “Secure Sockets Layer” on page 5, “VPN Tunnels for
Administrative Traffic” on page 43, and “MGT and VLAN1 Interfaces” on page 29.

Session ID
The security device assigns each HTTP administrative session a unique session ID.
For security devices that support virtual systems (vsys), the ID is globally unique
across all systems—root and vsys.

Each session ID is a 39-byte number resulting from the combination of five

pseudo-randomly generated numbers. The randomness of the ID
generation—versus a simple numerical incremental scheme—makes the ID nearly
impossible to predict. Furthermore, the randomness combined with the length of
the ID makes accidental duplication of the same ID for two concurrent
administrative sessions extremely unlikely.

The following are two benefits that a session ID provides to administrators:

 Figure 3 illustrates how the security device can distinguish concurrent sessions
from multiple admins behind a NAT device that assigns the same source IP
address to all outbound packets.

Figure 3: Session ID with a NAT device

Translates all source IP Security Device
NAT Device addresses to 10.1.1.2
Admin-A
Source IP
Address: SRC DST SRC DST
10.2.2.5 2.2.2.5 10.1.1.1 DATA 10.1.1.2 10.1.1.1 DATA Device assigns
each session a
Interface IP unique ID number
Admin-B Address: and can thereby
Source IP SRC DST SRC DST 10.1.1.1/24 distinguish one
Address: from the other.
10.2.2.6 10.2.2.5 10.1.1.1 DATA 10.1.1.2 10.1.1.1 DATA

 Figure 4 illustrates how the security device can distinguish concurrent root-level
admin sessions from the same source IP address to the root system and from
there to different virtual systems.

4  Management via the Web User Interface

 Chapter 1: Administration

Figure 4: Session ID with Source IP Address

Root Admin Security Device
2.2.2.5 Root System
1.1.1.1
SRC DST
ROOT Device assigns each
2.2.2.5 1.1.1.1 DATA session a unique ID
number and can thereby
2.2.2.5 1.1.1.1 DATA VSYS1 distinguish each session
from the same host for
2.2.2.5 1.1.1.1 DATA VSYS2 different root and virtual
systems.

Secure Sockets Layer

Secure Sockets Layer (SSL) is a set of protocols that can provide a secure connection
between a web client and a webserver communicating over a TCP/IP network. SSL
consists of the SSL Handshake Protocol (SSLHP), which can allow the client and
server to authenticate each other and negotiate an encryption method, and the SSL
Record Protocol (SSLRP), which provides basic security services to higher-level
protocols such as HTTP. These two protocols operate at the following two layers in
the Open Systems Interconnection (OSI) Model:

 SSLHP at the Application Layer (Layer 7)

 SSLRP at the Presentation Layer (Layer 6)

Independent of application protocol, SSL uses TCP to provide secure service (see
Figure 5). SSL uses certificates to authenticate first the server or both the client and
the server, and then encrypt the traffic sent during the session. ScreenOS supports
authentication only of the server (security device), not the client (administrator
attempting to connect to the security device through SSL).

Figure 5: SSL Client to Server

Alice (SSL client) contacts security device (SSL server) to log in.
Security Device
(SSL Server)
Device sends Alice a certificate and proposes that they use a secret
Alice key cipher (3DES, DES, RC4, or RC4-40), compression method
NetScreen-Security (PKZip or gzip), and hash algorithm (SHA-1 or MD5).
Manager Admin
(SSL Client)
Alice encrypts a random number with the public key in the certificate and sends it
back with a list of the proposed items that she accepted. (Alice meanwhile uses the
random number and the agreed-upon secret key cipher to create a secret key.)

Device uses its private key to decrypt the number. It then uses that
number and the agreed-upon secret key cipher to create a secret key.

Alice and security device use their shared secret key to encrypt traffic between themselves.
They also use the agreed-upon compression method to compress data and the agreed-upon
hash algorithm to generate a hash of the data to provide message integrity.

Management via the Web User Interface  5

 Concepts & Examples ScreenOS Reference Guide

A Juniper Networks security device can redirect administrative traffic using HTTP
(default port 80) to SSL (default port 443). The default certificate for SSL is the
automatically generated self-signed certificate, although you can later use a
different certificate if you want. Because SSL is integrated with PKI key/certificate
management, you can select the SSL certificate from any in the certificate list. You
can also use the same certificate for an IPSec VPN.

NOTE: For information about redirecting administrative HTTP traffic to SSL, see
“Redirecting HTTP to SSL” on page 8. For information about self-signed
certificates, see “Self-Signed Certificates” on page 5-47. For information on
obtaining certificates, see “Certificates and CRLs” on page 5-34.

The ScreenOS implementation of SSL provides the following capabilities,

compatibilities, and integration:

 SSL server authentication (not SSL server and client authentication); that is, the
security device authenticates itself to the administrator attempting to connect
through SSL, but the administrator does not use SSL to authenticate himself to
the device

 SSL version 3 compatibility (not version 2)

 Compatibility with Netscape Communicator 4.7x and later and Internet

Explorer 5.x later

 Public Key Infrastructure (PKI) key management integration (see “Public Key
Cryptography” on page 5-29)

 The following encryption algorithms for SSL:

 RC4-40 with 40-bit keys

 RC4 with 128-bit keys

 DES: Data Encryption Standard with 56-bit keys

 3DES: Triple DES with 168-bit keys

 The same authentication algorithms for SSL as for VPNs:

 Message Digest version 5 (MD5)—128-bit keys

 Secure Hash Algorithm version 1 (SHA-1)—160-bit keys

NOTE: The RC4 algorithms are always paired with MD5; DES and 3DES with SHA-1.

6  Management via the Web User Interface

 Chapter 1: Administration

SSL Configuration
The basic steps for setting up SSL are as follows:

1. Make use of the self-signed certificate that the security device automatically
generates during its initial bootup, or create another self-signed certificate, or
obtain a CA-signed certificate and load it on the device.

NOTE: Check your browser to see how strong the ciphers can be and which ones your
browser supports. (Both the security device and your browser must support the
same kind and size of ciphers you use for SSL.) In Internet Explorer 5x, click Help,
About Internet Explorer, and read the section about cipher strength. To obtain
the advanced security package, click Update Information. In Netscape
Communicator, click Help, About Communicator, and read the section about
RSA. To change the SSL configuration settings, click Security Info, Navigator,
Configure SSL v3.

For more information, see “Self-Signed Certificates” on page 5-47. For details on
requesting and loading a certificate, see “Certificates and CRLs” on page 5-34.

2. Enable SSL management.

NOTE: SSL is enabled by default.

WebUI
Configuration > Admin > Management: Enter the following, then click Apply:

SSL: (select)
Port: Use the default port number (443) or change it to another.
Certificate: Select the certificate you intend to use from the drop-down list.
Cipher: Select the cipher you intend to use from the drop-down list.

NOTE: If you change the SSL port number, the admins need to specify the nondefault
port number when entering the URL in their browser.

CLI
set ssl port num
set ssl cert id_num
set ssl encrypt { { 3des | des } sha-1 | { rc4 | rc4-40 } | md5 }
set ssl enable
save

NOTE: To learn the ID number for a certificate, use the following command:
get pki x509 list cert.

3. Configure the interface through which you manage the security device to
permit SSL management:

Management via the Web User Interface  7

 Concepts & Examples ScreenOS Reference Guide

WebUI
Network > Interfaces > Edit (for the interface you want to manage): Select the
SSL management service check box, then click OK.

CLI
set interface interface manage ssl
save

4. Connect to the security device via the SSL port. When you enter the IP address
for managing the security device in the browser’s URL field, change http to
https, and follow the IP address with a colon and the HTTPS (SSL) port number
if you have changed it from the default. For example:

https://123.45.67.89:1443).

Redirecting HTTP to SSL

The security device can redirect administrative traffic using HTTP (default port 80)
to SSL (default port 443), as shown in Figure 6.

During the SSL handshake, the security device sends Alice its certificate. Alice
encrypts a random number with the public key contained in the certificate and
sends it back to the device, which uses its private key to decrypt the number. Both
participants then use the shared random number and a negotiated secret key
cipher (3DES, DES, RC4, or RC4-40) to create a shared secret key, which they use to
encrypt traffic between themselves. They also use an agreed-upon compression
method (PKZip or gzip) to compress data and an agreed-upon hash algorithm
(SHA-1 or MD-5) to generate a hash of the data to provide message integrity.

Figure 6: Redirection of HTTP to SSL

Dst Port 80
HTTP-Get
Clear-text
Security Device
HTTP-Reply
Alice
(NetScreen Instructions to redirect
Admin) from HTTP to HTTPS

SSL Handshake

HTTP-Get Dst Port 443

Encrypted

To enable the redirection and use the default automatically generated self-signed
certificate for SSL, do either of the following:

WebUI
Configuration > Admin > Management: Enter the following, then click Apply:

Redirect HTTP to HTTPS: (select)

Certificate: Default – System Self-Signed Cert

8  Management via the Web User Interface

 Chapter 1: Administration

CLI
set admin http redirect
save

NOTE: You do not have to enter a CLI command to apply the automatically generated
self-signed certificate for use with SSL because the security device applies it to SSL
by default. If you have previously assigned another certificate for use with SSL and
you now want to use the default certificate instead, you must unset the other
certificate with the unset ssl cert id_num command, in which id_num is the ID
number of the previously assigned certificate.

Although HTTP does not provide the security that SSL does, you can configure the
security device so that it does not redirect HTTP traffic. To disable the HTTP-to-SSL
redirect mechanism, clear the Redirect HTTP to HTTPS option in the WebUI, or
enter the unset admin http redirect CLI command.

Management via the Command Line Interface

Advanced administrators can attain finer control by using the command line
interface (CLI). To configure a security device with the CLI, you can use any
software that emulates a VT100 terminal. With a terminal emulator, you can
configure the security device using a console from any Windows, UNIX, or
Macintosh operating system. For remote administration through the CLI, you can
use Telnet or Secure Shell (SSH). With a direct connection through the console port,
you can use HyperTerminal.

NOTE: For a complete listing of the ScreenOS CLI commands, refer to the ScreenOS CLI
Reference Guide: IPv4 Command Descriptions.

Telnet
Telnet is a login and terminal emulation protocol that uses a client/server
relationship to connect to and remotely configure network devices over a TCP/IP
network. The administrator launches a Telnet client program on the administration
workstation and creates a connection with the Telnet server program on the
security device. After logging in, the administrator can issue CLI commands, which
are sent to the Telnet program on the security device, effectively configuring the
device as if operating through a direct connection. Using Telnet to manage security
devices requires the following application and connection:

 Telnet software on the administrative workstation

 An Ethernet connection to the security device

Management via the Command Line Interface  9

 Concepts & Examples ScreenOS Reference Guide

Figure 7 illustrates the setup procedure for establishing a Telnet connection.

Figure 7: Establishing a Telnet Connection

1. Telnet client sends a TCP connection request to port 23

on the security device (acting as a Telnet server).

2. Device prompts the client to log in with a

username and password.

3. Client sends his username and password either in the

clear or encrypted in a VPN tunnel.

To minimize an unauthorized user’s chances of logging into a device, you can limit
the number of unsuccessful login attempts allowed before the security device
terminates a Telnet session. This restriction also protects against certain types of
attacks, such as automated dictionary attacks.

By default, the device allows up to three unsuccessful login attempts before it closes
the Telnet session. To change this number, enter the following command:

set admin access attempts number

NOTE: You must use the CLI to set this restriction.

Securing Telnet Connections

You can secure Telnet traffic by completely separating it from network user traffic.
Depending upon your security device model, you can run all administrative traffic
through the MGT interface or devote an interface such as the DMZ entirely to
administrative traffic.

In addition, to ensure that admin users use a secure connection when they manage
a security device through Telnet, you can require such users to Telnet only through a
virtual private network (VPN) tunnel. After you have set this restriction, the device
denies access if anyone tries to Telnet without going through a VPN tunnel.

NOTE: For information about VPN tunnels, see Volume 5: Virtual Private Networks.

To restrict Telnet access through a VPN, enter the following command:

set admin telnet access tunnel

NOTE: You must use the CLI to set this restriction.

10  Management via the Command Line Interface

 Chapter 1: Administration

Secure Shell
The built-in Secure Shell (SSH) server on a Juniper Networks security device
provides a means by which administrators can remotely manage the device in a
secure manner using applications that are SSH aware. SSH allows you to open a
remote command shell securely and execute commands. SSH provides protection
from IP or DNS spoofing attacks and password or data interception.

You can choose to run either an SSH version 1 (SSHv1) or an SSH version 2 (SSHv2)
server on the device. SSHv2 is considered more secure than SSHv1 and is currently
being developed as the IETF standard. However, SSHv1 has been widely deployed
and is commonly used. Note that SSHv1 and SSHv2 are not compatible with each
other. That is, you cannot use an SSHv1 client to connect to an SSHv2 server on the
security device, or vice versa. The client console or terminal application must run
the same SSH version as the server. Figure 8 illustrates SSH traffic flow.

Figure 8: SSH Traffic Flow

Encrypted Administrative Traffic ScreenOS

SSH Client Internet SSH Server

Administrator’s Security Device

Workstation

Management via the Command Line Interface  11

 Concepts & Examples ScreenOS Reference Guide

Figure 9 illustrates the basic SSH connection procedure.

Figure 9: SSH Connection

1. SSH client sends TCP connection request to port 22 on

security device (acting as SSH server).

2. Device and client exchange information about SSH

version they support. Keys

Host Key: Public key component of a public/private

3. Device sends public component of its host and server keys, cookie, key pair used to authenticate security device/vsys to
and encryption and authentication algorithms it supports. client and encrypt session key. (Each vsys has its own
host key.) Host key is permanently bound to the
device/vsys.
4. Client creates secret session key, encrypts it with the public
component of host and server keys, and sends session key to Server Key: Temporary RSA public/private key pair
device. used to encrypt session key. (Device generates new
one every hour by default for each vsys.)

Session Key: Temporary secret key (DES or 3DES)

that client and device create together during
5. Device signs session key with its private key and sends signed connection setup to encrypt communication (when
session key to client. Client verifies signature with session key session ends, it is discarded).
generated during key exchange. Creation of a secure channel is
complete. PKA Key: Persistent RSA public/private key pair that
resides on SSH client. Client’s public key must also be
loaded on security device before initiating SSH
connection; PKA key must be bound to the admin
user.
6. Device signals SSH client to prompt end user for authentication Note: Public/Private Key Pair = A set of cryptographic
information. keys that operate such that anything encrypted by one
can only be decrypted by the other.

7. Client encrypts username and either password or public

component of its PKA key and sends them for authentication.

A maximum of five SSH sessions are allowed on a Juniper Networks security device
at any one time.

Client Requirements
As mentioned in “Secure Shell” on page 11, the client application must run the
same SSH version as the server on the security device. SSHv2 clients must be
configured to request the Diffie-Hellman key exchange algorithm and the Digital
Signature Algorithm (DSA) for public key device authentication. SSHv1 clients must
be configured to request the RSA for public key device authentication.

12  Management via the Command Line Interface

 Chapter 1: Administration

Basic SSH Configuration on the Device

The following are the basic steps for configuring SSH on a Juniper Networks security
device:

1. Determine whether you will use password or Public Key Authentication (PKA)
for SSH. If PKA will be used, the PKA keys must be bound to an admin before
SSH connections can be made. See “Authentication” on page 14 for more
information about using passwords or PKA.

2. Determine which version of SSH you need to enable on the security device.
(Remember that the client application and the SSH server on the device must
run the same SSH version.) If you enabled SSH on the device in a previous
ScreenOS version, SSHv1 runs when you enable SSH now. To see which version
of SSH is active but not enabled on the device, enter the get ssh CLI command:

device> get ssh

SSH V1 is active
SSH is not enabled
SSH is not ready for connections
Maximum sessions: 8
Active sessions: 0

In the output shown above, SSHv1 is active and runs when you enable SSH. If
you want to use a different SSH version, make sure that all keys created with
the previous version are removed. For example, to clear SSHv1 keys and to use
SSHv2, enter the following CLI commands:

device> delete ssh device all

The following messages appear:

SSH disabled for vsys: 1

PKA key deleted from device: 0
Host keys deleted from device: 1
Execute the ‘set ssh version v2’ command to activate SSH v2 for the device

To use SSHv2, enter the following CLI command:

device-> set ssh version v2

NOTE: Setting the SSH version does not enable SSH on the security device.

3. If you do not want to use port 22 (the default port) for SSH client connections,
you can specify a port number between 1024 and 32767.

NOTE: You can also use the WebUI to change the port number and enable SSHv2 and
SCP on the Configuration > Admin > Management page.

device-> set admin ssh port 1024

4. Enable SSH for the root system or for the virtual system. See “SSH and Vsys” on
page 16 for additional information about enabling and using SSH for a vsys.

Management via the Command Line Interface  13

 Concepts & Examples ScreenOS Reference Guide

To enable SSH for the root system:

device-> set ssh enable

To enable SSH for a vsys, you need to first enter the vsys and then enable SSH:

device-> set vsys v1

device(v1)-> set ssh enable

5. Enable SSH on the interface on which the SSH client will connect.

device-> set interface manage ssh

6. Distribute the host key that is generated on the security device to the SSH
client. See “Host Key” on page 16 for more information.

Authentication
An administrator can connect to a Juniper Networks security device with SSH using
one of two authentication methods:

 Password Authentication: This method is used by administrators who need to

configure or monitor a security device. The SSH client initiates an SSH
connection to the device. If SSH manageability is enabled on the interface
receiving the connection request, the device signals the SSH client to prompt
the user for a username and password. When the SSH client has this
information, it sends it to the device, which compares it with the username and
password in the admin user’s account. If they match, the device authenticates
the user. If they do not match, the device rejects the connection request.

 Public Key Authentication (PKA): This method provides increased security

over the password authentication method and allows you to run automated
scripts. Instead of a username and password, the SSH client sends a username
and the public key component of a public/private key pair. The device
compares it with up to four public keys that can be bound to an admin. If one of
the keys matches, the device authenticates the user. If none of them matches,
the device rejects the connection request.

NOTE: The supported authentication algorithms are RSA for SSHv1 and DSA for SSHv2.

Both authentication methods require the establishment of a secure connection

before the SSH client logs on. After an SSH client has established an SSH connection
with the device, he must authenticate himself either with a username and password
or with a username and public key.

Both password authentication and PKA require that you create an account for the
admin user on the device and enable SSH manageability on the interface through
which you intend to manage the device via an SSH connection. (For information
about creating an admin user account, see “Defining Admin Users” on page 35.)
The password authentication method does not require any further set up on the
SSH client.

14  Management via the Command Line Interface

 Chapter 1: Administration

On the other hand, to prepare for PKA, you must first perform the following tasks:

1. On the SSH client, generate a public and private key pair using a key generation
program. (The key pair is either RSA for SSHv1 or DSA for SSHv2. See the SSH
client application documentation for more information.)

NOTE: If you want to use PKA for automated logins, you must also load an agent on the
SSH client to decrypt the private key component of the PKA public/private key
pair and hold the decrypted version of the private key in memory.

2. Move the public key from the local SSH directory to a directory on your TFTP
server, and launch the TFTP program.

NOTE: You can also paste the content of the public key file directly into the CLI command
set ssh pka-rsa [ username name_str ] key key_str (for SSHv1) or set ssh pka-dsa
[ user-name name_str ] key key_str (for SSHv2), pasting it where indicated by the
variable key_str, or into the Key field in the WebUI (Configuration > Admin >
Administrators > SSH PKA). However, the CLI and WebUI have a size restriction:
the public key size cannot exceed 512 bits. This restriction is not present when
loading the key via TFTP.

3. Log into the device so that you can configure it through the CLI.

4. To load the public key from the TFTP server to the device, enter one of the
following CLI commands:

For SSHv1:

exec ssh tftp pka-rsa [ username name ] file-name name_str ip-addr

tftp_ip_addr

For SSHv2:

exec ssh tftp pka-dsa [ user-name name ] file-name name_str ip-addr

tftp_ip_addr

The username or user-name options are only available to the root admin, so
that only the root admin can bind an RSA key to another admin. When you—as
the root admin or as a read/write admin—enter the command without a
username, the device binds the key to your own admin account; that is, it binds
the key to the admin that enters the command.

NOTE: The security device supports up to four PKA public keys per admin user.

When an administrator attempts to log in via SSH on an interface that has SSH
manageability enabled, the device first checks if a public key is bound to that
administrator. If so, the device authenticates the administrator using PKA. If a
public key is not bound to the administrator, the device prompts for a username
and password. (You can use the following command to force an admin to use only

Management via the Command Line Interface  15

 Concepts & Examples ScreenOS Reference Guide

the PKA method: set admin ssh password disable username name_str.) Regardless
of the authentication method you intend the administrator to use, when you initially
define his or her account, you still must include a password, even though when you
later bind a public key to this user, the password becomes irrelevant.

SSH and Vsys

For security devices that support vsys, you can enable and configure SSH for each
vsys. Each vsys has its own host key (see “Host Key” on page 16) and maintains and
manages a PKA key for the admin of the system.

The maximum number of SSH sessions is a device-wide limit and is between 2 and
24, depending upon the platform. If the maximum number of SSH clients are
already logged into the device, no other SSH client can log into the SSH server. The
root system and the vsys share the same SSH port number. This means that if you
change the SSH port from the default port 22, the port is changed for all vsys as
well.

NOTE: When you deploy a large number of virtual systems on a single device, be aware
that if many or all vsys admins use SSH, the storage reserved for PKI objects can
fill up.

Host Key
The host key allows the security device to identify itself to an SSH client. On devices
that support virtual systems (vsys), each vsys has its own host key. When SSH is first
enabled on a vsys (for devices that support vsys) or on a device, a host key is
generated that is unique to the vsys or device. The host key is permanently bound
to the vsys or device and the same host key is used if SSH is disabled and then
enabled again.

The host key on the device must be distributed to the SSH client in one of two ways:

 Manually—the root or vsys admin sends the host key to the client admin user
via email, telephone, and so on. The receiving admin stores the host key in the
appropriate SSH file on the SSH client system. (The SSH client application
determines the file location and format.)

 Automatically—When the SSH client connects to the device, the SSH server
sends the unencrypted public component of the host key to the client. The SSH
client searches its local host key database to see if the received host key is
mapped to the address of the device. If the host key is unknown (there is no
mapping to the device address in the client’s host key database), the Admin
user might be able to decide whether to accept the host key. Otherwise, the
connection is terminated. (See the appropriate SSH client documentation for
information on accepting unknown host keys.)

16  Management via the Command Line Interface

 Chapter 1: Administration

To verify that the SSH client has received the correct host key, the Admin user on
the client system can generate the SHA hash of the received host key. The client
Admin user can then compare this SHA hash with the SHA hash of the host key on
the device. On the device, you can display the SHA hash of the host key by
executing the CLI command get ssh host-key.

Example: SSHv1 with PKA for Automated Logins

In this example, you (as the root admin) set up SSHv1 public key authentication
(PKA) for a remote host that runs an automated script. The sole purpose for this
remote host to access the device is to download the configuration file every night.
Because authentication is automated, no human intervention is necessary when the
SSH client logs into the device.

You define an admin user account named cfg, with password cfg and read-write
privileges. You enable SSH manageability on interface ethernet1, which is bound to
the Untrust zone.

You have previously used a key generation program on your SSH client to generate
an RSA public/private key pair, moved the public key file, which has the filename
“idnt_cfg.pub”, to a directory on your TFTP server, and launched the TFTP program.
The IP address of the TFTP server is 10.1.1.5.

WebUI
Configuration > Admin > Administrators > New: Enter the following, then
click OK:

Name: cfg
New Password: cfg
Confirm Password: cfg
Privileges: Read-Write (select)
SSH Password Authentication: (select)

Network > Interfaces > Edit (for ethernet1): Select SSH in Service Options,
then click OK.

NOTE: You can only load a public key file for SSH from a TFTP server via the exec ssh
command.

CLI
set admin user cfg password cfg privilege all
set interface ethernet1 manage ssh
exec ssh tftp pka-rsa username cfg file-name idnt_cfg.pub ip-addr 10.1.1.5
save

Management via the Command Line Interface  17

 Concepts & Examples ScreenOS Reference Guide

Secure Copy
Secure Copy (SCP) provides a way for a remote client to transfer files to or from the
security device using the SSH protocol. (The SSH protocol provides authentication,
encryption, and data integrity to the SCP connection.) The device acts as an SCP
server to accept connections from SCP clients on remote hosts.

SCP requires that the remote client be authenticated before file transfer
commences. SCP authentication is exactly the same process used to authenticate
SSH clients. The SCP client can be authenticated with either a password or a PKA
key. Once the SCP client is authenticated, one or more files can be transferred to or
from the device. The SCP client application determines the exact method for
specifying the source and destination filenames; refer to the SCP client application
documentation.

SCP is disabled by default on the device. To enable SCP, you must also enable SSH.

WebUI
Configuration > Admin > Management: Select the following, then click Apply:

Enable SSH: (select)

Enable SCP: (select)

CLI
set ssh enable
set scp enable
save

The following is an example of an SCP client command to copy the configuration

file from flash memory on a device (administrator name is “juniper” and the IP
address is 10.1.1.1) to the file “ns_sys_config_backup” on the client system:

scp [email protected]:ns_sys_config ns_sys_config_backup

You can also copy a ScreenOS image to and from a device. To save an image named
“ns.5.1.0r1” to a device from an SCP client, enter the following SCP client
command, in which the administrator's login name is “juniper” and the IP address
of the device is 10.1.1.1:

scp ns.5.1.0r1 [email protected]:image

Then enter the reset command to reboot the security device to load and run the
new ScreenOS image.

To copy a ScreenOS image from a device to an SCP client and name the saved
image “current_image_backup,” enter the following SCP client command:

scp [email protected]:image current_image_backup

You need to consult your SCP client application documentation for information on
how to specify the administrator name, device IP address, source file, and
destination file.

18  Management via the Command Line Interface

 Chapter 1: Administration

Serial Console
You can manage a security device through a direct serial connection from the
administrator’s workstation to the device via the console port. Although a direct
connection is not always possible, this is the most secure method for
managing the device provided that the location around the device is
secure.

NOTE: To prevent unauthorized users from logging in remotely as the root admin, you
can require the root admin to log into the device through the console only. For
additional information on this restriction, see “Restricting the Root Admin to
Console Access” on page 42.

Depending on your Juniper Networks security device model, creating a serial

connection requires one of the following cables:

 A female DB-9 to male DB-25 straight-through serial cable

 A female DB-9 to male DB-9 straight-through serial cable

 A female DB-9 to male MiniDIN-8 serial cable

 A female DB-9 to RJ-45 adapter with an RJ-45 to RJ-45 straight-through Ethernet

cable

You will also need HyperTerminal software (or another kind of VT100 terminal
emulator) on the management workstation, with the HyperTerminal port settings
configured as follows:

 Serial communications 9600 bps

 8 bit

 No parity

 1 stop bit

 No flow control

NOTE: For more details on using HyperTerminal, refer to the ScreenOS CLI Reference
Guide: IPv4 Command Descriptions or the documentation for your device.

Management via the Command Line Interface  19

 Concepts & Examples ScreenOS Reference Guide

Remote Console
You can remotely access the console interface on a security device by dialing into it.
There are two ways of dialing into the console:

 Remote Console Using V.92 Modem Port

 Remote Console Using an AUX Port

Remote Console Using V.92 Modem Port

You can remotely manage the security devices that are equipped with v.92 modem
ports by dialing into the port and accessing the console interface. To use remote
console, you connect the v.92 modem port on the device to a telephone line, and
dial in to the device using a remote computer with a modem. You use a terminal
program such as HyperTerminal to establish the console session.

In order to use remote console connection, you must first enable remote
management with the following CLI command:

set interface serialx/0 modem aux enable

save

Figure 10 shows how to connect the device for remote console management.

Figure 10: Remote Console Management Connection

Management
workstation with
modem

Public telephone
system

v.92 port on
security device

You will also need HyperTerminal software (or another kind of VT100 terminal
emulator) on the management workstation, with the HyperTerminal port settings
configured as follows:

 Serial communications 9600 bps

 8 bit

 No parity

 1 stop bit

 No flow control

20  Management via the Command Line Interface

 Chapter 1: Administration

NOTE: For more details on using HyperTerminal, refer to the ScreenOS CLI Reference
Guide: IPv4 Command Descriptions or the documentation for your device.

Remote Console Using an AUX Port

You can remotely manage the security devices that are equipped with AUX ports by
dialing into a modem connected to the port and accessing the console interface. To
use remote console, you connect the AUX modem port on the device to a telephone
line using an external modem, and dial in to the device using a remote computer
with a modem. You use a terminal program such as HyperTerminal to establish the
console session.

Figure 11 shows how to connect the device for remote console management.

Figure 11: Remote Console Management Connection

Management
workstation with
modem

Public telephone
system

External v.92 AUX port on

modem security device

You will also need HyperTerminal software (or another kind of VT100 terminal
emulator) on the management workstation, with the HyperTerminal port settings
configured as follows:

 Serial communications 9600 bps

 8 bit

 No parity

 1 stop bit

 No flow control

NOTE: For more details on using HyperTerminal, refer to the ScreenOS CLI Reference
Guide: IPv4 Command Descriptions or the documentation for your device.

Management via the Command Line Interface  21

 Concepts & Examples ScreenOS Reference Guide

Modem Port
You can also manage a security device by connecting the administrator’s
workstation to the modem port on the device. The modem port functions similarly
to the console port, except that you cannot define parameters for the modem port
or use this connection to upload an image.

To prevent unauthorized users from managing the device through a direct

connection to the console or modem port, you can disable both ports by entering
the following commands:

set console disable

set console aux disable

Management via NetScreen-Security Manager

NetScreen-Security Manager is Juniper Networks’ enterprise-level management
software application that configures and monitors multiple Juniper Networks
security devices over a local area network (LAN) or a wide area network (WAN)
environment. The NetScreen-Security Manager User Interface (UI) enables network
administrators to deploy, configure, and manage multiple devices from central
locations.

NetScreen-Security Manager uses three components to enable remote

communication with security devices:

 The NetScreen-Security Manager User Interface (UI) is a java-based software

application that you use to access and configure data on your network with the
NetScreen-Security Manager management system. From the UI, you can view,
configure, and manage your network.

 The management system is a set of services that resides on an external host.

These services process, track, and store device management information
exchanged between a device and the NetScreen-Security Manager UI. The
management system is composed of two components:

 The GUI Server receives and responds to requests and commands from the
UI. It manages the system resources and configuration data required to
manage your network. It also contains a local data store of information
about your managed security devices, administrators, and configurations.

 The Device Server acts as a collection point for all data generated by each of
your network devices. It stores this data, primarily traffic logs, in the local
data store.

 NSM Agent is a service that resides on each managed security device. NSM
Agent receives configuration parameters from the external management
system and forwards them to ScreenOS. NSM Agent also monitors each
device and transmits reports back to the management system. NSM Agent
can download signature packs, certificates, and entitlements between a
security device and NetScreen-Security Manager.

22  Management via NetScreen-Security Manager

 Chapter 1: Administration

Figure 12 shows how NSM Agent communicates with the NetScreen-Security

Manager UI.

Figure 12: Security Device with NSM Agent Enabled

Management System
NetScreen-Security
Manager UI
Primary Server

The primary server

contains both a
device server and a
GUI server.
NSM Agent:
The security device uses its
embedded Agent to communicate with Device and GUI Servers: NetScreen-Security
the device server. Device server sends configuration changes to Manager administrator
security device and receives operational and operates management
statistical reports from it. system through the clien

GUI server processes configuration changes it

receives from one or more NetScreen-Security
Manager clients.

For more information about these and other NetScreen-Security Manager

components, refer to the NetScreen-Security Manager Administrator’s Guide.

Initiating Connectivity Between NSM Agent and the MGT System

Before NetScreen-Security Manager can access and manage a security device, it is
necessary to initiate communications between NSM Agent (which resides on the
device) and the management system (which resides on an external host).
Initialization might require up to two users at two different sites, depending upon
the current availability of the security device. These users might include the
NetScreen-Security Manager administrator, who uses the NetScreen-Security
Manager UI on a client host, and the on-site user, who executes CLI commands on a
device via a console session. Possible initialization cases include the following:

 Case 1: A device already has a known IP address and is reachable over your
network infrastructure.

In this case, the NetScreen-Security Manager administrator adds the device

using the NetScreen-Security Manager UI on the client host. (No on-site user is
necessary.) The device automatically connects back to the management system
and is ready to send configuration information to the NetScreen-Security
Manager database that resides there.

 Case 2: The IP address is unreachable.

In this case, both users perform initialization tasks. The administrator adds the
device through the NetScreen-Security Manager UI. The administrator also
determines which CLI commands the on-site user needs and delivers them to
the user, who then executes them through the console. The device then
automatically connects with the management system and is ready to send
configuration information to the NetScreen-Security Manager database.

Management via NetScreen-Security Manager  23

 Concepts & Examples ScreenOS Reference Guide

 Case 3: The device is a new appliance and contains the factory default settings.

In this case, both users perform initialization tasks. The on-site user can use an
encrypted configuration script, called Configlet, which the NetScreen-Security
Manager administrator generates. The process is as follows:

1. The administrator selects the device platform and ScreenOS version, using
the Add Device wizard in the NetScreen-Security Manager UI.

2. The administrator edits the device and enters the desired configuration.

3. The administrator activates the device.

4. The administrator generates and delivers the Configlet file (or the
necessary CLI commands, as with Case 2) to the on-site user.

5. The on-site user executes Configlet (or the CLI commands).

For more information, refer to the discussion about adding devices in the
NetScreen-Security Manager Administrator’s Guide.

Enabling, Disabling, and Unsetting NSM Agent

Before a security device can communicate with the management system, you must
enable the NetScreen-Security Manager (NSM) Agent residing on the device.

If you want to unset NetScreen-Security Manager, use the unset nsmgmt all
command. This command sets NSM Agent to its initial defaults, so it acts as though
it was never connected to NetScreen-Security Manager. Use the unset nsmgmt all
command when you want to reconfigure the NetScreen-Security Manager settings.

To enable NSM Agent on the security device, do either of the following:

WebUI
Configuration > Admin > NSM: Select Enable Communication with
NetScreen-Security Manager (NSM), then click Apply.

CLI
set nsmgt enable
save

To disable NSM Agent on the device, do either of the following:

WebUI
Configuration > Admin > NSM: Clear Enable Communication with
NetScreen-Security Manager (NSM), then click Apply.

CLI
unset nsmgt enable
save

24  Management via NetScreen-Security Manager

 Chapter 1: Administration

Setting the Primary Server IP Address of the Management System

The IP address by which NSM Agent identifies the external management system
servers is a configurable parameter.

In the following example you set the primary server IP address to 1.1.1.100.

WebUI
Configuration > Admin > NSM: Enter the following, then click Apply:

Primary IP Address/Name: 1.1.1.100

CLI
set nsmgmt server primary 1.1.1.100
save

Setting Alarm and Statistics Reporting

NSM Agent monitors the device events and transmits reports back to the
management system. This allows the NetScreen-Security Manager administrator to
view the events from the NetScreen-Security Manager UI.

The categories of events tracked by NSM Agent are as follows:

 Alarms report potentially dangerous attacks or traffic anomalies, including

attacks detected through deep inspection.

 Log events report changes in a device’s configuration and non-severe changes

that occur on a device.

 Protocol distribution events report messages generated by the following

protocols:

 Authentication Header (AH)

 Encapsulating Security Payload (ESP)

 Generic Routing Encapsulation (GRE)

 Internet Control Message Protocol (ICMP)

 Open Shortest Path First (OSPF)

 Transmission Control Protocol (TCP)

 User Datagram Protocol (UDP)

Management via NetScreen-Security Manager  25

 Concepts & Examples ScreenOS Reference Guide

 Statistics messages report the following statistical information:

 Attack statistics

 Ethernet statistics

 Traffic flow statistics

 Policy statistics

In the following example, you enable transmission of all Alarm and Statistics
messages to the Management System.

WebUI
Configuration > Admin > NSM: Enter the following, then click Apply:

Attack Statistics: (select)

Policy Statistics: (select)
Attack Alarms: (select)
Traffic Alarms: (select)
Flow Statistics: (select)
Ethernet Statistics: (select)
Deep Inspection Alarms: (select)
Event Alarms: (select)

CLI
set nsmgmt report statistics attack enable
set nsmgmt report statistics policy enable
set nsmgmt report alarm attack enable
set nsmgmt report alarm traffic enable
set nsmgmt report statistics flow enable
set nsmgmt report statistics ethernet enable
set nsmgmt report alarm idp enable
set nsmgmt report alarm other enable
save

Configuration Synchronization
If the ScreenOS configuration is changed from the last time it was synchronized
with NetScreen-Security Manager, then the security device notifies the
NetScreen-Security Manager administrator of the change. For example, the device
sends a message when a device administrator uses console, telnet, SSH, or the
WebUI to change a security device configuration. Changing the configuration with
any application other than NetScreen-Security Manager causes it to be
unsynchronized. The NetScreen-Security Manager configuration file must be
synchronized with the security device configuration file for NetScreen-Security
Manager to work correctly. The synchronization is achieved when you import the
configuration file to NetScreen-Security Manager. For information on importing
devices, refer to the NetScreen-Security Manager Administrator’s Guide.

26  Management via NetScreen-Security Manager

 Chapter 1: Administration

The following example displays the command used to view the configuration status.

Example: Viewing the Configuration State

In the following example, you view the configuration synchronization state of a
security device.

WebUI

NOTE: You must use the CLI to retrieve the running configuration state.

CLI
get config nsmgmt-dirty

NOTE: If applications other than NetScreen-Security Manager applications have not

changed the configuration file, then the command returns a blank; otherwise, it
returns a “yes.”

Example: Retrieving the Configuration Hash

NetScreen-Security Manager uses the configuration hash to verify the configuration
synchronization of a security device. In the following example, you retrieve the
running configuration hash for a specific virtual system.

WebUI

NOTE: You must use the CLI to retrieve the running configuration hash.

CLI
device-> enter vsys vsys1
device(vsys1)-> get config hash
a26a16cd6b8ef40dc79d5b2ec9e1ab4f
device(vsys1)->
device(vsys1)-> exit

Retrieving the Configuration Timestamp

A security device provides two configuration timestamps—running-config and
saved-config. The running-config timestamp is when the set or unset command was
last executed for each virtual system. The saved-config timestamp is when the
device configuration was last saved.

In the following example, the security device retrieves the last running and saved
configuration timestamps for the vsys1 virtual system:

WebUI

NOTE: You must use the CLI to retrieve the running and saved configuration timestamps.

Management via NetScreen-Security Manager  27

 Concepts & Examples ScreenOS Reference Guide

CLI
get config timestamp vsys vsys1
get config saved timestamp

NOTE: If you omit vsys vsys_name from the command, the security device retrieves the
configuration timestamp for the root system. If the timestamp is unavailable, then
an “unknown” message is displayed.

Controlling Administrative Traffic

ScreenOS provides the following options for configuring and managing the security
device:

 WebUI: Selecting this option allows the interface to receive HTTP traffic for
management via the Web user interface (WebUI).

 Telnet: A terminal emulation program for TCP/IP networks such as the Internet,
Telnet is a common way to remotely control network devices. Selecting this
option enables Telnet manageability.

 SSH: You can administer the security device from an Ethernet connection or a
dial-in modem using Secure Command Shell (SSH). You must have an SSH
client that is compatible with Version 1.5 of the SSH protocol. These clients are
available for Windows 95 and later, Windows NT, Linux, and UNIX. The security
device communicates with the SSH client through its built-in SSH server, which
provides device configuration and management services. Selecting this option
enables SSH manageability.

 SNMP: The security device supports both SNMPv1 and SNMPv2c, and all
relevant Management Information Base II (MIB II) groups, as defined in
RFC-1213. Selecting this option enables SNMP manageability.

 SSL: Selecting this option allows the interface to receive HTTPS traffic for secure
management of the security device via the WebUI.

 NetScreen-Security Manager: Selecting this option allows the interface to

receive NetScreen-Security Manager traffic.

 Ping: Selecting this option allows the security device to respond to an ICMP
echo request, or ping, which determines whether a specific IP address is
accessible over the network.

 Ident-Reset: Services like Mail and FTP send identification requests. If they
receive no acknowledgement, they send the request again. While the request is
processing, there is no user access. By enabling the Ident-reset option, the
security device sends a TCP reset announcement in response to an IDENT
request to port 113 and restores access that has been blocked by an
unacknowledged identification request.

To use these options, you enable them on one or more interfaces, depending on
your security and administrative needs.

28  Controlling Administrative Traffic

 Chapter 1: Administration

MGT and VLAN1 Interfaces

Some Juniper Networks security devices have a physical interface—Management
(MGT)—dedicated exclusively for management traffic. You can use this interface for
management traffic when interfaces are in NAT, Route, or Transparent mode.

In Transparent mode, you can configure all security devices to allow administration
through the logical interface, VLAN1. To enable management traffic to reach the
VLAN1 interface, you must enable the management options you want both on
VLAN1 and on the Layer 2 zones—V1-Trust, V1-Untrust, V1-DMZ, user-defined
Layer 2 zone—through which the management traffic passes to reach VLAN1.

To maintain the highest level of security, Juniper Networks recommends that you
limit administrative traffic exclusively to the VLAN1 or MGT interface and user
traffic to the security zone interfaces. Separating administrative traffic from
network user traffic greatly increases administrative security and ensures constant
management bandwidth.

Example: Administration Through the MGT Interface

In this example, you set the IP address of the MGT interface to 10.1.1.2/24 and
enable the MGT interface to receive web and SSH administrative traffic.

WebUI
Network > Interfaces > Edit (for mgt): Enter the following, then click OK:

IP Address/Netmask: 10.1.1.2/24
Management Services: WebUI, SSH: (select)

CLI
set interface mgt ip 10.1.1.2/24
set interface mgt manage web
set interface mgt manage ssh
save

Example: Administration Through the VLAN1 Interface

In this example, you set the IP address of the VLAN1 interface to 10.1.1.1/24 and
enable the VLAN1 interface to receive Telnet and web administrative traffic through
the V1-Trust zone.

WebUI
Network > Interfaces > Edit (for VLAN1): Enter the following, then click OK:

IP Address/Netmask: 10.1.1.1/24
Management Services: WebUI, Telnet: (select)

Network > Zones > Edit (for V1-Trust): Select the following, then click OK:

Management Services: WebUI, Telnet: (select)

Controlling Administrative Traffic  29

 Concepts & Examples ScreenOS Reference Guide

CLI
set interface vlan1 ip 10.1.1.1/24
set interface vlan1 manage web
set interface vlan1 manage telnet
set zone v1-trust manage web
set zone v1-trust manage telnet
save

Setting Administrative Interface Options

On security devices that have multiple physical interfaces for network traffic, but no
physical MGT interface, you might dedicate one physical interface exclusively for
administration, separating management traffic completely from network user
traffic. For example, you might have local management access the device through
an interface bound to the Trust zone and remote management through an interface
bound to the Untrust zone.

In this example, you bind ethernet1 to the Trust zone and ethernet3 to the Untrust
zone. You assign ethernet1 the IP address 10.1.1.1/24 and give it the Manage IP
address 10.1.1.2. (Note that the Manage IP address must be in the same subnet as
the security zone interface IP address.) You also allow ethernet1 to receive web and
Telnet traffic. You then assign ethernet3 the IP address 1.1.1.1/24 and block all
administrative traffic to that interface.

WebUI
Network > Interfaces > Edit (for ethernet1): Enter the following, then click
Apply:

Zone Name: Trust

Static IP: (select this option when present)
IP Address/Netmask: 10.1.1.1/24
Manage IP: 10.1.1.2
Management Services:
WebUI: (select)
SNMP: (clear)
Telnet: (select)
SSL: (clear)
SSH: (clear)

Enter the following, then click OK:

Interface Mode: NAT

Network > Interfaces > Edit (for ethernet3):

Enter the following, then click OK:

Zone Name: Untrust

Static IP: (select this option when present)
IP Address/Netmask: 1.1.1.1/24
Management Services:
WebUI: (clear)
SNMP: (clear)
Telnet: (clear)
SSL: (clear)
SSH: (clear)

30  Controlling Administrative Traffic

 Chapter 1: Administration

CLI
set interface ethernet1 zone trust
set interface ethernet1 ip 10.1.1.1/24
set interface ethernet1 manage-ip 10.1.1.2
set interface ethernet1 manage web
unset interface ethernet1 manage snmp
set interface ethernet1 manage telnet
unset interface ethernet1 manage ssl
unset interface ethernet1 manage ssh
set interface ethernet1 nat
set interface ethernet3 zone untrust
set interface ethernet3 ip 1.1.1.1/24
save

NOTE: When you bind an interface to any security zone other than the Trust and
V1-Trust zones, all management options are disabled by default. Therefore, in this
example, you do not have to disable the management options on ethernet3.

Setting Manage IPs for Multiple Interfaces

Any physical, redundant, or aggregate interface or sub-interface you bind to a
security zone can have at least two IP addresses:

 An interface IP address, which connects to a network.

 A logical manage IP address for receiving administrative traffic.

When a security device is a backup unit in a redundant group for high availability
(HA), you can access and configure the unit through its manage IP address (or
addresses)

NOTE: The manage IP address differs from the VLAN1 address in the following two ways:

When the security device is in Transparent mode, the VLAN1 IP address can be
the endpoint of a VPN tunnel, but the manage IP address cannot.

You can define multiple manage IP addresses—one for each network

interface—but you can only define one VLAN1 IP address—for the entire system.

If you select the Manageable option on the interface configuration page in the
WebUI, you can manage the security device either through the interface IP address
or the Manage IP address associated with that interface.

Figure 13 on page 32 illustrates this example in which you bind ethernet2 to the
DMZ zone and ethernet3 to the Untrust zone. You set the management options on
each interface to provide access for the specific kinds of administrative traffic. You
allow HTTP and Telnet access on ethernet2 for a group of local administrators in the
DMZ zone, and SNMP access on ethernet3 for central device monitoring from a
remote site. Ethernet2 and ethernet3 each have a manage IP address, to which the
administrative traffic is directed. You also set a route directing self-generated SNMP
traffic out ethernet3 to the external router at 1.1.1.250.

Controlling Administrative Traffic  31

 Concepts & Examples ScreenOS Reference Guide

Figure 13: Setting Management IPs for Multiple Interfaces

Untrust Zone
ethernet3
IP: 1.1.1.1/24
Manage IP: 1.1.1.2 SNMP
Internet
Management
Station

Router 1.1.1.250

Local Admins
DMZ Zone
ethernet2
IP: 1.2.2.1/24
Manage IP: 1.2.2.2

LAN

Trust Zone

WebUI
Network > Interfaces > Edit (ethernet2): Enter the following, then click OK:

Zone Name: DMZ

Static IP: (select this option when present)
IP Address/Netmask: 1.2.2.1/24
Manage IP: 1.2.2.2
Management Services:
WebUI: (select)
Telnet: (select)

Network > Interfaces > Edit (ethernet3): Enter the following, then click OK:

Zone Name: Untrust

Static IP: (select this option when present)
IP Address/Netmask: 1.1.1.1/24
Manage IP: 1.1.1.2
Management Services:
SNMP: (select)

32  Controlling Administrative Traffic

 Chapter 1: Administration

CLI
set interface ethernet2 zone dmz
set interface ethernet2 ip 1.2.2.1/24
set interface ethernet2 manage-ip 1.2.2.2
set interface ethernet2 manage web
set interface ethernet2 manage telnet
set interface ethernet3 zone untrust
set interface ethernet3 ip 1.1.1.1/24
set interface ethernet3 manage-ip 1.1.1.2
set interface ethernet3 manage snmp
save

Levels of Administration
Juniper Networks security devices support multiple administrative users. For any
configuration changes made by an administrator, the security device logs the
following information:

 The name of the administrator making the change

 The IP address from which the change was made

 The time of the change

There are several levels of administrative user. The availability of some of these
levels depends on the model of your Juniper Networks security device. The
following sections list all the admin levels and the privileges for each level. These
privileges are only accessible to an admin after he or she successfully logs in with a
valid username and password.

Root Administrator
The root administrator has complete administrative privileges. There is only one
root administrator per security device. The root administrator has the following
privileges:

 Manages the root system of the security device

 Adds, removes, and manages all other administrators

 Establishes and manages virtual systems, and assigns physical or logical

interfaces to them

 Creates, removes, and manages virtual routers (VRs)

 Adds, removes, and manages security zones

 Assigns interfaces to security zones

 Performs asset recovery

 Sets the device to FIPS mode

 Resets the device to its default settings

Levels of Administration  33
 Concepts & Examples ScreenOS Reference Guide

 Updates the firmware

 Loads configuration files

 Clears all active sessions of a specified admin or of all active admins

Read/Write Administrator
The read/write administrator has the same privileges as the root administrator, but
cannot create, modify, or remove other admin users. The read/write administrator
has the following privileges:

 Creates virtual systems and assigns a virtual system administrator for each one

 Monitors any virtual system

 Tracks statistics (a privilege that cannot be delegated to a virtual system

administrator)

Read-Only Administrator
The read-only administrator has only viewing privileges using the WebUI, and can
only issue the get and ping CLI commands. The read-only administrator has the
following privileges:

 Read-only privileges in the root system, using the following four commands:
enter, exit, get, and ping

 Read-only privileges in virtual systems

Virtual System Administrator

Some security devices support virtual systems. Each virtual system (vsys) is a
unique security domain, which can be managed by virtual system administrators
with privileges that apply only to that vsys. Virtual system administrators
independently manage virtual systems through the CLI or WebUI. On each vsys, the
virtual system administrator has the following privileges:

 Creates and edits auth, IKE, L2TP, XAuth, and Manual Key users

 Creates and edits services

 Creates and edits policies

 Creates and edits addresses

 Creates and edits VPNs

 Modifies the virtual system administrator login password

 Creates and manages security zones

 Adds and removes virtual system read-only administrators

34  Levels of Administration
 Chapter 1: Administration

Virtual System Read-Only Administrator

A virtual system read-only administrator has the same set of privileges as a
read-only administrator, but only within a specific virtual system. A virtual system
read-only administrator has viewing privileges for his particular vsys through the
WebUI, and can only issue the enter, exit, get, and ping CLI commands within his
vsys.

NOTE: For more information on virtual systems, see “Virtual Systems” on page 10-1.

Defining Admin Users

The root administrator is the only one who can create, modify, and remove admin
users. In the following example, the one performing the procedure must be a root
administrator.

Example: Adding a Read-Only Admin

In this example, you—as the root admin—add a read-only administrator named
Roger with password 2bd21wG7.

WebUI
Configuration > Admin > Administrators > New: Enter the following, then
click OK:

Name: Roger
New Password: 2bd21wG7
Confirm New Password: 2bd21wG7
Privileges: Read-Only (select)

NOTE: The password can be up to 31 characters long and is case sensitive.

CLI
set admin user Roger password 2bd21wG7 privilege read-only
save

Example: Modifying an Admin

In this example, you—as the root admin—change Roger’s privileges from read-only
to read/write.

WebUI
Configuration > Admin > Administrators > Edit (for Roger): Enter the
following, then click OK:

Name: Roger
New Password: 2bd21wG7
Confirm New Password: 2bd21wG7
Privileges: Read-Write (select)

Defining Admin Users  35

 Concepts & Examples ScreenOS Reference Guide

CLI
unset admin user Roger
set admin user Roger password 2bd21wG7 privilege all
save

Example: Deleting an Admin

In this example, you—as the root admin—delete the admin user Roger.

WebUI
Configuration > Admin > Administrators: Click Remove in the Configure
column for Roger.

CLI
unset admin user Roger
save

Example: Configuring Admin Accounts for Dialup Connections

Some devices support a modem connection for outbound dial-up disaster recovery
situations. You can set up trustee accounts for the interface, for the modem or for
both the interface and modem. This section describes the two types of trustees:

 Interface trustee

An interface trustee only has access to the WebUI and is restricted to the
signaling methods and IP address assignment for the primary Untrust interface.

For devices with ADSL interfaces, an interface trustee has control over the
following characteristics:

 Layer 1 characteristics: VPI/VCI, multiplexing mode, RFC1483 bridged or

routed

 Layer 2 signaling methods (PPPoE or PPPoA, and their parameters)

 IP address assignment methods (statically defined by an administrator, or

dynamically acquired from the circuit through PPPoE or PPPoA).

For devices with only ethernet interfaces, an interface trustee can control how
the interface IP address is assigned (statically defined by administrator, or
dynamically acquired from the circuit via DHCP or PPPoE).

 Modem trustee

A modem trustee only has access to the WebUI and is restricted to Modem and
ISP settings for the serial interface. A modem trustee can created, modify, and
delete modem definitions to suit their specific needs, and can create, modify,
and delete the settings for ISP1 and ISP2. A modem trustee can view the
configurations for ISP3 and ISP4, and can test connectivity for any defined ISP
and phone number.

36  Defining Admin Users

 Chapter 1: Administration

You can view all administrator accounts by entering the get admin user command,
or you can view only the trustee accounts by entering the get admin user trustee
command.

In the following example, you configure a Read/Write modem trustee account for
Richard Brockie. You set his username to be sdonovan and his password to be
!23fb.

WebUI
Configuration > Admin > Administrators

CLI
set admin user sdonovan password !23fb privilege all
set admin user sdonovan trustee modem

Example: Clearing an Admin’s Sessions

In this example, you—as the root admin—terminate all active sessions of the admin
user Roger. When you execute the following command, the security device closes
all active sessions and automatically logs off Roger from the system.

WebUI

NOTE: You must use the CLI to clear an admin’s sessions.

CLI
clear admin name Roger
save

Securing Administrative Traffic

To secure the security device during setup, perform the following steps:

1. On the WebUI, change the administrative port.

See “Changing the Port Number” on page 38.

2. Change the username and password for administration access.

See “Changing the Admin Login Name and Password” on page 39.

3. Define the management client IP addresses for the admin users.

See “Restricting Administrative Access” on page 42.

4. Turn off any unnecessary interface management service options.

See “Controlling Administrative Traffic” on page 28.

5. Disable the ping and ident-reset service options on the interfaces, both of which
respond to requests initiated by unknown parties and can reveal information
about your network:

Securing Administrative Traffic  37

 Concepts & Examples ScreenOS Reference Guide

WebUI
Network > Interfaces > Edit (for the interface you want to edit): Disable the
following service options, then click OK:

Ping: Selecting this option allows the security device to respond to an ICMP
echo request, or “ping,” which determines whether a specific IP address is
accessible from the device.

Ident-Reset: When a service such as Mail or FTP sends an identification

request and receives no acknowledgment, it sends the request again. While
the request is in progress, user access is disabled. With the Ident-Reset
check box enabled, the security device automatically restores user access.

CLI
unset interface interface manage ping
unset interface interface manage ident-reset

Changing the Port Number

Changing the port number to which the security device listens for HTTP
management traffic improves security. The default setting is port 80, the standard
port number for HTTP traffic. After you change the port number, you must then
enter the new port number in the URL field in your browser when you next attempt
to contact the security device. (In the following example, the administrator needs to
enter http://188.30.12.2:15522.)

In this example, the IP address of the interface bound to the Trust zone is
10.1.1.1/24. To manage the security device via the WebUI on this interface, you
must use HTTP. To increase the security of the HTTP connection, you change the
HTTP port number from 80 (the default) to 15522.

WebUI
Configuration > Admin > Management: In the HTTP Port field, enter 15522,
then click Apply.

CLI
set admin port 15522
save

38  Securing Administrative Traffic

 Chapter 1: Administration

Changing the Admin Login Name and Password

By default, the initial login name for security devices is netscreen. The initial
password is also netscreen. Because these have been widely published, Juniper
Networks recommends you change the login name and password immediately. The
login name and password are both case-sensitive. They can contain any character
that can be entered from the keyboard with the exception of ? and ". Record the
new admin login name and password in a secure manner.

WARNING: Be sure to record your new password. If you forget it, you must reset
the security device to its factory settings, and all your configurations will be lost.
For more information, see “Resetting the Device to the Factory Default Settings”
on page 41.

Admin users for the security device can be authenticated using the internal
database or an external auth server. When the admin user logs into the security
device, it first checks the local internal database for authentication. If there is no
entry present and an external auth server is connected, it then checks for a
matching entry in the external auth server database. After an admin user
successfully logs into an external auth server, the security device maintains the
admin’s login status locally.

NOTE: Juniper Networks supports RADIUS, SecurID, and LDAP servers for admin user
authentication. (For more information, see “Admin Users” on page 9-2.) Although
the root admin account must be stored on the local database, you can store
root-level read/write and root-level read-only admin users on an external auth
server. To store root-level and vsys-level admin users on an external auth server
and query their privileges, the server must be RADIUS and you must load the
netscreen.dct file on it.

For more information about admin user levels, see “Levels of Administration” on
page 33. For more about using external auth servers, see “External Authentication
Servers” on page 9-17.

When the root admin changes any attribute of an admin user’s profile—username,
password, or privilege—any administrative session that the admin currently has
open automatically terminates. If the root admin changes any of these attributes for
himself, or if a root-level read/write admin or vsys read/write admin changes his
own password, all of that user’s currently open admin sessions terminate, other
than the one in which he made the change.

NOTE: The behavior of an HTTP or HTTPS session using the WebUI is different. Because
HTTP does not support a persistent connection, any change that you make to your
own user profile automatically logs you out of that and all other open sessions.

Securing Administrative Traffic  39

 Concepts & Examples ScreenOS Reference Guide

Example: Changing an Admin User’s Login Name and Password

In this example, you—as the root admin—change a read/write administrator’s login
name from “John” to “Smith” and his password from xL7s62a1 to 3MAb99j2.

NOTE: Instead of using actual words for passwords, which might be guessed or
discovered through a dictionary attack, you can use an apparently random string
of letters and numbers. To create such a string that you can easily remember,
compose a sentence and use the first letter from each word. For example,
“Charles will be 6 years old on November 21” becomes “Cwb6yooN21.”

For more information, see “Levels of Administration” on page 33.

WebUI
Configuration > Admin > Administrators > Edit (for John): Enter the
following, then click OK:

Name: Smith
New Password: 3MAb99j2
Confirm New Password: 3MAb99j2

CLI
unset admin user John
set admin user Smith password 3MAb99j2 privilege all
save

Example: Changing Your Own Password

Admin users with read/write privileges can change their own administrator
password, but not their login name. In this example, an administrator with
read/write privileges and the login name “Smith” changes his password from
3MAb99j2 to ru494Vq5.

WebUI
Configuration > Admin > Administrators > Edit (for first entry): Enter the
following, then click OK:

Name: Smith
New Password: ru494Vq5
Confirm New Password: ru494Vq5

CLI
set admin password ru494Vq5
save

40  Securing Administrative Traffic

 Chapter 1: Administration

Setting the Minimum Length of the Root Admin Password

In some corporations, one person might initially configure the device as the root
admin, but another person later assumes the role of root admin and manages the
device. To prevent the subsequent root admin from using short passwords that are
potentially easier to decode, the initial root admin can set a minimum length
requirement for the root admin’s password to any number from 1 to 31.

You can set the minimum password length only if you are the root admin and your
own password meets the minimum length requirement you are attempting to set.
Otherwise, the security device displays an error message.

To specify a minimum length for the root admin’s password, enter the following CLI
command:

set admin password restrict length number

NOTE: You must use the CLI to set this restriction.

Resetting the Device to the Factory Default Settings

If the admin password is lost, you can use the following procedure to reset the
security device to its default settings. The configurations will be lost, but access to
the device will be restored. To perform this operation, you need to make a console
connection, which is described in detail in ScreenOS CLI Reference Guide: IPv4
Command Descriptions and the documentation for your device.

NOTE: By default, the device recovery feature is enabled. You can disable it by entering
the unset admin device-reset command. Also, if the security device is in FIPS
mode, the recovery feature is automatically disabled.

1. At the login prompt, enter the serial number of the device.

2. At the password prompt, enter the serial number again.

The following message appears:

!!!! Lost Password Reset !!!! You have initiated a command to reset the device
to factory defaults, clearing all current configuration, keys and settings. Would
you like to continue? y/n

3. Press the y key.

The following message appears:

!! Reconfirm Lost Password Reset!! If you continue, the entire configuration of

the device will be erased. In addition, a permanent counter will be
incremented to signify that this device has been reset. This is your last chance
to cancel this command. If you proceed, the device will return to factory
default configuration, which is: System IP: 192.168.1.1; username:
netscreen; password: netscreen. Would you like to continue? y/n

4. Press the y key to reset the device. You can now log in using netscreen as the
default username and password.

Securing Administrative Traffic  41

 Concepts & Examples ScreenOS Reference Guide

Restricting Administrative Access

You can administer security devices from one or multiple addresses of a subnet. By
default, any host on the trusted interface can administer a security device. To
restrict this ability to specific workstations, you must configure management client
IP addresses.

Example: Restricting Administration to a Single Workstation

In this example, the administrator at the workstation with the IP address
172.16.40.42 is the only administrator specified to manage the security device.

WebUI
Configuration > Admin > Permitted IPs: Enter the following, then click Add:

IP Address / Netmask: 172.16.40.42/32

CLI
set admin manager-ip 172.16.40.42/32
save

Example: Restricting Administration to a Subnet

In this example, the group of administrators with workstations in the
172.16.40.0/24 subnet are specified to manage a security device.

WebUI
Configuration > Admin > Permitted IPs: Enter the following, then click Add:

IP Address / Netmask: 172.16.40.0/24

CLI
set admin manager-ip 172.16.40.0 255.255.255.0
save

Restricting the Root Admin to Console Access

You can also require the root admin to log into the security device through the
console only. This restriction requires the root admin to have physical access to the
device to log in, thus preventing unauthorized users from logging in remotely as the
root admin. After you have set this restriction, the device denies access if anyone
tries to log in as the root admin through other means, such as the WebUI, Telnet, or
SSH, even if these management options are enabled on the ingress interface.

To restrict the access of the root admin to the console only, enter the following
command:

set admin root access console

NOTE: You must use the CLI to set this restriction.

42  Securing Administrative Traffic

 Chapter 1: Administration

VPN Tunnels for Administrative Traffic

You can use virtual private network (VPN) tunnels to secure remote management of
a security device from either a dynamically assigned or fixed IP address. Using a
VPN tunnel, you can protect any kind of traffic, such as NetScreen-Security
Manager, HTTP, Telnet, or SSH. (For information about creating a VPN tunnel to
secure self-initiated traffic such as NetScreen-Security Manager reports, syslog
reports, or SNMP traps, see “VPN Tunnels for Self-Initiated Traffic” on page 78.)

Juniper Networks security devices support two types of VPN tunnel configurations:

 Route-based VPNs: The security device uses route table entries to direct traffic
to tunnel interfaces, which are bound to VPN tunnels.

 Policy-based VPNs: The security device uses the VPN tunnel names specifically
referenced in policies to direct traffic through VPN tunnels.

For each VPN tunnel configuration type, there are the following types of VPN
tunnel:

 Manual key: You manually set the three elements that define a Security
Association (SA) at both ends of the tunnel: a Security Parameters Index (SPI),
an encryption key, and an authentication key. To change any element in the SA,
you must manually enter it at both ends of the tunnel.

 AutoKey IKE with pre-shared key: One or two pre-shared secrets—one for
authentication and one for encryption—function as seed values. Using them,
the IKE protocol generates a set of symmetrical keys at both ends of the tunnel;
that is, the same key is used to encrypt and decrypt. At predetermined
intervals, these keys are automatically regenerated.

 AutoKey IKE with certificates: Using the Public Key Infrastructure (PKI), the
participants at both ends of the tunnel use a digital certificate (for
authentication) and an RSA public/private key pair (for encryption). The
encryption is asymmetrical; that is, one key in a pair is used to encrypt and the
other to decrypt.

NOTE: For a complete description of VPN tunnels, see Volume 5: Virtual Private Networks.
For more information on NetScreen-Remote, refer to the NetScreen-Remote VPN
Client Administrator Guide.

If you use a policy-based VPN configuration, you must create an address book entry
with the IP address of an interface in any zone other than the one to which the
outgoing interface is bound. You can then use that as the source address in policies
referencing the VPN tunnel. This address also serves as the end entity address for
the remote IPSec peer. If you are using a route-based VPN configuration, such an
address book entry is unnecessary.

Securing Administrative Traffic  43

 Concepts & Examples ScreenOS Reference Guide

Administration Through a Route-Based Manual Key VPN Tunnel

Figure 14 illustrates an example in which you set up a route-based Manual Key VPN
tunnel to provide confidentiality for administrative traffic. The tunnel extends from
the NetScreen-Remote VPN client running on an admin’s workstation at 10.1.1.56
to ethernet1 (10.1.1.1/24). The admin’s workstation and ethernet1 are both in the
Trust zone. You name the tunnel “tunnel-adm”. You create an unnumbered tunnel
interface, name it tunnel.1, and bind it to the Trust zone and to the VPN tunnel
“tunnel-adm.”

The security device uses the internal IP address configured on the

NetScreen-Remote client—10.10.10.1—as the destination address to target beyond
the peer gateway address of 10.1.1.56. You define a route to 10.10.10.1/32 through
tunnel.1. A policy is unnecessary because of the following two reasons:

 The VPN tunnel protects administrative traffic that terminates at the security
device itself instead of passing through the device to another security zone.

 This is a route-based VPN, meaning that the route lookup—not a policy

lookup—links the destination address to the tunnel interface, which is bound to
the appropriate VPN tunnel.

NOTE: Compare this example with “Administration Through a Policy-Based Manual Key
VPN Tunnel” on page 47.

NetScreen-Remote uses the IP address of ethernet3—1.1.1.1—as the destination

address to target beyond the remote gateway at 10.1.1.1. The NetScreen-Remote
configuration specifies the remote party ID type as “IP address” and the protocol as
“All.”

Figure 14: Administration Through a Route-Based Manual Key VPN Tunnel

NetScreen-Remote ethernet1 ethernet3
10.1.1.1/24 1.1.1.1/24

Trust Zone Untrust Zone

Security Device
LAN Internet

Manual Key VPN

Tunnel “tunnel-adm”

Admin tunnel.1
10.1.1.56 unnumbered
(static IP address)
10.10.10.1/32
(internal IP address)

44  Securing Administrative Traffic

 Chapter 1: Administration

WebUI
1. Interfaces
Network > Interfaces > Edit (ethernet1): Enter the following, then click Apply:

Zone Name: Trust

Static IP: (select this option when present)
IP Address/Netmask: 10.1.1.1/24

Select the following, then click OK:

Interface Mode: NAT

Network > Interfaces > Edit (ethernet3): Enter the following, then click OK:

Zone Name: Untrust

Static IP: (select this option when present)
IP Address/Netmask: 1.1.1.1/24

Network > Interfaces > New Tunnel IF: Enter the following, then click OK:

Tunnel Interface Name: Tunnel.1

Zone (VR): Trust (trust-vr)
Unnumbered: (select)
Interface: ethernet1(trust-vr)

NOTE: The unnumbered tunnel interface borrows the IP address of the specified security
zone interface.

2. VPN
VPNs > Manual Key > New: Enter the following, then click OK:

VPN Tunnel Name: tunnel-adm

Gateway IP: 10.1.1.56
Security Index (HEX Number): 5555 (Local) 5555 (Remote)
Outgoing Interface: ethernet1
ESP-CBC: (select)
Encryption Algorithm: DES-CBC
Generate Key by Password: netscreen1
Authentication Algorithm: MD5
Generate Key by Password: netscreen2

> Advanced: Enter the following, then click Return to set the advanced
options and return to the basic configuration page:

Bind to Tunnel Interface: (select), Tunnel.1

NOTE: Because NetScreen-Remote processes passwords into keys differently than do

other Juniper Networks products, after you configure the tunnel you need to do
the following: (1) Return to the Manual Key Configuration dialog box (click Edit in
the Configure column for “tunnel-adm”); (2) copy the generated hexadecimal
keys; (3) use those hexadecimal keys when configuring the NetScreen-Remote
end of the tunnel.

Securing Administrative Traffic  45

 Concepts & Examples ScreenOS Reference Guide

3. Route
Network > Routing > Destination > trust-vr New: Enter the following, then
click OK:

Network Address/Netmask: 10.10.10.1/32

Gateway: (select)
Interface: Tunnel.1
Gateway IP Address: 0.0.0.0

CLI
1. Interfaces
set interface ethernet1 zone trust
set interface ethernet1 ip 10.1.1.1/24
set interface ethernet1 nat
set interface ethernet3 zone untrust
set interface ethernet3 ip 1.1.1.1/24
set interface tunnel.1 zone trust
set interface tunnel.1 ip unnumbered interface ethernet1

NOTE: The unnumbered tunnel interface borrows the IP address of the specified security
zone interface.

2. VPN
set vpn tunnel-adm manual 5555 5555 gateway 10.1.1.56 outgoing ethernet1 esp
des password netscreen1 auth md5 password netscreen2
set vpn tunnel-adm bind interface tunnel.1

NOTE: Because NetScreen-Remote processes passwords into keys differently than do

other Juniper Networks products, after you configure the tunnel you need to do
the following: (1) Enter get vpn admin-tun; (2) copy the hexadecimal keys
generated by “netscreen1” and “netscreen2”; (3) use those hexadecimal keys
when configuring the NetScreen-Remote end of the tunnel.

3. Route
set vrouter trust-vr route 10.10.10.1/32 interface tunnel.1
save

NetScreen-Remote Security Policy Editor

1. Click Options > Global Policy Settings, and select the Allow to Specify Internal
Network Address check box.

2. Click Options > Secure > Specified Connections.

3. Click Add a new connection, and enter Admin next to the new connection
icon that appears.

4. Configure the connection options:

Connection Security: Secure

Remote Party Identity and Addressing:
ID Type: IP Address, 1.1.1.1
Protocol: All
Connect using Secure Gateway Tunnel: (select)
ID Type: IP Address, 10.1.1.1

46  Securing Administrative Traffic

 Chapter 1: Administration

5. Click the PLUS symbol, located to the left of the UNIX icon, to expand the
connection policy.

6. Click My Identity, in the Select Certificate drop-down list, choose None, and in
the Internal Network IP Address, enter 10.10.10.1.

7. Click Security Policy, and select Use Manual Keys.

8. Click the PLUS symbol, located to the left of the Security Policy icon, then click
the PLUS symbol to the left of Key Exchange (Phase 2) to expand the policy
further.

9. Click Proposal 1, then select the following IPSec Protocols:

Encapsulation Protocol (ESP): (select)

Encrypt Alg: DES
Hash Alg: MD5
Encapsulation: Tunnel

10. Click Inbound Keys, and in the Security Parameters Index field, enter 5555.

11. Click Enter Key, enter the following, then click OK:

Choose key format: Binary

ESP Encryption Key: dccbee96c7e546bc
ESP Authentication Key: dccbe9e6c7e546bcb0b667794ab7290c

NOTE: These are the two generated keys that you copied after configuring the security
device.

12. Click Outbound Keys, and, in the Security Parameters Index field, enter 5555.

13. Click Enter Key, enter the following, then click OK:

Choose key format: Binary

ESP Encryption Key: dccbee96c7e546bc
ESP Authentication Key: dccbe9e6c7e546bcb0b667794ab7290c

14. Click Save.

Administration Through a Policy-Based Manual Key VPN Tunnel

Figure 15 illustrates an example in which you set up a policy-based Manual Key
VPN tunnel for administrative traffic. The tunnel extends from the
NetScreen-Remote VPN client running on an admin’s workstation at 10.1.1.56 to
ethernet1 (10.1.1.1/24). The admin’s workstation and ethernet1 are both in the
Trust zone. You name the tunnel “tunnel-adm” and bind it to the Trust zone.

The security device uses the internal IP address configured on the

NetScreen-Remote—10.10.10.1—as the destination address to target beyond the
peer gateway address of 10.1.1.56. You define a Trust zone address book entry
specifying 10.10.10.1/32, and an Untrust zone address book entry specifying the IP
address of ethernet3. Although the address of the ethernet3 interface is 1.1.1.1/24,
the address you create has a 32-bit netmask: 1.1.1.1/32. You use this address and

Securing Administrative Traffic  47

 Concepts & Examples ScreenOS Reference Guide

the internal address of the admin’s workstation in the policy you create referencing
the tunnel “tunnel-adm”. A policy is necessary because this is a policy-based VPN,
meaning that the policy lookup—not a route lookup—links the destination address
to the appropriate VPN tunnel.

You must also define a route to 10.10.10.1/32 through ethernet1.

NOTE: Compare this example with “Administration Through a Route-Based Manual Key
VPN Tunnel” on page 44.

NetScreen-Remote uses the IP address 1.1.1.1 as the destination address to target

beyond the remote gateway at 10.1.1.1. The NetScreen-Remote tunnel
configuration specifies the remote party ID type as IP address and the protocol as
“All.”

Figure 15: Administration Through a Policy-Based Manual Key VPN Tunnel

NetScreen-Remote ethernet1 ethernet3

10.1.1.1/24 1.1.1.1/24

Trust Zone Untrust Zone

LAN
Admin Internet
10.1.1.56 (static
IP address) Manual Key VPN
Tunnel “tunnel-adm”

WebUI
1. Interfaces
Network > Interfaces > Edit (ethernet1): Enter the following, then click Apply:

Zone Name: Trust

Static IP: (select this option when present)
IP Address/Netmask: 10.1.1.1/24

Select the following, then click OK:

Interface Mode: NAT

Network > Interfaces > Edit (ethernet3): Enter the following, then click OK:

Zone Name: Untrust

Static IP: (select this option when present)
IP Address/Netmask: 1.1.1.1/24
2. Addresses
Policy > Policy Elements > Addresses > Lists > New: Enter the following,
then click OK:

Address Name: Untrust-IF

IP Address/Domain Name:
IP/Netmask: (select), 1.1.1.1/32
Zone: Untrust

48  Securing Administrative Traffic

 Chapter 1: Administration

Policy > Policy Elements > Addresses > Lists > New: Enter the following,
then click OK:

Address Name: admin

IP Address/Domain Name:
IP/Netmask: (select), 10.10.10.1/32
Zone: Trust
3. VPN
VPNs > Manual Key > New: Enter the following, then click OK:

VPN Tunnel Name: tunnel-adm

Gateway IP: 10.1.1.56
Security Index (HEX Number): 5555 (Local) 5555 (Remote)
Outgoing Interface: ethernet1
ESP-CBC: (select)
Encryption Algorithm: DES-CBC
Generate Key by Password: netscreen1
Authentication Algorithm: MD5
Generate Key by Password: netscreen2

NOTE: Because NetScreen-Remote processes passwords into keys differently than do

other Juniper Networks products, after you configure the tunnel you need to do
the following: (1) Return to the Manual Key Configuration dialog box (click Edit in
the Configure column for “tunnel-adm”); (2) copy the generated hexadecimal
keys; (3) use those hexadecimal keys when configuring the NetScreen-Remote
end of the tunnel.

4. Route
Network > Routing > Destination > trust-vr New: Enter the following, then
click OK:

Network Address/Netmask: 10.10.10.1/32

Gateway: (select)
Interface: ethernet1
Gateway IP Address: 0.0.0.0
5. Policies
Policies > (From: Trust, To: Untrust) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), admin
Destination Address:
Address Book Entry: (select), Untrust-IF
Service: Any
Action: Tunnel
Tunnel:
VPN: tunnel-adm
Modify matching bidirectional VPN policy: (select)
Position at Top: (select)

Securing Administrative Traffic  49

 Concepts & Examples ScreenOS Reference Guide

CLI
1. Interfaces
set interface ethernet1 zone trust
set interface ethernet1 ip 10.1.1.1/24
set interface ethernet1 nat
set interface ethernet3 zone untrust
set interface ethernet3 ip 1.1.1.1/24
2. Addresses
set address trust admin 10.10.10.1/32
set address untrust Untrust-IF 1.1.1.1/32
3. VPN
set vpn tunnel-adm manual 5555 5555 gateway 10.1.1.56 outgoing ethernet1 esp
des password netscreen1 auth md5 password netscreen2

NOTE: Because NetScreen-Remote processes passwords into keys differently than do

other Juniper Networks products, after you configure the tunnel you need to do
the following: (1) Enter get vpn admin-tun; (2) copy the hexadecimal keys
generated by “netscreen1” and “netscreen2”; (3) use those hexadecimal keys
when configuring the NetScreen-Remote end of the tunnel.

4. Route
set vrouter trust-vr route 10.10.10.1/32 interface ethernet1
5. Policies
set policy top from trust to untrust admin Untrust-IF any tunnel vpn tunnel-adm
set policy top from untrust to trust Untrust-IF admin any tunnel vpn tunnel-adm
save

NetScreen-Remote Security Policy Editor

1. Click Options > Secure > Specified Connections.

2. Click Add a new connection, and enter Admin next to the new connection
icon that appears.

3. Configure the connection options:

Connection Security: Secure

Remote Party Identity and Addressing:
ID Type: IP Address, 1.1.1.1
Protocol: All
Connect using Secure Gateway Tunnel: (select)
ID Type: IP Address, 10.1.1.1

4. Click the PLUS symbol, located to the left of the UNIX icon, to expand the
connection policy.

5. Click My Identity, and, in the Select Certificate drop-down list, choose None.

6. Click Security Policy, and select Use Manual Keys.

7. Click the PLUS symbol, located to the left of the Security Policy icon, and then
the PLUS symbol to the left of Key Exchange (Phase 2) to expand the policy
further.

50  Securing Administrative Traffic

 Chapter 1: Administration

8. Click Proposal 1, and select the following IPSec Protocols:

Encapsulation Protocol (ESP): (select)

Encrypt Alg: DES
Hash Alg: MD5
Encapsulation: Tunnel

9. Click Inbound Keys, and in the Security Parameters Index field, enter 5555.

10. Click Enter Key, enter the following, and click OK:

Choose key format: Binary

ESP Encryption Key: dccbee96c7e546bc
ESP Authentication Key: dccbe9e6c7e546bcb0b667794ab7290c

NOTE: These are the two generated keys that you copied after configuring the security
device.

11. Click Outbound Keys, and in the Security Parameters Index field, enter 5555.

12. Click Enter Key, enter the following, then click OK:

Choose key format: Binary

ESP Encryption Key: dccbee96c7e546bc
ESP Authentication Key: dccbe9e6c7e546bcb0b667794ab7290c

13. Click Save.

Password Policy
The password policy feature allows you to enforce a minimum length and a
complexity scheme for administrator (admin) and authenticated (auth) user
passwords. The password policy feature is intended for use in a local database, and
therefore is useful in environments where the Windows directory or RADIUS are not
available to provide centralized password policy enforcement.

Setting a Password Policy

You can create a password policy to require that admin and auth passwords fulfill
one or both of the following:

 Minimum length

 Complexity

The range for password minimum length is 1 to 32 characters. Use the following
command to create a password policy requiring a minimum length of 8 characters
for admin passwords:

set password-policy user-type admin minimum-length 8

Password Policy  51
 Concepts & Examples ScreenOS Reference Guide

Password complexity means passwords must include at least two uppercase letters,
two lowercase letters, and two alphanumeric and two non-alphanumeric characters;
for example: AAbb12@#. To require that passwords contain complexity, you set
complexity to 1. To unset the complexity requirement, set complexity to 0. Use the
following command to create a password policy requiring that auth passwords
contain complexity:

set password-policy user-type auth complexity 1

In the following example, you create a password policy for admin and auth accounts
requiring complexity and a minimum length of 8 characters:

CLI
set password-policy user-type admin minimum-length 8
set password-policy user-type admin complexity 1
set password-policy user-type auth minimum-length 8
set password-policy user-type auth complexity 1
save

NOTE: You can configure a password policy only from the command line interface (CLI).

Removing a Password Policy

Use the unset password-policy command to delete a password policy. When you
remove a password policy, the password requirement for the account reverts to the
default settings. In the following example, you remove the minimum length
requirement for auth passwords.

CLI
unset password-policy user-type auth minimum-length

Viewing a Password Policy

Use the get password-policy command to display the password policy for admin
and auth users.

Recovering from a Rejected Default Admin Password

When you delete (unset) the root admin account on a device on which you have a
password policy configured, you might need to set a new admin password before
logging off the system. This is because ScreenOS reverts to the default password
(netscreen) when you delete the root admin account. If you have a password policy
requiring complexity, or a minimum length greater than 9 characters, your next
login attempt will fail. If this happens, use the asset recovery procedure to gain
access to the device. Refer to the installation and configuration guide for your
device for details.

52  Password Policy
 Chapter 1: Administration

In the following example, you delete the admin account named admin2005, then
display the current password policy. As shown, the policy specifies that passwords
must have a minimum length of 8 characters, and use complexity (a minimum of
two uppercase, two lowercase, two alphanumeric, and two non-alphanumeric
characters). You then create a new admin account named admin2006 and set a
password for it that fulfills the minimum length and complexity requirements of the
password policy.

CLI
unset admin admin2005
get password-policy

user-type: admin
password minimum length: 8
password complexity scheme: 1

user-type: auth
password minimum length: 8
password complexity scheme: 1

set admin admin2006 password AAbb12@#

save

NOTE: You can configure an admin account only from the command line interface (CLI).

Creating a Login Banner

The size of the login banner is increased to a maximum of 4Kbytes. This provides
space for terms of use statements, which are presented before administrators and
authenticated users log into the security device and into protected resources behind
the device. The login banner is a clear text ASCII file you create and store on the
security device, the file must be called usrterms.txt. You activate the banner by
restarting of the device. If the banner file is greater than 4Kbytes, the security
device will not accept it and will continue using existing banners entered through
the CLI and the WebUI.

When activated, the login banner is used globally by the root device and all virtual
systems (vsys). You cannot differentiate or customize between or within a vsys. The
login banner preempts all individually defined administrative access banners and
firewall authentication banners. After entering a username and password, the user
must click the Login button. Pressing the Enter key will not log the user into the
device.

Use the SCP utility to securely copy the banner file to the security device. With the
following command, an administrator with username netscreen copies the banner
file my_large_banner.txt to a security device at IP address 1.1.1.2. The banner file
must be saved on the security device as usrterms.txt.

linux:~#scp my_large_banner.txt [email protected]:usrterms.txt

You must restart the device to activate the new banner. To modify the banner file,
create a new file and overwrite the existing one with the new one.

Creating a Login Banner  53

 Concepts & Examples ScreenOS Reference Guide

To remove the banner, issue the following command on the security device:

device-> delete file usrterms.txt

This disables the login banner feature after you restart the device.

54  Creating a Login Banner

Chapter 2
Monitoring Security Devices

This chapter discusses the following topics about monitoring Juniper Networks
security devices. It contains the following sections:

 “Storing Log Information” on page 55

 “Event Log” on page 57

 “Traffic Log” on page 61

 “Self Log” on page 66

 “Downloading the Asset Recovery Log” on page 68

 “Traffic Alarms” on page 68

 “Syslog” on page 71

 “Simple Network Management Protocol” on page 74

 “VPN Tunnels for Self-Initiated Traffic” on page 78

 “Viewing Screen Counters” on page 92

Storing Log Information

All Juniper Networks security devices allow you to store event and traffic log data
internally (in flash storage) and externally (in a number of locations). Although
storing log information internally is convenient, the amount of device memory is
limited. When the internal storage space completely fills up, the security device
begins overwriting the oldest log entries with the latest ones. If this first-in-first-out
(FIFO) mechanism occurs before you save the logged information, you can lose
data. To mitigate such data loss, you can store event and traffic logs externally in a
syslog or WebTrends server or in the NetScreen-Global PRO database. The security
device sends new event and traffic log entries to an external storage location every
second.

Storing Log Information  55

 Concepts & Examples ScreenOS Reference Guide

The following list provides the possible destinations for logged data:

 Console: A destination for all log entries to appear when you are
troubleshooting a security device through the console. Optionally, you might
elect to have only alarm messages (critical, alert, emergency) appear here to
alert you immediately if you happen to be using the console at the time an
alarm is triggered.

 Internal: Allows you store a limited number of log entries.

 Email: A method for sending event and traffic logs to remote administrators.

 SNMP: In addition to the transmission of SNMP traps, a security device can also
send alarm messages (critical, alert, emergency) from its event log to an SNMP
community.

 Syslog: All event and traffic log entries that a security device can store
internally, it can also send to a syslog server. Because syslog servers have a
much greater storage capacity than the internal flash storage on a security
device, sending data to a syslog server can mitigate data loss that might occur
when log entries exceed the maximum internal storage space. Syslog stores
alert- and emergency-level events in the security facility that you specify, and
all other events (including traffic data) in the facility you specify.

 WebTrends: Allows you to view log data for critical-, alert-, and
emergency-level events in a more graphical format than syslog, which is a
text-based tool.

 CompactFlash (PCMCIA): Allows you to store data on a CompactFlash card.

 USB: Allows you to store data on a USB flash drive. When you set USB as the
log destination, the system sends log messages to a file on the USB flash drive.
The log file is named hostname_date.evt_log, where hostname is the system
hostname at boot time, and date is date on which the device was last started.
Logging to USB is disabled by default; use the set log usb enable CLI command
to enable USB logging.

Use the set log... destination... command to set the severity levels for all log
destinations. The following example logs all system module messages of level
critical or higher to the USB flash drive:

set log module system level critical destination usb

56  Storing Log Information

 Chapter 2: Monitoring Security Devices

Event Log
ScreenOS provides an event log for monitoring system events such as
admin-generated configuration changes, and self-generated messages and alarms
regarding operational behavior and attacks. The security device categorizes system
events by the following severity levels:

 Emergency: Messages on SYN attacks, Tear Drop attacks, and Ping of Death
attacks. For more information on these types of attacks, see Volume 4:
Attack Detection and Defense Mechanisms.

 Alert: Messages about conditions that require immediate attention, such as

firewall attacks and the expiration of license keys.

 Critical: Messages about conditions that probably affect the functionality of the
device, such as high availability (HA) status changes.

 Error: Messages about error conditions that probably affect the functionality of
the device, such as a failure in antivirus scanning or in communicating with
SSH servers.

 Warning: Messages about conditions that could affect the functionality of the
device, such as a failure to connect to email servers or authentication failures,
timeouts, and successes.

 Notification: Messages about normal events, including configuration changes

initiated by an admin.

 Information: Messages that provide general information about system

operations.

 Debugging: Messages that provide detailed information used for debugging

purposes.

The event log displays the date, time, level and description of each system event.
You can view system events for each category stored in flash storage on the
security device through the WebUI or the CLI. You can also open or save the file to
the location you specify, and then use an ASCII text editor (such as Notepad or
WordPad) to view the file. Alternatively, you can send them to an external storage
space (see “Storing Log Information” on page 55).

NOTE: For detailed information about the messages that appear in the event log, refer to
the ScreenOS Message Log Reference Guide.

Event Log  57
 Concepts & Examples ScreenOS Reference Guide

Viewing the Event Log by Severity Level and Keyword

You can view the event log stored in the device by using the CLI or the WebUI. You
can display log entries by severity level and search the event log by keyword in
both the WebUI and CLI.

To display the event log by severity level, do either of the following:

WebUI
Reports > System Log > Event: Select a severity level from the Log Level
drop-down list.

CLI
get event level { emergency | alert | critical | error | warning | notification |
information | debugging }

To search the event log by keyword, do either of the following:

WebUI
Reports > System Log > Event: Enter a word or phrase up to 15 characters in
length in the search field, then click Search.

CLI
get event include word_string

In this example, you view event log entries with a “warning” severity level and do a
search for the keyword AV.

WebUI
Reports > System Log > Event:

Log Level: Warning (select)

Search: Enter AV, then click Search.

CLI
get event level warning include av

Date Time Module Level Level Type Description

2003-05-16 15:56:20 system warn 00547 AV scanman is removed.
2003-05-16 09:45:52 system warn 00547 AV test1 is removed.
Total entries matched = 2

58  Event Log
 Chapter 2: Monitoring Security Devices

Sorting and Filtering the Event Log

Additionally, you can use the CLI to sort or filter the event log based on the
following criteria:

 Source or Destination IP Address: Only certain events contain a source or

destination IP address, such as authentication, land attacks, or ping flood
attacks. When you sort event logs by source or destination IP address, the
device sorts and displays only the event logs that contain source or destination
IP addresses. It ignores all event logs with no source or destination IP address.
The authentication log messages include the user’s IP address.

When you filter the event log by specifying a source or destination IP address
or range of addresses, the device displays the log entries for the specified
source or destination IP address, or range of addresses.

 Date: You can sort the event log by date only, or by date and time. When you
sort log entries by date and time, the device lists the log entries in descending
order by date and time.

You can also filter event log entries by specifying a start date, an end date, or a
date range. When you specify a start date, the device displays log entries with
date/time stamps after the start date. When you specify an end date, the device
displays log entries with date/time stamps before the end date.

 Time: When you sort logs by time, the device displays the log entries in
descending order by time, regardless of the date. When you specify a start
time, the device displays log entries with time stamps after the specified start
time, regardless of the date. When you specify an end time, the device displays
log entries with time stamps before the specified end time, regardless of the
date. When you specify both a start and end time, the device displays log
entries with time stamps within the specified time period.

 Message Type ID Number: You can display event log entries for a specific
message type ID number, or you can display log entries with message type ID
numbers within a specified range. The device displays log entries with the
message type ID number(s) you specified, in descending order by date and
time.

In this example you view event log entries that contain source IP addresses within
the range 10.100.0.0 to 10.200.0.0. The log entries are also sorted by source IP
address.

WebUI

NOTE: You must use the CLI to sort the event log by address entries.

CLI
get event sort-by src-ip 10.100.0.0-10.200.0.0

Event Log  59
 Concepts & Examples ScreenOS Reference Guide

Downloading the Event Log

You can open or save the event log to the location you specify, and then use an
ASCII text editor (such as Notepad or WordPad) to view the file. Alternatively, you
can send the log entries to an external storage space (see “Storing Log Information”
on page 55). You can download the entire event log through the WebUI. You can
download the event log by severity level through the CLI.

Example: Downloading the Entire Event Log

In this example, you download the event log to the local directory. Using the
WebUI, you download it to C:\netscreen\logs. Using the CLI, you download it to the
root directory of a TFTP server at the IP address 10.1.1.5. You name the file
“evnt07-02.txt.”

WebUI
1. Reports > System Log > Event: Click Save.

The File Download dialog box prompts you to open the file (using an ASCII
editor) or save it to disk.

2. Select the Save option, then click OK.

The File Download dialog box prompts you to choose a directory.

3. Specify C:\netscreen\logs, name the file evnt07-02.txt, then click Save.

CLI
get event > tftp 10.1.1.5 evnt07-02.txt

Example: Downloading the Event Log for Critical Events

In this example, you download the critical events entered in the event log to the
root directory of a TFTP server at the IP address 10.1.1.5. You name the file
crt_evnt07-02.txt.

WebUI

NOTE: You must use the CLI to download entries by severity level.

CLI
get event level critical > tftp 10.1.1.5 crt_evnt07-02.txt

60  Event Log
 Chapter 2: Monitoring Security Devices

Traffic Log
The Juniper Networks security device can monitor and record traffic that it permits
or denies based on previously configured policies. You can enable the logging
option for each policy that you configure. When you enable the logging option for a
policy that permits traffic, the device records the traffic allowed by that policy.
When you enable the logging option for a policy that denies traffic, the device
records traffic that attempted to pass through the device, but was dropped because
of that policy.

A traffic log notes the following elements for each session:

 Date and time that the connection started

 Duration

 Source address and port number

 Translated source address and port number

 Destination address and port number

 The duration of the session

 The service used in the session

To log all traffic that a security device receives, you must enable the logging option
for all policies. To log specific traffic, enable logging only on policies that apply to
that traffic. To enable the logging option on a policy, do either of the following:

WebUI
Policies > (From: src_zone, To: dst_zone) New: Select Logging and then click
OK.

CLI
set policy from src_zone to dst_zone src_addr dst_addr service action log

In addition to logging traffic for a policy, the device can also maintain a count in
bytes of all network traffic to which the policy was applied. When you enable the
counting option, the device includes the following information when it displays
traffic log entries

 Bytes transmitted from a source to a destination

 Bytes transmitted from a destination to a source

You can enable counting on a policy from the WebUI and from the CLI.

WebUI
Policies > (From: src_zone, To: dst_zone) New > Advanced: Select Counting,
click Return, then click OK.

CLI
set policy from src_zone to dst_zone src_addr dst_addr service action log count

Traffic Log  61
 Concepts & Examples ScreenOS Reference Guide

Viewing the Traffic Log

You can view traffic log entries stored in flash storage on the security device using
either the WebUI or the CLI.

WebUI
Policies > Logging (for policy ID number)

or

Reports > Policies > Logging (for policy ID number)

CLI
get log traffic policy number

Example: Viewing Traffic Log Entries

In this example, you view the traffic log details of a policy with ID number 3, and
for which you have previously enabled logging:

WebUI
Policies: Click the Logging icon for the policy with ID number 3.

The following information appears:

 Date/Time: 2003-01-09 21:33:43

 Duration: 1800 sec.

 Source IP Address/Port: 1.1.1.1:1046

 Destination IP Address/Port: 10.1.1.5:80

 Service: HTTP

 Reason for Close: Age out

 Translated Source IP Address/Port: 1.1.1.1:1046

 Translated Destination IP Address/Port: 10.1.1.5:80

 Policy ID number: 3

CLI
get log traffic policy 3

Sorting and Filtering the Traffic Log

Similar to the event log, when you use the CLI to view the traffic log, you can sort or
filter the log entries according to the following criteria:

 Source or Destination IP Address: You can sort the traffic log by source or
destination IP address. You can also filter the traffic log by specifying a source
or destination IP address or range of addresses.

62  Traffic Log
 Chapter 2: Monitoring Security Devices

 Date: You can sort the traffic log by date only, or by date and time. The device
lists the log entries in descending order by date and time.

You can also filter event log entries by specifying a start date, an end date, or a
date range. When you specify a start date, the device displays log entries with
date/time stamps after the start date. When you specify an end date, the device
displays log entries with date/time stamps before the end date.

 Time: When you sort the traffic log by time, the device displays the log entries
in descending order by time, regardless of the date. When you specify a start
time, the device displays log entries with time stamps after the specified start
time, regardless of the date. When you specify an end time, the device displays
log entries with time stamps before the specified end time, regardless of the
date. When you specify both a start and end time, the device displays log
entries with time stamps within the specified time period.

Example: Sorting the Traffic Log by Time

In this example you view the traffic log sorted by time with a time stamp after 1:00
a.m.

WebUI

NOTE: The ability to sort the traffic log by time is available only through the CLI.

CLI
get log traffic sort-by time start-time 01:00:00
Downloading the Traffic Log
You can also open or save the log to the location you specify, and then use an ASCII
text editor (such as Notepad or WordPad) to view the file.

Alternatively, you can send traffic log entries to an external storage space (see
“Storing Log Information” on page 55). The security device makes an entry in the
traffic log when a session terminates. When you enable the security device to send
traffic log entries to an external storage location, it sends new entries every second.
Because the security device makes a traffic log entry when a session closes, the
security device sends traffic log entries for all sessions that have closed within the
past second. You can also include traffic log entries with event log entries sent by
email to an admin.

In this example, you download the traffic log for a policy with ID number 12. For
the WebUI, you download it to the local directory “C:\netscreen\logs”. For the CLI,
you download it to the root directory of a TFTP server at the IP address
10.10.20.200. You name the file “traf_log11-21-02.txt.”

Traffic Log  63
 Concepts & Examples ScreenOS Reference Guide

WebUI
1. Reports > Policies > Logging (for policy ID 12): Click Save.

The File Download dialog box prompts you to open the file (using an ASCII
editor) or save it to disk.

2. Select the Save option, then click OK.

The File Download dialog box prompts you to choose a directory.

3. Specify C:\netscreen\logs, name the file traf_log11-21-02.txt, then click Save.

CLI
get log traffic policy 12 > tftp 10.10.20.200 traf_log11-21-02.txt

Removing the Reason for Close Field

By default ScreenOS records and displays the reason for session close so that you
can differentiate session creation messages from session close messages. If you do
not want the reason to display, you can explicitly configure the device not to
display the field.

Table 1 lists the reasons for session close that ScreenOS identifies. Any session that
cannot be identified is labeled OTHER.

Table 1: Reason Codes for Session Close

Logged Reason Meaning

TCP FIN TCP connection torn down due to FIN packet.
TCP RST TCP connection torn down due to RST packet.
RESP Special sessions, such as PING and DNS, close when response is
received.
ICMP ICMP error received.
AGE OUT Connection aged out normally.
ALG ALG forced session close either due to error or other reason specific to
that ALG.
NSRP NSRP session close message received.
AUTH Auth failure.
IDP Closed by IDP.
SYN PROXY FAIL SYN Proxy failure.
SYN PROXY LIMIT System limit for SYN proxy sessions reached.
TENT2NORM CONV Failure of tentative to normal session conversion.
PARENT CLOSED Parent session closed.
CLI User command closed.
OTHER Reason for close not identified.

64  Traffic Log
 Chapter 2: Monitoring Security Devices

Sample traffic log with reason for close listed:

device-> get log traffic

PID 1, from Trust to Untrust, src Any, dst Any, service ANY, action Permit
Total traffic entries matched under this policy = 2300
================================================================================
Date Time Duration Source IP Port Destination IP Port Service
Reason Xlated Src IP Port Xlated Dst IP Port ID
================================================================================
2001-10-25 07:08:51 0:00:59 10.251.10.25 137 172.24.16.10 137 NETBIOS (NS)
Close - AGE OUT 172.24.76.127 8946 172.24.16.10 137
2001-10-25 07:08:51 0:00:59 10.251.10.25 137 172.24.244.10 137 NETBIOS (NS)
Close - AGE OUT 172.24.76.127 8947 172.24.244.10 137
2001-10-25 07:07:53 0:00:01 10.251.10.25 1028 172.24.16.10 53 DNS
Close - RESP 172.24.76.127 8945 172.24.16.10 53
2001-10-25 07:06:29 0:01:00 10.251.10.25 138 172.24.244.10 138 NETBIOS (DGM)
Close - AGE OUT 172.24.76.127 8933 172.24.244.10 138
2001-10-25 07:06:11 0:03:16 10.251.10.25 2699 172.24.60.32 1357 TCP PORT 1357
Close - TCP FIN 172.24.76.127 8921 172.24.60.32 1357

Sample traffic log without reason for close listed:

device-> get log traffic

PID 1, from Trust to Untrust, src Any, dst Any, service HTTP, action Permit
Total traffic entries matched under this policy = 1538
================================================================================
Date Time Duration Source IP Port Destination IP Port Service
Xlated Src IP Port Xlated Dst IP Port ID
================================================================================
2002-07-19 15:53:11 0:01:33 10.251.10.25 2712 207.17.137.108 80 HTTP
10.251.10.25 2712 207.17.137.108 80
2002-07-19 15:51:33 0:00:12 10.251.10.25 2711 66.163.175.128 80 HTTP
10.251.10.25 2711 66.163.175.128 80
2002-07-19 15:41:33 0:00:12 10.251.10.25 2688 66.163.175.128 80 HTTP
10.251.10.25 2688 66.163.175.128 80
2002-07-19 15:31:39 0:00:18 10.251.10.25 2678 66.163.175.128 80 HTTP
10.251.10.25 2678 66.163.175.128 80

In the following example, you configure the device to not display the reason for
closing sessions because it interferes with a script that you want to run on the
traffic log. You must use the command line interface to change the log output style.

WebUI
Not available.

CLI
set log traffic detail 0
save

Traffic Log  65
 Concepts & Examples ScreenOS Reference Guide

Self Log
ScreenOS provides a self log to monitor and record all packets terminated at the
security device. For example, if you disable some management options on an
interface—such as WebUI, SNMP, and ping—and HTTP, SNMP, or ICMP traffic is
sent to that interface, entries appear in the self log for each dropped packet.

To activate the self log, do one of the following:

WebUI
Configuration > Report Settings > Log Settings: Select the Log Packets
Terminated to Self check box, then click Apply.

CLI
set firewall log-self

When you enable the self log, the security device logs the entries in two places: the
self log and the traffic log. Similar to the traffic log, the self log displays the date,
time, source address/port, destination address/port, duration, and service for each
dropped packet terminating at the security device. Self log entries typically have a
source zone of Null and a destination zone of “self.”

Viewing the Self Log

You can view the self log, which is stored in flash storage on the security device,
through either the CLI or WebUI.

WebUI
Reports > System Log > Self

CLI
get log self

Sorting and Filtering the Self Log

Similar to the event and traffic logs, when you use the CLI to view the self log, you
can sort or filter the log entries according to the following criteria:

 Source or Destination IP Address: You can sort the self log by source or
destination IP address. You can also filter the self log by specifying a source or
destination IP address or range of addresses.

 Date: You can sort the self log by date only, or by date and time. The device
lists the log entries in descending order by date and time.

You can also filter self log entries by specifying a start date, an end date, or a
date range. When you specify a start date, the device displays log entries with
date/time stamps after the start date. When you specify an end date, the device
displays log entries with date/time stamps before the end date.

 Time: When you sort the self log by time, the security device displays the log
entries in descending order by time, regardless of the date. When you specify a
start time, the device displays log entries with time stamps after the specified
start time, regardless of the date. When you specify an end time, the device

66  Self Log
 Chapter 2: Monitoring Security Devices

displays log entries with time stamps before the specified end time, regardless
of the date. When you specify both a start and end time, the device displays log
entries with time stamps within the specified time period.

Example: Filtering the Self Log by Time

In this example, you filter self log entries by the end time. The security device
displays log entries with time stamps before the specified end time:

WebUI

NOTE: The ability to filter the self log by time is available only through the CLI.

CLI
get log self end-time 16:32:57

Date Time Duration Source IP Port Destination IP Port Service

2003-08-21 16:32:57 0:00:00 10.100.25.1 0 224.0.0.5 0 OSPF
2003-08-21 16:32:47 0:00:00 10.100.25.1 0 224.0.0.5 0 OSPF
Total entries matched = 2

Downloading the Self Log

You can also save the log as a text file to a location you specify, and then use an
ASCII text editor (such as Notepad or WordPad) to view it.

In this example, you download a self log to the local directory “C:\netscreen\logs”
(WebUI) or to the root directory of a TFTP server at the IP address 10.1.1.5 (CLI).
You name the file “self_log07-03-02.txt.”

WebUI
1. Reports > System Log > Self: Click Save.

The File Download dialog box prompts you to open the file (using an ASCII
editor) or save it to disk.

2. Select the Save option, then click OK.

The File Download dialog box prompts you to choose a directory.

3. Specify C:\netscreen\logs, name the file self_log07-03-02.txt, then click Save.

CLI
get log self > tftp 10.1.1.5 self_log07-03-02.txt

Self Log  67
 Concepts & Examples ScreenOS Reference Guide

Downloading the Asset Recovery Log

A Juniper Networks security device provides an asset recovery log to display
information about each time the device is returned to its default settings using the
asset recovery procedure (see “Resetting the Device to the Factory Default Settings”
on page 41). In addition to viewing the asset recovery log through the WebUI or
CLI, you can also open or save the file to the location you specify. Use an ASCII text
editor (such as Notepad) to view the file.

In this example, you download the asset recovery log to the local directory
“C:\netscreen\logs” (WebUI) or to the root directory of a TFTP server at the IP
address 10.1.1.5 (CLI). You name the file “sys_rst.txt,”

WebUI
1. Reports > System Log > Asset Recovery: Click Save.

The File Download dialog box prompts you to open the file (using an ASCII
editor) or save it to disk.

2. Select the Save option, then click OK.

The File Download dialog box prompts you to choose a directory.

3. Specify C:\netscreen\logs, name the file sys_rst.txt, then click Save.

CLI
get log asset-recovery > tftp 10.1.1.5 sys_rst.txt

Traffic Alarms
The security device supports traffic alarms when traffic exceeds thresholds that you
have defined in policies. You can configure the security device to alert you through
one or more of the following methods whenever the security device generates a
traffic alarm:

 Console

 Internal (Event Log)

 Email

 SNMP

 Syslog

 WebTrends

 NetScreen-Global PRO

You set alarm thresholds to detect anomalous activity. To know what constitutes
anomalous activity, you must first establish a baseline of normal activity. To create
such a baseline for network traffic, you must observe traffic patterns over a period
of time. Then, after you have determined the amount of traffic that you consider as

68  Downloading the Asset Recovery Log

 Chapter 2: Monitoring Security Devices

normal, you can set alarm thresholds above that amount. Traffic exceeding that
threshold triggers an alarm to call your attention to a deviation from the baseline.
You can then evaluate the situation to determine what caused the deviation and
whether you need to take action in response.

You can also use traffic alarms to provide policy-based intrusion detection and
notification of a compromised system. Examples of the use of traffic alarms for
these purposes are provided below.

Example: Policy-Based Intrusion Detection

In this example, there is a webserver with IP address 211.20.1.5 (and name
“web1”) in the DMZ zone. You want to detect any attempts from the Untrust zone
to access this webserver via Telnet. To accomplish this, you create a policy denying
Telnet traffic from any address in the Untrust zone destined to the webserver
named web1 in the DMZ zone, and you set a traffic alarm threshold at 64 bytes.
Because the smallest size of IP packet is 64 bytes, even one Telnet packet
attempting to reach the webserver from the Untrust zone will trigger an alarm.

WebUI
Policy > Policy Elements > Addresses > List > New: Enter the following,
then click OK:

Address Name: web1

IP Address/Domain Name:
IP/Netmask: (select), 211.20.1.5/32
Zone: DMZ

Policies > (From: Untrust, To: DMZ) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), Any
Destination Address:
Address Book Entry: (select), web1
Service: Telnet
Action: Deny

> Advanced: Enter the following, then click Return to set the advanced
options and return to the basic configuration page:

Counting: (select)
Alarm Threshold: 64 Bytes/Sec, 0 Kbytes/Min

CLI
set address dmz web1 211.20.1.5/32
set policy from untrust to dmz any web1 telnet deny count alarm 64 0
save

Traffic Alarms  69
 Concepts & Examples ScreenOS Reference Guide

Example: Compromised System Notification

In this example, you use traffic alarms to provide notification of a compromised
system. You have an FTP server with IP address 211.20.1.10 (and name ftp1) in the
DMZ zone. You want to allow FTP-get traffic to reach this server. You don’t want
traffic of any kind to originate from the FTP server. The occurrence of such traffic
would indicate that the system has been compromised, perhaps by a virus similar
to the NIMDA virus. You define an address for the FTP server in the Global zone, so
that you can then create two global policies.

WebUI
Policy > Policy Elements > Addresses > List > New: Enter the following,
then click OK:

Address Name: ftp1

IP Address/Domain Name:
IP/Netmask: (select), 211.20.1.10/32
Zone: Global

Policies > (From: Global, To: Global) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), Any
Destination Address:
Address Book Entry: (select), ftp1
Service: FTP-Get
Action: Permit

Policies > (From: Global, To: Global) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), ftp1
Destination Address:
Address Book Entry: (select), Any
Service: ANY
Action: Deny

> Advanced: Enter the following, then click Return to set the advanced
options and return to the basic configuration page:

Counting: (select)
Alarm Threshold: 64 Bytes/Sec, 0 Kbytes/Min

CLI
set address global ftp1 211.20.1.10/32
set policy global any ftp1 ftp-get permit
set policy global ftp1 any deny count alarm 64 0
save

70  Traffic Alarms
 Chapter 2: Monitoring Security Devices

Example: Sending Email Alerts

In this example, you set up notification by email alerts when there is an alarm. The
mail server is at 172.16.10.254, the first email address to be notified is
[email protected], and the second address is [email protected]. The security
device includes traffic logs with event logs sent via email.

WebUI
Configuration > Report Settings > Email: Enter the following information,
then click Apply:

Enable E-Mail Notification for Alarms: (select)

Include Traffic Log: (select)
SMTP Server Name: 172.16.10.254
E-Mail Address 1: [email protected]
E-Mail Address 2: [email protected]

NOTE: If you have DNS enabled, you can also use a hostname for the mail server, such as
mail.juniper.net.

CLI
set admin mail alert
set admin mail mail-addr1 [email protected]
set admin mail mail-addr2 [email protected]
set admin mail server-name 172.16.10.254
set admin mail traffic-log
save

Syslog
A security device can generate syslog messages for system events at predefined
severity levels (see the list of severity levels in “Event Log” on page 57), and
optionally for traffic that policies permit across a firewall. It sends these messages
to up to four designated syslog hosts running on UNIX/Linux systems. For each
syslog host, you can specify the following:

 Whether the security device includes traffic log entries, event log entries, or
both traffic and event log entries.

 Whether to send traffic through a VPN tunnel to the syslog server and—if
through a VPN tunnel—which interface to use as the source interface (for
examples, see “Example: Self-Generated Traffic Through a Route-Based
Tunnel” on page 79 and “Example: Self-Generated Traffic Through a
Policy-Based Tunnel” on page 86).

 The port to which the security device sends syslog messages.

 The security facility, which classifies and sends emergency and alert level
messages to the Syslog host; and the regular facility, which classifies and sends
all other messages for events unrelated to security.

By default, the security device sends messages to syslog hosts via UDP (port 514).
To increase the reliability of the message delivery, you can change the transport
protocol for each syslog host to TCP.

Syslog  71
 Concepts & Examples ScreenOS Reference Guide

You can use syslog messages to create email alerts for the system administrator, or
to display messages on the console of the designated host using UNIX syslog
conventions.

NOTE: On UNIX/Linux platforms, modify the /etc/rc.d/init.d/syslog file so that syslog

retrieves information from the remote source (syslog -r).

Example: Enabling Multiple Syslog Servers

In this example, you configure the security device to send event and traffic logs via
TCP to three syslog servers at the following IP addresses/port numbers:
1.1.1.1/1514, 2.2.2.1/2514, and 3.3.3.1/3514. You set both the security and facility
levels to Local0.

WebUI
Configuration > Report Settings > Syslog: Enter the following, then click
Apply:

Enable syslog messages: Select this option to send logs to the specified
syslog servers.
No.: Select 1, 2, and 3 to indicate you are adding 3 syslog servers.
IP/Hostname: 1.1.1.1, 2.2.2.1, 3.3.3.1
Port: 1514, 2514, 3514
Security Facility: Local0, Local0, Local0
Facility: Local0, Local0, Local0
Event Log: (select)
Traffic Log: (select)
TCP: (select)

CLI
set syslog config 1.1.1.1 port 1514
set syslog config 1.1.1.1 log all
set syslog config 1.1.1.1 facilities local0 local0
set syslog config 1.1.1.1 transport tcp
set syslog config 2.2.2.1 port 2514
set syslog config 2.2.2.1 log all
set syslog config 2.2.2.1 facilities local0 local0
set syslog config 2.2.2.1 transport tcp
set syslog config 3.3.3.1 port 3514
set syslog config 3.3.3.1 log all
set syslog config 3.3.3.1 facilities local0 local0
set syslog config 2.2.2.1 transport tcp
set syslog enable
save

Enabling WebTrends for Notification Events

NetIQ offers a product called the WebTrends Firewall Suite that allows you to create
customized reports based on the logs generated by a security device. WebTrends
analyzes the log files and displays the information you need in a graphical format.
You can create reports on all events and severity levels or focus on an area such as
firewall attacks. (For additional information on WebTrends, refer to the WebTrends
product documentation.)

72  Syslog
 Chapter 2: Monitoring Security Devices

You can also send WebTrends messages through a VPN tunnel. In the WebUI, use
the Use Trust Zone Interface as Source IP for VPN option. In the CLI, use the set
webtrends vpn command.

In the following example, you send notification messages to the WebTrends host
(172.10.16.25).

WebUI
1. WebTrends Settings
Configuration > Report Settings > WebTrends: Enter the following, then click
Apply:

Enable WebTrends Messages: (select)

WebTrends Host Name/Port: 172.10.16.25/514
2. Severity Levels
Configuration > Report Settings > Log Settings: Enter the following, then click
Apply:

WebTrends Notification: (select)

NOTE: When you enable WebTrends on a security device running in Transparent mode,
you must set up a static route. See “Static Routing” on page 7 -1.

CLI
3. WebTrends Settings
set webtrends host-name 172.10.16.25
set webtrends port 514
set webtrends enable
4. Severity Levels
set log module system level notification destination webtrends
save

Syslog  73
 Concepts & Examples ScreenOS Reference Guide

Simple Network Management Protocol

The Simple Network Management Protocol (SNMP) agent for the Juniper Networks
security device provides network administrators with a way to view statistical data
about the network and the devices on it, and to receive notification of system
events of interest.

Juniper Networks security devices support the SNMPv1 protocol, described in

RFC-1157, A Simple Network Management Protocol, and the SNMPv2c protocol,
described in the following RFCs:

 RFC-1901, Introduction to Community-based SNMPv2

 RFC-1905, Protocol Operations for Version 2 of the Simple Network Management

Protocol (SNMPv2)

 RFC-1906, Transport Mappings for Version 2 of the Simple Network Management

Protocol (SNMPv2)

Security devices also support all relevant Management Information Base II (MIB II)
groups defined in RFC-1213, Management Information Base for Network
Management of TCP/IP-based Internets: MIB-II. The devices also have private
enterprise MIB files, which you can load into an SNMP MIB browser.

NOTE: Using SNMP MIB browser, you can check the CPU, memory usage, and session
usage counts on both the ScreenOS and the Intrusion Detection and Prevention
(IDP) security modules.

The Juniper Networks SNMP agent generates the following traps (notifications)
when specified events or conditions occur:

 Cold Start Trap: The security device generates a cold start trap when it
becomes operational after you power it on.

 Trap for SNMP Authentication Failure: The SNMP agent in the security device
triggers the authentication failure trap if someone attempts to connect to it
using an incorrect SNMP community string or if the IP address of the host
attempting the connection is not defined in an SNMP community. (This option
is enabled by default.)

 Traps for System Alarms: security device error conditions and firewall
conditions trigger system alarms. Three enterprise traps are defined to cover
alarms related to hardware, security, and software. (For more information on
firewall settings and alarms, see “ICMP Fragments” on page 4 -240 and “Traffic
Alarms” on page 68.)

 Traps for Traffic Alarms: Traffic alarms are triggered when traffic exceeds the
alarm thresholds set in policies. (For more information on configuring policies,
see “Policies” on page 2 -159.)

74  Simple Network Management Protocol

 Chapter 2: Monitoring Security Devices

Table 2 lists possible alarm types and their associated trap number.

Table 2: Trap Alarm Types

Trap Enterprise ID Description

100 Hardware problems
200 Firewall problems
300 Software problems
400 Traffic problems
500 VPN problems
600 NSRP problems
800 DRP problems
900 Interface failover
problems
1000 Firewall attacks

NOTE: The network administrator must have an SNMP manager application such as
HP OpenView or SunNet Manager to browse the SNMP MIB II data and to receive
traps from either the trusted or untrusted interface. Shareware and freeware
SNMP manager applications available from the Internet.

Security devices do not ship with a default configuration for the SNMP manager. To
configure your security device for SNMP, you must first create communities, define
their associated hosts, and assign permissions (read/write or read-only).

When you create an SNMP community, you can specify whether the community
supports SNMPv1, SNMPv2c, or both SNMP versions, as required by the SNMP
management stations. (For backward compatibility with earlier ScreenOS releases
that only support SNMPv1, security devices support SNMPv1 by default.) If an
SNMP community supports both SNMP versions, you must specify a trap version
for each community member.

For security reasons, an SNMP community member with read/write privileges can
change only the following variables on a security device:

 sysContact - Contact information for the admin of the security device in case
the SNMP admin needs to contact him or her. This can be the security admin’s
name, email address, telephone number, office location, or a combination of
such information.

 sysLocation - The physical location of the security device. This can be the
name of a country, city, building, or its exact location on a rack in a network
operations center (NOC).

 sysName - The name that SNMP administrators use for the security device. By
convention, this is a fully qualified domain name (FQDN), but it can be
something else.

Simple Network Management Protocol  75

 Concepts & Examples ScreenOS Reference Guide

 snmpEnableAuthenTraps - This enables or disables the SNMP agent in the

security device to generate a trap whenever someone attempts to contact the
SNMP agent with an incorrect SNMP community name.

 ipDefaultTTL - The default value inserted into the time-to-live (TTL) field in the
IP header of datagrams originating from the security device whenever the
Transport Layer protocol does not supply a TTL value.

 ipForwarding - This indicates whether or not the security device forwards

traffic—other than that destined for the security device itself. By default, the
security device indicates that it does not forward traffic.

Implementation Overview
Juniper Networks has implemented SNMP in its devices in the following ways:

 SNMP administrators are grouped in SNMP communities. A device can support

up to three communities, with up to eight members in each community.

 A community member can be either a single host or a subnet of hosts,

depending on the netmask you use when defining the member. By default, the
security device assigns an SNMP community member with a 32-bit netmask
(255.255.255.255), which defines it as a single host.

 If you define an SNMP community member as a subnet, any device on that

subnet can poll the security device for SNMP MIB information. However, the
security device cannot send an SNMP trap to a subnet, only to an individual
host.

 Each community has either read-only or read-write permission for the MIB II
data.

 Each community can support SNMPv1, SNMPv2c, or both. If a community

supports both versions of SNMP, you must specify a trap version for each
community member.

 You can allow or deny each community from receiving traps.

 You can access the MIB II data and traps through any physical interface.

 Each system alarm (a system event classified with a severity level of critical,
alert, or emergency) generates a single enterprise SNMP trap to each of the
hosts in each community that is set to receive traps.

 The security device sends Cold Start / Link Up / Link Down traps to all hosts in
communities that you set to receive traps.

 If you specify trap-on for a community, you also have the option to allow traffic
alarms.

 You can send SNMP messages through a route-based or policy-based VPN

tunnel. For more information, see “VPN Tunnels for Self-Initiated Traffic” on
page 78.

76  Simple Network Management Protocol

 Chapter 2: Monitoring Security Devices

Defining a Read/Write SNMP Community

In this example, you create an SNMP community, named MAge11. You assign it
read/write privileges and enable its members to receive MIB II data and traps. It has
the following two members 1.1.1.5/32 and 1.1.1.6/32. Each of these members has
an SNMP manager application running a different version of SNMP: SNMPv1 and
SNMPv2c. The community name functions as a password and needs to be
protected.

You provide contact information for the local admin of the security device in case
an SNMP community member needs to contact him—name: [email protected].
You also provide the location of the security device—location: 3-15-2. These
numbers indicate that the device is on the third floor, in the fifteenth row, and in
the second position in that row.

You also enable the SNMP agent to generate traps whenever someone illegally
attempts an SNMP connection to the security device. Authentication failure traps is
a global setting that applies to all SNMP communities and is disabled by default.

Finally, you enable SNMP manageability on ethernet1, an interface that you have
previously bound to the Trust zone. This is the interface through which the SNMP
manager application communicates with the SNMP agent in the security device.

WebUI
Configuration > Report Settings > SNMP: Enter the following settings, then
click Apply:

System Contact: [email protected]

Location: 3-15-2
Enable Authentication Fail Trap: (select)

Configuration > Report Settings > SNMP > New Community: Enter the
following settings, then click OK:

Community Name: MAge11

Permissions:
Write: (select)
Trap: (select)
Including Traffic Alarms: (clear)
Version: ANY (select)
Hosts IP Address/Netmask and Trap Version:
1.1.1.5/32 v1
1.1.1.6/32 v2c

Network > Interfaces > Edit (for ethernet1): Enter the following settings, then
click OK:

Service Options:
Management Services: SNMP

Simple Network Management Protocol  77

 Concepts & Examples ScreenOS Reference Guide

CLI
set snmp contact [email protected]
set snmp location 3-15-2
set snmp auth-trap enable
set snmp community MAge11 read-write trap-on version any
set snmp host Mage 1.1.1.5/32 trap v1
set snmp host Mage 1.1.1.6/32 trap v2
set interface ethernet1 manage snmp
save

VPN Tunnels for Self-Initiated Traffic

You can use virtual private network (VPN) tunnels to secure remote monitoring of a
security device from a fixed IP address. Using a VPN tunnel, you can protect traffic
addressed to and initiated from a security device. Types of traffic initiated from a
security device can include NetScreen-Global PRO reports, event log entries sent to
syslog and WebTrends servers, and SNMP MIB traps.

Juniper Networks security devices support two types of VPN tunnel configurations:

 Route-Based VPNs: The security device uses route table entries to direct traffic
to tunnel interfaces, which are bound to VPN tunnels.

To send traffic such as event log entries, NetScreen-Global PRO reports, or

SNMP traps generated by the security device through a route-based VPN
tunnel, you must manually enter a route to the proper destination. The route
must point to the tunnel interface that is bound to the VPN tunnel through
which you want the security device to direct the traffic. No policy is required.

 Policy-Based VPNs: The security device uses the VPN tunnel names specifically
referenced in policies to direct traffic through VPN tunnels.

To send self-initiated traffic through a policy-based VPN tunnel, you must

include the source and destination addresses in the policy. For the source
address, use the IP address of an interface on the security device. For the
destination address, use the IP address of the storage server or SNMP
community member’s workstation, if it is located behind a remote security
device. If the remote SNMP community member uses the NetScreen-Remote
VPN client to make VPN connections to the local security device, use an
internal IP address defined on the NetScreen-Remote as the destination
address.

If either the remote gateway or the end entity has a dynamically assigned IP
address, then the security device cannot initiate the formation of a VPN tunnel
because these addresses cannot be predetermined, and thus you cannot define
routes to them. In such cases, the remote host must initiate the VPN connection.
After either a policy-based or route-based VPN tunnel is established, both ends of
the tunnel can initiate traffic if policies permit it. Also, for a route-based VPN, there
must be a route to the end entity through a tunnel interface bound to the VPN
tunnel—either because you manually entered the route or because the local
security device received the route through the exchange of dynamic routing
messages after a tunnel was established. (For information about dynamic routing

78  VPN Tunnels for Self-Initiated Traffic

 Chapter 2: Monitoring Security Devices

protocols, see Volume 7: Routing.) You can also use VPN monitoring with the rekey
option or IKE heartbeats to ensure that once the tunnel is established, it remains up
regardless of VPN activity. (For more information about these options, see “VPN
Monitoring” on page 5 -252 and “Monitoring Mechanisms” on page 5 -303.)

For each VPN tunnel configuration type, you can use any of the following types of
VPN tunnel:

 Manual Key: You manually set the three elements that define a Security
Association (SA) at both ends of the tunnel: a Security Parameters Index (SPI),
an encryption key, and an authentication key. To change any element in the
SA, you must manually enter it at both ends of the tunnel.

 AutoKey IKE with Pre-shared Key: One or two pre-shared secrets—one for
authentication and one for encryption—function as seed values. Using them,
the IKE protocol generates a set of symmetrical keys at both ends of the tunnel;
that is, the same key is used to encrypt and decrypt. At predetermined
intervals, these keys are automatically regenerated.

 AutoKey IKE with Certificates: Using the Public Key Infrastructure (PKI), the
participants at both ends of the tunnel use a digital certificate (for
authentication) and an RSA public/private key pair (for encryption). The
encryption is asymmetrical; that is, one key in a pair is used to encrypt and the
other to decrypt.

NOTE: For a complete description of VPN tunnels, see Volume 5: Virtual Private Networks.
For more information on NetScreen-Remote, refer to the NetScreen-Remote VPN
Client Administrator Guide.

Example: Self-Generated Traffic Through a Route-Based Tunnel

Figure 16 illustrates an example in which you configure a local security device
(Device-A) to send SNMPv1 MIB traps and syslog reports through a route-based
AutoKey IKE VPN tunnel to an SNMP community member behind a remote
security device (Device-B). The tunnel uses a pre-shared key (Ci5y0a1aAG) for data
origin authentication and the security level predefined as “Compatible” for both
Phase 1 and Phase 2 proposals. You, as the local admin for Device-A, create the
tunnel.1 interface and bind it to vpn1. You and the admin for Device-B define the
proxy IDs as shown in Table 3.

Table 3: Proxy IDs for Route-Based Tunnel

Device-A Device-B
Local IP 10.1.1.1/32 Local IP 10.2.2.2/32
Remote IP 10.2.2.2/32 Remote IP 10.1.1.1/32
Service Any Service Any

You bind ethernet1 to the Trust zone and ethernet3 to the Untrust zone. The default
gateway IP address is 1.1.1.250. All zones are in the trust-vr routing domain.

VPN Tunnels for Self-Initiated Traffic  79

 Concepts & Examples ScreenOS Reference Guide

Figure 16: Traffic Through a Route-Based Tunnel

Untrust Zone
Local
Trust Zone Site

ethernet1 SNMP Manager

10.1.1.1/24 tunnel.1, Unnumbered and Syslog
NAT ethernet3, 1.1.1.1/24 Server 10.2.2.2
gateway, 1.1.1.250

Device-A Internet
LAN LAN
10.1.1.0/24 10.2.2.0/24
TUNNEL: VPN1 Device-B

gateway, 2.2.2.250
ethernet3, 2.2.2.2/24 ethernet1
10.2.2.1/24
tunnel.1, Unnumbered NAT

Remote
Untrust Zone Site Trust Zone

The remote admin for Device-B uses similar settings to define that end of the
AutoKey IKE VPN tunnel so that the pre-shared key, proposals, and proxy IDs
match.

You also configure an SNMP community named “remote_admin” with read/write

privileges, and you enable the community to receive traps. You define the host at
10.2.2.2/32 as a community member.

NOTE: This example assumes that the remote admin has already set up the syslog server
and SNMP manager application that supports SNMPv1. When the remote admin
sets up the VPN tunnel on his security device, he uses 1.1.1.1 as the remote
gateway and 10.1.1.1 as the destination address.

WebUI (Device-A)
1. Interfaces
Network > Interfaces > Edit (for ethernet1): Enter the following, then click
Apply:

Zone Name: Trust

Static IP: (select this option when present)
IP Address/Netmask: 10.1.1.1/24

Select the following, then click OK:

Interface Mode: NAT (select)

80  VPN Tunnels for Self-Initiated Traffic

 Chapter 2: Monitoring Security Devices

NOTE: By default, any interface that you bind to the Trust zone is in NAT mode.
Consequently, this option is already enabled for interfaces bound to the Trust
zone.

When the remote admin configures the SNMP manager, he must enter 10.1.1.1 in
the Remote SNMP Agent field. This is the address to which the SNMP manager
sends queries.

Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:

Zone Name: Untrust

Static IP: (select this option when present)
IP Address/Netmask: 1.1.1.1/24
Service Options:
Management Services: SNMP

Network > Interfaces > New Tunnel IF: Enter the following, then click OK:

Tunnel Interface Name: tunnel.1

Zone (VR): Untrust (trust-vr)
Unnumbered: (select)
Interface: ethernet1(trust-vr)
2. Syslog and SNMP
Configuration > Report Settings > Syslog: Enter the following, then click
Apply:

Enable Syslog Messages: (select)

No.: Select 1 to indicate you are adding 1 syslog server.
IP / Hostname: 10.2.2.2
Port: 514
Security Facility: auth/sec
Facility: Local0

Configuration > Report Settings > SNMP > New Community: Enter the
following, then click OK:

Community Name: remote_admin

Permissions:
Write: (select)
Trap: (select)
Including Traffic Alarms: (clear)
Version: V1
Hosts IP Address/Netmask:
10.2.2.2/32 V1
Trap Version:
V1

VPN Tunnels for Self-Initiated Traffic  81

 Concepts & Examples ScreenOS Reference Guide

3. VPN
VPNs > AutoKey IKE > New: Enter the following, then click OK:

VPN Name: vpn1

Security Level: Compatible
Remote Gateway: Create a Simple Gateway: (select)
Gateway Name: to_admin
Type: Static IP, Address/Hostname: 2.2.2.2
Preshared Key: Ci5y0a1aAG
Security Level: Compatible
Outgoing interface: ethernet3

> Advanced: Enter the following advanced settings, then click Return to
return to the basic AutoKey IKE configuration page:

Bind to: Tunnel Interface: (select), tunnel.1

Proxy-ID: (select)
Local IP/Netmask: 10.1.1.1/32
Remote IP/Netmask: 10.2.2.2/32
Service: ANY
4. Routes
Network > Routing > Destination > trust-vr New: Enter the following, then
click OK:

Network Address/Netmask: 10.2.2.2/32

Gateway: (select)
Interface: tunnel.1
Gateway IP Address: 0.0.0.0

Network > Routing > Destination > trust-vr New: Enter the following, then
click OK:

Network Address/Netmask: 0.0.0.0/0

Gateway: (select)
Interface: ethernet3
Gateway IP Address: (select) 1.1.1.250

CLI (Device-A)
1. Interfaces
set interface ethernet1 zone trust
set interface ethernet1 ip 10.1.1.1/24
set interface ethernet1 nat
set interface ethernet3 zone untrust
set interface ethernet3 ip 1.1.1.1/24
set interface ethernet3 manage snmp
set interface tunnel.1 zone untrust
set interface tunnel.1 ip unnumbered interface ethernet1

NOTE: When the remote admin configures the SNMP manager, he must enter 10.1.1.1 in
the Remote SNMP Agent field. This is the address to which the SNMP manager
sends queries.

By default, any interface that you bind to the Trust zone is in NAT mode.
Consequently, this option is already enabled for interfaces bound to the Trust
zone.

82  VPN Tunnels for Self-Initiated Traffic

 Chapter 2: Monitoring Security Devices

2. VPN
set ike gateway to_admin address 2.2.2.2 outgoing-interface ethernet3 preshare
Ci5y0a1aAG sec-level compatible
set vpn vpn1 gateway to_admin sec-level compatible
set vpn vpn1 bind interface tunnel.1
set vpn vpn1 proxy-id local-ip 10.1.1.1/32 remote-ip 10.2.2.2/32 any
3. Syslog and SNMP
set syslog config 10.2.2.2 auth/sec local0
set syslog enable
set snmp community remote_admin read-write trap-on version v1
set snmp host remote_admin 10.2.2.2/32
4. Routes
set vrouter trust-vr route 10.2.2.2/32 interface tunnel.1
set vrouter trust-vr route 0.0.0.0/0 interface ethernet3 gateway 1.1.1.250
save

WebUI (Device-B)
1. Interfaces
Network > Interfaces > Edit (for ethernet1): Enter the following, then click
Apply:

Zone Name: Trust

Static IP: (select this option when present)
IP Address/Netmask: 10.2.2.1/24

Select the following, then click OK:

Interface Mode: NAT

Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:

Zone Name: Untrust

Static IP: (select this option when present)
IP Address/Netmask: 2.2.2.2/24

Network > Interfaces > New Tunnel IF: Enter the following, then click OK:

Tunnel Interface Name: tunnel.1

Zone (VR): Untrust (trust-vr)
Unnumbered: (select)
Interface: ethernet1(trust-vr)
2. Addresses
Policy > Policy Elements > Addresses > Lists > New: Enter the following,
then click OK:

Address Name: addr1

IP Address/Domain Name: IP/Netmask: 10.2.2.2/32
Zone: Trust

VPN Tunnels for Self-Initiated Traffic  83

 Concepts & Examples ScreenOS Reference Guide

Policy > Policy Elements > Addresses > Lists > New: Enter the following,
then click OK:

Address Name: ns-a

IP Address/Domain Name: IP/Netmask: 10.1.1.1/32
Zone: Untrust
3. Service Group
Policy > Policy Elements > Services > Groups > New: Enter the following
group name, move the following services, then click OK:

Group Name: s-grp1

Select Syslog and use the << button to move the service from the
Available Members column to the Group Members column.

Select SNMP and use the << button to move the service from the
Available Members column to the Group Members column.

4. VPN
VPNs > AutoKey IKE > New: Enter the following, then click OK:

VPN Name: vpn1

Security Level: Compatible
Remote Gateway: Create a Simple Gateway: (select)
Gateway Name: to_admin
Type: Static IP, Address/Hostname: 1.1.1.1
Preshared Key: Ci5y0a1aAG
Security Level: Compatible
Outgoing Interface: ethernet3

> Advanced: Enter the following advanced settings, then click Return to
return to the basic AutoKey IKE configuration page:

Bind to: Tunnel Interface: (select), tunnel.1

Proxy-ID: (select)
Local IP/Netmask: 10.2.2.2/32
Remote IP/Netmask: 10.1.1.1/32
Service: Any
5. Routes
Network > Routing > Destination > trust-vr New: Enter the following, then
click OK:

Network Address/Netmask:10.1.1.1/32
Gateway: (select)
Interface: tunnel.1
Gateway IP Address: 0.0.0.0

Network > Routing > Destination > trust-vr New: Enter the following, then
click OK:

Network Address/Netmask: 0.0.0.0/0

Gateway: (select)
Interface: ethernet3
Gateway IP Address: (select) 2.2.2.250

84  VPN Tunnels for Self-Initiated Traffic

 Chapter 2: Monitoring Security Devices

6. Policies
Policies > (From: Trust, To: Untrust) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), addr1
Destination Address:
Address Book Entry: (select), ns-a
Service: s-grp1
Action: Permit
Position at Top: (select)

Policies > (From: Untrust, To: Trust) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), ns-a
Destination Address:
Address Book Entry: (select), addr1
Service: s-grp1
Action: Permit
Position at Top: (select)

CLI (Device-B)
1. Interfaces
set interface ethernet1 zone trust
set interface ethernet1 ip 10.2.2.1/24
set interface ethernet1 nat
set interface ethernet3 zone untrust
set interface ethernet3 ip 2.2.2.2/24
set interface tunnel.1 zone untrust
set interface tunnel.1 ip unnumbered interface ethernet1
2. Addresses
set address trust addr1 10.2.2.2/32
set address untrust ns-a 10.1.1.1/32
3. Service Group
set group service s-grp1
set group service s-grp1 add syslog
set group service s-grp1 add snmp
4. VPN
set ike gateway to_admin address 1.1.1.1 outgoing-interface ethernet3 preshare
Ci5y0a1aAG sec-level compatible
set vpn vpn1 gateway to_admin sec-level compatible
set vpn vpn1 bind interface tunnel.1
set vpn vpn1 proxy-id local-ip 10.2.2.2/32 remote-ip 10.1.1.1/32 any
5. Routes
set vrouter trust-vr route 10.1.1.1/32 interface tunnel.1
set vrouter trust-vr route 0.0.0.0/0 interface ethernet3 gateway 2.2.2.250
6. Policies
set policy top from trust to untrust addr1 ns-a s-grp1 permit
set policy top from untrust to trust ns-a addr1 s-grp1 permit
save

VPN Tunnels for Self-Initiated Traffic  85

 Concepts & Examples ScreenOS Reference Guide

Example: Self-Generated Traffic Through a Policy-Based Tunnel

In this example (illustrated in Figure 17), you configure a local security device
(Device-A) to send SNMPv2c MIB traps and syslog reports through a policy-based
AutoKey IKE VPN tunnel (vpn1) to an SNMP community member behind a remote
security device (Device-B). The tunnel uses a preshared key (Ci5y0a1aAG) for data
origin authentication and the security level predefined as “Compatible” for both
Phase 1 and Phase 2 proposals.

NOTE: This example assumes that the remote admin has already set up the syslog server
and an SNMP manager application that supports SNMPv2c. When the remote
admin sets up the VPN tunnel on his security device, he uses 1.1.1.1 as the
remote gateway and 10.1.1.1 as the destination address.

Both you and the remote admin bind ethernet1 to the Trust zone, and ethernet3 to
the Untrust zone on Device-A and Device-B. The default gateway IP address for
Device-A is 1.1.1.250. The default gateway IP address for Device-B is 2.2.2.250. All
zones are in the trust-vr routing domain.

Figure 17: Traffic Through a Policy-Based Tunnel

Local Untrust Zone

Trust Zone Site

SNMP Manager
ethernet1 and Syslog
10.1.1.1/24 ethernet3, 1.1.1.1/24 Server 10.2.2.2
NAT
gateway, 1.1.1.250

Device-A Internet
LAN LAN
10.1.1.0/24 10.2.2.0/24
TUNNEL: VPN1 Device-B

gateway, 2.2.2.250
ethernet3, 2.2.2.2/24 ethernet1
10.2.2.1/24
NAT

Untrust Zone Remote Trust Zone

Site

You also configure an SNMP community named “remote_admin” with read/write

privileges, and you enable the community to receive traps. You define the host at
10.2.2.2/32 as a community member.

The inbound and outbound policies on Device-A match the outbound and inbound
policies on Device-B. The addresses and service used in the policies are as follows:

 10.1.1.1/32, the address of the Trust zone interface on Device-A

 10.2.2.2/32, the address of the host for the SNMP community member and
syslog server

 Service group named “s-grp1,” which contains SNMP and syslog services

86  VPN Tunnels for Self-Initiated Traffic

 Chapter 2: Monitoring Security Devices

From the policies that you and the admin for Device-B create, the two security
devices derive the following proxy IDs for vpn1:

Table 4: Proxy IDs for Policy-Based Tunnel

Device-A Device-B
Local IP 10.1.1.1/32 Local IP 10.2.2.2/32
Remote IP 10.2.2.2/32 Remote IP 10.1.1.1/32
Service Any Service Any

NOTE: The security device treats a service group as “any” in proxy IDs.

WebUI (Device-A)
1. Interfaces—Security Zones
Network > Interfaces > Edit (for ethernet1): Enter the following, then click
OK:

Zone Name: Trust

Static IP: (select this option when present)
IP Address/Netmask: 10.1.1.1/24

Select the following, then click OK:

Interface Mode: NAT (select)

NOTE: When the remote admin configures the SNMP manager, he must enter 10.1.1.1 in
the Remote SNMP Agent field. This is the address to which the SNMP manager
sends queries.

By default, any interface that you bind to the Trust zone is in NAT mode.
Consequently, this option is already enabled for interfaces bound to the Trust
zone.

Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:

Zone Name: Untrust

Static IP: (select this option when present)
IP Address/Netmask: 1.1.1.1/24
Service Options:
Management Services: SNMP
2. Addresses
Policy > Policy Elements > Addresses > Lists > New: Enter the following,
then click OK:

Address Name: trust_int

IP Address/Domain Name:
IP/Netmask: 10.1.1.1/32
Zone: Trust

Policy > Policy Elements > Addresses > Lists > New: Enter the following,
then click OK:

VPN Tunnels for Self-Initiated Traffic  87

 Concepts & Examples ScreenOS Reference Guide

Address Name: remote_admin

IP Address/Domain Name:
IP/Netmask: 10.2.2.2/32
Zone: Untrust
3. Service Group
Policy > Policy Elements > Services > Groups > New: Enter the following
group name, move the following services, then click OK:

Group Name: s-grp1

Select Syslog and use the << button to move the service from the
Available Members column to the Group Members column.

Select SNMP and use the << button to move the service from the
Available Members column to the Group Members column.

4. VPN
VPNs > AutoKey IKE > New: Enter the following, then click OK:

VPN Name: vpn1

Security Level: Compatible
Remote Gateway: Create a Simple Gateway: (select)
Gateway Name: to_admin
Type: Static IP, Address/Hostname: 2.2.2.2
Preshared Key: Ci5y0a1aAG
Security Level: Compatible
Outgoing Interface: ethernet3
5. Syslog and SNMP
Configuration > Report Settings > Syslog: Enter the following, then click
Apply:

Enable Syslog Messages: (select)

Source Interface: ethernet1
No.: Select 1 to indicate you are adding 1 syslog server.
IP/Hostname: 10.2.2.2
Port: 514
Security Facility: auth/sec
Facility: Local0

Configuration > Report Settings > SNMP > New Community: Enter the
following, then click OK:

Community Name: remote_admin

Permissions:
Write: (select)
Trap: (select)
Including Traffic Alarms: (clear)
Version: V2C
Hosts IP Address/Netmask:
10.2.2.2/32 V2C
Trap Version:
V2C
Source Interface:
ethernet1 (select)
Configuration > Report Settings > SNMP: Enter the following, then click
Apply:

88  VPN Tunnels for Self-Initiated Traffic

 Chapter 2: Monitoring Security Devices

Enable Authentication Fail Trap: (select)

6. Route
Network > Routing > Destination > trust-vr New: Enter the following, then
click OK:

Network Address/Netmask: 0.0.0.0/0

Gateway: (select)
Interface: ethernet3
Gateway IP Address: 1.1.1.250
7. Policies
Policies > (From: Trust, To: Untrust) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), trust_int
Destination Address:
Address Book Entry: (select), remote_admin
Service: s-grp1
Action: Tunnel
Tunnel VPN: vpn1
Modify matching outgoing VPN policy: (select)
Position at Top: (select)

CLI (Device-A)
1. Interfaces—Security Zones
set interface ethernet1 zone trust
set interface ethernet1 ip 10.1.1.1/24
set interface ethernet1 nat
set interface ethernet3 zone untrust
set interface ethernet3 ip 1.1.1.1/24
set interface ethernet3 manage snmp

NOTE: By default, any interface that you bind to the Trust zone is in NAT mode.
Consequently, this option is already enabled for interfaces bound to the Trust
zone.

2. Addresses
set address trust trust_int 10.1.1.1/32
set address untrust remote_admin 10.2.2.2/32
3. Service Group
set group service s-grp1
set group service s-grp1 add syslog
set group service s-grp1 add snmp
4. VPN
set ike gateway to_admin address 2.2.2.2 outgoing-interface ethernet3 preshare
Ci5y0a1aAG sec-level compatible
set vpn vpn1 gateway to_admin sec-level compatible

VPN Tunnels for Self-Initiated Traffic  89

 Concepts & Examples ScreenOS Reference Guide

5. Syslog and SNMP

set syslog config 10.2.2.2 auth/sec local0
set syslog src-interface ethernet1
set syslog enable
set snmp community remote_admin read-write trap-on version v2c
set snmp host remote_admin 10.2.2.2/32 src-interface ethernet1
6. Route
set vrouter trust-vr route 0.0.0.0/0 interface ethernet3 gateway 1.1.1.250
7. Policies
set policy top from trust to untrust trust_int remote_admin s-grp1 tunnel vpn vpn1
set policy top from untrust to trust remote_admin trust_int s-grp1 tunnel vpn vpn1
save

WebUI (Device-B)
1. Interfaces—Security Zones
Network > Interfaces > Edit (for ethernet1): Enter the following, then click
Apply:

Zone Name: Trust

Static IP: (select this option when present)
IP Address/Netmask: 10.2.2.1/24

Select the following, then click OK:

Interface Mode: NAT

Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:

Zone Name: Untrust

Static IP: (select this option when present)
IP Address/Netmask: 2.2.2.2/24
2. Addresses
Policy > Policy Elements > Addresses > Lists > New: Enter the following,
then click OK:

Address Name: addr1

IP Address/Domain Name:
IP/Netmask: 10.2.2.2/32
Zone: Trust

Policy > Policy Elements > Addresses > Lists > New: Enter the following,
then click OK:

Address Name: ns-a

IP Address/Domain Name:
IP/Netmask: 10.1.1.1/32
Zone: Untrust

90  VPN Tunnels for Self-Initiated Traffic

 Chapter 2: Monitoring Security Devices

3. Service Groups
Policy > Policy Elements > Services > Group: Enter the following group
name, move the following services, then click OK:

Group Name: s-grp1

Select Syslog and use the << button to move the service from the
Available Members column to the Group Members column.

Select SNMP and use the << button to move the service from the
Available Members column to the Group Members column.

4. VPN
VPNs > AutoKey IKE > New: Enter the following, then click OK:

VPN Name: vpn1

Security Level: Compatible
Remote Gateway: Create a Simple Gateway: (select)
Gateway Name: to_admin
Type: Static IP, IP Address: 1.1.1.1
Preshared Key: Ci5y0a1aAG
Security Level: Compatible
Outgoing interface: ethernet3
5. Route
Network > Routing > Routing Table > trust-vr New: Enter the following, then
click OK:

Network Address/Netmask: 0.0.0.0/0

Gateway: (select)
Interface: ethernet3
Gateway IP Address: (select) 2.2.2.250
6. Policies
Policies > (From: Trust, To: Untrust) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), addr1
Destination Address:
Address Book Entry: (select), ns-a
Service: s-grp1
Action: Tunnel
Tunnel VPN: vpn1
Modify matching outgoing VPN policy: (select)
Position at Top: (select)

CLI (Device-B)
1. Interfaces—Security Zones
set interface ethernet1 zone trust
set interface ethernet1 ip 10.2.2.1/24
set interface ethernet1 nat
set interface ethernet3 zone untrust
set interface ethernet3 ip 2.2.2.2/24

VPN Tunnels for Self-Initiated Traffic  91

 Concepts & Examples ScreenOS Reference Guide

2. Addresses
set address trust addr1 10.2.2.2/32
set address untrust ns-a 10.1.1.1/32
3. Service Group
set group service s-grp1
set group service s-grp1 add syslog
set group service s-grp1 add snmp
4. VPN
set ike gateway to_admin address 1.1.1.1 outgoing-interface ethernet3 preshare
Ci5y0a1sec-level compatible
set vpn vpn1 gateway to_admin sec-level compatible
5. Route
set vrouter trust-vr route 0.0.0.0/0 interface ethernet3 gateway 2.2.2.250
6. Policies
set policy top from trust to untrust addr1 ns-a s-grp1 tunnel vpn vpn1
set policy top from untrust to trust ns-a addr1 s-grp1 tunnel vpn vpn1
save

Viewing Screen Counters

Juniper Networks security devices provide screen, hardware, and flow counters for
monitoring traffic. Counters give processing information for specified zones and
interfaces, and help you to verify configurations for desired policies.

Table 5 shows the screen counters for monitoring general firewall behavior and for
viewing the amount of traffic affected by specified policies.

Table 5: Screen Counters (page 1 of 2)

Counter Description
Bad IP Option Protection Number of frames discarded because of malformed or incomplete IP options
Dst IP-based session limiting Number of sessions dropped after the session threshold was reached
FIN bit with no ACK bit Number of packets detected and dropped with an illegal combination of flags
Fragmented packet protection Number of blocked IP packet fragments
HTTP Component Blocked Number of blocked packets with HTTP components
HTTP Component Blocking for ActiveX Number of ActiveX components blocked
controls
HTTP Component Blocking for .exe files Number of blocked HTTP packets with .exe files
HTTP Component Blocking for Java Number of blocked Java components
applets
HTTP Component Blocking for .zip files Number of blocked HTTP packets with .zip files
ICMP Flood Protection Number of ICMP packets blocked as part of an ICMP flood
ICMP Fragment Number of ICMP frames with the More Fragments flag set, or with offset
indicated in the Offset field
IP Spoofing Attack Protection Number of IP addresses blocked as part of an IP spoofing attack
IP Sweep Protection Number of IP sweep attack packets detected and blocked

92  Viewing Screen Counters

 Chapter 2: Monitoring Security Devices

Table 5: Screen Counters (page 2 of 2)

Counter Description
Land Attack Protection Number of packets blocked as part of a suspected land attack
Large ICMP Packet Number of ICMP frames detected with an IP length greater than 1024
Limit Session Number of undeliverable packets because the session limit had been reached
Loose Src Route IP Option Number of IP packets detected with the Loose Source Route option enabled
Malicious URL Protection Number of suspected malicious URLs blocked
Ping-of-Death Protection Number of suspected and rejected ICMP packets that are oversized or of an
irregular size
Port Scan Protection Number of port scans detected and blocked
Record Route IP Option Number of frames detected with the Record Route option enabled
Security IP Option Number of frames discarded with the IP Security option set
Src IP-based session limiting Number of sessions dropped after the session threshold was reached
Source Route IP Option Filter Number of IP source routes filtered
Stream IP Option Number of packets discarded with the IP Stream identifier set
Strict Src Route IP Option Number of packets detected with the Strict Source Route option enabled
SYN-ACK-ACK-Proxy DoS Number of blocked packets because of the SYN-ACK-ACK-proxy DoS SCREEN
option
SYN and FIN bits set Number of packets detected with an illegal combination of flags
SYN Flood Protection Number of SYN packets detected as part of a suspected SYN flood
SYN Fragment Detection Number of packet fragments dropped as part of a suspected SYN fragments
attack
Timestamp IP Option Number of IP packets discarded with the Internet Timestamp option set
TCP Packet without Flag Number of illegal packets dropped with missing or malformed flags field
Teardrop Attack Protection Number of packets blocked as part of a Teardrop attack
UDP Flood Protection Number of UDP packets dropped as part of a suspected UDP flood
Unknown Protocol Protection Number of packets blocked as part of an unknown protocol
WinNuke Attack Protection Number of packets detected as part of a suspected WinNuke attack

Table 6 shows the hardware counters for monitoring hardware performance and
packets with errors.

Table 6: Hardware Counters (page 1 of 2)

Counter Description
drop vlan Number of packets dropped because of missing VLAN tags, an undefined sub-interface, or because
VLAN trunking was not enabled when the security device was in Transparent mode
early frame Number of counters used in an Ethernet driver buffer descriptor management
in align err Number of incoming packets with an alignment error in the bit stream
in bytes Number of bytes received
in coll err Number of incoming collision packets
in crc err Number of incoming packets with a cyclic redundancy check (CRC) error
in dma err Number of incoming packets with a Direct Memory Access (DMA) error

Viewing Screen Counters  93

 Concepts & Examples ScreenOS Reference Guide

Table 6: Hardware Counters (page 2 of 2)

Counter Description
in misc err Number of incoming packets with a miscellaneous error
in no buffer Number of unreceived packets because of unavailable buffers
in overrun Number of transmitted overrun packets
in packets Number of packets received
in short frame Number of incoming packets with an Ethernet frame shorter than 64 bytes (including the frame
checksum)
in underrun Number of transmitted underrun packets
late frame Number of counters used in an Ethernet driver buffer descriptor management
out bs pak Number of packets held in back store while searching for an unknown MAC address
When the security device forwards a packet, it first checks if the destination MAC address is in the
ARP table. If it cannot find the destination MAC in the ARP table, the security device sends an ARP
request to the network. If the security device receives another packet with the same destination MAC
address before it receives a reply to the first ARP request, it increases the out bs pak counter by one.
out bytes Number of bytes sent
out coll err Number of outgoing collision packets
out cs lost Number of dropped outgoing packets because the Carrier Sense Multiple Access/Collision Detect
(CSMA/CD) protocol lost the signal
out defer Number of deferred outgoing packets
out discard Number of discarded outgoing packets
out heartbeat Number of outgoing heartbeat packets
out misc err Number of outgoing packets with a miscellaneous error
out no buffer Number of unsent packets because of unavailable buffers
out packets Number of packets sent
re xmt limit Number of dropped packets when the retransmission limit was exceeded while an interface was
operating at half-duplex

Table 7 shows the flow counters for monitoring the number of packets inspected at
the flow level.

Table 7: Flow Counters (page 1 of 3)

Counter Description
address spoof Number of suspected address spoofing attack packets received
auth deny Number of times user authentication was denied
auth fail Number of times user authentication failed
big bkstr Number of packets that are too big to buffer in the ARP back store while waiting for MAC-to-IP
address resolution
connections Number of sessions established since the last boot
encrypt fail Number of failed Point-to-Point Tunneling Protocol (PPTP) packets
*icmp broadcast Number of ICMP broadcasts received
icmp flood Number of ICMP packets that are counted toward the ICMP flood threshold
illegal pak Number of packets dropped because they do not conform to the protocol standards

94  Viewing Screen Counters

 Chapter 2: Monitoring Security Devices

Table 7: Flow Counters (page 2 of 3)

Counter Description
in arp req Number of incoming arp request packets
in arp resp Number of outgoing arp request packets
in bytes Number of bytes received
in icmp Number of Internet Control Message Protocol (ICMP) packets received
in other Number of incoming packets that are of a different Ethernet type
in packets Number of packets received
in self Number of packets addressed to the Management IP address
*in un auth Number of unauthorized incoming TCP, UDP, and ICMP packets
*in unk prot Number of incoming packets using an unknown Ethernet protocol
in vlan Number of incoming vlan packets
in vpn Number of IPSec packets received
invalid zone Number of packets destined for an invalid security zone
ip sweep Number of packets received and discarded beyond the specified ip sweep threshold
land attack Number of suspected land attack packets received
loopback drop Number of packets dropped because they cannot be looped back through the security device. An
example of a loopback session is when a host in the Trust zone sends traffic to a MIP or VIP address
that is mapped to a server that is also in the Trust zone. The security device creates a loopback
session that directs such traffic from the host to the MIP or VIP server.
mac relearn Number of times that the MAC address learning table had to relearn the interface associated with a
MAC address because the location of the MAC address changed
mac tbl full Number of times that the MAC address learning table completely filled up
mal url Number of blocked packets destined for a URL determined to be malicious
*misc prot Number of packets using a protocol other than TCP, UDP, or ICMP
mp fail Number of times a problem occurred when sending a PCI message between the master processor
module and the processor module
no conn Number of packets dropped because of unavailable Network Address Translation (NAT) connections
no dip Number of packets dropped because of unavailable dynamic IP (DIP) addresses
no frag netpak Number of times that the available space in the netpak buffer fell below 70%
*no frag sess The number of times that fragmented sessions were greater than half of the maximum number of
NAT sessions
no g-parent Number of packets dropped because the parent connection could not be found
no gate Number of packets dropped because no gate was available
no gate sess Number of terminated sessions because there were no gates in the firewall for them
no map Number of packets dropped because there was no map to the trusted side
no nat vector Number of packets dropped because the Network Address Translation (NAT) connection was
unavailable for the gate
*no nsp tunnel Number of dropped packets sent to a tunnel interface to which no VPN tunnel is bound
no route Number of unroutable packets received
no sa The number of packets dropped because no Security Associations (SA) was defined
no sa policy Number of packets dropped because no policy was associated with an SA
*no xmit vpnf Number of dropped VPN packets due to fragmentation

Viewing Screen Counters  95

 Concepts & Examples ScreenOS Reference Guide

Table 7: Flow Counters (page 3 of 3)

Counter Description
null zone Number of dropped packets erroneously sent to an interface bound to the Null zone
nvec err Number of packets dropped because of NAT vector error
out bytes Number of bytes sent
out packets Number of packets sent
out vlan Number of outgoing vlan packets
ping of death Number of suspected Ping of Death attack packets received
policy deny Number of packets denied by a defined policy
port scan Number of packets that are counted as a port scan attempt
proc sess Number of times that the total number of sessions on a processor module exceeded the maximum
threshold
sa inactive Number of packets dropped because of an inactive SA
sa policy deny Number of packets denied by an SA policy
sessn thresh the threshold for the maximum number of sessions
*slow mac Number of frames whose MAC addresses were slow to resolve
src route Number of packets dropped because of the filter source route option
syn frag Number of dropped SYN packets because of a fragmentation
tcp out of seq Number of TCP segments received whose sequence number is outside the acceptable range
tcp proxy Number of packets dropped from using a TCP proxy such as the SYN flood protection option or user
authentication
teardrop Number of packets blocked as part of a suspected Teardrop attack
tiny frag Number of tiny fragmented packets received
trmn drop Number of packets dropped by traffic management
trmng queue Number of packets waiting in the queue
udp flood Number of UDP packets that are counted toward the UDP flood threshold
url block Number of HTTP requests that were blocked
winnuke Number of WinNuke attack packets received
wrong intf Number of session creation messages sent from a processor module to the master processor module
wrong slot Number of packets erroneously sent to the wrong processor module

NOTE: For more information about the Carrier Sense Multiple Access/Collision Detect
(CSMA/CD) protocol, refer to the IEEE 802.3 standard available at
http://standards.ieee.org.

In this example, you view the device screen counters for the Trust zone.

WebUI
Reports > Counters > Zone Screen: Select Trust from the Zone drop-down
list.

CLI
get counter screen zone trust

96  Viewing Screen Counters

Index
A HTTP
administration session ID ...................................................................4
CLI ...............................................................................9 HyperText Transfer Protocol
restricting .................................................................42 See HTTP
WebUI .........................................................................2
administrative traffic .....................................................29 I
alarms Ident-Reset......................................................................28
email alert ................................................................68 inactive SA ......................................................................96
NetScreen-Security Manager, reporting to ...........25 in-short error ..................................................................94
thresholds.................................................................69 interfaces
traffic ...............................................................68 to 71 manageable ..............................................................31
asset recovery log ..........................................................68 management options ..............................................28
AutoKey IKE VPN .....................................................43, 79 internal flash storage .....................................................56
IP addresses
B manage IP ................................................................31
back store .......................................................................94 NetScreen-Security Manager servers ....................25
bit stream .......................................................................93
browser requirements .....................................................2 L
logging....................................................................55 to 68
C asset recovery log ....................................................68
cables, serial ...................................................................19 CompactFlash (PCMCIA).........................................56
CLI .....................................................................................9 console......................................................................56
command line interface email .........................................................................56
See CLI event log ...................................................................57
CompactFlash ................................................................56 internal .....................................................................56
configuration settings, browser requirements..............2 NetScreen-Security Manager ..................................25
console ............................................................................56 self log.......................................................................66
SNMP ..................................................................56, 74
D syslog ..................................................................56, 72
devices, resetting to factory defaults ...........................41 USB............................................................................56
DIP...................................................................................95 WebTrends .........................................................56, 72
dynamic IP
See DIP M
manage IP .......................................................................31
E management client IP addresses .................................42
email alert notification ............................................71, 73 Management information base II
event log .........................................................................57 See MIB II
management methods
F CLI ...............................................................................9
factory defaults, resetting devices to ...........................41 console......................................................................19
filter source route ..........................................................96 SSL...............................................................................5
Telnet ..........................................................................9
H WebUI .........................................................................2
Help files ...........................................................................2 management options
interfaces ..................................................................28

Index  IX-I
 Concepts & Examples ScreenOS Reference Guide

manageable ............................................................. 31 land attack ...............................................................95

MGT interface .......................................................... 29 Network Address Translation (NAT) .....................95
NetScreen-Security Manager ................................. 28 Point to Point Tunneling Protocol (PPTP) ............94
ping ........................................................................... 28 received ..................................................93, 94, 95, 96
SNMP ........................................................................ 28 transmitted underrun .............................................94
SSH ........................................................................... 28 unreceivable ............................................................94
SSL ............................................................................ 28 unroutable ................................................................95
Telnet........................................................................ 28 parent connection .........................................................95
Transparent mode .................................................. 29 passwords
VLAN1 ...................................................................... 29 forgetting ..................................................................39
WebUI ...................................................................... 28 root admin ...............................................................41
manual keys, VPNs .................................................. 43, 79 PCMCIA ...........................................................................56
messages ping management options ...........................................28
alert ........................................................................... 57 PKI keys ............................................................................6
critical ....................................................................... 57 Point-to-Point Tunneling Protocol (PPTP) ....................94
debug ........................................................................ 57 ports, modem ..........................................................20, 22
emergency ............................................................... 57 protocol distribution, NetScreen-Security Manager,
error .......................................................................... 57 reporting to ..................................................................25
info ............................................................................ 57
notification ............................................................... 57 R
warning .................................................................... 57 RADIUS ...........................................................................39
WebTrends .............................................................. 73 root admin, logging in...................................................42
MGT interface, management options .......................... 29
MIB II ........................................................................ 28, 74 S
modem ports ........................................................... 20, 22 SA policy .........................................................................96
SCP
N enabling ....................................................................18
NAT vector error ............................................................ 96 example client command ......................................18
NetScreen-Security Manager Secure Copy
definition .................................................................. 22 See SCP
enabling NSM Agent ............................................... 24 Secure Shell
events, reporting ..................................................... 25 See SSH
initial connectivity setup ........................................ 23 Secure Sockets Layer
logging ...................................................................... 25 See SSL
management options ............................................. 28 Security Associations (SA) ............................................95
management system .................................. 22, 23, 25 self log .............................................................................66
NSM Agent ......................................................... 22, 25 serial cables ....................................................................19
reporting events ...................................................... 26 session ID .........................................................................4
UI .............................................................................. 22 SMTP server IP ...............................................................71
Network Address Translation (NAT) ............................. 95 SNMP ........................................................................28, 74
NSM Agent ............................................................... 22, 23 cold start trap ..........................................................74
enabling.................................................................... 24 configuration............................................................77
events, reporting ..................................................... 25 encryption ..........................................................76, 78
management options..............................................28
P SNMP community
packets ............................................................................ 96 private ......................................................................77
address spoofing attack.......................................... 94 public ........................................................................77
collision .............................................................. 93, 94 SNMP traps
denied....................................................................... 96 100, hardware problems ........................................75
dropped .............................................................. 95, 96 200, firewall problems ...........................................75
fragmented .............................................................. 96 300, software problems .........................................75
incoming .................................................................. 93 400, traffic problems ..............................................75
Internet Control Message Protocol (ICMP) ..... 92, 95 500, VPN problems .................................................75
IPSec ......................................................................... 95 allow or deny ...........................................................76

IX-II  Index
 Index

system alarm ...........................................................74 manual keys .............................................................43

traffic alarm .............................................................74
types .........................................................................75 W
source route....................................................................96 Web user interface
SSH .........................................................................11 to 16 See WebUI
authentication method priority .............................15 WebTrends ................................................................56, 72
automated logins .....................................................17 encryption ..........................................................73, 78
connection procedure .............................................12 messages ..................................................................73
forcing PKA authentication only ...........................16 WebUI................................................................................2
loading public keys, CLI .........................................15 Help files.....................................................................2
loading public keys, TFTP ................................15, 17 management options ..............................................28
loading public keys, WebUI ...................................15
management options ..............................................28
password authentication ........................................14
PKA ...........................................................................15
PKA authentication .................................................14
SSL .....................................................................................5
SSL Handshake Protocol
See SSLHP
SSL management options .............................................28
SSLHP................................................................................5
statistics, reporting to NSM...........................................26
syslog ..............................................................................56
encryption ................................................................78
facility ...........................................................72, 81, 88
host ...........................................................................72
hostname ...............................................72, 73, 81, 88
messages ..................................................................71
port ...............................................................72, 81, 88
security facility ............................................72, 81, 88

T
TCP proxy .......................................................................96
Telnet ................................................................................9
Telnet management options ........................................28
Telnet, logging in via .....................................................10
traffic alarms .........................................................68 to 71
Transparent mode, management options ..................29

U
USB ..................................................................................56
users, multiple administrative ......................................33

V
virtual private networks
See VPNs
virtual systems
admins ......................................................................34
read-only admins ....................................................34
VLAN1, management options ......................................29
VPNs
AutoKey IKE.......................................................43, 79
for administrative traffic ........................................78
manual key ..............................................................79

Index  IX-III
 Concepts & Examples ScreenOS Reference Guide

IX-IV  Index
Concepts & Examples
ScreenOS Reference Guide

Volume 4:
Attack Detection and Defense Mechanisms

Release 6.1.0, Rev. 03

Juniper Networks, Inc.

1194 North Mathilda Avenue
Sunnyvale, CA 94089
USA
408-745-2000
www.juniper.net
 Copyright Notice
Copyright © 2009 Juniper Networks, Inc. All rights reserved.

Juniper Networks, the Juniper Networks logo, JUNOS, NetScreen, ScreenOS, and Steel-Belted Radius are registered trademarks of Juniper Networks, Inc.
in the United States and other countries. JUNOSe is a trademark of Juniper Networks, Inc. All other trademarks, service marks, registered trademarks, or
registered service marks are the property of their respective owners.

All specifications are subject to change without notice. Juniper Networks assumes no responsibility for any inaccuracies in this document or for any
obligation to update information in this document. Juniper Networks reserves the right to change, modify, transfer, or otherwise revise this publication
without notice.

FCC Statement
The following information is for FCC compliance of Class A devices: This equipment has been tested and found to comply with the limits for a Class A
digital device, pursuant to part 15 of the FCC rules. These limits are designed to provide reasonable protection against harmful interference when the
equipment is operated in a commercial environment. The equipment generates, uses, and can radiate radio-frequency energy and, if not installed and
used in accordance with the instruction manual, may cause harmful interference to radio communications. Operation of this equipment in a residential
area is likely to cause harmful interference, in which case users will be required to correct the interference at their own expense.

The following information is for FCC compliance of Class B devices: The equipment described in this manual generates and may radiate radio-frequency
energy. If it is not installed in accordance with Juniper Networks’ installation instructions, it may cause interference with radio and television reception.
This equipment has been tested and found to comply with the limits for a Class B digital device in accordance with the specifications in part 15 of the FCC
rules. These specifications are designed to provide reasonable protection against such interference in a residential installation. However, there is no
guarantee that interference will not occur in a particular installation.

If this equipment does cause harmful interference to radio or television reception, which can be determined by turning the equipment off and on, the user
is encouraged to try to correct the interference by one or more of the following measures:

 Reorient or relocate the receiving antenna.

 Increase the separation between the equipment and receiver.

 Consult the dealer or an experienced radio/TV technician for help.

 Connect the equipment to an outlet on a circuit different from that to which the receiver is connected.

Caution: Changes or modifications to this product could void the user's warranty and authority to operate this device.

Disclaimer
THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED
WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED
WARRANTY, CONTACT YOUR JUNIPER NETWORKS REPRESENTATIVE FOR A COPY.

ii 
Table of Contents
About This Volume ix
Document Conventions.................................................................................... x
Web User Interface Conventions .............................................................. x
Command Line Interface Conventions ...................................................... x
Naming Conventions and Character Types .............................................. xi
Illustration Conventions .......................................................................... xii
Requesting Technical Support ........................................................................ xii
Self-Help Online Tools and Resources..................................................... xiii
Opening a Case with JTAC ...................................................................... xiii
Document Feedback ..................................................................................... xiii

Chapter 1 Protecting a Network 1

Stages of an Attack........................................................................................... 2
Detection and Defense Mechanisms ................................................................ 2
Exploit Monitoring ........................................................................................... 5
Example: Monitoring Attacks from the Untrust Zone................................. 5

Chapter 2 Reconnaissance Deterrence 7

IP Address Sweep ............................................................................................ 8
Port Scanning................................................................................................... 9
Network Reconnaissance Using IP Options ....................................................10
Operating System Probes............................................................................... 12
SYN and FIN Flags Set ............................................................................. 12
FIN Flag Without ACK Flag ...................................................................... 13
TCP Header Without Flags Set .................................................................14
Evasion Techniques ....................................................................................... 15
FIN Scan .................................................................................................. 15
Non-SYN Flags......................................................................................... 15
IP Spoofing ..............................................................................................18
Example: L3 IP Spoof Protection ....................................................... 20
Example: L2 IP Spoof Protection ....................................................... 22
IP Source Route Options.......................................................................... 23

Chapter 3 Denial of Service Attack Defenses 27

Firewall DoS Attacks ...................................................................................... 28
Session Table Flood ................................................................................. 28
Source-Based and Destination-Based Session Limits ......................... 28
Example: Source-Based Session Limiting .......................................... 30
Example: Destination-Based Session Limiting ................................... 30
Aggressive Aging............................................................................... 31
Example: Aggressively Aging Out Sessions........................................ 32
CPU Protection with Blacklisting DoS Attack Traffic .......................... 33

Table of Contents  iii

 Concepts & Examples ScreenOS Reference Guide

Example............................................................................................ 34
Prioritizing Critical Traffic .................................................................35
SYN-ACK-ACK Proxy Flood ...................................................................... 36
Network DoS Attacks ..................................................................................... 38
SYN Flood................................................................................................ 38
SYN Cookie..............................................................................................48
ICMP Flood ..............................................................................................50
UDP Flood ............................................................................................... 51
Land Attack ............................................................................................. 52
OS-Specific DoS Attacks ................................................................................. 53
Ping of Death........................................................................................... 53
Teardrop Attack....................................................................................... 54
WinNuke ................................................................................................. 55

Chapter 4 Content Monitoring and Filtering 57

Fragment Reassembly.................................................................................... 58
Malicious URL Protection......................................................................... 58
Application Layer Gateway ...................................................................... 59
Example: Blocking Malicious URLs in Packet Fragments ................... 60
Antivirus Scanning ......................................................................................... 62
External AV Scanning .............................................................................. 62
Scanning Modes................................................................................ 63
Load-Balancing ICAP Scan Servers ....................................................63
Internal AV Scanning ............................................................................... 64
AV Scanning of IM Traffic ........................................................................ 65
IM Clients.......................................................................................... 65
IM Server .......................................................................................... 66
IM Protocols ...................................................................................... 67
Instant Messaging Security Issues ..................................................... 67
IM Security Issues ............................................................................. 67
Scanning Chat Messages ................................................................... 68
Scanning File Transfers ..................................................................... 68
AV Scanning Results ................................................................................ 69
Policy-Based AV Scanning ....................................................................... 70
Scanning Application Protocols................................................................ 71
Scanning FTP Traffic ......................................................................... 72
Updating the AV Pattern Files for the Embedded Scanner .......................80
Subscribing to the AV Signature Service ............................................ 80
AV Scanner Global Settings...................................................................... 83
AV Resource Allotment ..................................................................... 83
Fail-Mode Behavior ........................................................................... 84
Maximum Content Size and Maximum Messages (Internal AV Only) 84
HTTP Keep-Alive ............................................................................... 85
HTTP Trickling (Internal AV Only) ..................................................... 86
AV Profiles............................................................................................... 87
Assigning an AV Profile to a Firewall Policy....................................... 88
Initiating an AV Profile for Internal AV .............................................. 88
Example: (Internal AV) Scanning for All Traffic Types .......................89
Anti-Spam Filtering ........................................................................................ 94
Blacklists and Whitelists .......................................................................... 94
Basic Configuration.................................................................................. 95
Filtering Spam Traffic........................................................................ 95
Dropping Spam Messages .................................................................95
Defining a Blacklist .................................................................................. 96

iv  Table of Contents
 Table of Contents

Defining a Whitelist ................................................................................. 96

Defining a Default Action......................................................................... 96
Enabling a Spam-Blocking List Server ...................................................... 97
Testing Anti-Spam ................................................................................... 97
Web Filtering ................................................................................................. 98
Using the CLI to Initiate Web-Filtering Modes .......................................... 98
Integrated Web Filtering .......................................................................... 99
SurfControl Servers .........................................................................100
Web Filtering Cache........................................................................100
Configuring Integrated Web Filtering ..............................................101
Example: Integrated Web Filtering..................................................106
Redirect Web Filtering ...........................................................................108
Virtual System Support....................................................................109
Configuring Redirect Web Filtering .................................................110
Example: Redirect Web Filtering.....................................................113

Chapter 5 Deep Inspection 117

Overview .....................................................................................................118
Attack Object Database Server .....................................................................122
Predefined Signature Packs ...................................................................122
Updating Signature Packs ......................................................................123
Before You Start Updating Attack Objects .......................................124
Immediate Update ..........................................................................124
Automatic Update ...........................................................................125
Automatic Notification and Immediate Update ...............................126
Manual Update................................................................................127
Updating DI Patterns from a Proxy Server ......................................129
Attack Objects and Groups ...........................................................................130
Supported Protocols ..............................................................................131
Stateful Signatures .................................................................................134
TCP Stream Signatures ..........................................................................135
Protocol Anomalies................................................................................135
Attack Object Groups.............................................................................136
Changing Severity Levels.................................................................136
Example: Deep Inspection for P2P..................................................137
Disabling Attack Objects........................................................................139
Attack Actions..............................................................................................140
Example: Attack Actions—Close Server, Close, Close Client ............141
Brute Force Attack Actions ....................................................................148
Brute Force Attack Target................................................................149
Brute Force Attack Timeout.............................................................149
Example 1.......................................................................................150
Example 2.......................................................................................150
Example 3.......................................................................................151
Attack Logging .............................................................................................151
Example: Disabling Logging per Attack Group.................................151
Mapping Custom Services to Applications ....................................................153
Example: Mapping an Application to a Custom Service...................154
Example: Application-to-Service Mapping for HTTP Attacks ............156
Customized Attack Objects and Groups........................................................157
User-Defined Stateful Signature Attack Objects......................................157
Regular Expressions........................................................................158
Example: User-Defined Stateful Signature Attack Objects ...............159
TCP Stream Signature Attack Objects ....................................................161

Table of Contents  v
 Concepts & Examples ScreenOS Reference Guide

Example: User-Defined Stream Signature Attack Object..................162

Configurable Protocol Anomaly Parameters ..........................................163
Example: Modifying Parameters .....................................................163
Negation ......................................................................................................164
Example: Attack Object Negation....................................................164
Granular Blocking of HTTP Components ......................................................168
ActiveX Controls....................................................................................169
Java Applets...........................................................................................169
EXE Files ...............................................................................................169
ZIP Files.................................................................................................169

Chapter 6 Intrusion Detection and Prevention 171

IDP-Capable Security Devices.......................................................................172
Traffic Flow in an IDP-Capable Device .........................................................173
Configuring Intrusion Detection and Prevention ..........................................175
Preconfiguration Tasks ..........................................................................175
Example 1: Basic IDP Configuration ......................................................176
Example 2: Configuring IDP for Active/Passive Failover ........................178
Example 3: Configuring IDP for Active/Active Failover ..........................180
Configuring Security Policies ........................................................................183
About Security Policies ..........................................................................183
Managing Security Policies ....................................................................183
Installing Security Policies .....................................................................184
Using IDP Rulebases ....................................................................................184
Role-Based Administration of IDP Rulebases .........................................185
Configuring Objects for IDP Rules..........................................................185
Using Security Policy Templates ............................................................186
Enabling IDP in Firewall Rules .....................................................................186
Enabling IDP..........................................................................................187
Specifying Inline or Inline Tap Mode .....................................................187
Configuring IDP Rules ..................................................................................188
Adding the IDP Rulebase .......................................................................189
Matching Traffic ....................................................................................190
Source and Destination Zones.........................................................190
Source and Destination Address Objects .........................................191
Example: Setting Source and Destination........................................191
Example: Setting Multiple Sources and Destinations .......................191
Services...........................................................................................192
Example: Setting Default Services ...................................................192
Example: Setting Specific Services ..................................................193
Example: Setting Nonstandard Services ..........................................193
Terminal Rules ................................................................................195
Example: Setting Terminal Rules.....................................................195
Defining Actions ....................................................................................196
Setting Attack Objects............................................................................198
Adding Attack Objects Individually..................................................198
Adding Attack Objects by Category .................................................198
Example: Adding Attack Objects by Service ....................................198
Adding Attack Objects by Operating System ...................................198
Adding Attack Objects by Severity ..................................................199
Setting IP Action ....................................................................................199
Choosing an IP Action .....................................................................200
Choosing a Blocking Option ............................................................200
Setting Logging Options ..................................................................200

vi  Table of Contents
 Table of Contents

Setting Timeout Options .................................................................200

Setting Notification ................................................................................200
Setting Logging ...............................................................................201
Setting an Alert ...............................................................................201
Logging Packets ..............................................................................201
Setting Severity......................................................................................201
Setting Targets.......................................................................................202
Entering Comments...............................................................................202
Configuring Exempt Rules............................................................................202
Adding the Exempt Rulebase.................................................................203
Defining a Match ...................................................................................204
Source and Destination Zones.........................................................204
Source and Destination Address Objects .........................................204
Example: Exempting a Source/Destination Pair ..............................205
Setting Attack Objects............................................................................205
Example: Exempting Specific Attack Objects ..................................205
Setting Targets.......................................................................................205
Entering Comments...............................................................................206
Creating an Exempt Rule from the Log Viewer ......................................206
Configuring Backdoor Rules .........................................................................207
Adding the Backdoor Rulebase ..............................................................207
Defining a Match ...................................................................................208
Source and Destination Zones.........................................................208
Source and Destination Address Objects .........................................209
Services...........................................................................................209
Setting the Operation ............................................................................209
Setting Actions.......................................................................................209
Setting Notification ................................................................................210
Setting Logging ...............................................................................210
Setting an Alert ...............................................................................210
Logging Packets ..............................................................................210
Setting Severity......................................................................................211
Setting Targets.......................................................................................211
Entering Comments...............................................................................211
Configuring IDP Attack Objects ....................................................................211
About IDP Attack Object Types..............................................................211
Signature Attack Objects .................................................................212
Protocol Anomaly Attack Objects ....................................................212
Compound Attack Objects...............................................................212
Viewing Predefined IDP Attack Objects and Groups ..............................212
Viewing Predefined Attacks.............................................................213
Viewing Predefined Groups .............................................................213
Creating Custom IDP Attack Objects......................................................214
Creating a Signature Attack Object..................................................216
Creating a Protocol Anomaly Attack................................................221
Creating a Compound Attack ..........................................................222
Editing a Custom Attack Object.......................................................224
Deleting a Custom Attack Object.....................................................224
Creating Custom IDP Attack Groups ......................................................225
Configuring Static Groups................................................................225
Configuring Dynamic Groups ..........................................................226
Example: Creating a Dynamic Group ..............................................227
Updating Dynamic Groups ..............................................................228
Editing a Custom Attack Group .......................................................229

Table of Contents  vii

 Concepts & Examples ScreenOS Reference Guide

Deleting a Custom Attack Group .....................................................229

Configuring the Device as a Standalone IDP Device .....................................229
Enabling IDP..........................................................................................229
Example: Configuring a Firewall Rule for Standalone IDP ...............230
Configuring Role-Based Administration .................................................230
Example: Configuring an IDP-Only Administrator ...........................231
Managing IDP ..............................................................................................232
About Attack Database Updates.............................................................232
Downloading Attack Database Updates .................................................232
Using Updated Attack Objects .........................................................233
Updating the IDP Engine.................................................................233
Viewing IDP Logs...................................................................................235
ISG-IDP Devices ...........................................................................................236
Compiling a Policy.................................................................................236
Policy Size Multiplier .......................................................................236
Unloading Existing Policies .............................................................237

Chapter 7 Suspicious Packet Attributes 239

ICMP Fragments ..........................................................................................240
Large ICMP Packets......................................................................................241
Bad IP Options .............................................................................................242
Unknown Protocols......................................................................................243
IP Packet Fragments ....................................................................................244
SYN Fragments ............................................................................................245

Appendix A Contexts for User-Defined Signatures A-I

Index..........................................................................................................................IX-I

viii  Table of Contents

About This Volume

Volume 4: Attack Detection and Defense Mechanisms describes the Juniper Networks
security options available in ScreenOS. You can enable many of these options at the
security zone level. These options apply to traffic reaching the Juniper Networks
security device through any interface bound to a zone for which you have enabled
such options. These options offer protection against IP address and port scans,
denial of service (DoS) attacks, and other kinds of malicious activity. You can apply
other network security options, such as Web filtering, antivirus checking, and
intrusion detection and prevention (IDP), at the policy level. These options only
apply to traffic under the jurisdiction of the policies in which they are enabled.

NOTE: The subject of policies is presented only peripherally in this volume, as it applies to
the network security options that you can enable at the policy level. For a
complete examination of policies, see “Policies” on page 2-159.

This volume contains the following sections:

 Chapter 1, “Protecting a Network,” outlines the basic stages of an attack and

the firewall options available to combat the attacker at each stage.

 Chapter 2, “Reconnaissance Deterrence,” describes the options available for

blocking IP address sweeps, port scans, and attempts to discover the type of
operating system (OS) of a targeted system.

 Chapter 3, “Denial of Service Attack Defenses,” explains firewall, network, and

OS-specific DoS attacks and how ScreenOS mitigates such attacks.

 Chapter 4, “Content Monitoring and Filtering,” describes how to protect users

from malicious uniform resource locators (URLs) and how to configure the
Juniper Networks security device to work with third-party products to provide
antivirus scanning, anti-spam, and Web filtering.

 Chapter 5, “Deep Inspection,” describes how to configure the Juniper Networks

security device to obtain Deep Inspection (DI) attack object updates, how to
create user-defined attack objects and attack object groups, and how to apply
DI at the policy level.

 Chapter 6, “Intrusion Detection and Prevention,” describes Juniper Networks

Intrusion Detection and Prevention (IDP) technology, which can both detect
and stop attacks when deployed inline to your network. The chapter describes
how to apply IDP at the policy level to drop malicious packets or connections
before the attacks can enter your network.

 ix
 Concepts & Examples ScreenOS Reference Guide

 Chapter 7, “Suspicious Packet Attributes,” presents several SCREEN options

that protect network resources from potential attacks indicated by unusual IP
and ICMP packet attributes.

 Appendix A, “Contexts for User-Defined Signatures,” provides descriptions of

contexts that you can specify when defining a stateful signature attack object.

Document Conventions
This document uses the conventions described in the following sections:

 “Web User Interface Conventions” on page x

 “Command Line Interface Conventions” on page x

 “Naming Conventions and Character Types” on page xi

 “Illustration Conventions” on page xii

Web User Interface Conventions

The Web user interface (WebUI) contains a navigational path and configuration
settings. To enter configuration settings, begin by clicking a menu item in the
navigation tree on the left side of the screen. As you proceed, your navigation path
appears at the top of the screen, with each page separated by angle brackets.

The following example shows the WebUI path and parameters for defining an
address:

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: addr_1

IP Address/Domain Name:
IP/Netmask: (select), 10.2.2.5/32
Zone: Untrust

To open Online Help for configuration settings, click the question mark (?) in the
upper left of the screen.

The navigation tree also provides a Help > Config Guide configuration page to help
you configure security policies and Internet Protocol Security (IPSec). Select an
option from the list, and follow the instructions on the page. Click the ? character in
the upper left for Online Help on the Config Guide.

Command Line Interface Conventions

The following conventions are used to present the syntax of command line
interface (CLI) commands in text and examples.

In text, commands are in boldface type and variables are in italic type.

In examples:

x  Document Conventions
 About This Volume

 Variables are in italic type.

 Anything inside square brackets [ ] is optional.

 Anything inside braces { } is required.

 If there is more than one choice, each choice is separated by a pipe ( | ). For
example, the following command means “set the management options for the
ethernet1, the ethernet2, or the ethernet3 interface”:

set interface { ethernet1 | ethernet2 | ethernet3 } manage

NOTE: When entering a keyword, you only have to type enough letters to identify the
word uniquely. Typing set adm u whee j12fmt54 will enter the command set
admin user wheezer j12fmt54. However, all the commands documented in this
guide are presented in their entirety.

Naming Conventions and Character Types

ScreenOS employs the following conventions regarding the names of objects—such
as addresses, admin users, auth servers, IKE gateways, virtual systems, VPN
tunnels, and zones—defined in ScreenOS configurations:

 If a name string includes one or more spaces, the entire string must be
enclosed within double quotes; for example:

set address trust “local LAN” 10.1.1.0/24

 Any leading spaces or trailing text within a set of double quotes are trimmed;
for example, “ local LAN ” becomes “local LAN”.

 Multiple consecutive spaces are treated as a single space.

 Name strings are case-sensitive, although many CLI keywords are

case-insensitive. For example, “local LAN” is different from “local lan”.

ScreenOS supports the following character types:

 Single-byte character sets (SBCS) and multiple-byte character sets (MBCS).

Examples of SBCS are ASCII, European, and Hebrew. Examples of MBCS—also
referred to as double-byte character sets (DBCS)—are Chinese, Korean, and
Japanese.

 ASCII characters from 32 (0x20 in hexadecimals) to 255 (0xff), except double

quotes ( “ ), which have special significance as an indicator of the beginning or
end of a name string that includes spaces.

NOTE: A console connection only supports SBCS. The WebUI supports both SBCS and
MBCS, depending on the character sets that your browser supports.

Document Conventions  xi
 Concepts & Examples ScreenOS Reference Guide

Illustration Conventions
Figure 1 shows the basic set of images used in illustrations throughout this volume.

Figure 1: Images in Illustrations

Autonomous System Local Area Network (LAN)
or with a Single Subnet
Virtual Routing Domain or
Security Zone

Dynamic IP (DIP) Pool

Internet

Policy Engine
Security Zone Interfaces:
White = Protected Zone Interface
(example = Trust Zone)
Black = Outside Zone Interface
(example = Untrust Zone)
Generic Network Device

Tunnel Interface

Server

VPN Tunnel

Router

Juniper Networks
Switch Security Devices

Hub

Requesting Technical Support

Technical product support is available through the Juniper Networks Technical
Assistance Center (JTAC). If you are a customer with an active J-Care or JNASC
support contract, or are covered under warranty, and need postsales technical
support, you can access our tools and resources online or open a case with JTAC.

 JTAC policies—For a complete understanding of our JTAC procedures and

policies, review the JTAC User Guide located at
http://www.juniper.net/customers/support/downloads/710059.pdf.

 Product warranties—For product warranty information, visit

http://www.juniper.net/support/warranty/.

 JTAC hours of operation—The JTAC centers have resources available 24 hours a

day, 7 days a week, 365 days a year.

xii  Requesting Technical Support

 About This Volume

Self-Help Online Tools and Resources

For quick and easy problem resolution, Juniper Networks has designed an online
self-service portal called the Customer Support Center (CSC) that provides you with
the following features:

 Find CSC offerings—http://www.juniper.net/customers/support/

 Find product documentation—http://www.juniper.net/techpubs/

 Find solutions and answer questions using our Knowledge Base—

http://kb.juniper.net/

 Download the latest versions of software and review your release notes—
http://www.juniper.net/customers/csc/software/

 Search technical bulletins for relevant hardware and software notifications—

http://www.juniper.net/alerts/

 Join and participate in the Juniper Networks Community Forum—

http://www.juniper.net/company/communities/

 Open a case online in the CSC Case Manager—

http://www.juniper.net/customers/cm/

 To verify service entitlement by product serial number, use our Serial Number
Entitlement (SNE) Tool—
https://tools.juniper.net/SerialNumberEntitlementSearch/

Opening a Case with JTAC

You can open a case with JTAC on the Web or by telephone.

 Use the Case Manager tool in the CSC at http://www.juniper.net/customers/cm/.

 Call 1-888-314-JTAC (1-888-314-5822—toll free in USA, Canada, and Mexico).

For international or direct-dial options in countries without toll-free numbers, visit

us at http://www.juniper.net/customers/support/requesting-support/.

Document Feedback
If you find any errors or omissions in this document, contact Juniper Networks at
[email protected].

Document Feedback  xiii

 Concepts & Examples ScreenOS Reference Guide

xiv  Document Feedback

Chapter 1
Protecting a Network

There can be many reasons for invading a protected network. The following list
contains some common objectives:

 Gathering the following kinds of information about the protected network:

 Topology

 IP addresses of active hosts

 Numbers of active ports on active hosts

 Operating systems of active hosts

 Overwhelming a host on a protected network with bogus traffic to induce a

denial of service (DoS)

 Overwhelming the protected network with bogus traffic to induce a

network-wide DoS

 Overwhelming a firewall with bogus traffic to induce a denial of service (DoS)

for the network behind it

 Causing damage to and stealing data from a host on a protected network

 Gaining access to a host on a protected network to obtain information

 Gaining control of a host to launch other exploits

 Gaining control of a firewall to control access to the network that it protects

ScreenOS provides detective and defensive tools for uncovering and thwarting the
efforts of attackers to achieve the above objectives when they attempt to target a
network protected by a Juniper Networks security device.

This chapter presents an overview of the main stages of an attack and the various
defense mechanisms that you can employ to thwart an attack at each stage:

 “Stages of an Attack” on page 2

 “Detection and Defense Mechanisms” on page 2

 “Exploit Monitoring” on page 5

 1
 Concepts & Examples ScreenOS Reference Guide

Stages of an Attack
Each attack typically progresses in two major stages. In the first stage, the attacker
gathers information, and in the second stage he or she launches the attack.

1. Perform reconnaissance.

a. Map the network and determine which hosts are active (IP address sweep).

b. Discern which ports are active (port scans) on the hosts discovered by the
IP address sweep.

c. Determine the operating system (OS), which might expose a weakness in

the OS or suggest an attack to which that particular OS is susceptible.

2. Launch the attack.

a. Conceal the origin of the attack.

b. Perform the attack.

c. Remove or hide evidence.

Detection and Defense Mechanisms

An exploit can be an information-gathering probe or an attack to compromise,
disable, or harm a network or network resource. In some cases, the distinction
between the two objectives of an exploit can be unclear. For example, a barrage of
TCP SYN segments might be an IP address sweep with the intent of triggering
responses from active hosts, or it might be a SYN flood attack with the intent of
overwhelming a network so that it can no longer function properly. Furthermore,
because an attacker usually precedes an attack by performing reconnaissance on
the target, we can consider information-gathering efforts as a precursor to an
impending attack—that is, they constitute the first stage of an attack. Thus, the term
exploit encompasses both reconnaissance and attack activities, and the distinction
between the two is not always clear.

Juniper Networks provides various detection methods and defense mechanisms at

the zone and policy levels to combat exploits at all stages of their execution:

 SCREEN options at the zone level

 Firewall policies at the inter-, intra-, and super-zone policy levels (super-zone
here means in global policies, where no security zones are referenced).

NOTE: Although the VLAN and MGT zones are function zones and not security zones, you
can set SCREEN options for them. The VLAN zone supports the same set of
SCREEN options as a Layer 3 security zone. (Layer 2 security zones support an
additional SYN flood option that Layer 3 zones do not: Drop Unknown MAC).
Because the following SCREEN options do not apply to the MGT zone, they are not
available for that zone: SYN flood protection, SYN-ACK-ACK proxy flood
protection, HTTP component blocking, and WinNuke attack protection.

2  Stages of an Attack
 Chapter 1: Protecting a Network

To secure all connection attempts, Juniper Networks security devices use a dynamic
packet-filtering method known as stateful inspection. Using this method, the
security device notes various components in the IP packet and TCP segment
headers— source and destination IP addresses, source and destination port
numbers, and packet sequence numbers—and maintains the state of each TCP
session and pseudo UDP session traversing the firewall. (The device also modifies
session states based on changing elements such as dynamic port changes or
session termination.) When a responding TCP packet arrives, the device compares
the information reported in its header with the state of its associated session stored
in the inspection table. If they match, the responding packet is allowed to pass the
firewall. If the two do not match, the packet is dropped.

ScreenOS SCREEN options secure a zone by inspecting, then allowing or denying,

all connection attempts that require crossing an interface bound to that zone. The
security device then applies firewall policies, which can contain content filtering
and intrusion detection and prevention (IDP) components, to the traffic that passes
the SCREEN filters.

A Juniper Networks firewall provides the following sets of defense mechanisms:

 Reconnaissance deterrence

 IP address sweep

 Port scanning

 Operating system probes

 Evasion techniques

 Content monitoring and filtering

 Fragment reassembly

 Antivirus scanning

 Anti-spam filtering

 Web filtering

 Deep inspection

 Stateful signatures

 Protocol anomalies

 Granular blocking of HTTP components

Detection and Defense Mechanisms  3

 Concepts & Examples ScreenOS Reference Guide

 Denial of service (DoS) attack defenses

 Firewall DoS attacks

 Session table flood

 SYN-ACK-ACK proxy flood

 Network DoS attacks

 SYN flood

 ICMP flood

 UDP flood

 OS-specific DoS attacks

 Ping of death

 Teardrop attack

 WinNuke

 Suspicious packet attributes

 ICMP fragments

 Large ICMP packets

 Bad IP options

 Unknown protocols

 IP packet fragments

 SYN fragments

ScreenOS network-protection settings operate at two levels: security zone and

policy. The Juniper Networks security device performs reconnaissance deterrence
and DoS attack defenses at the security zone level. In the area of content
monitoring and filtering, the security device applies fragment reassembly at the
zone level and antivirus (AV) scanning and uniform resource locator (URL) filtering
at the policy level. The device applies IDP at the policy level, except for the
detection and blocking of HTTP components, which occurs at the zone level.
Zone-level firewall settings are SCREEN options. A network protection option set in
a policy is a component of that policy.

4  Detection and Defense Mechanisms

 Chapter 1: Protecting a Network

Exploit Monitoring
Although you typically want the security device to block exploits, there might be
times when you want to gather intelligence about them. You might want to learn
specifically about a particular exploit—to discover its intention, its sophistication,
and possibly (if the attacker is careless or unsophisticated) its source.

If you want to gather information about an exploit, you can let it occur, monitor it,
analyze it, perform forensics, and then respond according to a previously prepared
incident response plan. You can instruct the security device to notify you of an
exploit, but then, instead of taking action, you can have the device allow the exploit
to transpire. You can then study what occurred and try to understand the attacker’s
methods, strategies, and objectives. Increased understanding of the threat to the
network can then allow you to better fortify your defenses. Although a smart
attacker can conceal his or her location and identity, you might be able to gather
enough information to discover where the attack originated. You also might be able
to estimate the attacker’s capabilities. Gathering and analyzing this kind of
information allows you to determine your response.

Example: Monitoring Attacks from the Untrust Zone

In this example, IP spoofing attacks from the Untrust zone have been occurring
daily, usually between 21:00 and midnight. Instead of dropping the packets with the
spoofed source IP addresses, you want the security device to notify you that the
packets have arrived but allow them to pass, perhaps directing them to a honeypot
(a decoy network server that is designed to lure attackers and then record their
actions during an attack) that you have connected on the DMZ interface connection.
At 20:55 PM, you change the firewall behavior from notification and rejection of
packets belonging to a detected attack to notification and acceptance. When the
attack occurs, you can then use the honeypot to monitor the attacker’s activity after
crossing the firewall. You might also work in cooperation with the upstream ISP to
begin tracking the source of the packets back to their source.

WebUI
Screening > Screen (Zone: Untrust): Enter the following, then click Apply:

Generate Alarms without Dropping Packet: (select)

IP Address Spoof Protection: (select)

CLI
set zone untrust screen alarm-without-drop
set zone untrust screen ip-spoofing
save

Exploit Monitoring  5
 Concepts & Examples ScreenOS Reference Guide

NOTE: The alarm-without-drop option does not apply to the following:

 SYN-ACK-ACK proxy protection

 Source IP Based Session Limit

 Destination IP Based Session Limit

 Malicious URL protection

If this option is set, the device does not generate alarms and pass the packets.
Instead, it drops or forwards the packet based on the inspection results.

6  Exploit Monitoring
Chapter 2
Reconnaissance Deterrence

Attackers can better plan their attack when they first know the layout of the
targeted network (which IP addresses have active hosts), the possible entry points
(which port numbers are active on the active hosts), and the constitution of their
victims (which operating system the active hosts are running). To gain this
information, attackers must perform reconnaissance. Juniper Networks provides
several SCREEN options to deter attackers’ reconnaissance efforts and thereby
hinder them from obtaining valuable information about the protected network and
network resources.

 “IP Address Sweep” on page 8

 “Port Scanning” on page 9

 “Network Reconnaissance Using IP Options” on page 10

 “Operating System Probes” on page 12

 “SYN and FIN Flags Set” on page 12

 “FIN Flag Without ACK Flag” on page 13

 “TCP Header Without Flags Set” on page 14

 “Evasion Techniques” on page 15

 “FIN Scan” on page 15

 “Non-SYN Flags” on page 15

 “IP Spoofing” on page 18

 “IP Source Route Options” on page 23

 7
 Concepts & Examples ScreenOS Reference Guide

IP Address Sweep
An address sweep occurs when one source IP address sends 10 ICMP packets to
different hosts within a defined interval (5000 microseconds is the default). The
purpose of this scheme is to send ICMP packets—typically echo requests—to
various hosts in the hopes that at least one replies, thus uncovering an address to
target. The security device internally logs the number of ICMP packets to different
addresses from one remote source. Using the default settings, if a remote host
sends ICMP traffic to 10 addresses in 0.005 seconds (5000 microseconds), the
security device flags this as an address sweep attack, and rejects all further ICMP
echo requests from that host for the remainder of the specified threshold time
period. The device detects and drops the tenth packet that meets the address sweep
attack criterion. This is illustrated in Figure 2.

In Figure 2, the security device makes an entry in its session table for the first 10
ICMP packets from 2.2.2.5 and does a route lookup and policy lookup for these. If
no policy permits these packets, the device tags these as invalid and removes them
from the session table in the next “garbage sweep,” which occurs every two
seconds. After the tenth packet, the device rejects all further ICMP traffic from
2.2.2.5.

Figure 2: Address Sweep

Source: 2.2.2.5
(Most likely a spoofed
address or zombie agent) ethernet0/3 ethernet0/2
1.1.1.1/24 1.2.2.1/24
Untrust DMZ

ICMP Packets
Src addr Dst addr
11 ICMP packets 2.2.2.5 1.2.2.5
within 0.005 seconds 2.2.2.5 1.2.2.160
2.2.2.5 1.2.2.84
Note: After 10 ICMP packets are 2.2.2.5 1.2.2.211
received, the security device logs 2.2.2.5 1.2.2.10
this as an IP address sweep and 2.2.2.5 1.2.2.20
rejects the eleventh packet. 2.2.2.5 1.2.2.21
2.2.2.5 1.2.2.240
2.2.2.5 1.2.2.17
2.2.2.5 1.2.2.123
Rejected 2.2.2.5 1.2.2.6

Consider enabling this SCREEN option for a security zone only if there is a policy
permitting ICMP traffic from that zone. Otherwise, you do not need to enable it. The
lack of such a policy denies all ICMP traffic from that zone, precluding an attacker
from successfully performing an IP address sweep anyway.

To block IP address sweeps originating in a particular security zone:

WebUI
Screening > Screen (Zone: select a zone name): Enter the following, then click
Apply:

IP Address Sweep Protection: (select)

Threshold: (enter a value to trigger IP address sweep protection)

8  IP Address Sweep
 Chapter 2: Reconnaissance Deterrence

NOTE: The value unit is microseconds. The default value is 5000 microseconds.

CLI
set zone zone screen ip-sweep threshold number
set zone zone screen ip-sweep

Port Scanning
A port scan occurs when one source IP address sends IP packets containing TCP
SYN segments to 10 different ports at the same destination IP address within a
defined interval (5000 microseconds is the default). The purpose of this scheme is
to scan the available services in the hopes that at least one port will respond, thus
identifying a service to target. The security device internally logs the number of
different ports scanned from one remote source. Using the default settings, if a
remote host scans 10 ports in 0.005 seconds (5000 microseconds), the device flags
this as a port scan attack and rejects all further packets from the remote source for
the remainder of the specified timeout period. The device detects and drops the
tenth packet that meets the port scan attack criterion. This is illustrated in Figure 3.

In Figure 3, the security device makes an entry in its session table for the first 10
connection attempts from 2.2.2.5 to 1.2.2.5 and does a route lookup and policy
lookup for these. If no policy permits these connection attempts, the device tags
these as invalid and removes them from the session table in the next “garbage
sweep,” which occurs every two seconds. After the tenth attempt, the device rejects
all further connection attempts.

Figure 3: Port Scan

Source: 2.2.2.5
(Most likely a spoofed
address or zombie agent) ethernet3 ethernet2
1.1.1.1/24 1.2.2.1/24
Untrust DMZ

destination: 1.2.2.5

IP Packets with TCP SYN Segments

Src addr:port Dst addr:port
11 SYN segments 2.2.2.5:17820 1.2.2.5:21
within 0.005 seconds 2.2.2.5:42288 1.2.2.160:23
2.2.2.5:22814 1.2.2.84:53
Note: After 10 IP packets containing 2.2.2.515401 1.2.2.211:80
TCP SYN segments to different ports 2.2.2.5:13373 1.2.2.10:111
are received at the same destination IP 2.2.2.5:33811 1.2.2.20:113
address, the security device logs this as 2.2.2.5:17821 1.2.2.21:123
a port scan and rejects further packets 2.2.2.5:19003 1.2.2.240:129
from the source address. 2.2.2.5:26450 1.2.2.17:137
2.2.2.5:38087 1.2.2.123:138
Rejected 2.2.2.5:24111 1.2.2.6139

Port Scanning  9
 Concepts & Examples ScreenOS Reference Guide

To block port scans originating in a particular security zone:

WebUI
Screening > Screen (Zone: select a zone name): Enter the following, then click
Apply:

Port Scan Protection: (select)

Threshold: (enter a value to trigger protection against port scans)

NOTE: The value unit is microseconds. The default value is 5000 microseconds.

CLI
set zone zone screen port-scan threshold number
set zone zone screen port-scan

Network Reconnaissance Using IP Options

The Internet Protocol standard RFC 791, Internet Protocol, specifies a set of options
to provide special routing controls, diagnostic tools, and security. These options
appear after the destination address in an IP packet header, as shown in Figure 4.

Figure 4: Routing Options

IP Header Header Type of Service

Version Length Total Packet Length (in Bytes)

Identification 0 D M Fragment Offset

Time to Live (TTL) Protocol Header Checksum

Source Address

Destination Address

Options

Payload

RFC 791 states that these options are “unnecessary for the most common
communications” and, in reality, they rarely appear in IP packet headers. When
they do appear, they are frequently being put to some illegitimate use. Table 1 lists
the IP options and their accompanying attributes.

Table 1: IP Options and Attributes

Type Class Number Length Intended Use Nefarious Use

End of 01 0 0 Indicates the end of one or more IP None.
Options options.
No Options 0 1 0 Indicates there are no IP options in the None.
header.
Security 0 2 11 bits Provides a way for hosts to send security, Unknown. However, because it is
TCC (closed user group) parameters, and obsolete, its presence in an IP
Handling Restriction Codes compatible header is suspect.
with Department of Defense (DoD)
requirements. (This option, as specified in
RFC 791, Internet Protocol, and RFC 1038,
Revised IP Security Option, is obsolete.)

10  Network Reconnaissance Using IP Options

 Chapter 2: Reconnaissance Deterrence

Type Class Number Length Intended Use Nefarious Use

Loose Source 0 3 Varies Specifies a partial route list for a packet to Evasion. The attacker can use the
Route take on its journey from source to specified routes to hide the true
destination. The packet must proceed in source of a packet or to gain access
the order of addresses specified, but it is to a protected network. (See “IP
allowed to pass through other routers in Source Route Options” on page 23.)
between those specified.
Record 0 7 Varies Records the IP addresses of the network Reconnaissance. If the destination
Route devices along the path that the IP packet host is a compromised machine in
travels. The destination machine can then the attacker’s control, he or she can
extract and process the route information. glean information about the
(Due to the size limitation of 40 bytes for topology and addressing scheme of
both the option and storage space, this can the network through which the
only record up to 9 IP addresses.) packet passed.
Stream ID 0 8 4 bits (Obsolete) Provided a way for the 16-bit Unknown. However, because it is
SATNET stream identifier to be carried obsolete, its presence in an IP
through networks that did not support the header is suspect.
stream concept.
Strict Source 0 9 Varies Specifies the complete route list for a Evasion. An attacker can use the
Route packet to take on its journey from source specified routes to hide the true
to destination. The last address in the list source of a packet or to gain access
replaces the address in the destination to a protected network. (See “IP
field. Source Route Options” on page 23.)
Timestamp 22 4 Records the time (in Universal Time3) Reconnaissance. If the destination
when each network device receives the host is a compromised machine in
packet during its trip from the point of the attacker’s control, he or she can
origin to its destination. The network glean information about the
devices are identified by IP number. topology and addressing scheme of
This option develops a list of IP addresses the network through which the
of the routers along the path of the packet packet passed.
and the duration of transmission between
each one.

1.The class of options identified as “0” was designed to provide extra packet or network control.
2.The class of options identified as “2” was designed diagnostics, debugging, and measurement.
3.The timestamp uses the number of milliseconds since midnight Universal Time (UT). UT is also known as Greenwich Mean
Time (GMT), which is the basis for the international time standard.

The following SCREEN options detect IP options that an attacker can use for
reconnaissance or for some unknown but suspect purpose:

 Record Route: The security device detects packets where the IP option is 7
(Record Route) and records the event in the SCREEN counters list for the
ingress interface.

 Timestamp: The security device detects packets where the IP option list
includes option 4 (Internet Timestamp) and records the event in the SCREEN
counters list for the ingress interface.

 Security: The security device detects packets where the IP option is 2 (security)
and records the event in the SCREEN counters list for the ingress interface.

 Stream ID: The security device detects packets where the IP option is 8 (Stream
ID) and records the event in the SCREEN counters list for the ingress interface.

Network Reconnaissance Using IP Options  11

 Concepts & Examples ScreenOS Reference Guide

To detect packets with the above IP options set, do either of the following, where
the specified security zone is the one from which the packets originate:

WebUI
Screening > Screen (Zone: select a zone name): Enter the following, then click
Apply:

IP Record Route Option Detection: (select)

IP Timestamp Option Detection: (select)
IP Security Option Detection: (select)
IP Stream Option Detection: (select)

CLI
set zone zone screen ip-record-route
set zone zone screen ip-timestamp-opt
set zone zone screen ip-security-opt
set zone zone screen ip-stream-opt

Operating System Probes

Before launching an exploit, an attacker might try to probe the targeted host to
learn its operating system (OS). With that knowledge, he can better decide which
attack to launch and which vulnerabilities to exploit. A Juniper Networks security
device can block reconnaissance probes commonly used to gather information
about OS types.

SYN and FIN Flags Set

Both the SYN and FIN control flags are not normally set in the same TCP segment
header. The SYN flag synchronizes sequence numbers to initiate a TCP connection.
The FIN flag indicates the end of data transmission to finish a TCP connection. Their
purposes are mutually exclusive. A TCP header with the SYN and FIN flags set is
anomalous TCP behavior, causing various responses from the recipient, depending
on the OS. See Figure 5.

Figure 5: TCP Header with SYN and FIN Flags Set

TCP Header 16-bit Source Port Number 16-bit Destination Port Number

32-bit Sequence Number

32-bit Acknowledgement Number

4-bit Header Reserved U A P R S F

R C S S Y I 16-bit Window Size
G K H T N N
16-bit TCP Checksum 16-bit Urgent Pointer

Options (if any)

Data (if any)

The SYN and FIN flags are set.

12  Operating System Probes

 Chapter 2: Reconnaissance Deterrence

An attacker can send a segment with both flags set to see what kind of system reply
is returned and thereby determine what kind of OS is on the receiving end. The
attacker can then use any known system vulnerabilities for further attacks.

When you enable this SCREEN option, the security device checks if the SYN and
FIN flags are set in TCP headers. If it discovers such a header, it drops the packet.

To block packets with both the SYN and FIN flags set, do either of the following,
where the specified security zone is the one from which the packets originate:

WebUI
Screening > Screen (Zone: select a zone name): Select SYN and FIN Bits Set
Protection, then click Apply.

CLI
set zone zone screen syn-fin

FIN Flag Without ACK Flag

Figure 6 shows TCP segments with the FIN control flag set (to signal the conclusion
of a session and terminate the connection). Normally, TCP segments with the FIN
flag set also have the ACK flag set (to acknowledge the previous packet received).
Because a TCP header with the FIN flag set but not the ACK flag is anomalous TCP
behavior, there is no uniform response to this. The OS might respond by sending a
TCP segment with the RST flag set. Another might completely ignore it. The victim’s
response can provide the attacker with a clue as to its OS. (Other purposes for
sending a TCP segment with the FIN flag set are to evade detection while
performing address and port scans and to evade defenses on guard for a SYN flood
by performing a FIN flood instead. For information about FIN scans, see “FIN Scan”
on page 15.)

NOTE: Vendors have interpreted RFC 793, Transmission Control Protocol, variously when
designing their TCP/IP implementations. When a TCP segment arrives with the
FIN flag set but not the ACK flag, some implementations send RST segments.
Some drop the packet without sending an RST.

Figure 6: TCP Header with FIN Flag Set

TCP Header 16-bit Source Port Number 16-bit Destination Port Number

32-bit Sequence Number

32-bit Acknowledgement Number

4-bit Header Reserved U A P R S F

R C S S Y I 16-bit Window Size
G K H T N N
16-bit TCP Checksum 16-bit Urgent Pointer

Options (if any)

Data (if any)

Only the FIN flag is set.

Operating System Probes  13

 Concepts & Examples ScreenOS Reference Guide

When you enable this SCREEN option, the security device checks if the FIN flag is
set but not the ACK flag in TCP headers. If it discovers a packet with such a header,
it drops the packet.

To block packets with the FIN flag set but not the ACK flag, do either of the
following, where the specified security zone is the one from which the packets
originate:

WebUI
Screening > Screen (Zone: select a zone name): Select FIN Bit with No ACK Bit
in Flags Protection, then click Apply.

CLI
set zone zone screen fin-no-ack

TCP Header Without Flags Set

A normal TCP segment header has at least one flag control set. A TCP segment with
no control flags set is an anomalous event. Because different operating systems
respond differently to such anomalies, the response (or lack of response) from the
targeted device can provide a clue as to the type of OS it is running. See Figure 7.

Figure 7: TCP Header with No Flags Set

TCP Header 16-bit Source Port Number 16-bit Destination Port Number
32-bit Sequence Number
32-bit Acknowledgement Number

4-bit Header Reserved U A P R S F

R C S S Y I 16-bit Window Size
G K H T N N
16-bit TCP Checksum 16-bit Urgent Pointer

Options (if any)

Data (if any)

None of the flags is set.

When you enable the security device to detect TCP segment headers with no flags
set, the device drops all TCP packets with a missing or malformed flags field.

To block packets with no flags set, do either of the following, where the specified
security zone is the one from which the packets originate:

WebUI
Screening > Screen (Zone: select a zone name): Select TCP Packet without
Flag Protection, then click Apply.

CLI
set zone zone screen tcp-no-flag

14  Operating System Probes

 Chapter 2: Reconnaissance Deterrence

Evasion Techniques
Whether gathering information or launching an attack, it is generally expected that
the attacker avoids detection. Although some IP address and port scans are blatant
and easily detectable, more wily attackers use a variety of means to conceal their
activity. Such techniques as using FIN scans instead of SYN scans—which attackers
know most firewalls and intrusion detection programs detect—indicate an
evolution of reconnaissance and exploit techniques to evade detection and
successfully accomplish their tasks.

FIN Scan
A FIN scan sends TCP segments with the FIN flag set in an attempt to provoke a
response (a TCP segment with the RST flag set) and thereby discover an active host
or an active port on a host. An attacker might use this approach rather than perform
an address sweep with ICMP echo requests or an address scan with SYN segments
because he or she knows that many firewalls typically guard against the latter two
approaches—but not necessarily against FIN segments. The use of TCP segments
with the FIN flag set might evade detection and thereby help the attacker succeed in
his or her reconnaissance efforts.

To thwart a FIN scan, you can do either or both of the following:

 Enable the SCREEN option that specifically blocks TCP segments with the FIN
flag set but not the ACK flag, which is anomalous for a TCP segment:

WebUI: Screening > Screen: Select the zone to which you want to apply
this SCREEN option from the Zone drop-down list, then select FIN Bit With
No ACK Bit in Flags Protection.

CLI: Enter set zone name screen fin-no-ack, in which name is the name of
the zone to which you want to apply this SCREEN option.

 Change the packet processing behavior to reject all non-SYN packets that do
not belong to an existing session by entering the CLI command: set flow
tcp-syn-check. (For more information about SYN flag checking, see “Non-SYN
Flags” on page 15.)

NOTE: Changing the packet flow to check that the SYN flag is set for packets that do not
belong to existing sessions also thwarts other types of non-SYN scans, such as a
null scan (when no TCP flags are set).

Non-SYN Flags
By default, the security device checks for SYN flags in the first packet of a session
and rejects any TCP segments with non-SYN flags attempting to initiate a session.
You can leave this packet flow as is or change it to so that the device does not
enforce SYN flag checking before creating a session. Figure 8 on page 16 illustrates
packet flow sequences when SYN flag checking is enabled and when it is disabled.

Evasion Techniques  15
 Concepts & Examples ScreenOS Reference Guide

NOTE: By default, checking for the TCP SYN flag in the initial packet of a session is
enabled when you install a Juniper Networks security device running ScreenOS
5.1.0 or higher. If you upgrade from a release prior to ScreenOS 5.1.0, SYN
checking remains disabled by default—unless you have previously changed the
default behavior.

These packet flows are the same whether the ingress interface is operating at
Layer 3 (Route or NAT mode) or at Layer 2 (Transparent mode).

Figure 8: SYN Flag Checking

When SYN flag checking is enabled When SYN flag checking is disabled

Packet arrives at Packet arrives at

ingress interface ingress interface

In In
session session
Session Session Session Session FORWARD
Lookup Update FORWARD Lookup Update

Not in Not in
session session

Policy Permit SYN Flag Yes Session Policy Permit Session

Lookup FORWARD Lookup Creation FORWARD
Check Creation

Deny No Deny

DROP DROP DROP

When the security device with SYN flag checking enabled receives a non-SYN TCP
segment that does not belong to an existing session, it drops the packet and sends
the source host to a TCP RST—unless the code bit of the initial non-SYN TCP packet
is also RST. In that case, the security device simply drops the packet.

You can enable and disable SYN checking with the following CLI commands:

set flow tcp-syn-check

unset flow tcp-syn-check

Not checking for the SYN flag in the first packets offers the following advantages:

 NSRP with Asymmetric Routing: In an Active/Active NSRP configuration in a

dynamic routing environment, a host might send the initial TCP segment with
the SYN flag set to one security device (Device-A) but the SYN/ACK might be
routed to the other security device in the cluster (Device-B). If this asymmetric
routing occurs after Device-A has synchronized its session with Device-B, all is
well. On the other hand, if the SYN/ACK response reaches Device-B before
Device-A synchronizes the session and SYN checking is enabled, Device-B
rejects the SYN/ACK, and the session cannot be established. With SYN checking
disabled, Device-B accepts the SYN/ACK response—even though there is no
existing session to which it belongs—and creates a new session table entry for
it.

16  Evasion Techniques
 Chapter 2: Reconnaissance Deterrence

 Uninterrupted Sessions: If SYN checking is enabled and you add a security

device operating in Transparent mode to a working network, it disrupts all
existing sessions, which must then be restarted. For lengthy sessions, such as
large data transfers or database backups, this can be a troublesome disruption.
Similarly, if you reset the device or even change a component in the core
section of a policy and SYN checking is enabled, all existing sessions or those
sessions to which the policy change applies are disrupted and must be
restarted. Disabling SYN checking avoids such disruptions to network traffic
flows.

NOTE: A solution to this scenario is to install the security device with SYN checking
disabled initially. Then, after a few hours—when established sessions are running
through the device—enable SYN checking.

The core section in a policy contains the following main components: source and
destination zones, source and destination addresses, one or more services, and an
action.

However, note that the above advantages exact the following security sacrifices:

 Reconnaissance Holes: When an initial TCP segment with a non-SYN

flag—such as ACK, URG, RST, FIN—arrives at a closed port, many operating
systems (Windows, for example) respond with a TCP segment that has the RST
flag set. If the port is open, then the recipient does not generate any response.

By analyzing these responses or lack thereof, an intelligence gatherer can

perform reconnaissance on the protected network and also on the ScreenOS
policy set. If he sends a TCP segment with a non-SYN flag set and the policy
permits it through, the destination host receiving such a segment might drop it
and respond with a TCP segment that has the RST flag set. Such a response
informs the perpetrator of the presence of an active host at a specific address
and that the targeted port number is closed. The intelligence gatherer also
learns that the firewall policy permits access to that port number on that host.

By enabling SYN flag checking, the security device drops TCP segments without
a SYN flag if they do not belong to an existing session. It does not return a TCP
RST segment. Consequently, the scanner gets no replies regardless of the policy
set or whether the port is open or closed on the targeted host.

 Session Table Floods: If SYN checking is disabled, an attacker can bypass the
ScreenOS SYN flood protection feature by flooding a protected network with a
barrage of TCP segments that have non-SYN flags set. Although the targeted
hosts drop the packets—and possibly send TCP RST segments in reply—such a
flood can fill up the session table of the security device. When the session table
is full, the device cannot process new sessions for legitimate traffic.

By enabling SYN checking and SYN flood protection, you can thwart this kind
of attack. Checking that the SYN flag is set on the initial packet in a session
forces all new sessions to begin with a TCP segment that has the SYN flag set.
SYN flood protection then limits the number of TCP SYN segments per second
so that the session table does not become overwhelmed.

Evasion Techniques  17
 Concepts & Examples ScreenOS Reference Guide

NOTE: For information about session table floods, see “Session Table Flood” on page 28.
For information about SYN floods, see “SYN Flood” on page 38.

If you do not need SYN checking disabled, we strongly recommend that it be

enabled (its default state for an initial installation of ScreenOS). You can enable it
with the following command: set flow tcp-syn-check. With SYN checking enabled,
the security device rejects TCP segments with non-SYN flags set unless they belong
to an established session.

IP Spoofing
One method of attempting to gain access to a restricted area of the network is to
insert a bogus source address in the packet header to make the packet appear to
come from a trusted source. This technique is called IP spoofing. ScreenOS has two
IP spoofing detection methods, both of which accomplish the same task:
determining that the packet came from a location other than that indicated in its
header. The method that a Juniper Networks security device uses depends on
whether it is operating at Layer 3 or Layer 2 in the OSI Model.

 Layer 3—When interfaces on the security device are operating in Route or NAT
mode, the mechanism to detect IP spoofing relies on route table entries. If, for
example, a packet with source IP address 10.1.1.6 arrives at ethernet3, but the
security device has a route to 10.1.1.0/24 through ethernet1, IP spoof checking
notes that this address arrived at an invalid interface—as defined in the route
table, a valid packet from 10.1.1.6 can only arrive via ethernet1, not ethernet3.
Therefore, the device concludes that the packet has a spoofed source IP address
and discards it.

Figure 9: Layer 3 IP Spoofing

1. An IP packet arrives at ethernet3.
Its source IP address is 10.1.1.6.
2. Because IP spoof protection is enabled in the
Untrust zone, the device checks if 10.1.1.6 is a valid
IP Packet with Source IP 10.1.1.6 source IP address for a packet arriving on ethernet3.
Untrust Zone

ethernet3
1.1.1.1/24
X Route Table
3. When the route table lookup reveals ID IP-Prefix Interface Gateway P
that 10.1.1.6 is not a valid source IP
address for a packet arriving on 1 10.1.10/24 eth 1 0.0.0.0 C
ethernet3, the device rejects the
packet. ethernet1
Trust Zone
10.1.1.1/24

Subnet: 10.1.1.0/24

18  Evasion Techniques
 Chapter 2: Reconnaissance Deterrence

If the source IP address in a packet does not appear in the route table, by
default the security device allows that packet to pass (assuming that a policy
exists permitting it). Using the following CLI command—where the specified
security zone is the one from which the packets originate—you can instruct the
security device to drop any packet whose source IP address is not in the route
table:

set zone zone screen ip-spoofing drop-no-rpf-route

 Layer 2—When interfaces on the security device are operating in Transparent

mode, the IP spoof checking mechanism makes use of the address book
entries. For example, you define an address for “serv A” as 1.2.2.5/32 in the
V1-DMZ zone. If a packet with source IP address 1.2.2.5 arrives at a V1-Untrust
zone interface (ethernet3), IP spoof checking notes that this address arrived at
an invalid interface. The address belongs to the V1-DMZ zone, not to the
V1-Untrust zone, and is accepted only at ethernet2, which is bound to V1-DMZ.
The device concludes that the packet has a spoofed source IP address and
discards it.

Figure 10: Layer 2 IP Spoofing

1. An IP packet arrives from the V1-Untrust 2. Because IP spoof protection is enabled in the
zone. Its source IP address is 1.2.2.5. V1-Untrust zone, the device checks if 1.2.2.5 is
V1-Untrust Zone a valid source IP address for a packet arriving
IP Packet with Source IP 1.2.2.5 from the V1-Untrust zone.

ethernet3
0.0.0.0/0

Address Zone Name: V1-DMZ

3. When the address book lookup
reveals that 1.2.2.5 is not a Name Address Netmask
valid source IP address for a
packet arriving from the Subnet: 1.2.2.0/24 1.2.2.5
serv A 255.255.255.255
V1-Untrust zone, the device C
rejects the packet. serv A ethernet2
1.2.2.5 0.0.0.0/0

V1-DMZ Zone

Be careful when defining addresses for the subnet that straddles multiple
security zones. In Figure 10, 1.2.2.0/24 belongs to both the V1-Untrust and
V1-DMZ zones. If you configure the security device as follows, the device will
block traffic from the V1-DMZ zone that you want it to permit:

 You define an address for 1.2.2.0/24 in the V1-Untrust zone.

 You have a policy permitting traffic from any address in the V1-DMZ zone
to any address in the V1-Untrust zone (set policy from v1-dmz to
v1-untrust any any any permit).

 You enable IP spoof checking.

Because addresses in the V1-DMZ zone are also in the 1.2.2.0/24 subnet, when
traffic from these addresses reaches ethernet2, the IP spoof check refers to the
address book and finds 1.2.2.0/24 in the V1-Untrust zone. Consequently, the
security device blocks the traffic.

Evasion Techniques  19
 Concepts & Examples ScreenOS Reference Guide

Example: L3 IP Spoof Protection

In this example, you enable IP spoof protection for the Trust, DMZ, and Untrust
zones for a Juniper Networks security device operating at Layer 3. By default, the
device automatically makes entries in the route table for the subnets specified in
interface IP addresses. In addition to these automatic route table entries, you
manually enter the three routes shown in the following table:

Destination Egress Interface Next Gateway

10.1.2.0/24 ethernet1 10.1.1.250
1.2.3.0/24 ethernet2 1.2.2.250
0.0.0.0/0 ethernet3 1.1.1.250

If you enable the IP spoof protection SCREEN option but do not enter the above
three routes, the device drops all traffic from the addresses in the “Destination”
column and enters alarms in the event log. For example, if a packet with the source
address 10.1.2.5 arrives at ethernet1 and there is no route to the 10.1.2.0/24 subnet
via ethernet1, the device determines that packet has arrived at an invalid interface
and drops it.

All the security zones in this example are in the trust-vr routing domain.

Figure 11: Example of Layer 3 IP Spoofing

Router ethernet1 ethernet3 Router
10.1.1.250 10.1.1.1/24 1.1.1.1/24 1.1.1.250

ethernet2
1.2.2.1/24

10.1.2.0/24 10.1.1.0/24 1.1.1.0/24 0.0.0.0/0

Trust Zone Untrust Zone

1.2.2.0/24

1.2.3.0/24
DMZ
Zone

Router
1.2.2.250

20  Evasion Techniques
 Chapter 2: Reconnaissance Deterrence

WebUI
1. Interfaces
Network > Interfaces > Edit (for ethernet1): Enter the following, then click
Apply:

Zone Name: Trust

Static IP: (select this option when present)
IP Address/Netmask: 10.1.1.1/24

Enter the following, then click OK:

Interface Mode: NAT

Network > Interfaces > Edit (for ethernet2): Enter the following, then click
OK:

Zone Name: DMZ

Static IP: (select this option when present)
IP Address/Netmask: 1.2.2.1/24

Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:

Zone Name: Untrust

Static IP: (select this option when present)
IP Address/Netmask: 1.1.1.1/24
2. Routes
Network > Routing > Routing Entries > trust-vr New: Enter the following,
then click OK:

Network Address/Netmask: 10.1.2.0/24

Gateway: (select)
Interface: ethernet1
Gateway IP Address: 10.1.1.250

Network > Routing > Routing Entries > trust-vr New: Enter the following,
then click OK:

Network Address/Netmask: 1.2.3.0/24

Gateway: (select)
Interface: ethernet2
Gateway IP Address: 1.2.2.250

Network > Routing > Routing Entries > trust-vr New: Enter the following,
then click OK:

Network Address/Netmask: 0.0.0.0/0

Gateway: (select)
Interface: ethernet3
Gateway IP Address: 1.1.1.250

Evasion Techniques  21
 Concepts & Examples ScreenOS Reference Guide

3. IP Spoof Protection
Screening > Screen (Zone: Trust): Select IP Address Spoof Protection, then
click Apply.

Screening > Screen (Zone: DMZ): Select IP Address Spoof Protection, then
click Apply.

Screening > Screen (Zone: Untrust): Select IP Address Spoof Protection, then
click Apply.

CLI
1. Interfaces
set interface ethernet1 zone trust
set interface ethernet1 ip 10.1.1.1/24
set interface ethernet1 nat
set interface ethernet2 zone dmz
set interface ethernet2 ip 1.2.2.1/24
set interface ethernet3 zone untrust
set interface ethernet3 ip 1.1.1.1/24
2. Routes
set vrouter trust-vr route 10.1.2.0/24 interface ethernet1 gateway 10.1.1.250
set vrouter trust-vr route 1.2.3.0/24 interface ethernet2 gateway 1.2.2.250
set vrouter trust-vr route 0.0.0.0/0 interface ethernet3 gateway 1.1.1.250
3. IP Spoof Protection
set zone trust screen ip-spoofing
set zone dmz screen ip-spoofing
set zone untrust screen ip-spoofing
save

Example: L2 IP Spoof Protection

In this example, you protect the V1-DMZ zone from IP spoofing on traffic
originating in the V1-Untrust zone. First, you define the following addresses for
three webservers in the V1-DMZ zone:

 servA: 1.2.2.10

 servB: 1.2.2.20

 servC: 1.2.2.30

You then enable IP spoofing in the V1-Untrust zone.

If an attacker in the V1-Untrust zone attempts to spoof the source IP address using
any of the three addresses in the V1-DMZ zone, the security device checks the
address against those in the address books. When it finds that the source IP address
on a packet coming from the V1-Untrust zone belongs to a defined address in the
V1-DMZ zone, the device rejects the packet.

22  Evasion Techniques
 Chapter 2: Reconnaissance Deterrence

WebUI
1. Addresses
Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: servA

IP Address/Domain Name:
IP/Netmask: (select), 1.2.2.10/32
Zone: V1-DMZ

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: servB

IP Address/Domain Name:
IP/Netmask: (select), 1.2.2.20/32
Zone: V1-DMZ

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: servC

IP Address/Domain Name:
IP/Netmask: (select), 1.2.2.30/32
Zone: V1-DMZ
2. IP Spoof Protection
Screening > Screen (Zone: V1-Trust): Select IP Address Spoof Protection, then
click Apply.

CLI
1. Addresses
set address v1-dmz servA 1.2.2.10/32
set address v1-dmz servB 1.2.2.20/32
set address v1-dmz servC 1.2.2.30/32
2. IP Spoof Protection
set zone v1-untrust screen ip-spoofing
save

IP Source Route Options

Source routing was designed to allow the user at the source of an IP packet
transmission to specify the IP addresses of the routers (also referred to as “hops”)
along the path that he or she wants an IP packet to take on its way to its
destination. The original intent of the IP source route options was to provide routing
control tools to aid diagnostic analysis. If, for example, the transmission of a packet
to a particular destination meets with irregular success, you might first use either
the record route or timestamp IP option to discover the addresses of routers along
the path or paths that the packet takes. You can then use either the loose or strict
source route option to direct traffic along a specific path, using the addresses you
learned from the results that the record route or timestamp options produced. By

Evasion Techniques  23
 Concepts & Examples ScreenOS Reference Guide

changing router addresses to alter the path and sending several packets along
different paths, you can note changes that either improve or lessen the success rate.
Through analysis and the process of elimination, you might be able to deduce
where the trouble lies.

Figure 12: IP Source Routing

IP Source Route Options
for Diagnostics Four Routers
1 3
A Packet Path B
Transmission from A to B is successful
50% of the time using routers 1 and 3.
2 4

1 3
A B
Using IP source routing, A sends traffic
through routers 2 and 3. Transmission from A
2 4 to B remains successful only 50% of the time.

1 3
A B Using IP source routing, A sends traffic
through routers 1 and 4. Transmission
from A to B is successful 100% of the time.
2 4 Therefore, we can conclude that the
trouble lies in router #3.

Although the uses of IP source route options were originally benign, attackers have
learned to put them to more devious uses. They can use IP source route options to
hide their true address and access restricted areas of a network by specifying a
different path. For an example showing how an attacker can put both deceptions to
use, consider the following scenario as illustrated in Figure 13.

Figure 13: Loose IP Source Route Option for Deception

Four Routers ethernet3 ethernet1 HTTP Server
1.1.1.1/24 10.1.1.1/24 10.1.1.5
Untrust Zone Trust Zone
1 3
Packet Path

2.2.2.0/24 10.1.1.0/24
2 4

No IP Spoof Checking Mapped IP: 1.1.1.5 - 10.1.1.5

No Access Control Policy: set policy from untrust to trust
Attacker 2.2.2.0/24 MIP(1.1.1.5) HTTP permit
Packet Information
Real Source Address: 6.6.6.5 SCREEN Options for the Untrust Zone includes
Spoofed Source Address: 2.2.2.5 “Deny IP Source Route Option”.
Destination Address: 1.1.1.5 The security device drops the packet.
IP Loose Source Route: 6.6.6.250, 2.2.2.250

24  Evasion Techniques
 Chapter 2: Reconnaissance Deterrence

The Juniper Networks security device only allows traffic 2.2.2.0/24 if it comes
through ethernet3, an interface bound to the Untrust zone. Routers 3 and 4 enforce
access controls but routers 1 and 2 do not. Furthermore, router 2 does not check for
IP spoofing. The attacker spoofs the source address, and by using the loose source
route option, directs the packet through router 2 to the 2.2.2.0/24 network and
from there out router 1. Router 1 forwards it to router 3, which forwards it to the
security device. Because the packet came from the 2.2.2.0/24 subnet and has a
source address from that subnet, it seems to be valid. However, one remnant of the
earlier chicanery remains: the loose source route option. In this example, you have
enabled the “Deny IP Source Route Option” SCREEN option for the Untrust zone.
When the packet arrives at ethernet3, the device rejects it.

You can enable the security device to either block any packets with loose or strict
source route options set or detect such packets and then record the event in the
counters list for the ingress interface. The SCREEN options are as follows:

 Deny IP Source Route Option: Enable this option to block all IP traffic that
employs the loose or strict source route option. Source route options can allow
an attacker to enter a network with a false IP address.

 Detect IP Loose Source Route Option: The security device detects packets
where the IP option is 3 (Loose Source Routing) and records the event in the
SCREEN counters list for the ingress interface. This option specifies a partial
route list for a packet to take on its journey from source to destination. The
packet must proceed in the order of addresses specified, but it is allowed to
pass through other routers in between those specified.

 Detect IP Strict Source Route Option: The security device detects packets
where the IP option is 9 (Strict Source Routing) and records the event in the
SCREEN counters list for the ingress interface. This option specifies the
complete route list for a packet to take on its journey from source to
destination. The last address in the list replaces the address in the destination
field.

(For more information about all the IP options, see “Network Reconnaissance
Using IP Options” on page 10.)

To block packets with either a loose or strict source route option set, do either of the
following, where the specified security zone is the one from which the packets
originate:

WebUI
Screening > Screen (Zone: select a zone name): Select IP Source Route Option
Filter, then click Apply.

CLI
set zone zone screen ip-filter-src

Evasion Techniques  25
 Concepts & Examples ScreenOS Reference Guide

To detect and record (but not block) packets with a loose or strict source route
option set, do either of the following, where the specified security zone is the one
from which the packets originate:

WebUI
Screening > Screen (Zone: select a zone name): Enter the following, then click
Apply:

IP Loose Source Route Option Detection: (select)

IP Strict Source Route Option Detection: (select)

CLI
set zone zone screen ip-loose-src-route
set zone zone screen ip-strict-src-route

26  Evasion Techniques
Chapter 3
Denial of Service Attack Defenses

The intent of a denial of service (DoS) attack is to overwhelm the targeted victim
with a tremendous amount of bogus traffic so that the victim becomes so
preoccupied processing the bogus traffic that it is unable to process legitimate
traffic. The target can be the security device, the network resources to which the
device controls access, or the specific hardware platform or operating system (OS)
of an individual host.

If a DoS attack originates from multiple source addresses, it is known as a

distributed denial of service (DDoS) attack. Typically, the source address of a DoS
attack is spoofed. The source addresses in a DDoS attack might be spoofed or the
actual addresses of hosts that the attacker has previously compromised and which
he or she is now using as zombie agents from which to launch the attack.

The security device can defend itself and the resources it protects from DoS and
DDoS attacks. The following sections describe the various defense options available:

 “Firewall DoS Attacks” on page 28

 “Session Table Flood” on page 28

 “SYN-ACK-ACK Proxy Flood” on page 36

 “Network DoS Attacks” on page 38

 “SYN Flood” on page 38

 “SYN Cookie” on page 48

 “ICMP Flood” on page 50

 “UDP Flood” on page 51

 “Land Attack” on page 52

 “OS-Specific DoS Attacks” on page 53

 “Ping of Death” on page 53

 “Teardrop Attack” on page 54

 “WinNuke” on page 55

 27
 Concepts & Examples ScreenOS Reference Guide

Firewall DoS Attacks

If an attacker discovers the presence of the Juniper Networks security device, the
attacker might launch a denial of service (DoS) attack against the security device
instead of the network behind it. A successful DoS attack against a firewall amounts
to a successful DoS attack against the protected network in that it thwarts attempts
of legitimate traffic to traverse the firewall. This section explains the two methods
an attacker might use to fill up the session table of a Juniper Networks security
device and thereby produce a DoS: session table flood and SYN-ACK-ACK proxy
flood.

Session Table Flood

A successful DoS attack overwhelms its victim with such a massive barrage of false
traffic that the victim becomes unable to process legitimate connection requests.
DoS attacks can take many forms—SYN flood, SYN-ACK-ACK flood, UDP flood,
ICMP flood, and so on—but they all have the same objective: to fill up their victim’s
session table. When the session table is full, that host cannot create any new
sessions and begins rejecting new connection requests. The following SCREEN
options help mitigate such attacks:

 Source-Based and Destination-Based Session Limits

 Aggressive Aging

 CPU Protection with Blacklisting DoS Attack Traffic

 Prioritizing Critical Traffic

Source-Based and Destination-Based Session Limits

In addition to limiting the number of concurrent sessions from the same source IP
address, you can also limit the number of concurrent sessions to the same
destination IP address. One benefit of setting a source-based session limit is that it
can stem an attack such as the Nimda virus (which is actually both a virus and a
worm) that infects a server and then begins generating massive amounts of traffic
from that server. Because all the virus-generated traffic originates from the same IP
address, a source-based session limit ensures that the firewall can curb such
excessive amounts of traffic.

28  Firewall DoS Attacks

 Chapter 3: Denial of Service Attack Defenses

Figure 14: Limiting Sessions Based on Source IP Address

Source-Based Session Limiting:

Nimda Virus/Worm Traffic Containment Untrust Zone

A webserver is infected with the Nimda After the number of concurrent sessions
virus/worm hybrid, which causes the server from the infected server reaches the
to generate excessive amounts of traffic. DMZ … maximum limit, the security device
begins blocking all further connection
Zone Infected attempts from that server.
Server

Another benefit of source-based session limiting is that it can mitigate attempts to

fill up the ScreenOS session table (if all the connection attempts originate from the
same source IP address). However, a wily attacker can launch a distributed denial of
service (DDoS) attack. In a DDoS attack, the malicious traffic can come from
hundreds of hosts, known as zombie agents, that are surreptitiously under the
control of an attacker. In addition to the SYN, UDP, and ICMP flood detection and
prevention SCREEN options, setting a destination-based session limit can ensure
that the security device allows only an acceptable number of concurrent connection
requests—no matter what the source—to reach any one host.

Figure 15: Distributed DoS Attack

Source-based session limiting: Destination-based session limiting:

denial of service attack distributed denial of service attack
Attacker Attacker

Nonexistent host
Src IP: 6.6.6.6 Zombie
agents
Untrust Zone Untrust
Zone

DMZ DMZ

Webserver Webserver

When the number of concurrent sessions from 6.6.6.6 When the number of concurrent sessions to the webserver
surpasses the maximum limit, the security device begins surpasses the maximum limit, the security device begins
blocking further connection attempts from that IP address. blocking further connection attempts to that IP address.

Firewall DoS Attacks  29

 Concepts & Examples ScreenOS Reference Guide

Determining what constitutes an acceptable number of connection requests

requires a period of observation and analysis to establish a baseline for typical
traffic flows. You also need to consider the maximum number of concurrent
sessions required to fill up the session table of the particular Juniper Networks
platform you are using. To see the maximum number of sessions that your session
table supports, use the CLI command get session, and then look at the first line in
the output, which lists the number of current (allocated) sessions, the maximum
number of sessions, and the number of failed session allocations:

alloc 420/max 128000, alloc failed 0

The default maximum for both source- and destination-based session limits is 128
concurrent sessions, a value that might need adjustment to suit the needs of your
network environment and the platform.

Example: Source-Based Session Limiting

In this example, you want to limit the amount of sessions that any one server in the
DMZ and Trust zones can initiate. Because the DMZ zone only contains webservers,
none of which should initiate traffic, you set the source-session limit at the lowest
possible value: 1 session. On the other hand, the Trust zone contains personal
computers, servers, printers, and so on, many of which do initiate traffic. For the
Trust zone, you set the source-session limit maximum to 80 concurrent sessions.

WebUI
Screening > Screen (Zone: DMZ): Enter the following, then click OK:

Source IP Based Session Limit: (select)

Threshold: 1 Sessions

Screening > Screen (Zone: Trust): Enter the following, then click OK:

Source IP Based Session Limit: (select)

Threshold: 80 Sessions

CLI
set zone dmz screen limit-session source-ip-based 1
set zone dmz screen limit-session source-ip-based
set zone trust screen limit-session source-ip-based 80
set zone trust screen limit-session source-ip-based
save

Example: Destination-Based Session Limiting

In this example, you want to limit the amount of traffic to a webserver at 1.2.2.5.
The server is in the DMZ zone. After observing the traffic flow from the Untrust
zone to this server for a month, you have determined that the average number of
concurrent sessions it receives is 2000. Based on this information, you decide to set
the new session limit at 4000 concurrent sessions. Although your observations
show that traffic spikes sometimes exceed that limit, you opt for firewall security
over occasional server inaccessibility.

30  Firewall DoS Attacks

 Chapter 3: Denial of Service Attack Defenses

WebUI
Screening > Screen (Zone: Untrust): Enter the following, then click OK:

Destination IP Based Session Limit: (select)

Threshold: 4000 Sessions

CLI
set zone untrust screen limit-session destination-ip-based 4000
set zone untrust screen limit-session destination-ip-based
save

Aggressive Aging
By default, an initial TCP session 3-way handshake takes 20 seconds to time out
(that is, to expire because of inactivity). After a TCP session has been established,
the timeout value changes to 30 minutes. For HTTP and UDP sessions, the session
timeouts are 5 minutes and 1 minute, respectively. The session timeout counter
begins when a session starts and is refreshed every 10 seconds if the session is
active. If a session becomes idle for more than 10 seconds, the timeout counter
begins to decrement.

On certain hardware platforms, ScreenOS provides a mechanism for accelerating

the timeout process when the number of sessions in the session table surpasses a
specified high-watermark threshold. This feature is not available on the high-end
systems.

When the number of sessions dips below a specified low-watermark threshold, the
timeout process returns to normal. During the period when the aggressive aging out
process is in effect, a security device ages out the oldest sessions first, using the
aging out rate that you specify. These aged-out sessions are tagged as invalid and
are removed in the next “garbage sweep,” which occurs every 2 seconds.

The aggressive ageout option shortens default session timeouts by the amount you
enter. When you set and enable the aggressive ageout option, the normal session
timeout value displayed in the configuration remains unchanged—1800 seconds for
TCP, 300 seconds for HTTP, and 60 seconds for UDP sessions. However, when the
aggressive ageout period is in effect, these sessions time out earlier—by the
amount you specify for early ageout—instead of counting down all the way to zero.

The aggressive ageout value can be between 2 and 10 units, where each unit
represents a 10-second interval (that is, the aggressive ageout setting can be
between 20 and 100 seconds). The default setting is 2 units, or 20 seconds. If you
define the aggressive ageout setting at 100 seconds, for example, you shorten the
TCP and HTTP session timeouts as follows:

 TCP: The session timeout value shortens from 1800 seconds (30 minutes) to
1700 seconds (28:20 minutes) during the time when the aggressive aging
process is in effect. During that period, the security device automatically
deletes all TCP sessions whose timeout value has passed 1700 seconds,
beginning with the oldest sessions first.

Firewall DoS Attacks  31

 Concepts & Examples ScreenOS Reference Guide

Figure 16: TCP Session Timeout

Mins 30 25 20 15 10 5 0
Default TCP Session Timeout: 30 Mins (1800 Secs)
Aggressive Ageout = 10 (-100 Secs from Default):
28:20 Mins (1700 Secs) Secs 1800 1500 1200 900 600 300 0

 HTTP: The session timeout value shortens from 300 seconds (5 minutes) to 200
seconds (3:20 minutes) during the time when the aggressive aging process is in
effect. During that period, the security device automatically deletes all HTTP
sessions whose timeout value has passed 200 seconds, beginning with the
oldest sessions first.

Figure 17: HTTP Session Timeout

Mins 5 4 3 2 1 0
Default HTTP Session Timeout: 5 Mins (300 Secs)
Aggressive Ageout = 10 (-100 Secs from Default):
3:20 Mins (200 Secs)
Secs 300 240 180 120 60 0

 UDP: Because the default UDP session timeout is 60 seconds, defining an early
ageout setting at 100 seconds causes all UDP sessions to ageout and be marked
for deletion in the next garbage sweep.

Example: Aggressively Aging Out Sessions

In this example, you set the aggressive aging out process to commence when traffic
exceeds a high-watermark of 80 percent and cease when it retreats below a
low-watermark of 70 percent. You specify 40 seconds for the aggressive age-out
interval. When the session table is more than 80 percent full (the high-mark
threshold), the security device decreases the timeout for all sessions by 40 seconds
and begins aggressively aging out the oldest sessions until the number of sessions
in the table is under 70 percent (the low-mark threshold).

Figure 18: Aging Out Sessions Aggressively

100%
When the number of sessions exceeds 80% capacity,
the aggressive aging mechanism commences.
80% High-Watermark
Aggressive Aging
(- 40-sec age out)
70% Low-Watermark
Sessions aggressively age out until their
number drops below 70%. At that point, the
Sessions aggressive aging mechanism ceases.

0%

WebUI

NOTE: You must use the CLI to configure the aggressive age-out settings.

32  Firewall DoS Attacks

 Chapter 3: Denial of Service Attack Defenses

CLI
set flow aging low-watermark 70
set flow aging high-watermark 80
set flow aging early-ageout 4
save

CPU Protection with Blacklisting DoS Attack Traffic

When a DoS attack occurs, the CPU recognizes the attack traffic and drops it. This
can cause high CPU utilization and might make the security device drop all packets,
including critical traffic such as management traffic. To prevent this, you can
configure the security device to drop malicious packets within the device itself that
processes them, after the CPU has recognized malicious traffic. In this mechanism,
you create a blacklist of IP addresses from which malicious traffic reaches the
security device, based on which the CPU instructs the device to drop the traffic. This
saves significant processing load on the CPU during DoS attacks.

NOTE: The blacklist protection feature is not available for the following traffic conditions:

 IPV6 traffic

 IPV4 traffic when IPv6 is set as environment variable

 Traffic that has hardware session enabled

When a packet reaches the device, the packet processing hardware checks the
packet against the list of blacklist entries. If a match occurs, the device drops that
packet. If the packet does not match any blacklist entry, the device passes the
packet to the next stage that prioritizes the packet. For each entry in the blacklist,
the security device maintains a drop counter to record the number of packets
dropped against that entry.

The blacklist protection mechanism applies to the entire security device and is not
limited to specific virtual systems that you may have created on the security device.
In security devices that support virtual systems but do not support blacklist
creation, CPU protection features such as rate limiting apply.

Creating a Blacklist
To implement blacklisting of DoS attack traffic, you create a blacklist. The security
device CPU screens the traffic that reaches it and determines if a flow matches a
DoS attack pattern. If a packet matches the blacklist entry, the device drops the
packet.

You can set the timeout value for each of the blacklist entries. To permanently block
specific traffic that has been identified as DoS attack traffic, set the timeout value
for that blacklist entry to 0.

Firewall DoS Attacks  33

 Concepts & Examples ScreenOS Reference Guide

You create the blacklist with the following information:

Field Description
Source IP Address The source IP address from which the DoS attack traffic originated
Destination IP Address The destination IP address.
Source Port The source port in a TCP or UDP session. Setting this to 0 matches all
ports
Destination Port The destination port in a TCP or UDP session. Setting this to 0 matches
all ports.
Protocol Set this to 0 to match any protocol. The source port and destination port
are valid only when you have set the protocol as UDP or TCP
Source IP Address Range is 0–32. Setting this to 0 matches all source IP addresses.
Mask
Destination IP Mask Range is 0–32. Setting this to 0 matches all destination IP addresses.
Blacklist ID The ID of the blacklists. Range is 0–31.
Timeout The time out for the blacklist entry in the range 0 to 600 minutes. If you
set the timeout for a blacklist entry to 0, the security device never times
out that entry. The security device saves only the permanent entries in
the blacklist configuration.

Example
In this example, you create a blacklist entry that times out after 90 minutes.

WebUI
Configuration > CPU Protection > Black List > New: Enter the following, then click
OK:
ID: 1
Source IP/Netmask: 1.1.1.0/24
Source Port: 5
Destination IP/Netmask : 2.2.2.0/24
Destination Port: 7
Protocol: 17
Timeout: 90

CLI
set cpu-protection blacklist id 1 1.1.1.0/24 2.2.2.0/24 protocol 17 src-port 5
dst-port 7 timeout 90

save

NOTE: You cannot create a blacklist entry with the source IP address mask, the
destination IP address mask, and the protocol values set to 0.

34  Firewall DoS Attacks

 Chapter 3: Denial of Service Attack Defenses

Prioritizing Critical Traffic

In addition to dropping the malicious packets in the device, this mechanism
provides prioritizing of traffic in high CPU utilization situations so that the security
device allows critical traffic such as management traffic and drops noncritical
traffic. For this mechanism to function, you configure a utilization threshold on the
CPU. During a high-utilization situation, this mechanism compares the current CPU
utilization with the threshold value you have set, and then prioritizes the critical
traffic. This can cause the security device to drop noncritical traffic.

.
Type Class Protocol
Critical 1 TELNET—device management
SSH—device management
HTTP/HTTPS—device management
BGP—routing protocol updates
OSPF—routing protocol updates
RIP—routing protocol updates
RIPNG—routing protocol updates
PIM—multicast routing protocol updates
NSRP—NSRP updates
IKE/VPN Monitor—tunnel setup and VPN Monitor packets
ARP—ARP responses, so that the device can move the session to
hardware
RADIUS—authentication protocol
LDAP—authentication protocol
SNMP/SNMP traps—SNMP updates
NSM—communication with the NetScreen-Security Manager application
TFTP—Trivial File Transfer Protocol
ICMP—Internet Control Message Protocol
Noncritical 2 Broadcast
3 Non-first packet
4 First packet
5 Other

WebUI
Configuration > CPU Protection > General Settings: Enter the CPU Protection
Threshold, then click Apply:

CLI
set cpu-protection threshold number
save

The following table shows the traffic statistics of the get cpu-protection command
when the threshold is set to 70 percent.

Firewall DoS Attacks  35

 Concepts & Examples ScreenOS Reference Guide

Current usage: 80% High CPU threshold: 70%

Class Traffic Dropped Passed

1 Critical 0 16
2 ICMP/BC/ARP 3 6
3 Non-first 0 7
4 First 0 3
5 Other 1 2

SYN-ACK-ACK Proxy Flood

When an authentication user initiates a Telnet or FTP connection, the user sends a
SYN segment to the Telnet or FTP server. The security device intercepts the SYN
segment, creates an entry in its session table, and proxies a SYN-ACK segment to
the user. The user then replies with an ACK segment. At that point, the initial
three-way handshake is complete. The device sends a login prompt to the user. If
the user, with malicious intent, does not log in, but instead continues initiating
SYN-ACK-ACK sessions, the ScreenOS session table can fill up to the point where the
device begins rejecting legitimate connection requests.

See Figure 19 for a step-by-step process:

1. The client sends a SYN segment to the server.

2. The security device proxies a SYN/ACK segment.

3. The client responds with an ACK segment.

4. The security device prompts the client (auth user) to log in.

5. The client ignores the login prompt and keeps repeating steps 1—4 until the
session table is full.

6. Because the session table is full, the security device must reject all further
connection requests.

36  Firewall DoS Attacks

 Chapter 3: Denial of Service Attack Defenses

Figure 19: SYN-ACK-ACK Proxy Flood

Telnet or FTP Client

(Authentication User) Telnet or FTP
Untrust Zone Trust Zone Server

SYN

SYN/ACK ScreenOS session table:

Extensive available resources.
ACK

Name: ?
Password: ?

SYN
SYN/ACK
ACK The session table is filling up.
Name: ?
Password: ?
.
.
.
SYN The session table is full.

To prevent such an attack, you can enable the SYN-ACK-ACK proxy protection
SCREEN option. After the number of connections from the same IP address reaches
the SYN-ACK-ACK proxy threshold, the security device rejects further connection
requests from that IP address. By default, the threshold is 512 connections from any
single IP address. You can change this threshold (to any number between 1 and
250,000) to better suit the requirements of your network environment.

NOTE: The alarm-without-drop option does not apply to this SCREEN option. For more
information about this option, see “Exploit Monitoring” on page 5.

To enable protection against a SYN-ACK-ACK proxy flood, do either of the following,

where the specified zone is that in which the attack originates:

WebUI
Screening > Screen (Zone: select a zone name): Enter the following, then click
Apply:

SYN-ACK-ACK Proxy Protection: (select)

Threshold: (enter a value to trigger SYN-ACK-ACK proxy flood protection)

NOTE: The value unit is connections per source address. The default value is 512
connections from any single address.

CLI
set zone zone screen syn-ack-ack-proxy threshold number
set zone zone screen syn-ack-ack-proxy

Firewall DoS Attacks  37

 Concepts & Examples ScreenOS Reference Guide

Network DoS Attacks

A denial of service (DoS) attack directed against one or more network resources
floods the target with an overwhelming number of SYN, ICMP, or UDP packets, or
with an overwhelming number of SYN fragments. Depending on the attacker’s
purpose and the extent and success of previous intelligence gathering efforts, the
attacker might single out a specific host, such as a router or server; or he or she
might aim at random hosts across the targeted network. Either approach has the
potential of upsetting service to a single host or to the entire network, depending on
how critical the role of the victim is to the rest of the network.

SYN Flood
A SYN flood occurs when a host becomes so overwhelmed by SYN segments
initiating incomplete connection requests that it can no longer process legitimate
connection requests.

Two hosts establish a TCP connection with a triple exchange of packets known as a
three-way handshake: A sends a SYN segment to B; B responds with a SYN/ACK
segment; and A responds with an ACK segment. A SYN flood attack inundates a site
with SYN segments containing forged (spoofed) IP source addresses with
nonexistent or unreachable addresses. B responds with SYN/ACK segments to these
addresses and then waits for responding ACK segments. Because the SYN/ACK
segments are sent to nonexistent or unreachable IP addresses, they never elicit
responses and eventually time out.

Figure 20: SYN Flood Attack

Host at 2.2.2.5 sends SYN segments in IP If a policy permits the inbound traffic, the security device permits the
Actual packets with spoofed source addresses. SYN segments. The victim responds by sending SYN/ACK segments to
IP Address the spoofed source IP address and waits for a response until the effort
2.2.2.5 times out.
Nonexistent or
Unreachable IP
Addresses
3.3.3.5
SYN
Protected
SYN/ACK LAN
4.4.4.20
SYN

SYN/ACK
5.5.5.10
SYN The memory buffer
in the victim begins
SYN/ACK filling up.
6.6.6.3
SYN

SYN/ACK

By flooding a host with incomplete TCP connections, the attacker eventually fills the
memory buffer of the victim. Once this buffer is full, the host can no longer process
new TCP connection requests. The flood might even damage the victim’s operating
system. Either way, the attack disables the victim and its normal operations.

38  Network DoS Attacks

 Chapter 3: Denial of Service Attack Defenses

SYN Flood Protection

Juniper Networks security devices can impose a limit on the number of SYN
segments permitted to pass through the firewall per second. You can base the
attack threshold on the destination address and port, the destination address only,
or the source address only. When the number of SYN segments per second exceeds
one of these thresholds, the security device starts proxying incoming SYN
segments, replying with SYN/ACK segments and storing the incomplete connection
requests in a connection queue. The incomplete connection requests remain in the
queue until the connection is completed or the request times out. In Figure 21, the
SYN attack threshold has been passed, and the device has started proxying SYN
segments.

Figure 21: Proxying SYN Segments

Actual IP Address Host at 2.2.2.5 continues sending SYN segments in
2.2.2.5 IP packets with the spoofed source addresses.
Nonexistent or
Unreachable
IP Addresses
7.7.7.11 SYN Protected
LAN
SYN/ACK

8.8.8.8 SYN

SYN/ACK
The memory buffer in the
9.9.9.22 victim stops filling up.
— SYN Attack Threshold —
2.2.2.4
SYN
When the number of SYN
SYN/ACK segments from the same source
address or to the same
3.3.3.25 SYN destination address reaches a The proxied connection
specified threshold, the security queue in the security
SYN/ACK device begins intercepting the device begins filling up.
connection requests and proxying
. the SYN/ACK segments.
.
.

In Figure 22, the proxied connection queue has completely filled up, and the
security device is rejecting new incoming SYN segments. This action shields hosts
on the protected network from the bombardment of incomplete three-way
handshakes.

Network DoS Attacks  39

 Concepts & Examples ScreenOS Reference Guide

Figure 22: Rejecting New SYN Segments

Actual IP Address Host at 2.2.2.5 continues sending SYN segments in

2.2.2.5 IP packets with the spoofed source address 3.3.3.5.
Security device
Protected
Nonexistent or LAN
Unreachable
IP Address
3.3.3.5 — SYN Attack Threshold —

SYN
The security device intercepts the The memory buffer in the
SYN/ACK SYN segments and proxies the victim returns to normal.
SYN/ACK responses until the
proxied connection queue fills up.
SYN
The proxied connection
SYN/ACK queue in the security
device is full.
— Alarm Threshold —

. The security device enters an

. alarm in the event log.
.
— Maximum Limit of the Proxied Connection Queue —

The security device rejects new

SYN segments from all addresses
in the same security zone.
SYN

SYN segment from a different

address in the same security zone.

The security device starts receiving new SYN packets when the proxy queue drops
below the maximum limit.

NOTE: The procedure of proxying incomplete SYN connections above a set threshold
pertains only to traffic permitted by existing policies. Any traffic for which a policy
does not exist is automatically dropped.

40  Network DoS Attacks

 Chapter 3: Denial of Service Attack Defenses

By default, the SYN Flood protection SCREEN option is enabled on the Untrust
zone. To enable the SYN Flood protection SCREEN option and define its parameters,
do either of the following, where the specified zone is that in which a SYN flood
might originate:

WebUI
Screening > Screen (Zone: select a zone name): Enter the following, then click
Apply:

SYN Flood Protection: (select to enable)

Threshold: (enter the number of SYN packets—that is, TCP segments with
the SYN flag set—per second required to activate the SYN proxying
mechanism)

Alarm Threshold: (enter the number of proxied TCP connection requests

required to write an alarm in the event log)

Source Threshold: (enter the number of SYN packets per second from a
single IP address required for the security device to begin rejecting new
connection requests from that source)
Destination Threshold: (enter the number of SYN packets per second to a
single IP address required for the security device to begin rejecting new
connection requests to that destination)

Timeout Value: (enter the length of time in seconds that the security
device holds an incomplete TCP connection attempt in the proxied
connection queue)

Queue Size: (enter the number of proxied TCP connection requests held in
the proxied connection queue before the security device starts rejecting
new connection requests)

NOTE: For more details about each of these parameters, see the descriptions in the
following CLI section.

CLI
To enable SYN Flood protection:

set zone zone screen syn-flood

You can set the following parameters for proxying uncompleted TCP connection
requests:

 Attack Threshold: The number of SYN segments (that is, TCP segments with
the SYN flag set) to the same destination address and port number per second
required to activate the SYN proxying mechanism. Although you can set the
threshold at any number, you need to know the normal traffic patterns at your
site to set an appropriate threshold for it. For example, if it is an e-business site
that normally gets 2000 SYN segments per second, you might want to set the
threshold at 3000/second. If a smaller site normally gets 20 SYN
segments/second, you might consider setting the threshold at 40.

set zone zone screen syn-flood attack-threshold number

Network DoS Attacks  41

 Concepts & Examples ScreenOS Reference Guide

 Alarm Threshold: The number of proxied, half-complete TCP connection

requests per second after which the security device enters an alarm in the
event log. The value you set for an alarm threshold triggers an alarm when the
number of proxied, half-completed connection requests to the same
destination address and port number per second exceeds that value. For
example, if you set the SYN attack threshold at 2000 SYN segments per second
and the alarm at 1000, then a total of 3001 SYN segments to the same
destination address and port number per second is required to trigger an alarm
entry in the log. More precisely:

1. The firewall passes the first 2000 SYN segments per second that meet
policy requirements.

2. The firewall proxies the next 1000 SYN segments in the same second.

3. The 1001st proxied connection request (or 3001st connection request in

that second) triggers the alarm.

set zone zone screen syn-flood alarm-threshold number

For each SYN segment to the same destination address and port number in
excess of the alarm threshold, the attack detection module generates a
message. At the end of the second, the logging module compresses all similar
messages into a single log entry that indicates how many SYN segments to the
same destination address and port number arrived after exceeding the alarm
threshold. If the attack persists beyond the first second, the event log enters an
alarm every second until the attack stops.

 Source Threshold: This option allows you to specify the number of SYN
segments received per second from a single source IP address—regardless of
the destination IP address and port number—before the security device begins
dropping connection requests from that source.

set zone zone screen syn-flood source-threshold number

Tracking a SYN flood by source address uses different detection parameters

from tracking a SYN flood by destination address and destination port number.
When you set a SYN attack threshold and a source threshold, you put both the
basic SYN flood protection mechanism and the source-based SYN flood
tracking mechanism in effect.

 Destination Threshold: This option allows you to specify the number of SYN
segments received per second for a single destination IP address before the
security device begins dropping connection requests to that destination. If a
protected host runs multiple services, you might want to set a threshold based
on destination IP address only—regardless of the destination port number.

set zone zone screen syn-flood destination-threshold number

When you set a SYN attack threshold and a destination threshold, you put both
the basic SYN flood protection mechanism and the destination-based SYN flood
tracking mechanism in effect.

42  Network DoS Attacks

 Chapter 3: Denial of Service Attack Defenses

Tracking a SYN flood by destination address uses different detection

parameters from tracking a SYN flood by destination address and destination
port number. Consider the following case where the security device has policies
permitting FTP requests (port 21) and HTTP requests (port 80) to the same
server. If the SYN flood attack threshold is 1000 packets per second (pps) and
an attacker sends 999 FTP packets and 999 HTTP packets per second, neither
set of packets (where a set is defined as having the same destination address
and port number) activates the SYN proxying mechanism. The basic SYN flood
attack mechanism tracks destination address and port number, and neither set
exceeds the attack threshold of 1000 pps. However, if the destination threshold
is 1000 pps, the device treats both FTP and HTTP packets with the same
destination address as members of a single set and rejects the 1001st
packet—FTP or HTTP—to that destination.

 Timeout: The maximum length of time before a half-completed connection is

dropped from the queue. The default is 20 seconds, and you can set the
timeout from 0–50 seconds. You might try decreasing the timeout value to a
shorter length until you begin to see any dropped connections during normal
traffic conditions. Twenty seconds is a very conservative timeout for a
three-way handshake ACK response.

set zone zone screen syn-flood timeout number

 Queue size: The number of proxied connection requests held in the proxied
connection queue before the security device starts rejecting new connection
requests. The longer the queue size, the longer the device needs to scan the
queue to match a valid ACK response to a proxied connection request. This can
slightly slow the initial connection establishment; however, because the time to
begin data transfer is normally far greater than any minor delays in initial
connection setup, users would not see a noticeable difference.

set zone zone screen syn-flood queue-size number

 Drop Unknown MAC: When a security device detects a SYN attack, it proxies
all TCP connection requests. However, a device in Transparent mode cannot
proxy a TCP connection request if the destination MAC address is not in its MAC
learning table. By default, a device in Transparent mode that has detected a
SYN attack passes SYN packets containing unknown MAC addresses. You can
use this option to instruct the device to drop SYN packets containing unknown
destination MAC addresses instead of letting them pass.

set zone zone screen syn-flood drop-unknown-mac

Network DoS Attacks  43

 Concepts & Examples ScreenOS Reference Guide

Example: SYN Flood Protection

In this example, you protect four webservers in the DMZ zone from SYN flood
attacks originating in the Untrust zone by enabling the SYN flood protection
SCREEN option for the Untrust zone.

NOTE: We recommend that you augment the SYN flood protection that the security
device provides with device-level SYN flood protection on each of the webservers.
In this example, the webservers are running UNIX, which also provides some SYN
flood defenses, such as adjusting the length of the connection request queue and
changing the timeout period for incomplete connection requests.

Figure 23: Device-Level SYN Flood Protection

ethernet3 ethernet2 Webservers
1.1.1.1/24 1.2.2.1/24

Untrust Zone 1.2.2.10

Security device 1.2.2.20

DMZ Zone
Internet
HTTP 1.2.2.30
SYN Flood
1.2.2.40
Firewall

To configure the SYN flood protection parameters with appropriate values for your
network, you must first establish a baseline of typical traffic flows. For one week,
you run a sniffer on ethernet3—the interface bound to the Untrust zone—to
monitor the number of new TCP connection requests arriving every second for the
four webservers in the DMZ. Your analysis of the data accumulated from one week
of monitoring produces the following statistics:

 Average number of new connection requests per server: 250/second

 Average peak number of new connection requests per server: 500/second

NOTE: A sniffer is a network-analyzing device that captures packets on the network

segment to which you attach it. Most sniffers allow you to define filters to collect
only the type of traffic that interests you. Later, you can view and evaluate the
accumulated information. In this example, you want the sniffer to collect all TCP
packets with the SYN flag set arriving at ethernet3 and destined for one of the four
webservers in the DMZ.

You might want to continue running the sniffer at regular intervals to see if there
are traffic patterns based on the time of day, days of the week, the time of month,
or the season of the year. For example, in some organizations, traffic might
increase dramatically during a critical event. Significant changes probably warrant
adjusting the various thresholds.

44  Network DoS Attacks

 Chapter 3: Denial of Service Attack Defenses

Based on this information, you set the following SYN flood protection parameters
for the Untrust zone, as shown in Table 2.

Table 2: SYN Flood Protection Parameters

Parameter Value Reason for Each Value

Attack 625 packets This is 25% higher than the average peak number of new connection requests per second per
Threshold per second server, which is unusual for this network environment. When the number of SYN packets per
(pps) second for any one of the four webservers exceeds this number, the device begins proxying
new connection requests to that server. (In other words, beginning with the 626th SYN packet
to the same destination address and port number in one second, the device begins proxying
connection requests to that address and port number.)
Alarm 250 pps 250 pps is 1/4 of the queue size (1000 proxied, half-completed connection requests1). When
Threshold the device proxies 251 new connection requests in one second, it makes an alarm entry in the
event log. By setting the alarm threshold somewhat higher than the attack threshold, you can
avoid alarm entries for traffic spikes that only slightly exceed the attack threshold.
Source 25 pps When you set a source threshold, the device tracks the source IP address of SYN packets,
Threshold regardless of the destination address and port number. (Note that this source-based tracking is
separate from the tracking of SYN packets based on destination address and destination port
number that constitutes the basic SYN flood protection mechanism.)
In the one week of monitoring activity, you observed that no more than 1/25 of new connection
requests for all servers came from any one source within a one-second interval. Therefore,
connection requests exceeding this threshold are unusual and provide sufficient cause for the
device to execute its proxying mechanism. (25 pps is 1/25 of the attack threshold, which is 625
pps.)
If the device tracks 25 SYN packets from the same source IP address, beginning with the 26th
packet, it rejects all further SYN packets from that source for the remainder of that second and
the next second as well.
Destination 0 pps When you set a destination threshold, the device runs a separate tracking of only the
Threshold destination IP address, regardless of the destination port number. Because the four webservers
only receive HTTP traffic (destination port 80)—no traffic to any other destination port number
reaches them—setting a separate destination threshold offers no additional advantage.
Timeout 20 seconds Because the queue size is relatively short (1000 proxied connection requests), the default value
of 20 seconds is a reasonable length of time to hold incomplete connection requests in the
queue for this configuration.
Queue Size 1000 proxied, 1000 proxied, half-completed connection requests is twice the average peak number of new
half-completed connection requests (500 pps). The device proxies up to 1000 requests per second before
connections dropping new requests. Proxying twice the average peak number of new connection requests
provides a conservative buffer for legitimate connection requests to get through.

1.Half-completed connection requests are incomplete three-way handshakes. A three-way handshake is the initial phase of a
TCP connection. It consists of a TCP segment with the SYN flag set, a response with the SYN and ACK flags set, and a response
to that with the ACK flag set.

Network DoS Attacks  45

 Concepts & Examples ScreenOS Reference Guide

WebUI
1. Interfaces
Network > Interfaces > Edit (for ethernet2): Enter the following, then click
OK:

Zone Name: DMZ

Static IP: (select this option when present)
IP Address/Netmask: 1.2.2.1/24

Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:

Zone Name: Untrust

Static IP: (select this option when present)
IP Address/Netmask: 1.1.1.1/24
2. Addresses
Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: ws1

IP Address/Domain Name:
IP/Netmask: (select), 1.2.2.10/32
Zone: DMZ

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: ws2

IP Address/Domain Name:
IP/Netmask: (select), 1.2.2.20/32
Zone: DMZ

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: ws3

IP Address/Domain Name:
IP/Netmask: (select), 1.2.2.30/32
Zone: DMZ

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: ws4

IP Address/Domain Name:
IP/Netmask: (select), 1.2.2.40/32
Zone: DMZ

Policy > Policy Elements > Addresses > Groups > (for Zone: DMZ) New:
Enter the following group name, move the following addresses, then click OK:

Group Name: web_servers

Select ws1 and use the << button to move the address from the Available
Members column to the Group Members column.

46  Network DoS Attacks

 Chapter 3: Denial of Service Attack Defenses

Select ws2 and use the << button to move the address from the Available
Members column to the Group Members column.

Select ws3 and use the << button to move the address from the Available
Members column to the Group Members column.

Select ws4 and use the << button to move the address from the Available
Members column to the Group Members column.

3. Policy
Policies > (From: Untrust, To: DMZ) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), Any
Destination Address:
Address Book Entry: (select), web_servers
Service: HTTP
Action: Permit
4. Screen
Screening > Screen (Zone: Untrust): Enter the following, then click Apply:

SYN Flood Protection: (select)

Threshold: 625
Alarm Threshold: 250
Source Threshold: 25
Destination Threshold: 0
Timeout Value: 20
Queue Size: 1000

NOTE: Because 20 seconds is the default setting, you do not have to set the timeout to 20
seconds unless you have previously set it to another value.

CLI
1. Interfaces
set interface ethernet2 zone dmz
set interface ethernet2 ip 1.2.2.1/24
set interface ethernet3 zone untrust
set interface ethernet3 ip 1.1.1.1/24
2. Addresses
set address dmz ws1 1.2.2.10/32
set address dmz ws2 1.2.2.20/32
set address dmz ws3 1.2.2.30/32
set address dmz ws4 1.2.2.40/32
set group address dmz web_servers add ws1
set group address dmz web_servers add ws2
set group address dmz web_servers add ws3
set group address dmz web_servers add ws4
3. Policy
set policy from untrust to dmz any web_servers HTTP permit

Network DoS Attacks  47

 Concepts & Examples ScreenOS Reference Guide

4. Screen
set zone untrust screen syn-flood attack-threshold 625
set zone untrust screen syn-flood alarm-threshold 250
set zone untrust screen syn-flood source-threshold 25
set zone untrust screen syn-flood timeout 20
set zone untrust screen syn-flood queue-size 1000
set zone untrust screen syn-flood
save

NOTE: Because 20 seconds is the default setting, you do not have to set the timeout to 20
seconds unless you have previously set it to another value.

SYN Cookie
SYN Cookie is a stateless SYN Proxy mechanism you can use in conjunction with
the defenses against a SYN Flood attack described in “SYN Flood” on page 38. Like
traditional SYN proxying, SYN Cookie is activated when the SYN Flood attack
threshold is exceeded, but because SYN Cookie is stateless, it does not set up a
session or do policy and route lookups upon receipt of a SYN segment, and
maintains no connection request queues. This dramatically reduces CPU and
memory usage and is the primary advantage of using SYN Cookie over the
traditional SYN proxying mechanism.

When SYN Cookie is enabled on the security device and becomes the
TCP-negotiating proxy for the destination server, it replies to each incoming SYN
segment with a SYN/ACK containing an encrypted cookie as its Initial Sequence
Number (ISN). The cookie is a MD5 hash of the original source address and port
number, destination address and port number, and ISN from the original SYN
packet. After sending the cookie, the device drops the original SYN packet and
deletes the calculated cookie from memory. If there is no response to the packet
containing the cookie, the attack is noted as an active SYN attack and is effectively
stopped.

If the initiating host responds with a TCP packet containing the cookie +1 in the
TCP ACK field, the device extracts the cookie, subtracts 1 from the value, and
recomputes the cookie to validate that it is a legitimate ACK. If it is legitimate, the
device starts the TCP proxy process by setting up a session and sending a SYN to
the server containing the source information from the original SYN. When the
device receives a SYN/ACK from the server, it sends ACKs to the sever and to the
initiation host. At this point the connection is established and the host and server
are able to communicate directly.

48  Network DoS Attacks

 Chapter 3: Denial of Service Attack Defenses

Figure 24 shows how a connection is established between an initiating host and a

server when SYN Cookie is active on the security device.

Figure 24: Establishing a Connection with SYN Cookie Active

Security device
TCP Host TCP Server

1 SYN
1. Session lookup -- No session match
2. SYN Cookie triggered
3. Calculate ISN
4. Send SYN/ACK back to host
2 SYN/ACK
Send ACK

3 ACK
1. Session lookup -- No session match
2. SYS Cookie validated
3. Restore MSS
4. First packet passed--routing,
policy lookup, session setup
5. Send SYN to the server
4 SYN
1. Accept connection
2. Send SYN/ACK
55 SYN/ACK

Send ACK to both ends

7 ACK 6 ACK
Connected

8 Data/ACK

Data/ACK
9

To enable SYN Cookie, set a SYN flood attack threshold (as described in “SYN
Flood” on page 38), and do one of the following:

WebUI
Configuration > Advanced > Flow: Enter the following, then click Apply:

TCP SYN-proxy SYN-cookie: (select)

CLI
set flow syn-proxy syn-cookie

Network DoS Attacks  49

 Concepts & Examples ScreenOS Reference Guide

ICMP Flood
An ICMP flood typically occurs when ICMP echo requests overload its victim with so
many requests that it expends all its resources responding until it can no longer
process valid network traffic. When enabling the ICMP flood protection feature, you
can set a threshold that once exceeded invokes the ICMP flood attack protection
feature. (The default threshold value is 1000 packets per second.) If the threshold is
exceeded, the security device ignores further ICMP echo requests for the remainder
of that second plus the next second as well.

NOTE: An ICMP flood can consist of any type of ICMP message. Therefore, a Juniper
Networks security device monitors all ICMP message types, not just echo requests.

Figure 25: ICMP Flooding

The attacker sends ICMP echo requests The security device passes the echo
with spoofed source addresses. requests only if a policy permits them.

Echo Request Protected

LAN
ICMP echo Echo Reply
requests from a
variety of spoofed Echo Request
IP addresses
Echo Reply

Echo Request

Echo Reply
.
.
.
— Maximum Limit of ICMP Echo Requests per Second —

Echo Request After the ICMP threshold is

reached, the security device
rejects further ICMP echo
requests from all addresses in
Echo Request the same security zone for the
remainder of the current second
and the next second as well.
Legitimate ICMP echo request from an
address in the same security zone

To enable ICMP flood protection, do either of the following, where the specified
zone is that in which a flood might originate:

WebUI
Screening > Screen (Zone: select a zone name): Enter the following, then click
Apply:

ICMP Flood Protection: (select)

Threshold: (enter a value to trigger ICMP flood protection)

NOTE: The value unit is ICMP packets per second. The default value is 1000 packets per
second.

50  Network DoS Attacks

 Chapter 3: Denial of Service Attack Defenses

CLI
set zone zone screen icmp-flood threshold number
set zone zone screen icmp-flood

UDP Flood
Similar to the ICMP flood, UDP flooding occurs when an attacker sends IP packets
containing UDP datagrams with the purpose of slowing down the victim to the
point that it can no longer handle valid connections. After enabling the UDP flood
protection feature, you can set a threshold that, once exceeded, invokes the UDP
flood attack protection feature. (The default threshold value is 1000 packets per
second.) If the number of UDP datagrams from one or more sources to a single
destination exceeds this threshold, the security device ignores further UDP
datagrams to that destination for the remainder of that second plus the next second
as well.

Figure 26: UDP Flooding

The attacker sends UDP datagrams in IP The security device passes the UDP
packets with spoofed source addresses. datagrams only if a policy permits them.

Protected LAN
UDP Datagram DNS Server
UDP datagrams The datagrams are IP: 1.2.2.5
inside IP packets targeting a DNS
from a variety of Port: 53 (UDP)
server at 1.2.2.5:53.
spoofed IP UDP Datagram
addresses

UDP Datagram

— Maximum Limit of UDP Datagrams per Second —

UDP Datagram After the UDP flood threshold is

reached, the security device
rejects further UDP datagrams
from all addresses in the same
UDP Datagram security zone for the remainder of
the current second and the next
second as well.
Legitimate UDP datagram from an
address in the same security zone

To enable UDP flood protection, do either of the following, where the specified zone
is that in which a flood might originate:

Network DoS Attacks  51

 Concepts & Examples ScreenOS Reference Guide

WebUI
Screening > Screen (Zone: select a zone name): Enter the following, then click
Apply:

UDP Flood Protection: (select)

Threshold: (enter a value to trigger UDP flood protection)

NOTE: The value unit is UDP packets per second. The default value is 1000 packets per
second.

CLI
set zone zone screen udp-flood threshold number
set zone zone screen udp-flood

Land Attack
Combining a SYN attack with IP spoofing, a land attack occurs when an attacker
sends spoofed SYN packets containing the IP address of the victim as both the
destination and source IP address. The receiving system responds by sending the
SYN-ACK packet to itself, creating an empty connection that lasts until the idle
timeout value is reached. Flooding a system with such empty connections can
overwhelm the system, causing a denial of service.

Figure 27: Land Attack

Attacker Both the source and destination Victim

addresses are those of the victim.
The source address in the IP header The victim creates empty
is spoofed, while the true source connections with itself.
address remains hidden.
Source Destination

1.2.2.5 1.2.2.5 Data

The victim’s
Source Destination available resources

1.2.2.5 1.2.2.5 Data

The empty
connections are
consuming the
Source Destination victim’s resources.

1.2.2.5 1.2.2.5 Data

All resources are

consumed, which
inhibits normal
operations.

When you enable the SCREEN option to block land attacks, the security device
combines elements of the SYN flood defense and IP spoofing protection to detect
and block any attempts of this nature.

52  Network DoS Attacks

 Chapter 3: Denial of Service Attack Defenses

To enable protection against a land attack, do either of the following, where the
specified zone is that in which the attack originates:

WebUI
Screening > Screen (Zone: select a zone name): Select Land Attack Protection,
then click Apply.

CLI
set zone zone screen land

OS-Specific DoS Attacks

If an attacker not only identifies the IP address and responsive port numbers of an
active host but also its operating system (OS), instead of resorting to brute-force
attacks, he or she can launch more elegant attacks that can produce one-packet or
two-packet kills. The attacks presented in this section can cripple a system with
minimum effort. If your Juniper Networks security device is protecting hosts
susceptible to these attacks, you can enable the security device to detect these
attacks and block them before they reach their target.

Ping of Death
The maximum allowable IP packet size is 65,535 bytes, including the packet
header, which is typically 20 bytes long. An ICMP echo request is an IP packet with
a pseudo header, which is 8 bytes long. Therefore, the maximum allowable size of
the data area of an ICMP echo request is 65,507 bytes (65,535 - 20 - 8 = 65,507).

However, many ping implementations allow the user to specify a packet size larger
than 65,507 bytes. A grossly oversized ICMP packet can trigger a range of adverse
system reactions such as denial of service (DoS), crashing, freezing, and rebooting.

When you enable the Ping of Death SCREEN option, the security device detects and
rejects such oversized and irregular packet sizes even when the attacker hides the
total packet size by purposefully fragmenting it.

NOTE: For information about IP specifications, refer to RFC 791, Internet Protocol.

For information about ICMP specifications, refer to RFC 792, Internet Control
Message Protocol.

For information about ping of death attacks, see

http://insecure.org/sploits/ping-o-death-html

Figure 28: Ping of Death

20 Bytes 8 Bytes 65,510 Bytes
Original,
ICMP
Unfragmented IP Header ICMP Data
Header
Packet

The size of this packet is 65,538 bytes. It exceeds the size limit prescribed by RFC 791, Internet
Protocol, which is 65,535 bytes. As the packet is transmitted, it becomes broken into numerous
fragments. The reassembly process might cause the receiving system to crash.

OS-Specific DoS Attacks  53

 Concepts & Examples ScreenOS Reference Guide

To enable protection against a ping of death attack, do either of the following,

where the specified zone is that in which the attack originates:

WebUI
Screening > Screen (Zone: select a zone name): Select Ping of Death Attack
Protection, then click Apply.

CLI
set zone zone screen ping-death

Teardrop Attack
Teardrop attacks exploit the reassembly of fragmented IP packets. In the IP header,
one of the fields is the fragment offset field, which indicates the starting position, or
offset, of the data contained in a fragmented packet relative to the data of the
original unfragmented packet.

Figure 29: Teardrop Attacks

The security device checks for
IP Header discrepancies in the fragment offset field.

Header
Version Type of Service Total Packet Length (in Bytes)
Length
Identification x D M Fragment Offset
20
Time to Live (TTL) Protocol Header Checksum Bytes
Source Address

Destination Address

Options (if any)

Payload

When the sum of the offset and size of one fragmented packet differ from that of
the next fragmented packet, the packets overlap, and the server attempting to
reassemble the packet can crash, especially if it is running an older operating
system that has this vulnerability.

Figure 30: Fragment Discrepancy

20 Bytes 800 Bytes

Fragmented
IP Header Data
Packet #1
Offset = 0
Length = 820
More Fragments = 1
The second fragment purports to begin
20 Bytes 600 Bytes 20 bytes earlier (at 800) than the first
Fragmented fragment ends (at 820). The offset of
IP Header Data fragment #2 is not in accord with the
Packet #2
packet length of fragment #1. This
Offset = 800 discrepancy can cause some systems to
Length = 620 crash during the reassembly attempt.
More Fragments = 0

54  OS-Specific DoS Attacks

 Chapter 3: Denial of Service Attack Defenses

After you enable the Teardrop Attack SCREEN option, whenever the device detects
this discrepancy in a fragmented packet, it drops it.

To enable protection against a Teardrop attack, do either of the following, where the
specified zone is that in which the attack originates:

WebUI
Screening > Screen (Zone: select a zone name): Select Teardrop Attack
Protection, then click Apply.

CLI
set zone zone screen tear-drop

WinNuke
WinNuke is a DoS attack targeting any computer on the Internet running Windows.
The attacker sends a TCP segment—usually to NetBIOS port 139 with the urgent
(URG) flag set—to a host with an established connection. This introduces a NetBIOS
fragment overlap, which causes many machines running Windows to crash. After
rebooting the attacked machine, the following message appears, indicating that an
attack has occurred:

An exception OE has occurred at 0028:[address] in VxD MSTCP(01) +

000041AE. This was called from 0028:[address] in VxD NDIS(01) +
00008660. It may be possible to continue normally.

Press any key to attempt to continue.

Press CTRL+ALT+DEL to restart your computer. You will lose any unsaved
information in all applications.

Press any key to continue.

Figure 31: WinNuke Attack Indicators

The destination port is 139.
TCP Header

Source Port Number Destination Port: 139

Sequence Number

Acknowledgement Number

Header U A P R S F
Reserved R C S S Y I Window Size
Length
G K H T N N
TCP Checksum Urgent Pointer

Options (if any)

Data (if any)

The URG flag is set.

OS-Specific DoS Attacks  55

 Concepts & Examples ScreenOS Reference Guide

If you enable the WinNuke attack defense SCREEN option, the security device scans
any incoming Microsoft NetBIOS session service (port 139) packets. If the device
observes that the URG flag is set in one of those packets, it unsets the URG flag,
clears the URG pointer, forwards the modified packet, and makes an entry in the
event log noting that it has blocked an attempted WinNuke attack.

To enable protection against a WinNuke attack, do either of the following, where

the specified zone is that in which the attack originates:

WebUI
Screening > Screen (Zone: select a zone name): Select WinNuke Attack
Protection, then click Apply.

CLI
set zone zone screen winnuke

56  OS-Specific DoS Attacks

Chapter 4
Content Monitoring and Filtering

Juniper Networks provides broad protection and control of network activity through
ScreenOS features and the pairing of ScreenOS with Websense, SurfControl, and
Kaspersky Lab products.

This chapter describes how to configure the device to perform segment and packet
reassembly, monitor HTTP traffic for malicious URLs, and communicate with other
devices to perform antivirus (AV) scanning and Web filtering. This chapter contains
the following sections:

 “Fragment Reassembly” on page 58

 “Malicious URL Protection” on page 58

 “Application Layer Gateway” on page 59

 “Antivirus Scanning” on page 62

 “External AV Scanning” on page 62

 “Internal AV Scanning” on page 64

 “Policy-Based AV Scanning” on page 70

 “Scanning Application Protocols” on page 71

 “Updating the AV Pattern Files for the Embedded Scanner” on page 80

 “AV Scanner Global Settings” on page 83

 “AV Profiles” on page 87

 “Anti-Spam Filtering” on page 94

 “Web Filtering” on page 98

 “Integrated Web Filtering” on page 99

 “Redirect Web Filtering” on page 108

 57
 Concepts & Examples ScreenOS Reference Guide

Fragment Reassembly
Typically, a network-forwarding device such as a router or switch does not
reassemble the fragmented packets that it receives. Usually the destination host
reconstructs the fragmented packets when they all arrive. The main function of a
forwarding device is the efficient delivery of traffic. If the forwarding device also
needs to queue, reassemble, and refragment all packets, its efficiency is adversely
affected. However, passing fragmented packets through a firewall is insecure. An
attacker can intentionally break up packets to conceal traffic strings that the firewall
otherwise would detect and block.

ScreenOS allows you to enable fragment reassembly for individual zones. This
method allows the security device to expand its ability to detect and block malicious
URL strings. Fragment reassembly occurs on Application Layer Gateway
(ALG)-enabled traffic only if a device is configured for NAT.

Malicious URL Protection

In addition to the Web filtering feature (explained in “Redirect Web Filtering” on
page 108), you can define up to 48 malicious URL string patterns per zone, each of
which can be up to 64 characters long, for malicious URL protection at the zone
level. With the Malicious URL blocking feature enabled, the security device
examines the data payload of all HTTP packets. If it locates a URL and detects that
the beginning of its string—up to a specified number of characters—matches the
pattern you defined, the device blocks that packet from passing through the
firewall.

A resourceful attacker, realizing that the string is known and might be guarded
against, can deliberately fragment the IP packets or TCP segments to make the
pattern unrecognizable during a packet-by-packet inspection. For example, if the
malicious URL string is 120.3.4.5/level/50/exec, IP fragmentation might break up
the string into the following sections:

 First packet: 120

 Second packet: 3.4.5/level/50

 Third packet: /exec

Individually, the fragmented strings can pass undetected through the security
device, even if you have the string defined as 120.3.4.5/level/50/exec with a length
of 20 characters. The string in the first packet—“120.”— matches the first part of
the defined pattern, but it is shorter than the required length of 20 matching
characters. The strings in the second and third packets do not match the beginning
of the defined pattern, so they would also pass without being blocked.

58  Fragment Reassembly
 Chapter 4: Content Monitoring and Filtering

However, if the packets are reassembled, the fragments combine to form a

recognizable string that the device can block. Using the Fragment Reassembly
feature, the device can buffer fragments in a queue, reassemble them into a
complete packet, and then inspect that packet for a malicious URL. Depending on
the results of this reassembly process and subsequent inspection, the device
performs one of the following actions:

 If the device discovers a malicious URL, it drops the packet and enters the event
in the log.

 If the device cannot complete the reassembly process, a time limit is imposed
to age out and discard fragments.

 If the device determines that the URL is not malicious but the reassembled
packet is too big to forward, the device fragments that packet into multiple
packets and forwards them.

 If the device determines that the URL is not malicious and does not need to
fragment it, it forwards the packet.

NOTE: The device can drop or forward the packets based on the reassembly process and
subsequent inspection. When using the malicious URL protection feature, you
cannot make the device notify you about malicious traffic while allowing the
traffic to pass. The alarm-without-drop option does not apply to this feature. For
more information about this option, see “Exploit Monitoring” on page 5.

Application Layer Gateway

ScreenOS provides an Application Layer Gateway (ALG) for a number of protocols
such as DNS, FTP, H.323, and HTTP. Of these, fragment reassembly can be an
important component in the enforcement of policies involving FTP and HTTP
services. The ability of the Juniper Networks firewall to screen packets for protocols
such as FTP-Get and FTP-Put requires it to examine not only the packet header but
also the data in the payload.

For example, there might be a policy denying FTP-Put from the Untrust to the DMZ
zone:

set policy from untrust to dmz any any ftp-put deny

If the security device finds STOR filename, the client has sent a request to store the
specified file on the server, and the device blocks the packet.

NOTE: For a deny policy, FTP-Put, FTP-Get, and FTP service behave the same way by
blocking all packets.

In a permit policy, FTP-Get, FTP-Put, and FTP are all different services. For example,
there might be a policy permitting FTP-Get from the Untrust to the DMZ zone.

set policy from untrust to dmz any any ftp-get permit

Fragment Reassembly  59
 Concepts & Examples ScreenOS Reference Guide

If the security device reads RETR filename, the FTP client has sent a request to
retrieve the specified file from the FTP server, and the device allows the packet to
pass.

If you have two policies, one denying FTP-Put from the Untrust to the DMZ zone
and another permitting FTP-Get from the Untrust to the DMZ zone, then the device
blocks the packet.

set policy from untrust to dmz any any ftp-put deny

set policy from untrust to dmz any any ftp-get permit

To thwart this defense, an attacker can deliberately fragment a single FTP-Put

packet into two packets that contain the following text in their respective payloads:

 packet 1: ST

 packet 2: OR filename

When the security device inspects each packet individually, it does not find the
string STOR filename, so would consequently allow both fragments to pass.

However, if the packets are reassembled, the fragments combine to form a

recognizable string upon which the security device can act. Using the Fragment
Reassembly feature, the device buffers the FTP fragments in a queue, reassembles
them into a complete packet, and then inspects that packet for the complete FTP
request. Depending on the results of this reassembly process and subsequent
inspection, the device performs one of the following actions:

 If the device discovers an FTP-Put request, it drops the packet and enters the
event in the log.

 If the device cannot complete the reassembly process, a time limit is imposed
to age out and discard fragments.

 If the device discovers an FTP-Get request but the reassembled packet is too big
to forward, the device fragments that packet into multiple packets and forwards
them.

 If the device discovers an FTP-Get request and does not need to fragment it, the
device then forwards the packet.

Example: Blocking Malicious URLs in Packet Fragments

In this example, you define the following three malicious URL strings and enable
the malicious URL blocking option:

 Malicious URL 1

 ID: Perl

 Pattern: scripts/perl.exe

 Length: 14

 Malicious URL 2

60  Fragment Reassembly
 Chapter 4: Content Monitoring and Filtering

 ID: CMF

 Pattern: cgi-bin/phf

 Length: 11

 Malicious URL 3

 ID: DLL

 Pattern: 210.1.1.5/msadcs.dll

 Length: 18

The values for length indicate the number of characters in the pattern that must be
present in a URL—starting from the first character—for a positive match. Note that
for 1 and 3, not every character is required.

You then enable fragment reassembly for the detection of the URLs in fragmented
HTTP traffic arriving at an Untrust zone interface.

WebUI
Security > Screening > Mal-URL (Zone: Untrust): Enter the following, then
click OK:

ID: perl
Pattern: /scripts/perl.exe
Length: 14

Security > Screening > Mal-URL (Zone: Untrust): Enter the following, then
click OK:

ID: cmf
Pattern: cgi-bin/phf
Length: 11

Security > Screening > Mal-URL (Zone: Untrust): Enter the following, then
click OK:

ID: dll
Pattern: 210.1.1.5/msadcs.dll
Length: 18

Network > Zones > Edit (for Untrust): Select the TCP/IP Reassembly for ALG
check box, then click OK.

CLI
set zone untrust screen mal-url perl “get /scripts/perl.exe” 14
set zone untrust screen mal-url cmf “get /cgi-bin/phf” 11
set zone untrust screen mal-url dll “get /210.1.1.5/msadcs.dll” 18
set zone untrust reassembly-for-alg
save

Fragment Reassembly  61
 Concepts & Examples ScreenOS Reference Guide

Antivirus Scanning
A virus is executable code that infects or attaches itself to other executable code in
order to reproduce itself. Some malicious viruses erase files or lock up systems,
while other viruses merely infect files and can overwhelm the target host or
network with bogus data.

Juniper Networks supports internal and external antivirus (AV) scanning on select
security devices. See the ScreenOS Release Notes for a list of security devices and the
supported AV scan engine.

You have the following two antivirus solutions for the ISG series of products:

 Internet Content Adaptation Protocol (ICAP) AV

Use this solution for lower speeds, such as in T-3 or fractional T-3 deployments.
For more details, see “External AV Scanning” on page 62.

 Policy based routing (PBR)

Use this solution for higher speeds, such as in OC-3 deployments. In this
scenario, PBR on the ISG offloads specific traffic to a high-end security device
running the embedded AV scanner (internal AV scanner). For more details on
this configuration, see “Advanced PBR Example” on page 7-138. For more
details on the embedded AV scanner, see “Internal AV Scanning” on page 64.

External AV Scanning
External AV scanning occurs when the security device redirects traffic to an external
ICAP AV scan server. The ICAP client on the security device communicates with the
external ICAP scan server to provide the following features:

 Supports ICAP v1.0 and is fully compliant with RFC 3507

 Supports Symantec Scan Engine 5.0 ICAP server

 Scalable antivirus scanning (add additional ICAP scan servers)

 Multiple security devices (firewalls) share the same ICAP scan server

 Load balancing traffic among a set of ICAP servers

 Encapsulation of HTTP and SMTP traffic

 Supports custom HTML message for HTTP traffic

 Supports custom x-response header

 Supports persistent connection to the same ICAP server

Persistent connection reduces processing overhead and enhances AV scanning
throughput.

Figure 32 illustrates how external AV scanning works with the security device.

62  Antivirus Scanning
 Chapter 4: Content Monitoring and Filtering

Figure 32: How External Scanning Works

Remote
Trust Zone HTTP/SMTP
Untrust Zone Security device Servers

Remote FTP
Server ICAP Servers
PW R A LA R M TEM
P S TA T U S H A running
Symantec scan
FA N M O 1D M O 2D M O 3D F LA S H
ISG 2000

engine 5.0

ICAP client

1. A client establishes an HTTP or SMTP session.

2. The AV profile in the security device determines if the data should be sent for
antivirus scanning.

3. If the scanning is configured, a connection is established between the firewall

and an ICAP server chosen from the ICAP scan server group.
4. The ICAP client sends the scan data (in encapsulated ICAP format) to the ICAP
server and holds the data in memory until the ICAP server acknowledges receiving
it.

5. The ICAP server returns the scan results with the entire content to the ICAP
client.

• If a virus is not found, the traffic is forwarded to its destination.

• If a virus is found, the data is replaced and the destination notified. For HTTP,
the data is replaced with custom HTML message. If a custom HTML message
is not provided, then a log event is generated to record the virus.

Scanning Modes
After the traffic undergoes AV scanning, the ICAP server running Symantec Scan
Engine 5.0 provides one of the following results:

 Scan only. Denies access to the infected file but does nothing to the file.

 Scan and delete. Deletes all infected files, including files that are embedded in
archive files, without attempting to repair.

 Scan and repair files. Attempts to repair infected files but does nothing to files
that cannot be repaired.

 Scan and repair or delete. Attempts to repair infected files and deletes any
unrecoverable files from archive files.

Refer to your ICAP server documentation for more information about scanning
behavior and results.

Load-Balancing ICAP Scan Servers

ScreenOS external AV scanning allows you to load-balance ICAP scan servers
configured in an ICAP server group. The load-balancing algorithm used among the
ICAP scan servers in the group is least request. The ICAP servers are load-balanced
based upon the server’s health and traffic volume (number of pending requests).
Unhealthy servers are bypassed, and traffic is reduced automatically to the
overloaded server.

Antivirus Scanning  63
 Concepts & Examples ScreenOS Reference Guide

A configured ICAP server can be in either an enabled or a disabled state. The status
of an enabled ICAP server can be in-service or out-of-service. When an ICAP server is
configured as disabled, then the server is not used to serve new requests.

ICAP servers are monitored through a probing mechanism. For example, if the
probe interval is set to 30, then an enabled ICAP server is automatically probed
every 30 seconds to determine its status (in-service or out-of-service).

An auto probe returns an out-of-service result for the following conditions:

 Firewall cannot establish a successful TCP connection to an ICAP server

 Invalid ICAP server AV license

 Client-side error response for ICAP options request

 Server-side error response for ICAP options request

The server goes into an out-of-service state when three consecutive probes fail.

Internal AV Scanning
Internal AV scanning is performed when the scan engine in the security device
scans traffic for viruses. The internal or embedded scan engine is a
Juniper-Kaspersky scan engine.

NOTE: The internal AV scanner requires you to install an AV license on your security
device. An AV license is not required if you are using an external AV scanner.

The embedded scan engine allows you to do the following:

 Enable/disable scanning based on file extension and content type

For example, you can set up a profile that supports scanning of executable files
(.exe) but not documentation files (.doc or .pdf).

 Configure decompression layers for specific application protocols

In each profile, you can configure different decompression levels for each
protocol (HTTP/SMTP/POP3/IMAP/FTP). Based on your network environment,
for example, you might want to specify the number of embedded zip files to
unpack for each protocol.

 Configure AV scanning for Instant Messaging (IM) traffic

For more information about scanning IM traffic, see “AV Scanning of IM Traffic”
on page 65.

 Configure email notification to sender/receiver on detected virus and scanning

errors

 Configure scanning levels to provide spyware and phishing protection

64  Antivirus Scanning
 Chapter 4: Content Monitoring and Filtering

The Juniper-Kaspersky scan engine, by default, provides the highest level of

security. In addition to stopping all viruses (including polymorphic and other
advanced viruses), this scan engine also provides inbound spyware and
phishing protection.

Spyware protection. The spyware-protection feature adds another layer of

protection to Juniper Networks anti-spyware and anti-adware solutions by
letting you block incoming spyware, adware, keyloggers, and related malware
to prevent the malicious traffic from penetrating your enterprise.

This solution complements Juniper Networks Intrusion Detection and

Prevention (IDP) products, which provide spyware phone-home protection (that
is, stopping spyware from sending sensitive data if your
laptops/desktops/servers are infected).

Phishing protection. The phishing protection feature lets you block emails that
try to entice users to fake (phishing) sites that steal sensitive data.

You can change the default security level of scanning by choosing one of the
following two options:

 Basic in-the-wild scanning. This level of scanning administers a lower

degree of security by scanning the most prevalent viruses, although it
provides increased performance. To enable basic in-the-wild scanning,
enter the following command:

set av scan-mgr pattern-type itw

 Extended scanning. This level of scanning includes traditionally more

noisy pieces of spyware/adware in the standard scan. It provides more
spyware coverage but potentially can return more false positives. To enable
extended scanning, enter the following command:

set av scan-mgr pattern-type extended

NOTE: You must use the CLI to modify the default security level of scanning.

The standard option (set av scan-mgr pattern-type standard) is the default.

AV Scanning of IM Traffic
An Instant Messaging (IM) network is composed of clients and servers, along with
the protocols needed to connect them.

IM Clients
Each IM client has three major components:

 A buddy list or other roster of friends with whom you wish to communicate.

 A separate window that shows the text chats in progress—Users type their
messages and view their correspondents’ responses in this window.

 Additional features for video and audio chats and for file transfers between
users.

Antivirus Scanning  65
 Concepts & Examples ScreenOS Reference Guide

All major IM clients are moving beyond simple text chats to more integrated
and sophisticated communications, including real-time voice and video calls.

ScreenOS supports scanning of popular public IM applications such as:

 AOL Instant Messenger (AIM)

 I Seek You (ICQ)

 Yahoo! Messenger (YMSG)

 MSN Messenger

The AV scanning features in this release of ScreenOS apply to the following IM

services:

 Text chat message

 Group chat Message

 File transfer/file sharing

IM Server
The IM server maintains the directory of user accounts, keeps track of who is
online, and, in most cases, routes messages among users. The IM server operates in
real time, sending messages back and forth between two users as they finish typing
each line of text. The servers also pass real-time information about the availability
of various users in the directory, such as when they come online and change their
status message.

Each IM server communicates with its clients over an assigned port number across
the Internet. But IM clients however, can login using other ports when the default
port is blocked by a deny policy. Typical port numbers include those shown in the
following table:

IM Application Service Port Numbers Proxies

AIM 5190 SOCKS 4, SOCKS 5,
HTTP, HTTPS
ICQ 5190
YMSG 50501 (443 and 80) SOCKS 4, SOCKS 5,
HTTP
MSN Messenger 1863 SOCKS 4, SOCKS 5,
HTTP

1.In addition to port 5050, make sure traffic is permitted on

ports 443 (HTTPS) and 80 (HTTP).

NOTE: AV scanning is not supported for AIM or ICQ traffic communicating in encrypted
format.

66  Antivirus Scanning
 Chapter 4: Content Monitoring and Filtering

IM Protocols
The IM network employs a client-server model for authentication to the service and
for communication with other clients using the protocols shown in the following
table:

IM Application Supported Protocol

AIM/ICQ Open System for Communication in Realtime protocol (OSCAR)
YMSG Yahoo Messenger Service Gateway Protocol (YMSG)
MSN Messenger Mobile Status Notification Protocol (MSNP)

Because the proprietary protocol for the respective IM applications is constantly

being updated, ScreenOS provides a configurable parameter to control the firewall
behavior. See the software release notes for the supported client and protocol
version. ScreenOS, however, processes traffic for unsupported versions of the
protocol in one of the following two ways:

 Best Effort: Uses the existing protocol knowledge to process the traffic

 Pass: Passes the traffic without scanning it

Instant Messaging Security Issues

Generally, worms spread over instant messaging services and appear as a URL.
These URLs are accessed because they appear from someone on your buddy list. If
the URL is clicked, the worm infects your PC and spreads to everyone on the buddy
list.

The buddy list also leads to social engineering. Social engineering occurs when
people obtain information from legitimate users of a computer
system—specifically, information that will allow them to gain unauthorized access
to a particular system.

The file transfer service is another security risk where instant messaging
applications can send Trojans and viruses.

IM Security Issues
Instant messaging (IM) services are vulnerable to attacks such as viruses, worms,
and Trojans via the following methods:

 Buddy lists

A worm can spread through IM services because it generally appears as URL in

an instant message. These URLS often appear to come from someone on your
buddy list. If you click such a malicious URL, the worm infects your PC and can
easily spread to everyone on your buddy list.

 Social engineering

Social engineering occurs when an attacker illegally obtains sensitive

information (such as a buddy list) from legitimate users of a system or
service—information the attacker then uses to gain unauthorized access.

Antivirus Scanning  67
 Concepts & Examples ScreenOS Reference Guide

 File transfers

Trojans and viruses can easily spread when files are sent from one user to
another via an IM session.

Scanning Chat Messages

When the device is enabled for AV, the firewall processes the data packets sent
between the IM client and the server. The firewall detects the beginning of an
individual chat message in a data packet and retains the data packets that follow
until the chat message is complete. The complete message is sent to the AV scan
engine for virus scanning using the procedure shown in the following table.

If... The Chat Message Result

Virus is found Is dropped. A virus drop notification message is
forwarded to the original message’s
destination.
Scanning error occurs Is dropped. A scan-error drop notification message is
(scan error permit is forwarded to the original message’s
disabled) destination.
AV scanning finishes with Is forwarded to its Message reaches destination.
no virus or scanning errors destination.

NOTE: In an AOL Instant Message (AIM) session, if a group chat message includes a virus,
the drop message is sent back to the client, after which the client is unable to send
any more messages.

Scanning File Transfers

The firewall processes the data packets communicated between the IM client and
the server. Typically, file sharing means get file, but AIM file transfer includes send
file, get file, and send directory. When the firewall detects file transfer commands,
the following occurs:

68  Antivirus Scanning
 Chapter 4: Content Monitoring and Filtering

File Transfer/File
If File Size Is... Sharing Result
<= AV max_content_size AV scanning occurs  Virus found. File content is replaced by
virus notification message.
 Scanning error (AV scan error permit is
disabled). File content is replaced by
scan-error notification message.
> AV max_content_size Skips AV scanning Drops the file and forwards drop-notification
(max_content_size drop is message to original message’s destination.
enabled)
> AV max_content_size Skips AV scanning Forwards file to its destination.
(max_content_size drop is
disabled)

NOTE: This release of ScreenOS does not support instant messaging P2P traffic through
the firewall.

AV Scanning Results
AV scanning may not occur for several reasons. When your device is configured for
external scanning, the device simply redirects the traffic to the external ICAP server.
Refer to your ICAP server documentation for information about AV scanning
behavior and results.

If your device is configured for internal AV scanning, the get av stat command
displays scanning failures. In addition to the following scan-code results, this
command generates an event log that contains more information about scanning
results.

Scan Code: Clear

Scan Code: Infect
Scan Code: Psw Archive File
Scan Code: Decompress Layer
Scan Code: Corrupt File
Scan Code: Out Of Resource
Scan Code: Internal Error
Scan Code: Error
Scan Eng: Error:
Fail Mode:

In the following scenarios, traffic is dropped and replacement data is forwarded to

its destination:

 AV scan engine returns one of the following scan-errors and the corresponding
configuration drop setting is enabled.

 Max-decompress-layer setting is exceeded.

 Password protected file.

 Corrupted file.

Antivirus Scanning  69
 Concepts & Examples ScreenOS Reference Guide

 Out of resource.

When AV scan results in an out of resource error condition, the file is

dropped or passed based on the max-content-size setting, but the
out-of-resource counter is incremented.

 AV scan engine returns any of the above scan-errors and fail-mode permit is
disabled.

 Size of file transfer exceeds the AV max-content-size setting and

max-content-size drop is enabled.

NOTE: If the file to be sent exceeds the max-content-size and the fail mode is drop, both
ends will receive the message of File transfer error.

NOTE: If the max-decompress-layer setting is set to drop the data packets on exceeding
the decompress layer setting, a replacement file is sent to the receiver. The MSN
Server however, does not send a replacement file or an error message about the
download failure.

See “Scanning Application Protocols” on page 71 for information about AV-scanning

failure, including those instances when data cannot be successfully scanned.

See the ScreenOS Message Log Reference Guide for a list of error messages generated
from AV scanning.

Policy-Based AV Scanning
AV scanning profiles increase the flexibility and granularity of AV scans.
Profile-based scanning allows you to configure a profile to scan traffic and assign
the profile to a policy. Policy-based scanning allows you to:

 Select specific data traffic for AV scanning

 Enhance performance and control the AV scan engine

To configure policy-based scanning, you must configure AV profiles for use in

policies by doing the following:

1. Initiate an AV profile context. For more information, see “Initiating an AV Profile

for Internal AV” on page 88.

2. Configure a profile (ns-profile is predefined for internal AV) to examine network

traffic for the protocols shown in the following table.

70  Antivirus Scanning
 Chapter 4: Content Monitoring and Filtering

Protocols See
File Transfer Protocol (FTP) “Scanning FTP Traffic” on page 72
HyperText Transfer Protocol (HTTP) “Scanning HTTP Traffic” on page 74
Internet Mail Access Protocol (IMAP) “Scanning IMAP and POP3 Traffic” on page 76
Post Office Protocol, version 3 (POP3) “Scanning IMAP and POP3 Traffic” on page 76
Simple Mail Transfer Protocol (SMTP) “Scanning SMTP Traffic” on page 77
Internet Content Adaptation Protocol (ICAP) “Redirecting Traffic to ICAP AV Scan Servers” on
page 79

3. Exit the AV profile context.

4. Assign the AV profile to a firewall policy. (Only one AV profile can be linked to a
policy.)

To apply AV protection, you reference the AV profile in a security policy. When

the security device receives traffic to which a policy requiring AV scanning
applies, it directs the content it receives to the AV scanner (internal or external).

5. Save your profile.

Figure 33 shows how the AV profile works with the AV scanner (internal or
external).

Figure 33: How the AV Profile Works with the AV Scanner

If no virus is found, the data is A client establishes a connection with a server

5 forwarded to its original destination. and starts a session.

Scan Manager monitors all the requests sent

Untrust Zone 2 from the client and extracts protocol-specific data. Trust Zone

Remote Local
FTP Server FTP Client
AV profile determines whether the request
3 should be sent for antivirus scanning.
If virus is found, message is
6 logged and email notification is sent
If the data is configured to be scanned, then
4 data is sent to the Scan engine for scanning. based on the AV profile setting.

Scanning Application Protocols

The internal embedded AV scan engine supports scanning for specific Application
Layer transactions allowing you to select the content (FTP, HTTP, IMAP, POP3, or
SMTP traffic) to scan. For example, scan performance can be enhanced by not
scanning certain content. Similarly, external AV scanning is supported for HTTP and
SMTP protocols only.

NOTE: You need to assess the risk and determine the best trade-off between security and
performance.

Antivirus Scanning  71
 Concepts & Examples ScreenOS Reference Guide

This section discusses how to configure the following application protocols for AV
scanning:

 “Scanning FTP Traffic” on page 72

 “Scanning HTTP Traffic” on page 74

 “Scanning IMAP and POP3 Traffic” on page 76

 “Scanning SMTP Traffic” on page 77

Each of the above applications can be configured for one or more of the following:

Command Description
decompress-layer Specifies how many layers of nested compressed files the internal AV
scanner can decompress before it executes the virus scan.
extension list Specifies the extension list name (string) to include or exclude defined
extensions.
scan-mode Specifies how the scan engine scans traffic for a specific protocol.
timeout Specifies the timeout value for an AV session for a specific protocol.
http skipmime Skips the specified MIME list from AV scanning.
Note: Disabling skipmime allows the security device to scan all kinds of
HTTP traffic regardless of MIME content types.
email-notify Notifies sender or recipient of detected virus or scanning errors for IMAP,
POP3, and SMTP traffic only.

Scanning FTP Traffic

For File Transfer Protocol (FTP) traffic, the security device monitors the control
channel and, when it detects one of the FTP commands for transferring data (RETR,
STOR, STOU, APPE, or NLST), it scans the data sent over the data channel.

Depending on the results of the scan and how you have configured the fail-mode
behavior, the security device takes one of the following actions:

If the Data And The Security Device

is uncontaminated passes the data to the FTP client through the data channel
contains a virus drops the data from the data channel and sends a
virus-notification message to the FTP client through the control
channel
exceeds the maximum content size drop is set drops the data from the data channel and sends a “file too
large” message to the FTP client through the control channel
exceeds the maximum content size drop is unset passes the unexamined data to the FTP client through the data
channel
cannot successfully be scanned fail mode is unset drops the data from the data channel and sends a “scan error”
(drop) message to the FTP client through the control channel
cannot successfully be scanned fail mode is permit passes the data to the FTP client through the data channel
(traffic permit is set)

72  Antivirus Scanning
 Chapter 4: Content Monitoring and Filtering

If the Data And The Security Device

exceeds the maximum concurrent drop is set drops the data from the data channel and sends an “exceeding
messages maximum message setting” message to the FTP client through
the control channel
exceeds the maximum concurrent drop is unset passes the data to the FTP client through the data channel
messages

Figure 34: Antivirus Scanning for FTP Traffic

Control Channel

Untrust Zone Trust Zone

Remote Local
FTP Server FTP Client

Internal AV Scanner

Data Channel

1. A local FTP client opens an FTP control channel to an FTP server and requests
the transfer of some data.
2. The FTP client and server negotiate a data channel over which the server sends
the requested data. The security device intercepts the data and passes it to its
internal AV scan engine, which scans it for viruses.
3. After completing the scan, the device follows one of two courses*:
• If there is no virus, it forwards the data to the client.
• If there is a virus, it replaces the data with a drop message in the data channel
and sends a message reporting the infection in the control channel.

* If the scanned data exceeds the maximum content setting, or, if the scan cannot be
successfully completed, the device follows a different course of action depending on the
fail-mode setting.

Antivirus Scanning  73
 Concepts & Examples ScreenOS Reference Guide

Scanning HTTP Traffic

For HTTP traffic, the security device scans both HTTP responses and requests (get,
post, and put commands). The internal AV scanner examines HTTP downloads, that
is, HTTP data contained in responses from a webserver to HTTP requests from a
client. The internal AV scanner also scans uploads, such as when an HTTP client
completes a questionnaire on a webserver or when a client writes a message in an
email originating on a webserver.

Depending on the results of the scan and how you have configured the fail-mode
behavior, the security device takes one of the following actions:

If the Data And The Security Device

is uncontaminated passes the data to the HTTP client
contains a virus drops the data and sends a virus notification message to the
HTTP client
exceeds the maximum content size drop is set drops the data and sends a “file too large” message to the HTTP
client
exceeds the maximum content size drop is unset passes the data to the HTTP client
cannot successfully be scanned fail mode is unset drops the data and sends a “scan error” message to the HTTP
(drop) client
cannot successfully be scanned traffic permit is set passes the data to the HTTP client
(fail mode is permit)
exceeds the maximum concurrent drop is set drops the data from the data channel and sends an “exceeding
messages maximum message setting” message to the HTTP client through
the control channel
exceeds the maximum concurrent drop is unset passes the data to the HTTP client through the data channel
messages

Figure 35: Antivirus Scanning for HTTP Traffic

Untrust Zone Trust Zone

Remote Local
Webserver HTTP Client

Internal AV Scanner

4. A webserver responds to an HTTP request. 1. An HTTP client sends an HTTP request to a webserver.
5. The security device intercepts the HTTP response and passes 2. The security device intercepts the request and passes the data to
the data to its internal AV scan engine, which scans it for viruses. the internal AV scanner, which scans it for viruses.
6. After completing the scan, the device follows one of two 3. After completing the scan, the device follows one of two courses*:
courses*:
• If there is no virus, it forwards the request to the webserver.
• If there is no virus, it forwards the response to the HTTP client.
• If there is a virus, it drops the request and sends an HTTP
• If there is a virus, it drops the response and sends an HTTP message reporting the infection to the client.
message reporting the infection to the client.

* If the scanned data exceeds the maximum content setting, or, if the scan cannot be
successfully completed, the security device follows a different course of action
depending on the fail-mode setting.

74  Antivirus Scanning
 Chapter 4: Content Monitoring and Filtering

HTTP MIME Extensions

By default, HTTP scanning does not scan HTTP entities composed of any of the
following Multipurpose Internet Mail Extensions (MIME) content types and subtypes
(when present following a slash):

 Application/x-director

 Application/pdf

 Image/

 Video/

 Audio/

 Text/css

 Text/html

To improve performance, Juniper Networks security devices do not scan the above
MIME content types. Because most HTTP entities are made up of the above content
types, HTTP scanning only applies to a small subset of HTTP entities, such as
application/zip and application/exe content types, which are most likely to contain
viruses.

To change HTTP scanning behavior so that the security device scans all HTTP traffic
regardless of MIME content types, enter the following command:

set av profile jnpr-profile

(av:jnpr-profile)-> unset av http skipmime
(av:jnpr-profile)-> exit
save

Antivirus Scanning  75
 Concepts & Examples ScreenOS Reference Guide

Scanning IMAP and POP3 Traffic

For IMAP and POP3 traffic, the security device redirects traffic from a local mail
server to the internal AV scanner before sending it to the local IMAP or POP3 client.
Depending on the results of the scan and how you have configured the fail-mode
behavior, the security device takes one of the following actions:

If the Data And The Security Device

is uncontaminated passes the message to the IMAP or POP3 client.
contains a virus email notification is changes the content type to text/plain, replaces the body of the message with the
set following notice, sends it to the IMAP or POP3 client, and notifies the sender:
VIRUS WARNING.
Contaminated File: filename
Virus Name: virus_name
exceeds the drop is set changes the content type to “text/plain,” replaces the body of the message with
maximum content the following notice, and sends it to the IMAP or POP3 client:
size Content was not scanned for viruses because reason_text_str (code number), and
it was dropped.
or
reason_text_str can be one of the following:
cannot successfully fail mode is unset  The file was too large.
be scanned (drop)
 An error or a constraint was found.
or  The maximum content size was exceeded.
 The maximum number of messages was exceeded.
exceeds the email notification is
maximum set notifies the sender/recipient of detected virus or scanning errors.
concurrent
messages
exceeds the drop is unset passes the original message to the IMAP or POP3 client with the original subject
maximum content line modified as follows:
size original_subject_text_str (No virus check because reason_text_str, code number)
or notifies the sender/recipient of detected virus or scanning errors.

cannot successfully traffic permit is set

be scanned (fail mode is permit)

or

exceeds the drop is unset

maximum email notification is
concurrent set
messages

76  Antivirus Scanning
 Chapter 4: Content Monitoring and Filtering

Figure 36: Antivirus Scanning for IMAP and POP3 Traffic

DMZ Zone

Local
Mail Server

Untrust Zone Trust Zone

Internet

Internal AV Scanner IMAP or POP3 Client

1. The IMAP or POP3 client downloads an email message from the local mail server.
2. The security device intercepts the email message and passes the data to the internal AV
scanner, which scans it for viruses.
3. After completing the scan, the security device follows one of two courses*:
• If there is no virus, it forwards the message to the client.
• If there is a virus, it sends a message reporting the infection to the client.

* If the scanned message exceeds the maximum content setting or, if, the scan cannot be
successfully completed, the security device follows a different course of action depending on
the fail-mode setting.

Scanning SMTP Traffic

For SMTP traffic, the security device redirects traffic from local SMTP clients to the
internal AV scanner before sending it to the local mail server. Depending on the
results of the scan and how you have configured the fail-mode behavior, the security
device takes one of the following actions:

If the Data And The Security Device

is uncontaminated passes the message to the SMTP recipient.
contains a virus email notification changes the content type to text/plain, replaces the body of the message with the
is set following notice, sends it to the SMTP recipient, and notifies the sender:
VIRUS WARNING.
Contaminated File: filename
Virus Name: virus_name

Antivirus Scanning  77
 Concepts & Examples ScreenOS Reference Guide

If the Data And The Security Device

exceeds the drop is set changes the content type to text/plain, replaces the body of the message with the
maximum content following notice, and sends it to the SMTP recipient:
size Content was not scanned for viruses because reason_text_str (code number), and it
was dropped.
or
reason_text_str can be one of the following:
cannot successfully fail mode is unset  The file was too large.
be scanned (drop)
 An error or constraint was found.
or  The maximum content size was exceeded.
 The maximum number of messages was exceeded
exceeds the drop is set
maximum email notification notifies the sender/recipient of detected virus or scanning errors.
concurrent is set
messages
exceeds the drop is disabled passes the original message to the SMTP recipient with the original subject line
maximum content modified as follows:
level original_subject_text_str (No virus check because reason_text_str, code number)
or notifies the sender/recipient of detected virus or scanning errors.
cannot successfully traffic permit is set
be scanned (fail mode is permit)

or
exceeds the drop is unset
maximum email notification
concurrent is set
messages

NOTE: Because an SMTP client refers to the entity that sends email, a client could, in fact,
be another SMTP server.

78  Antivirus Scanning
 Chapter 4: Content Monitoring and Filtering

Figure 37: Antivirus Scanning for SMTP Traffic

DMZ Zone

Untrust Zone Trust Zone

Internet

Remote Mail Server Internal AV Scanner SMTP Client

4. A remote mail server forwards an email message via SMTP to the A. An SMTP client sends an email message to a local mail server.
local mail server.
B. The security device intercepts the email message and passes the
5. The security device intercepts the email message and passes the data to the internal AV scanner, which scans it for viruses.
data to the internal AV scanner, which scans it for viruses.
C. After completing the scan, the device follows one of two courses*:
6. After completing the scan, the device follows one of two courses*:
• If there is no virus, it forwards the message to the local server.
• If there is no virus, it forwards the message to the local server.
• If there is a virus, it sends a message reporting the infection to
• If there is a virus, it sends a message reporting the infection to the client.
the remote server.

* If the scanned message exceeds the maximum content setting, or, if the scan cannot be successfully completed, the security
device follows a different course of action depending on the fail-mode setting.
1. A remote mail server forwards an email message via SMTP to the local mail server.
2. The security device intercepts the email message and passes the data to the internal AV scanner, which scans it for viruses.
3.After completing the scan, the device follows one of two courses*:
•If there is no virus, it forwards the message to the local server.
•If there is a virus, it sends a message reporting the infection to the remote server.

Redirecting Traffic to ICAP AV Scan Servers

Your Juniper Networks security device communicates with an external AV scan
engine using the Internet Content Adaptation Protocol (ICAP). ScreenOS 5.4
supports redirection of HTTP and SMTP traffic only.

To configure the security device to support external ICAP AV scanning, perform the
following steps:

1. Use the set icap command to configure the external ICAP scan server.

2. Configure an ICAP profile and specify one or more of the following:

Command Description
timeout Specifies the timeout value for an AV session for a specific protocol
(HTTP or SMTP).
http skipmime Skips the specified files in the MIME list from AV scanning.
Note: Disabling the skipmime list allows the security device to scan all
kinds of HTTP traffic regardless of MIME content types.
email-notify Notifies sender or recipient of detected virus or scanning errors for
SMTP traffic only.

Antivirus Scanning  79
 Concepts & Examples ScreenOS Reference Guide

WebUI
Objects > Antivirus > ICAP Server >New: Enter the following, then click
Apply:

ICAP AV Server Name: ICAP_Server1

Enable: (select), Scan Server Name/IP: 1.1.1.1
Scan Server Port: 1344, Scan URL: /SYMCScan-Resp-AV
Probe Interval: 10, Max Connections:

CLI
set icap server icap_server1 host 1.1.1.1
save

The ICAP server is automatically enabled when it is set up.

Updating the AV Pattern Files for the Embedded Scanner

Internal AV scanning requires that you load a database of AV patterns onto the
Juniper Networks security device and periodically update the pattern file.

Before you start updating the AV pattern files, make sure your device supports the
following:

Prerequisites Description
Valid AV license key av_v2_key
Access to the Internet Your device has a route to the internet
DNS and port settings Verify your DNS setting and port 80
AV signature service See “Subscribing to the AV Signature Service” on
page 80

Subscribing to the AV Signature Service

To purchase a subscription for the AV signature service you must first register your
device. For the life of the subscription, you can load the current version of the
database and update it as newer versions become available. The procedure for
initiating the AV signature service varies depending on one of the following:

 If you purchased a security device with AV functionality, you can load an AV

pattern file for a short period after the initial purchase. You must, however,
register the device and purchase a subscription for AV signatures in order to
continue receiving pattern updates.

 If you are upgrading a current security device to use internal AV scanning, you
must register the device and purchase a subscription for AV signatures before
you can begin loading the AV pattern file. After completing the registration
process, you must wait up to four hours before initiating the AV pattern file
download.

NOTE: For more information about the AV signature service, see “Registration and
Activation of Subscription Services” on page 2-251.

80  Antivirus Scanning
 Chapter 4: Content Monitoring and Filtering

Updating AV Patterns from a Server

You can update antivirus (AV) patterns from the Juniper Networks server or from a
proxy server. Figure 38 and Figure 39 illustrate how the pattern file is updated from
the Juniper Networks server.

Update the AV pattern file as follows:

1. On the security device, specify the URL of the pattern-update server:

http://update.juniper-updates.net/av/5gt/

Figure 38: Updating Pattern Files—Step 1

File Transfer Request Update Server
Security device

Internet

Juniper-Kaspersky URL = http://update.juniper-updates.net/av/5gt

2. After the security device downloads the server-initialization file, the device
checks that the pattern file is valid. The device then parses the file to obtain
information about it, including the file version, size, and location of the pattern
fileserver.

NOTE: ScreenOS contains a CA certificate for authenticating communications with the

pattern update fileserver.

3. If the pattern file on the security device is out of date (or nonexistent because
this is the first time you are loading it), and, if the AV pattern-update service
subscription is still valid, the device automatically retrieves an updated pattern
file from the pattern fileserver.

Figure 39: Updating Pattern Files—Step 2

Pattern File Request
Security device Pattern fileserver

Internet

AV Pattern File AV Pattern File Transfer AV Pattern File

4. The device saves the new pattern file to flash memory and RAM and, if there is
an existing file, overwrites it.

Antivirus Scanning  81
 Concepts & Examples ScreenOS Reference Guide

Updates to the pattern file are added as new viruses propagate. You can configure
the security device to regularly update the pattern file automatically, or you can
update the file manually.

NOTE: Once your subscription expires, the update server no longer permits you to update
the AV pattern file.

Example: Automatic Update

In this example, you configure the security device to update the pattern file
automatically every 120 minutes. (The default AV pattern-update interval is 60
minutes.) For example, if the pattern-update server is located at the URL
http://update.juniper-updates.net/av/5gt/, you configure automatic update as
follows:

WebUI
Security > Antivirus > Scan Manager: Enter the following, then click Apply:

Pattern Update Server: http://update.juniper-updates.net/av/5gt

Auto Pattern Update: (select), Interval: 120 minutes (10~10080)

CLI
set av scan-mgr pattern-update-url http://update.juniper-updates.net/av/5gt
interval 120
save

Example: Manual Update

In this example, you update the pattern file manually. The pattern update
server is located at the following URL:

http://update.juniper-updates.net/av/5gt/

WebUI
Security > Antivirus > Scan Manager: Enter the following, then click Apply:

Pattern Update Server: http://update.juniper-updates.net/av/5gt

Update Now: (select)

CLI
exec av scan-mgr pattern-update

The set command is not required because the URL is the default.

82  Antivirus Scanning
 Chapter 4: Content Monitoring and Filtering

Updating AV Patterns from a Proxy Server

You can update the AV patterns from the proxy server. This update does not require
Internet access and is done offline.

To configure a proxy server:

WebUI
Security > Proxy: Set the HTTP and SSL proxy addresses, then click Apply:

HTTP Proxy: 10.0.0.5:8080

SSL Proxy: 10.0.0.5:443

CLI
set pattern-update proxy http 10.0.0.5:8080
save

NOTE: You cannot configure an HTTPs proxy, because you cannot cache an HTTPs proxy.

AV Scanner Global Settings

You can modify AV scanner settings to serve the needs of your network
environment. The global scan-mgr command in the CLI configures the Scan
Manager, which is the AV component that interacts with the scan engine. For
example, the set or get av scan-mgr CLI command sets the global commands that
control parameters such as max-content-size, max-msgs, pattern-type,
pattern-update, and queue-size.

The following sections explain the global settings for your AV scanner:

 “AV Resource Allotment” on page 83

 “Fail-Mode Behavior” on page 84

 “Maximum Content Size and Maximum Messages (Internal AV Only)” on

page 84

 “HTTP Keep-Alive” on page 85

 “HTTP Trickling (Internal AV Only)” on page 86

Use the get av all or get av scan-mgr to see the global antivirus settings on the
device.

AV Resource Allotment
A malicious user might generate a large amount of traffic all at once in an attempt
to consume all available resources and hinder the ability of the AV scanner to scan
other traffic. To prevent such activity from succeeding, the Juniper Networks
security device can impose a maximum percentage of AV resources that traffic from
a single source can consume at one time. The default maximum percentage is 70
percent. You can change this setting to any value between 1 and 100 percent,
where 100 percent does not impose any restriction on the amount of AV resources
that traffic from a single source can consume.

Antivirus Scanning  83
 Concepts & Examples ScreenOS Reference Guide

WebUI

NOTE: You must use the CLI to configure this option.

CLI
set av all resources number
unset av all resources

The above unset av command returns the maximum percentage of AV resources

per source to the default (70 percent).

Fail-Mode Behavior
Fail-mode is the behavior that the security device applies when it cannot complete a
scan operation—either to permit the unexamined traffic or to block it. By default, if
a device cannot complete a scan, it blocks the traffic that a policy with antivirus
checking enabled permits. You can change the default behavior from block to
permit.

When the AV scan engine is scanning a file and runs out of memory (typically, when
decompressing files), the content is either dropped or passed based on the out of
resource (set av scan-mgr out-of-resource) setting, instead of the fail-mode setting.

WebUI
Security > Antivirus > Global: Select Fail Mode Traffic Permit to permit
unexamined traffic, or clear it to block unexamined traffic, then click Apply.

CLI
set av all fail-mode traffic permit
unset av all fail-mode traffic

The above unset av command returns the fail mode behavior to the default (block
unexamined traffic).

Maximum Content Size and Maximum Messages (Internal AV Only)

Scan Manager settings for maximum content size and maximum messages are
supported on internal AV only. ICAP AV does not support the maximum content size
and maximum messages settings.

On some devices, the internal AV scanner examines a maximum of 256 messages

and 30 megabytes (MB) of decompressed file content at a time. The values for
Maximum Content Size and Maximum Number of Messages depend on the device
(see the ScreenOS Release Notes).

If the total number of messages or the size of the content received concurrently
exceeds the device limits, by default the scanner drops the content without
checking for viruses. For slow links, such as ISDN, decrease the max-content-size to
a lesser value (set av scan-mgr max-content-size 20), so that AV scanning does not
time out.

NOTE: On some security devices, the default for Maximum Content Size is 10 MB.
However, if DI is enabled, we recommend that you configure a value of 6 MB.

84  Antivirus Scanning
 Chapter 4: Content Monitoring and Filtering

For example, the scanner can receive and examine four 4-megabyte messages
concurrently. If the scanner receives nine 2-megabyte messages concurrently, it
drops the contents of the last two files without scanning it. You can change this
default behavior so that the scanner passes the traffic instead of dropping it by
doing the following:

WebUI
Security > Antivirus > Scan Manager

Content Oversize: Select Permit to pass traffic if the file size exceeds 30,000 KB

Or

Msgs Overflow: Select Permit if the number of files exceeds the maximum
number of messages on the device, then click Apply.

CLI
unset av scan-mgr max-content-size drop
unset av scan-mgr max-msgs drop

When the AV scan engine is scanning a file and runs out of memory (typically, when
decompressing files), the content is either dropped or passed based on the out of
resource (set av scan-mgr out-of-resource) setting, instead of the fail-mode (set av all
failmode) setting.

HTTP Keep-Alive
By default, the security device uses the HTTP “keep-alive” connection option, which
does not send a TCP FIN to indicate the termination of data transmission. The HTTP
server must indicate that it has sent all the data in another way, such as by sending
the content length in the HTTP header or by some form of encoding. (The method
that a server uses varies by server type.) This method keeps the TCP connection
open while the antivirus examination occurs, which decreases latency and
improves processor performance.

You can change the default behavior of the security device to use the HTTP “close”
connection option for indicating the end of data transmission. (If necessary, the
device changes the token in the connection header field from “keep-alive” to
“close.”) With this method, when the HTTP server completes its data transmission,
it sends a TCP FIN to close the TCP connection and indicate that the server has
finished sending data. When the device receives a TCP FIN, it has all the HTTP data
from the server and can instruct the AV scanner to begin scanning it.

NOTE: The “keep-alive” not as secure as the “close” connection method. You can change
the default behavior if you find that HTTP connections are timing out during the
antivirus examination.

WebUI
Security > Antivirus > Global: Select Keep Alive to use the “keep-alive”
connection option, or clear it to use the “close” connection option, then click
Apply.

Antivirus Scanning  85
 Concepts & Examples ScreenOS Reference Guide

CLI
set av http keep-alive
unset av http keep-alive

HTTP Trickling (Internal AV Only)

HTTP trickling is the forwarding of specified amounts of unscanned HTTP traffic to
the requesting HTTP client to prevent the browser window from timing out while
the scan manager examines downloaded HTTP files. (The security device forwards
small amounts of data in advance of transferring an entire scanned file.) By default,
HTTP trickling is disabled. To enable it and use the default HTTP trickling
parameters:

WebUI
Security > Antivirus > Global: Select the Trickling Default check box, then click
Apply.

CLI
set av http trickling default

NOTE: HTTP trickling is supported on internal AV only. For YMSG however, trickling is
disabled for chat and file transfer. ICAP AV does not support HTTP trickling.

With the default parameters, the security device employs trickling if the size of an
HTTP file is 3MB or larger. The device forwards 500 bytes of content for every 1MB
sent for scanning.

ScreenOS allows you to configure more granular trickling options if your browser
times out during AV scanning. The browser times out if the security device requires
more time to scan traffic or when the traffic is slow. Based on your environment,
customize the values for time and data to trigger HTTP trickling as follows:

WebUI
Security > Antivirus > Global: Enter the following, then click Apply:

Trickling:
Custom: (select)
Minimum Length to Start Trickling: number1.
Trickle Size: number2.
Trickle for Every KB Sent for Scanning: number3.
Trickle Timeout: number4.

CLI
set av http trickling threshold number1 segment-size number3 trickle-size number2
timeout number4

The four number variables have the following meanings:

 number1: The minimum size (in kilobytes) of an HTTP file required to

trigger trickling. If your browser times out because of a slow download,
then reduce this value to trigger trickling sooner.

 number2: The size (a nonzero value) in bytes of unscanned traffic that the
security device forwards.

86  Antivirus Scanning
 Chapter 4: Content Monitoring and Filtering

 number3: The size (in kilobytes) of a block of traffic to which the security
device applies trickling.

 number4: The time (in seconds) to trigger the trickling event. Time-based
trickling begins when the initial size (number1) is reached. The value 0
indicates that time-based trickling is disabled.

NOTE: Data trickled to the client’s browser appears as a small, unusable file. Because
trickling works by forwarding a small amount of data to a client without scanning
it, virus code might be among the data that the security device has trickled to the
client. We advise users to delete such files.

You can disable HTTP trickling in the WebUI (Security > Antivirus: Click
Disable in the Trickling section) or with the CLI command unset av http
trickling enable. However, if a file being downloaded is larger than 8MB and
HTTP trickling is disabled, the browser window will probably time out.

AV Profiles
Policies use AV profiles to determine which traffic undergoes AV examination and
the actions to take as a result of this examination. ScreenOS supports the following
types of profiles:

 Predefined AV Profiles

ScreenOS supports two predefined profiles: the default, ns-profile (read only)
and scan-mgr profile (read and write). Both profiles are supported for internal
embedded AV only.

The scan-mgr profile is automatically generated for backward compatibility,

when you upgrade from ScreenOS 5.2 or earlier to ScreenOS 5.3 or later. The
scan-mgr profile is generated to migrate the global Scan Manager commands.

The Scan Manager is the AV component that manages the scan engine. For
more information about the Scan Manager options, see “AV Scanner Global
Settings” on page 83.

The scan-mgr profile executes the following commands, so that the

commands are now entered from within a profile context:

set ftp decompress-layer 2

set http decompress-layer 2
set imap decompress-layer 2
set pop3 decompress-layer 2
set smtp decompress-layer 2
set http skipmime enable
set http skipmime mime-list ns-skip-mime-list

For example, the get av profile ns-profile or get av profile scan-mgr

command displays profile settings for the supported protocols:

device->get av profile ns-profile

ftp Setting:
status: enable
mode: scan-intelligent

Antivirus Scanning  87
 Concepts & Examples ScreenOS Reference Guide

decompress layer: 3
timeout: 180 seconds
include ext list: N/A
exclude ext list: N/A
http Setting:
status: enable
mode: scan-intelligent
decompress layer: 2
timeout: 180 seconds
include ext list: N/A
exclude ext list: N/A
skip scanning:text/html;text/css;audio/;video/;image/;
application/x-director
---
 Custom AV profiles

Create your own AV profiles to customize the settings for each protocol. You can
define a maximum of 8 AV profiles for each vsys (and root).

Assigning an AV Profile to a Firewall Policy

Only one AV profile can be linked to a firewall policy. Do the following to link the AV
profile to a firewall policy.

WebUI
Policy > Policies: Click Edit on the policy to which you want to link the AV
profile and select the profile under Antivirus Profile. Click OK.

CLI
device-> set policy id policy_num av ns-profile

The following sections explain how to initiate an AV profile and configure the profile
settings:

 “Initiating an AV Profile for Internal AV” on page 88

 “Example: (Internal AV) Scanning for All Traffic Types” on page 89

 “Example: AV Scanning for SMTP and HTTP Traffic Only” on page 89

 “AV Profile Settings” on page 90

Initiating an AV Profile for Internal AV

The following commands initiate a custom AV profile named jnpr-profile, which by
default is configured to scan FTP, HTTP, IMAP, POP3, and SMTP traffic.

WebUI
Security > Antivirus > Profile: Select New and enter the profile name,
jnpr-profile, then click OK.

CLI
set av profile jnpr-profile
device(av:jnpr-profile)->

device-> set av profile jnpr-profile

device(av:jnpr-profile)->

88  Antivirus Scanning
 Chapter 4: Content Monitoring and Filtering

After you enter an AV profile context, all subsequent command executions modify
the specified AV profile (jnpr-profile).

Example: (Internal AV) Scanning for All Traffic Types

In this example, you configure the AV scanner to examine FTP, HTTP, IMAP, POP3,
IM, and SMTP traffic. Because you anticipate that the scanner will be processing a
lot of traffic, you also increase the timeout from 180 seconds (the default setting) to
300 seconds.

WebUI
Security > Antivirus > Profile: Enter profile_name, then click OK.

By default, traffic for all six protocols is scanned.

NOTE: To change the timeout value, you must use the CLI.

CLI
set av profile jnpr-profile
(av:jnpr-profile)-> set http enable
(av:jnpr-profile)-> set http timeout 300
(av:jnpr-profile)-> set ftp enable
(av:jnpr-profile)-> set ftp timeout 300
(av:jnpr-profile)-> set imap enable
(av:jnpr-profile)-> set imap timeout 300
(av:jnpr-profile)-> set pop3 enable
(av:jnpr-profile)-> set pop3 timeout 300
(av:jnpr-profile)-> set smtp enable
(av:jnpr-profile)-> set smtp timeout 300
(av:jnpr-profile)-> exit
save

Example: AV Scanning for SMTP and HTTP Traffic Only

By default, the AV scanner examines FTP, HTTP, IMAP, POP3, and SMTP traffic. You
can change the default behavior so that the scanner examines specific types of
network traffic only.

You can also change the timeout value for each protocol. By default, an AV scan
operation times out after 180 seconds if the security device does not start scanning
after it receives all the data. The range is 1 to 1800 seconds.

In this example, you configure the AV scanner to examine all SMTP and HTTP
traffic. You return the timeout value for both protocols to their defaults: 180
seconds.

NOTE: The internal AV scanner examines specific HTTP Webmail patterns only. The
patterns for Yahoo!, Hotmail, and AOL mail services are predefined.

WebUI
Security > Antivirus > Select New and enter the profile name jnpr-profile.

Antivirus Scanning  89
 Concepts & Examples ScreenOS Reference Guide

Enter the following, then click OK.

Protocols to be scanned:
HTTP: (select)
SMTP: (select)
POP3: (clear)
FTP: (clear)
IMAP: (clear)

NOTE: To change the timeout value, you must use the CLI.

CLI
set av profile jnpr-profile
(av:jnpr-profile)-> set smtp timeout 180
(av:jnpr-profile)-> set http timeout 180
(av:jnpr-profile)-> unset pop3 enable
(av:jnpr-profile)-> unset ftp enable
(av:jnpr-profile)-> unset imap enable
(av:jnpr-profile)-> exit
save

AV Profile Settings
The following scanning options are configured for each application protocol:

 “Decompressing File Attachments” on page 90

 “AV Scanning Based on File Extensions” on page 91

 “AV Scanning Based on HTTP Content Type” on page 91

 “Notifying Sender and Recipient via Email” on page 92

 “Example: Dropping Large Files” on page 93

Decompressing File Attachments

When the security device receives content, the internal AV scanner decompresses
any compressed files. You can configure the internal AV scanner to decompress up
to four nested compressed files before executing a virus scan.

For example, if a message contains a compressed .zip file that contains another
compressed .zip file, there are two compression layers, and decompressing both
files requires a decompress-layer setting of 2.

WebUI
Security > Antivirus > Profile: Select New or Edit to edit an existing profile.
Update the Decompress Layer to 2, then click Apply.

CLI
set av profile jnpr-profile
(av:jnpr-profile)-> set smtp decompress-layer 2

When transmitting data, some protocols use content encoding. The AV scan engine
needs to decode this layer, which is considered as a decompression level before it
scans for viruses.

90  Antivirus Scanning
 Chapter 4: Content Monitoring and Filtering

AV Scanning Based on File Extensions

ScreenOS supports three modes of scanning:

 scan-all. The AV engine forwards all files to the scan engine for virus scanning.

 scan-intelligent. The AV engine uses a built-in algorithm to decide if files need

to be scanned.

This default scan-intelligent option specifies that the AV engine uses an

algorithm that scans the traffic for the most common and prevalent viruses,
including ensuring the file type is true and that it doesn’t infect other files
directly. Although this option is not as broad in coverage as scan-all, it provides
better performance

 scan-extension. The AV engine forwards files for scanning based on

extensions, exclusive and inclusive list (see the following section).

File-extension lists are used to determine which files undergo AV scanning for a
specific protocol. You can select to Include a file-extension list and Exclude a
file-extension list for each protocol.

A message is scanned when the file extension of a message is in the inclusion

file-extension list. A message is not scanned if the file extension is in the exclusion
file-extension list. If the file extension is not in either file-extension list, then the
scanning decision depends on the default file-extension-scan setting. The default
file extension is in the scan engine database, so it is read-only. Use the get av
scan-mgr command to view the Scan engine default file extension list. There is no
predefined file extension list for each protocol.

Configure the AV scanner to scan IMAP traffic by extensions and exclude files with
the following extensions: .ace, .arj, and .chm.

WebUI
Security > Antivirus > Ext-list >New > Enter an extension-list name (elist1),
and enter the list of extensions (ace;arj;chm). Click OK.

Security > Antivirus >Profile > Select the Profile to Edit > Select IMAP >
Select the following options, then click OK:

Enable
Scan Mode: Scan by Extension
Exclude Extension List: elist1
CLI
set av extension-list elist1 ace;arj;chm
set av profile test1
(av:test1)-> set imap scan-mode scan-ext
(av:test1)-> set imap extension-list exclude elist1

AV Scanning Based on HTTP Content Type

You may use this option to determine which HTTP traffic must undergo AV
scanning. The HTTP traffic is categorized into default predefined Multipurpose
Internet Mail Extensions (MIME) types such as application/x-director,
application/pdf, image, and so on.

Antivirus Scanning  91
 Concepts & Examples ScreenOS Reference Guide

You can configure the AV profile to skip MIME lists containing specific MIME types.
The default predefined MIME list is ns-skip-mime-list. Yahoo Messenger file transfer
ignores the MIME extensions specified in the MIME list because it uses the HTTP
protocol. As part of the HTTP GET/PUT operation, the content-type header is
specified as text or html for all files.

In this example, you configure the security device to scan all kinds of HTTP traffic
regardless of MIME content type:

WebUI
Security > Antivirus > Profile > Select the Profile to Edit> Select HTTP and
clear the Skipmime Enable option. Click OK.

CLI
set av profile jnpr-profile
(av:jnpr-profile)-> unset av http skipmime
(av:jnpr-profile)-> exit
save

For more information about MIME types, see the ScreenOS CLI Reference Guide: IPv4
Command Descriptions.

Notifying Sender and Recipient via Email

The email-notification option applies only to the IMAP, POP3, and SMTP protocols.
You can configure the AV profile to notify senders or recipients scanning errors or
virus information.

When a virus is found in an email message, the content of the warning message
(virus name, source/destination IP) is included in a notification-level message. The
warning-level message is sent via an email through the SMTP protocol.

When a scanning error occurs in a message, the content of the scanning error
message should be included in a warning-level message. This message is sent via an
email through the SMTP protocol.

In this example, you configure the security device to do the following:

 Notify the sender when a virus is detected

 Notify the sender and recipients if scanning errors occur

92  Antivirus Scanning
 Chapter 4: Content Monitoring and Filtering

WebUI
Security > Antivirus > Profile > Select the Profile to Edit> Select IMAP, then
click OK.

Enter the following, then click OK:

Protocols to be scanned:
Email Notify > Select Virus Sender
Email Notify > Select Scan-error Sender
Email Notify > Select Scan-error Recipient
CLI
set av profile jnpr-profile
(av:jnpr-profile)-> set imap email-notify virus sender
(av:jnpr-profile)-> set imap email-notify scan-error sender
(av:jnpr-profile)-> set imap email-notify scan-error recipient
(av:jnpr-profile)-> exit
save

Example: Dropping Large Files

In this example, you configure the AV scanner to decompress HTTP traffic of up to
three files layered within one another. You also configure the scanner to drop
content either if the total number of messages received concurrently exceeds four
messages or if the total decompressed size of the content exceeds the configured
value. The total decompressed file content size that ScreenOS can handle is
device-specific with a minimum of 10 MB.

NOTE: The default value for decompressed file content size is per message and not the
total number of concurrent messages being examined.

The default values for Maximum Concurrent Messages and Maximum Queue size
indicate that the AV scanner can examine a total of 16 concurrent messages at any
specific time. The 17th message is dropped or passed as configured.

WebUI
Security > Antivirus > Scan Manager: Enter the following, then click OK:

Content Oversize: Drop Max Content Size: 3000 KB (20~10000)

Msg Overflow: Drop Max Concurrent messages is 256

Security > Antivirus > Profile: Select Edit > HTTP: Enter the following, then
click OK:

File decompression: 3 layers (1~4)

CLI
set av scan-mgr max-msgs drop
set av scan-mgr max-content-size 3000
set av scan-mgr max-content-size drop
set av profile jnpr-profile
(av:jnpr-profile)-> set http decompress-layer 3
(av:jnpr-profile)-> exit
save

Antivirus Scanning  93
 Concepts & Examples ScreenOS Reference Guide

Anti-Spam Filtering
Spam consists of unwanted email messages, usually sent by commercial, malicious,
or fraudulent entities. The anti-spam feature examines transmitted messages to
identify spam. When the device detects a message deemed to be spam, it either
drops the message or tags the message field with a preprogrammed string.

This anti-spam feature is not meant to replace your anti-spam server, but to
complement it. Configuring this command prevents an internal corporate email
server from receiving and distributing spams. Corporate users retrieve emails from
an internal email server without going through the firewall. This should be a typical
configuration in an enterprise environment.

Juniper Networks anti-spam uses a constantly updated, IP-based, spam-blocking

service that uses information gathered worldwide. Because this service is robust
and yields very few false positives, you are not required to tune or configure
blacklists. However, you have the option of adding specific domains and IPs to local
whitelists or blacklists, which the device can enforce locally.

NOTE: This release supports anti-spam for the SMTP protocol only.

To prevent or reduce the volume of spam messages you receive, you can configure
an anti-spam profile. You can use the profile in policies to detect and filter out
suspected spam messages. An anti-spam profile allows you to designate lists of IP
addresses, emails, hostnames, or domain names identified as malicious (spam) or
benign (non-spam). The anti-spam profile can include lists of the following types:

 Public-based blacklists or whitelists

If the connection is from a mail-forwarding agent, the device can filter the
connection’s source IP address using lists of devices deemed to be benign
(whitelist) or malicious (blacklist).

 Custom defined blacklists or whitelists

 Domain-name-based blacklists or whitelists

The device can use such lists to filter connections that use domain names
deemed to be benign or malicious.

 Address-book-based blacklists or whitelists

The device can use such lists to base filtering on the sender’s email address
or domain. By default, any email server should accept its own user’s email.

Blacklists and Whitelists

The anti-spam feature requires that the firewall have Internet connectivity with the
Spam Block List (SBL) server. Domain Name Service (DNS) must be available to
access the SBL server. The firewall performs reverse DNS lookups on the source of
the SMTP sender (or relaying agent), adding the name of the SBL server (such as
sbl-server) as the authoritative domain. The DNS server then forwards each request
to the SBL server, which returns a value to the firewall.

94  Anti-Spam Filtering
 Chapter 4: Content Monitoring and Filtering

Alternatively, you can configure local whitelists and blacklists. In this case, by
default the system checks first against the local database of whitelists/blacklists. If it
does not find the hostname, the firewall proceeds to query the SBL server located
on the Internet.

Basic Configuration
The following commands provide an example of basic anti-spam configuration
where you are protecting an smtp server (or relay server) from receiving spam
emails.

set anti-spam profile ns-profile

set policy from untrust to trust any mail-server SMTP permit log anti-spam
ns-profile

In the following example, the firewall tests spammer.org to see if it resides on the
whitelist or the blacklist.

exec anti-spam testscan spammer.org

If the blacklist contains spammer.org, the device might produce the following
output:

AS: anti spam result: action Tag email subject, reason: Match local blacklist

Alternatively, if the whitelist contains spammer.org, the device may produce the
following output:

AS: anti spam result: action Pass, reason: Match local whitelist

For information about creating blacklists or whitelists, see “Defining a Blacklist” on

page 96 and “Defining a Whitelist” on page 96.

Filtering Spam Traffic

In the following examples, SMTP traffic that includes spam traverses the security
device. However, ScreenOS checks for spam by either DNS name or IP address.

The following commands provide an example of filtering spam traffic.

device-> exec anti-spam test 2.2.2.2

AS: anti spam result: action Tag email subject, reason: Match local black list
exec anti-spam testscan spammer.org
AS: anti spam result: action Tag email subject, reason: Match local black list

Dropping Spam Messages

Executing the set anti-spam profile ns-profile command without specifying
further options places the CLI within the context of a new or existing anti-spam
profile. For example, the following commands define a profile named ns-profile
and then enter the ns-profile context to instruct the device to drop suspected spam
messages:

device-> set anti-spam profile ns-profile

device(ns-profile)-> set default action drop

Anti-Spam Filtering  95
 Concepts & Examples ScreenOS Reference Guide

After you enter an anti-spam context, all subsequent command executions modify
the specified anti-spam profile (ns-profile in this example). To save your changes,
you must first exit the anti-spam context and then enter the save command:

device(ns-profile)-> exit
device-> save

Defining a Blacklist
Use the black-list commands to add or remove an IP or email address, a hostname,
or a domain name from the local anti-spam blacklist. Each entry in a blacklist can
identify a possible spammer.

To define a blacklist, perform the following steps:

1. Initiate a profile context (ns-profile).

2. Give the profile a blacklist entry that prevents connections with the hostname
www.wibwaller.com.

3. Exit the spam context and apply the profile to an existing policy (id 2).

device-> set anti-spam profile ns-profile

device(anti-spam:ns-profile)-> set blacklist www.wibwaller.com
device(anti-spam:ns-profile)-> exit
device-> set policy id 2 anti-spam ns-profile

Defining a Whitelist
Use the white-list commands to add or remove an IP or email address, a hostname,
or a domain name from the local whitelist. Each entry in a whitelist can identify an
entity that is not a suspected spammer. The following table shows some possible
entries.

To define a whitelist:

1. Initiate a profile context (ns-profile).

2. Give the profile a whitelist entry that allows connections with the hostname
www.fiddwicket.com.

3. Exit the spam context and apply the profile to an existing policy (id 2).

device-> set anti-spam profile ns-profile

device(anti-spam:ns-profile)-> set whitelist www.fiddwicket.com
device(anti-spam:ns-profile)-> exit
device-> set policy id 2 anti-spam ns-profile

Defining a Default Action

Use the default commands to specify how the device handles messages deemed to
be spam. The device can either drop a spam message or identify it as spam by
tagging it.

You can place the tag either in the message header or the subject line.

96  Anti-Spam Filtering
 Chapter 4: Content Monitoring and Filtering

To define the default action for spam, perform the following tasks:

1. Initiate a profile context (ns-profile).

2. Specify that email messages deemed to be spam will have the string “This is
spam” added to the message header.

3. Exit the spam context and apply the profile to an existing policy (id 2).

device-> set anti-spam profile ns-profile

device(anti-spam:ns-profile)-> set default action tag header “This is spam”
device(anti-spam:ns-profile)-> exit
device-> set policy id 2 anti-spam ns-profile

Enabling a Spam-Blocking List Server

Use the sbl command to enable use of the external spam-blocking SBL service,
which uses a blacklist to identify known spam sources. The service replies to
queries from the device about whether an IP address belongs to a known spammer.

Example: These commands perform the following tasks:

1. Initiate a profile context (ns-profile).

2. Enable use of the default anti-spam service.

3. Exit the spam context and apply the profile to an existing policy (id 2).

device-> set anti-spam profile ns-profile

device(anti-spam:ns-profile)-> set sbl default-server-enable
device(anti-spam:ns-profile)-> exit
device-> set policy id 2 anti-spam ns-profile

Testing Anti-Spam
Use the command, exec anti-spam testscan <IP addr> to cause the security device
to scan for known spammer IP addresses.

Example: These commands tests the IP address 12.13.2.3 for spam:

device-> set console dbuf

device-> exec anti-spam testscan 12.13.2.3
device-> get dbuf stream
anti spam result: action Pass, reason: No match

Anti-Spam Filtering  97
 Concepts & Examples ScreenOS Reference Guide

Web Filtering
Web filtering enables you to manage Internet access by preventing access to
inappropriate web content. ScreenOS provides two Web filtering solutions:

 Integrated

Select security devices support an integrated Web filtering solution that

employs Content Portal Authority (CPA) servers from WebSense.

NOTE: Integrated Web filtering requires you to install a license key on your security
device.

Integrated Web filtering allows you to permit or block access to a requested site
by binding a Web filtering profile to a firewall policy. A Web filtering profile
specifies URL categories and the action the security device takes (permit or
block) when it receives a request to access a URL in each category. URL
categories are predefined and maintained by or are user-defined. For
information about configuring the integrated Web filtering feature, see
“Integrated Web Filtering” on page 99.

 Redirect

Select security devices support a Web filtering solution that employs

SurfControl and Websense services to a SurfControl or Websense server.

In redirect Web filtering, the security device sends the HTTP request in a TCP
connection to either a Websense server or a SurfControl server, enabling you to
block or permit access to different sites based on their URLs, domain names,
and IP addresses. For information about configuring the redirect Web filtering
feature, see “Redirect Web Filtering” on page 108.

NOTE: Use integrated Web filtering to manage HTTPS traffic. Redirect Web filtering does
not support HTTPS traffic.

Using the CLI to Initiate Web-Filtering Modes

You can use the WebUI or CLI to configure your security device for Web filtering. If
you are using the CLI, then you perform the following steps to configure either of
the Web filtering solutions:

1. Select the protocol.

For example, the set url protocol type { sc-cpa | scfp | websense } command
selects the protocol.

2. Initiate the Web filtering mode.

Executing the set url protocol { sc-cpa | scfp | websense } command places
the CLI in the Web filtering context. Once you initiate the Web filtering context,
all subsequent command executions apply to that Web filtering mode.

98  Web Filtering
 Chapter 4: Content Monitoring and Filtering

Table 3 shows the commands for entering and exiting the three different Web
filtering modes.

Table 3: Entering and Exiting the Web Filtering Modes

Integrated Redirecting to Redirecting to

Web Filtering SurfControl Server Websense Server
1. Select the set url protocol type sc-cpa set url protocol type scfp set url protocol type websense
protocol
2. Initiate the set url protocol sc-cpa set url protocol scfp set url protocol websense
Web filtering (url:sc-cpa)-> : (url:scfp)-> : (url:websense)-> :
context
3. Exit the Web (url:sc-cpa)-> :exit (url:scfp)-> :exit (url:websense)-> :exit
filtering
mode

Integrated Web Filtering

To enable Web filtering, you first bind a Web filtering profile to a firewall policy.
With integrated Web filtering, the Juniper Networks security device intercepts each
HTTP request, determines whether to permit or block access to a requested site by
categorizing its URL, then matches the URL category to a Web filtering profile. A
Web filtering profile defines the action the security device takes (permit or block)
when it receives a request to access a URL.

A URL category is a list of URLs organized by content. Security devices use the
SurfControl predefined URL categories to determine the category of the requested
URL. SurfControl Content Portal Authority (CPA) servers maintain the largest
database of all types of Web content classified into about 40 categories. A partial list
of the URL categories is shown in “Define URL Categories (Optional)” on page 102.

For a complete list of SurfControl URL categories, visit the Websense website at
http://www.websense.com/global/en/scwelcome.

In addition to the SurfControl predefined URL categories, you can also group URLs
and create categories based on your needs. For information about creating
user-defined categories, see “Define URL Categories (Optional)” on page 102.

Following is the basic sequence of events when a host in the Trust zone tries an
HTTP connection to a server in the Untrust zone:

1. The security device checks for a firewall policy that applies to the traffic:

 If there is no firewall policy for the traffic, the device drops the traffic.

 If there is a firewall policy and if Web filtering is enabled on that policy, the
device intercepts all HTTP requests.

2. The device checks for a user-defined profile bound to the firewall policy. If there
is none, the device then uses the default profile, ns-profile.

3. The device determines if the category of the requested URL is already cached. If
it is not, the device sends the URL to the SurfControl CPA server for
categorization and caches the result.

Web Filtering  99
 Concepts & Examples ScreenOS Reference Guide

4. Once the device determines the category of the URL, it checks for the category
in the Web filtering profile bound to the firewall policy.

 If the category is in the profile, the device blocks or permits access to the
URL as defined in the profile.

 If the category is not in the profile, the device performs the configured
default action.

This section addresses the following integrated Web filtering topics:

 “SurfControl Servers” on page 100

 “Redirect Web Filtering” on page 108

 “Web Filtering Cache” on page 100

 “Configuring Integrated Web Filtering” on page 101

 “Example: Integrated Web Filtering” on page 106

SurfControl Servers
SurfControl has three server locations, each of which serves a specific geographic
area: the Americas, Asia Pacific, and Europe/MiddleEast/Africa. The default primary
server is the Americas, and the default backup server is Asia Pacific. You can change
the primary server, and the security device automatically selects a backup server,
based on the primary server. (The Asia Pacific server is the backup for the Americas
server, and the Americas server is the backup for the other two servers.)

The SurfControl CPA server periodically updates its list of categories. Since the CPA
server does not notify its clients when the list is updated, the security device must
periodically poll the CPA server. By default, the device queries the CPA server for
category updates every two weeks. You can change this default to support your
networking environment. You can also manually update the category list by
entering the Web filtering context and executing the exec cate-list-update
command. To manually update the category list, do the following:

device-> set url protocol sc-cpa

device(url:sc-cpa)-> exec cate-list-update

Web Filtering Cache

By default, the security device caches the URL categories. This action reduces the
overhead of accessing the SurfControl CPA server each time the device receives a
new request for previously requested URLs. You can configure the size and duration
of the cache, according to the performance and memory requirements of your
networking environment. The default cache size is platform-dependent, and the
default timeout is 24 hours.

In the following example, you change the cache size to 500 kilobytes (KB) and the
timeout value to 18 hours.

100  Web Filtering

 Chapter 4: Content Monitoring and Filtering

WebUI
Security > Web Filtering > Protocol Selection > Select Integrated
(SurfControl), then click Apply.

Enable Cache: (select)

Cache Size: 500 (K)
Cache Timeout: 18 (Hours)

CLI
device-> set url protocol sc-cpa
device(url:sc-cpa)-> set cache size 500
device(url:sc-cpa)-> set cache timeout 18
device(url:sc-cpa)-> exit
device-> save

Configuring Integrated Web Filtering

To configure a security device for Web filtering, perform the following steps:

1. “Set Up a Domain Name Server” on page 101

2. “Enable Web Filtering” on page 101

3. “Define URL Categories (Optional)” on page 102

4. “Define Web Filtering Profiles (Optional)” on page 103

5. “Enable Web Filtering Profile and Policy” on page 105

Each step is described in detail in the following sections.

1. Set Up a Domain Name Server

The Juniper Networks security device incorporates Domain Name System (DNS)
support, allowing you to use domain names as well as IP addresses for identifying
locations. You must configure at least one DNS server to enable the security device
to resolve the CPA server name to an address. For more information about DNS, see
“Domain Name System Support” on page 2-217.

2. Enable Web Filtering

You can use the Web UI or CLI commands to enable integrated Web filtering on a
security device. If you use the CLI, you must enter the Web filtering context before
entering the commands specific to integrated Web filtering.

WebUI
Security > Web Filtering > Protocol Selection: Select Integrated (SurfControl),
then click Apply. Then select Enable Web Filtering via CPA Server, and click
Apply again.

CLI
device-> set url protocol type sc-cpa
device-> set url protocol sc-cpa
device(url:sc-cpa)-> set enable
device(url:sc-cpa)-> exit
device-> save

Web Filtering  101

 Concepts & Examples ScreenOS Reference Guide

The device(url:sc-cpa)-> prompt indicates that you have entered the integrated Web
filtering context and can now configure integrated Web filtering parameters.

3. Define URL Categories (Optional)

A category is a list of URLs grouped by content. There are two types of categories:
predefined and user-defined. SurfControl maintains about 40 predefined categories.
A partial list of the URL categories is shown in Table 4 on page 102. For a complete
list and description of each URL category developed by SurfControl, visit the
Websense website at http://www.websense.com/global/en/scwelcome.

To view the list of SurfControl predefined URL categories:

WebUI
Security > Web Filtering > Profiles > Predefined category

CLI
device-> set url protocol type sc-cpa
device-> set url protocol sc-cpa
device(url:sc-cpa)-> get category pre

The URL category list displayed is similar to that shown in Table 4.

Table 4: Partial List of SurfControl URL Categories

Type Code Category Name

Predefine 76 Advertisements
Predefine 50 Arts & Entertainment
Predefine 3001 Chat
Predefine 75 Computing & Internet

The predefined categories list displays the categories and their SurfControl internal
codes. Although you cannot list the URLs within a category, you can determine the
category of a website by using the Test A Site feature on the Websense website at
http://www.websense.com/global/en/scwelcome.

In addition to the SurfControl predefined URL categories, you can group URLs and
create categories specific to your needs. Each category can have a maximum of 20
URLs. When you create a category, you can add either the URL or the IP address of
a site. When you add a URL to a user-defined category, the device performs DNS
lookup, resolves the hostname into IP addresses, and caches this information.
When a user tries to access a site with the IP address of the site, the device checks
the cached list of IP addresses and tries to resolve the hostname.

Many sites have dynamic IP addresses, meaning that their IP addresses change
periodically. A user attempting to access a site can type an IP address that is not in
the cached list on the device. Therefore, if you know the IP addresses of sites you
are adding to a category, enter both the URL and the IP address(es) of the site.

NOTE: If a URL appears in both a user-defined category and a predefined category, the
device matches the URL to the user-defined category.

102  Web Filtering

 Chapter 4: Content Monitoring and Filtering

In the following example, you create a category named Competitors and add the
following URLs: www.games1.com and www.games2.com

WebUI
Security > Web Filtering > Profiles > Custom > New: Enter the following,
then click Apply:

Category Name: Competitors

URL: www.games1.com

Enter the following, then click OK:

URL: www.games2.com

CLI
device-> set url protocol sc-cpa
device(url:sc-cpa)-> set category competitors url www.games1.com
device(url:sc-cpa)-> set category competitors url www.games2.com
device(url:sc-cpa)-> exit
device-> save

4. Define Web Filtering Profiles (Optional)

A Web filtering profile consists of a group of URL categories assigned with one of
the following actions:

 Permit - The security device always allows access to the websites in this
category.

 Block - The security device blocks access to the websites in this category. When
the device blocks access to this category of websites, it displays a message in
your browser indicating the URL category.

You can edit an existing message or create a new message (up to 500
characters) to be sent from the security device. To create or edit a deny
message:

WebUI
Security > Web Filtering > Protocol > Selection: Select Integrated
(SurfControl).

Enter the message in the Web Filter Deny Message text area, then click Apply.

The device displays the following default message:

Your page is blocked due to a security policy that prohibits access to

$URL-CATEGORY.

CLI
device-> set deny-message deny-message-str

 Black List—The security device always blocks access to the websites in this
list. You can create a user-defined category or use a predefined category.

 White List—The security device always allows access to the websites in this
list. You can create a user-defined category or use a predefined category.

Web Filtering  103

 Concepts & Examples ScreenOS Reference Guide

Juniper Networks security devices provide a default profile called ns-profile. This
profile lists the SurfControl predefined URL categories and their actions. You cannot
edit the default profile. To view the predefined profile, use the following command:

WebUI
Security > Web Filtering > Profiles > Predefined

CLI
device-> set url protocol sc-cpa
device(url:sc-cpa)-> get profile ns-profile

The security device displays the predefined profile as illustrated below:

Profile Name: ns-profile

Black-List category: None
White-List category: None
Default Action: Permit
Category Action
Advertisements block
Arts & Entertainment permit
Chat permit
Computing & Internet permit
.
.
.
Violence block
Weapons block
Web-based Email permit
other permit

If the URL in an HTTP request is not in any of the categories listed in the default
profile, the default action of the security device is to permit access to the site.

You can create a custom profile by cloning an existing profile, saving it with a new
name, and then editing the profile. Perform the following step in the WebUI to clone
ns-profile.

WebUI
Security > Web Filtering > Profiles > Custom: ns-profile: Select Clone.

NOTE: You must use the WebUI to clone ns-profile.

You can also create your own Web filtering profile. When you create a Web filtering
profile, you can:

 Add both user-defined and SurfControl predefined URL categories

 Specify a category for the blacklist and/or the whitelist

 Change the default action

104  Web Filtering

 Chapter 4: Content Monitoring and Filtering

In the following example, you create a custom profile called my-profile with a
default action of permit. Then, you take the category you created in the previous
example and add it to my-profile with an action of block.

WebUI
Security > Web Filtering > Profiles > Custom > New: Enter the following,
then click Apply:

Profile Name: my-profile

Default Action: Permit
Select the following, then click OK:
Subscribers Identified by:
Category Name: Competitors (select)
Action: Block (select)
Configure: Add (select)

NOTE: To configure the default action using the CLI, specify the action for the Other
category.

CLI
device-> set url protocol type sc-cpa
device-> set url protocol sc-cpa
device(url:sc-cpa)-> set profile my-profile other permit
device(url:sc-cpa)-> set profile my-profile competitors block
device(url:sc-cpa)-> exit
device-> save

5. Enable Web Filtering Profile and Policy

Firewall policies permit or deny specified types of unidirectional traffic between two
points. (For information about firewall policies, see “Policies” on page 2-159.) You
can enable both antivirus (AV) scanning and integrated Web filtering in a policy. (For
information about AV scanning, see “Antivirus Scanning” on page 62.)

Enable Web filtering in the policy and bind the profile to the policy. When you
enable integrated Web filtering in a policy, the security device intercepts all HTTP
requests. If there is a Web filtering profile bound to the policy, the device matches
the URL in the incoming HTTP request to the categories in the profile in the
following sequence:

1. Blacklist

2. Whitelist

3. User-defined categories

4. SurfControl predefined URL categories

If the device is unable to determine the category of the requested URL, then it
blocks or permits access based on the default configuration in the profile.

Web Filtering  105

 Concepts & Examples ScreenOS Reference Guide

Figure 40: Web Filtering Profiles and Policies Flowchart

HTML request

In N In N In user-defined N In predefined N Default Action -

black-list? white-list? category? category? Block/Permit

Y Y Y Y

Block URL Permit URL Block/Permit as defined Block/Permit as defined

If the device determines that the URL is in a permitted category, and if AV scanning
is enabled for that policy, then the device scans the contents for viruses. If the
device determines that the URL is in a blocked category, it closes the TCP
connection, sends a message alerting the user, and does not perform AV scanning.

Example: Integrated Web Filtering

In this example, you perform the following steps to enable integrated Web filtering
on the security device and block access to the competitor sites.

1. Create a category called Competitors.

2. Add the following URLS to the category: www.comp1.com and www.comp2.com

3. Create a profile called my-profile, and add the Competitors category.

4. Apply my-profile to a firewall policy.

WebUI
1. Web Filtering
Security > Web Filtering > Protocol > Select Integrated (SurfControl), then
click Apply. Then, select Enable Web Filtering via CPA Server, and click Apply
again.

2. URL Category
Security > Web Filtering > Profile > Custom List > New: Enter the following,
then click Apply:

Category Name: Competitors

URL: www.comp1.com

Enter the following, then click OK:

URL: www.comp2.com

106  Web Filtering

 Chapter 4: Content Monitoring and Filtering

3. Web Filtering Profile

Security > Web Filtering > Profile > Custom Profile > New: Enter the
following, then click Apply:

Profile Name: my-profile

Default Action: Permit

Category Name: Competitors (select)

Action: Block (select)
Configure: Add (select)
4. Policy
Policies > (From: Trust, To: Untrust) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), Any
Destination Address:
Address Book Entry: (select), Any
Service: HTTP
Web Filtering: (select), my-profile
Action: Permit

CLI
1. Web Filtering
device->set url protocol sc-cpa
device(url:sc-cpa)-> set enable
2. URL Category
device(url:sc-cpa)-> set category competitors url www.comp1.com
device(url:sc-cpa)-> set category competitors url www.comp2.com
3. Web Filtering Profile
device(url:sc-cpa)-> set profile my-profile other permit
device(url:sc-cpa)-> set profile my-profile competitors block
device(url:sc-cpa)-> exit
4. Firewall Policy
device-> set policy id 23 from trust to untrust any any http permit url-filter
device-> set policy id 23
device(policy:23)-> set url protocol sc-cpa profile my-profile
device(policy:23)-> exit
device-> save

Web Filtering  107

 Concepts & Examples ScreenOS Reference Guide

Redirect Web Filtering

Juniper Networks security devices support redirect Web filtering using either the
Websense Enterprise Engine or the SurfControl Web Filter, both of which enable
you to block or permit access to different sites based on their URLs, domain names,
and IP addresses. The security device can link directly to a Websense or SurfControl
Web filtering server.

NOTE: For additional information about Websense, visit

http://www.websense.com/global/en. For additional information about
SurfControl, visit http://www.websense.com/global/en/scwelcome.

Figure 41 shows the basic sequence of events when a host in the Trust zone
attempts an HTTP connection to a server in the Untrust zone. However, Web
filtering determines that the requested URL is prohibited.

Figure 41: A Blocked URL from Trust Zone to Untrust Zone

set policy from trust to untrust Web Filtering Server
any any http permit web-filter (in Trust Zone)

HTTP Client Web Filter Web Filter

Request HTTP Server
Reply: “block”

Trust Zone Untrust Zone

TCP Three-Way SYN
Handshake SYN/ACK
ACK
HTTP Get
Request HTTP GET
The security device intercepts and buffers the
HTTP GET request. It then sends the requested
URL to the Web filtering server. The web-
filtering server replies with a “block” message.
Blocked URL
Message BLCK URL
TCP RST RST RST
The security device drops the HTTP packet and
sends the source a “blocked URL” message. It
closes the connection, sending a TCP RST to the
source and destination addresses.

If the server permits access to the URL, the sequence of events in the HTTP
connection attempt proceeds as shown in Figure 42.

108  Web Filtering

 Chapter 4: Content Monitoring and Filtering

Figure 42: A Permitted URL from Trust Zone to Untrust Zone

set policy from trust to untrust Web Filtering Server
any http permit url-filter (in Trust Zone)

URL Filter URL Filter

HTTP Client Reply: “permit” HTTP Server
Request

Trust Zone Untrust Zone

TCP Three-Way SYN
Handshake SYN / ACK
ACK
HTTP Get HTTP GET
Request
The security device intercepts and buffers the HTTP GET
request. It then sends the requested URL to the URL-filtering
server. The Web filtering-server replies with a “permit” message.
Forwards HTTP HTTP GET
GET Request
HTTP Response

See the following sections for more details on redirect Web filtering:

 “Virtual System Support” on page 109

 “Configuring Redirect Web Filtering” on page 110

 “Example: Redirect Web Filtering” on page 113

Virtual System Support

Security devices with virtual systems (vsys) support up to eight Web filtering
servers—one server reserved for the root system, which can be shared with an
unrestricted number of virtual systems, and seven Web filtering servers for private
use by the virtual systems. A root-level administrator can configure the Web filtering
module at the root and vsys levels. A vsys-level administrator can configure the URL
module for his or her own vsys if that vsys has its own dedicated Web filtering
server. If the vsys-level administrator uses the root Web filtering server settings, that
administrator can view—but not edit—the root-level Web filtering settings.

Alternatively, devices with virtual systems that use Websense Web filtering servers
can share all eight Websense servers, not just the root server. Each Websense server
can support an unrestricted number of virtual systems, allowing you to balance the
traffic load among the eight servers.

Web Filtering  109

 Concepts & Examples ScreenOS Reference Guide

To configure multiple virtual systems to connect to a Websense Web filtering server,

the root-level or vsys administrator must perform the following steps:

1. Create a account name for each vsys. Use the following CLI command:

device-> set url protocol type websense

device-> set url protocol websense
device(url:websense)-> set account name

When a host in a vsys sends out a URL request, it includes the account name.
This name enables the Websense server to identify which vsys sent the URL
request.

2. Configure the same Web filtering server settings and system-level parameters
for each vsys that shares a Websense Web filtering server. The next section
contains information about configuring Web filtering settings and parameters.

Configuring Redirect Web Filtering

To configure a security device to perform redirected Web filtering, follow these
steps:

1. Set Up a Domain Name System (DNS) Server

The Juniper Networks security device incorporates Domain Name System (DNS)
support, allowing you to use domain names as well as IP addresses for identifying
locations. You must configure at least one DNS server to enable the security device
to resolve the CPA server name to an address. For more information about DNS, see
“Domain Name System Support” on page 2-217.

2. Set Up Communication with the Web Filtering Servers

Configure the security device to communicate with one of the following servers:

 Websense server

 SurfControl server using the SurfControl Content Filtering Protocol (SCFP)

You can set up communications with up to eight Web filtering servers.

WebUI
Security > Web Filtering > Protocol > Select Redirect (Websense) or Redirect
(SurfControl), then click Apply.

CLI
Enter the Web filtering context for SurfContol (scfp) or Websense (websense)
redirect filtering. For more information, see “Using the CLI to Initiate
Web-Filtering Modes” on page 98.

device-> set url protocol type { websense | scfp }

device-> set url protocol { websense | scfp }
device(url:scfp)-> set server { ip_addr | dom_name } port_num timeout_num

110  Web Filtering

 Chapter 4: Content Monitoring and Filtering

Configure the following Web filtering settings at the system level for Web filtering
server communication:

 Source Interface: The source from which the device initiates web-filter requests
to a Web filtering server.

 Server Name: The IP address or Fully Qualified Domain Name (FQDN) of the
computer running the Websense or SurfControl server.

 Server Port: If you have changed the default port on the server, you must also
change it on the security device. (The default port for Websense is 15868, and
the default port for SurfControl is 62252.) Please refer to your Websense or
SurfControl documentation for full details.

 Communication Timeout: The time interval, in seconds, that the device waits
for a response from the Web filtering server. If the server does not respond
within the time interval, the device either blocks or allows the request. For the
time interval, enter a value from 10 through 240.

If a device with multiple virtual systems connects to a Websense server, the virtual
systems can share the server. To configure multiple virtual systems to share a
Websense server, use the following CLI commands to create an account name for
each vsys:

device-> set url protocol type websense

device-> set url protocol websense
device(url:websense)-> set account name

Once you have configured the vsys names, you define the settings for the Web
filtering server and the parameters for the behavior that you want the security
device to take when applying Web filtering. If you configure these settings in the
root system, they also apply to any vsys that shares the Web filtering configuration
with the root system. For a vsys, the root and vsys administrators must configure
the settings separately. Virtual systems that share the same Websense Web filtering
server must have the same Web filtering settings.

3. Enable Web Filtering at the Root and Vsys Levels

You must enable Web filtering at the system level. For a device that is hosting virtual
systems, enable Web filtering for each system that you want to apply it. For
example, if you want the root system and a vsys to apply Web filtering, enable Web
filtering in both the root system and that vsys.

To enable Web filtering, do either of the following:

WebUI
Security > Web Filtering > Protocol > Select Redirect (Websense) or Redirect
(SurfControl), then click Apply.
Enable Web Filtering check box.

CLI
device-> set url protocol type { websense | scfp }
device-> set url protocol { websense | scfp }
device(url:scfp)-> set config enable

Web Filtering  111

 Concepts & Examples ScreenOS Reference Guide

When Web filtering is enabled at the system level, HTTP requests are redirected to a
Websense or SurfControl server. This action allows the device to check all HTTP
traffic for policies (defined in that system) that require Web filtering. If you disable
Web filtering at the system level, the device ignores the Web filtering component in
policies and treats the policies as “permit” policies.

4. Define the System-Level Behavioral Parameters

Define the parameters that you want the system—root or vsys—to use when
applying Web filtering. One set of parameters can apply to the root system and any
vsys that shares the Web filtering configuration with the root system. Other sets can
apply to virtual systems that have a dedicated Web filtering server.

The options are as follows:

 If connectivity to the server is lost: If the security device loses contact with the
Web filtering server, you can specify whether to Block or Permit all HTTP
requests.

 Blocked URL Message Type: If you select NetPartners Websense/SurfControl,

the security device forwards the message it receives in the “block” response
from the Websense or SurfControl server. When you select Juniper Networks,
the device sends the message that you have previously entered in the Juniper
Networks Blocked URL Message field.

NOTE: If you select Juniper Networks, some of the functions that Websense provides,
such as redirection, are suppressed.

 Juniper Networks Blocked URL Message: This is the message the security
device returns to the user after blocking a site. You can use the message sent
from the Websense or SurfControl server, or you can create a message (up to
500 characters) to be sent from the device.

To configure these settings, use either of the following:

WebUI
Security > Web Filtering > Protocol > Select Redirect (Websense) or Redirect
(SurfControl), then click Apply.

CLI
device-> set url protocol type { websense | scfp }
device-> set url protocol { websense | scfp }
device(url:scfp)-> set fail-mode permit
device(url:scfp)-> set deny-message use-server

112  Web Filtering

 Chapter 4: Content Monitoring and Filtering

5. Enable Web Filtering in Individual Policies

Configure the device to contact the Web filtering server based on the policy.

To enable Web filtering in a policy, use either of the following:

WebUI
Policy > Policies > Click Edit (edit the policy that you want Web filtering to
apply), then select the Web Filter check box.
Select the Web filtering profile from the drop-down box.

CLI
set policy from zone to zone src_addr dst_addr service permit url-filter

NOTE: The device reports the status of the Websense or SurfControl server. To update the
status report, click the Server Status icon in the WebUI:

Security > Web Filtering > Protocol > Select Redirect (Websense) or Redirect
(SurfControl), then click Apply.

Example: Redirect Web Filtering

In this example, you configure the security device to do the following:

1. Set the interfaces to work with a SurfControl server at IP address 10.1.2.5, with
port number 62252 (default), and have the Web filtering server in the Trust
security zone.

2. Enable Web filtering on all outbound HTTP traffic from hosts in the Trust zone
to hosts in the Untrust zone. If the device loses connectivity with the Web
filtering server, the device permits outbound HTTP traffic. When an HTTP client
requests access to a prohibited URL, the device sends the following message:
“We’re sorry, but the requested URL is prohibited. Contact
[email protected].”

3. Set both security zones to be in the trust-vr routing domain with the interface
for the Untrust zone as ethernet3, IP address 1.1.1.1/24, and the interface for
the Trust zone as ethernet1, IP address 10.1.1.1/24. Because the Web filtering
server is not in the immediate subnet of one of the device interfaces, a route is
added to it through ethernet1 and the internal router at 10.1.1.250.

4. Configure the policy to enable Web filtering so that Trust to Untrust permits
HTTP service from any source address to any destination address.

Web Filtering  113

 Concepts & Examples ScreenOS Reference Guide

WebUI
1. Interfaces
Network > Interfaces > List >Edit (for ethernet1): Enter the following, then
click Apply:

Zone Name: Trust

Static IP: (select this option when present)
IP Address/Netmask: 10.1.1.1/24

Enter the following, then click OK:

Interface Mode: NAT

Network > Interfaces > List >Edit (for ethernet3): Enter the following, then
click OK:

Zone Name: Untrust

Static IP: (select this option when present)
IP Address/Netmask: 1.1.1.1/24
2. Web Filtering Server
Security > Web Filtering > Protocol: Select Redirect (SurfControl), then click
Apply. Then enter the following, and click Apply again:

Enable Web Filtering: (select)

Server Name: 10.1.2.5
Server Port: 62252
Communication Timeout: 10 (seconds)
If connectivity to the server is lost … all HTTP requests: Permit
Blocked URL Message Type: Juniper Networks
Juniper Blocked URL Message: We’re sorry, but the requested URL is
prohibited. Contact [email protected].
3. Routes
Network > Routing > Destination > trust-vr New: Enter the following, then
click OK:

Network Address/Netmask: 0.0.0.0/0

Gateway: (select)
Interface: ethernet3
Gateway IP Address: 1.1.1.250

Network > Routing > Destination > trust-vr New: Enter the following, then
click OK:

Network Address/Netmask: 10.1.2.0/24

Gateway: (select)
Interface: ethernet1
Gateway IP Address: 10.1.1.250

114  Web Filtering

 Chapter 4: Content Monitoring and Filtering

4. Policy
Policy > Policies > (From: Trust, To: Untrust) New: Enter the following, then
click OK:

Source Address:
Address Book Entry: (select), Any
Destination Address:
Address Book Entry: (select), Any
Service: HTTP
Action: Permit
Web Filtering: (select)

CLI
1. Interfaces
set interface ethernet1 zone trust
set interface ethernet1 ip 10.1.1.1/24
set interface ethernet3 zone untrust
set interface ethernet3 ip 1.1.1.1/24
2. Web Filtering Server
device-> set url protocol type scfp
device-> set url protocol scfp
device(url:scfp)-> set server 10.1.2.5 62252 10
device(url:scfp)-> set fail-mode permit
device(url:scfp)-> set deny-message “We’re sorry, but the requested URL is
prohibited. Contact [email protected].”
device(url:scfp)-> set config enable
3. Routes
set vrouter trust-vr route 0.0.0.0/0 interface ethernet3 gateway 1.1.1.250
set vrouter trust-vr route 10.1.2.0/24 interface ethernet1 gateway 10.1.1.250
4. Policy
set policy from trust to untrust any any http permit url-filter
save

Web Filtering  115

 Concepts & Examples ScreenOS Reference Guide

116  Web Filtering

Chapter 5
Deep Inspection

You can enable deep inspection (DI) in policies to examine permitted traffic and
take action if the DI module in ScreenOS finds attack signatures or protocol
anomalies. The following sections present the DI elements that appear in policies
and explains how to configure them:

 “Overview” on page 118

 “Attack Object Database Server” on page 122

 “Attack Objects and Groups” on page 130

 “Supported Protocols” on page 131

 “Stateful Signatures” on page 134

 “TCP Stream Signatures” on page 135

 “Protocol Anomalies” on page 135

 “Attack Object Groups” on page 136

 “Disabling Attack Objects” on page 139

 “Attack Actions” on page 140

 “Brute Force Attack Actions” on page 148

 “Attack Logging” on page 151

 “Mapping Custom Services to Applications” on page 153

 “Customized Attack Objects and Groups” on page 157

 “User-Defined Stateful Signature Attack Objects” on page 157

 “TCP Stream Signature Attack Objects” on page 161

 “Configurable Protocol Anomaly Parameters” on page 163

 “Negation” on page 164

 117
 Concepts & Examples ScreenOS Reference Guide

You can also enable DI at the security zone level for HTTP components. These
SCREEN options are explained in the final section of this chapter:

 “Granular Blocking of HTTP Components” on page 168

 “ActiveX Controls” on page 169

 “Java Applets” on page 169

 “EXE Files” on page 169

 “ZIP Files” on page 169

Overview
Deep inspection (DI) is a mechanism for filtering the traffic permitted by the Juniper
Networks firewall. DI examines Layer 3 and Layer 4 packet headers and Layer 7
application content and protocol characteristics in an effort to detect and prevent
any attacks or anomalous behavior that might be present. Figure 43 shows how a
packet undergoes Layer 3 inspection.

NOTE: Juniper Networks security devices detect anomalous traffic patterns at Layer 3 and
Layer 4 (IP and TCP) via SCREEN options set at the zone level, not the policy level.
Examples of IP and TCP traffic-anomaly detection are “IP Address Sweep” on
page 8, “Port Scanning” on page 9, and the various flood attacks described in
“Network DoS Attacks” on page 38.

118  Overview
 Chapter 5: Deep Inspection

Figure 43: Stateful Firewall Inspection

Stateful firewall inspection Does an initial packet in a session

Match? No match the L3 and L4 requirements
of a policy?
Drop
packet Or...
Yes
Does the state of a packet in an
existing session match the
expectations in the session table?

Permit? No Does the policy permit or deny

this packet?
Drop
packet
Yes

Stateful signature, protocol anomaly,

and (on some security devices) DI? Attack
TCP stream inspection Yes found? Yes

Perform attack
response action
No No

Forward packet

When the security device receives the first packet of a session, it inspects the
source and destination IP addresses in the IP packet header (Layer 3 inspection)
and the source and destination port numbers and protocol in the TCP segment
or UDP datagram header (Layer 4 inspection). If the Layer 3 and 4 components
match the criteria specified in a policy, the device then performs the specified
action on the packet—permit, deny, or tunnel. When the device receives a
packet for an established session, it compares it with the state information
maintained in the session table to determine if it belongs to the session.

NOTE: If the specified action is tunnel, the notion of permission is implied. Note that if
you enable DI in a policy whose action is tunnel, the security device performs the
specified DI operations before encrypting an outbound packet and after
decrypting an inbound packet.

If you have enabled DI in the policy that applies to this packet and the policy action
is “permit” or “tunnel,” then the security device further inspects it and its
associated data stream for attacks. It scans the packet for patterns that match those
defined in one or more groups of attack objects. Attack objects can be attack
signatures or protocol anomalies, which you can either define yourself or download
to the security device from a database server. (For more information, see “Attack
Objects and Groups” on page 130 and “Customized Attack Objects and Groups” on
page 157.)

Overview  119
 Concepts & Examples ScreenOS Reference Guide

NOTE: The deep inspection (DI) feature is available after you have obtained and loaded
an advanced mode license key. (If you upgrade from a pre-5.0.0 version of
ScreenOS, the mode automatically becomes “advanced.” In this case, an
advanced-mode license key is not required.) The ability to download signature
packs from the database server requires that you first subscribe for the service. For
more information, see “Registration and Activation of Subscription Services” on
page 2-251.

Based on the attack objects specified in the policy, the security device might
perform the following inspections (see Figure 44):

 Examine header values and payload data for stateful attack signatures

 Compare the format of the transmitted protocol with the standards specified in
the RFCs and RFC extensions for that protocol to determine if someone has
altered it, possibly for malicious purposes

Figure 44: Firewall Inspection Versus Deep Inspection

First: Firewall Inspection (Network Layers): Then: Deep Inspection (Network and Application Layers):
SRC IP, DST IP, SRC Port, DST Port, SRC IP, DST IP, SRC Port, DST Port,
and Service (Protocol) Service (Protocol), and Payload Data

Firewall Deep Inspection

SRC IP DST IP SRC PT DST PT PROTO SRC IP DST IP SRC PT DST PT PROTO
Payload Data Payload Data

If the security device detects an attack, it performs the action specified for the
attack object group to which the matching attack object belongs: close, close-client,
close-server, drop, drop-packet, ignore, or none. If it does not find an attack, it
forwards the packet. (For more information about attack actions, see “Attack
Actions” on page 140.)

You can conceptually separate a set policy command into two parts—the core
section and the DI component:

 The core section contains the source and destination zones, source and
destination addresses, one or more services, and an action.

 The DI component instructs the security device to inspect traffic permitted by

the core section of the policy for patterns matching the attack objects contained
in one or more attack object groups. If the security device detects an attack
object, it then performs the action defined for the corresponding group.

120  Overview
 Chapter 5: Deep Inspection

NOTE: You can optionally add other extensions to the core component of a set policy
command: VPN and L2TP tunnel references, a schedule reference, address
translation specifications, user authentication specifications, antivirus checking,
logging, counting, and traffic management settings. Whereas these extensions are
optional, the elements that constitute the core of a policy—source and destination
zones, source and destination addresses, service (or services), and action—are
required. (An exception to this is a global policy, in which no source and
destination zones are specified: set policy global src_addr dst_addr service action.
For more information about global policies, see “Global Policies” on page 2-162.)

The following set policy command includes a DI component:

Figure 45: DI Component in the set policy Command

Core Section of a Policy Deep Inspection Component

set policy id 1 from untrust to dmz any websrvl http permit attack HIGH:HTTP:ANOM action close

Source Source Service Attack

Zone Address Group Action if the
security device
Destination Destination Action if traffic matches L3 detects an attack
Zone Address and L4 components

The above command directs the security device to permit HTTP traffic from any
address in the Untrust zone to the destination address “websrv1” in the DMZ zone.
It also instructs the device to inspect all HTTP traffic permitted by this policy. If any
pattern in the traffic matches an attack object defined in the attack object group
“HIGH:HTTP:ANOM”, the device closes the connection by dropping the packet and
sending TCP RST notifications to the hosts at the source and destination addresses.

It is possible to enter the context of an existing policy by using its ID number. For
example:

device-> set policy id 1

device(policy:1)->

NOTE: The command prompt changes to signal that the subsequent command will be
within a particular policy context.

Overview  121
 Concepts & Examples ScreenOS Reference Guide

Entering a policy context is convenient if you want to enter several commands

related to a single policy. For example, the following set of commands creates a
policy that permits HTTP and HTTPS traffic from the any address in the Untrust to
websrv1 and websrv2 in the DMZ zone and looks for high and critical HTTP stateful
signature and protocol anomaly attacks:

device-> set policy id 1 from untrust to dmz any websrv1 http permit attack
CRITICAL:HTTP:ANOM action close
device-> set policy id 1
device(policy:1)-> set dst-address websrv2
device(policy:1)-> set service https
device(policy:1)-> set attack CRITICAL:HTTP:SIGS action close-server
device(policy:1)-> set attack HIGH:HTTP:ANOM action drop
device(policy:1)-> set attack HIGH:HTTP:SIGS action close-server
device(policy:1)-> exit
device-> save

The above configuration permits both HTTP and HTTPS traffic, but only looks for
attacks in HTTP traffic. To be able to add attack object groups within a policy
context, you must first specify a DI attack and action in the top-level command. In
the above example, you can add CRITICAL:HTTP:SIGS, HIGH:HTTP:ANOM, and
HIGH:HTTP:SIGS attack object groups because you first configured the policy for DI
with the CRITICAL:HTTP:ANOM group.

NOTE: You can specify a different attack action for each attack object group in a policy. If
the security device simultaneously detects multiple attacks, it applies the most
severe action, which in the above example is “close.” For information about the
seven attack actions, including their severity levels, see “Attack Actions” on
page 140.

Attack Object Database Server

The attack object database server contains all the predefined attack objects,
organized into attack object groups by protocol and severity level. Juniper Networks
stores the attack object database on a server at
https://services.juniper.net/restricted/sigupdates.

Predefined Signature Packs

The attack object database is organized into four signature packs: base, server
protection, client protection, and worm mitigation. This approach is ideal because
of the limited device memory and increased protocol support in the signature
packs. Table 5 describes each of the predefined signature packs and the threat
coverage.

122  Attack Object Database Server

 Chapter 5: Deep Inspection

Table 5: Predefined Signature Packs

Signature Pack Description Threat Coverage

Base1 A selected set of signatures for client/server and Includes a sample of worm, client-to-server, and
worm protection optimized for remote and server-to-client signatures for Internet-facing
branch offices along with small/medium protocols and services, such as HTTP, DNS, FTP,
businesses. SMTP, POP3, IMAP, NetBIOS/SMB, MS-RPC, P2P, and
IM (AIM, YMSG, MSN, and IRC).
Server protection For small/medium enterprises and remote and Primarily focuses on protecting a server farm. It
branch offices of large enterprises needing includes a comprehensive set of server-oriented
perimeter defense and compliance for server protocols, such as HTTP, DNS, FTP, SMTP, IMAP,
infrastructure, such as IIS, and Exchange. MS-SQL, and LDAP. Also includes worm signatures
that target servers.
Client protection For small/medium enterprises and remote and Primarily focuses on protecting users from getting
branch offices of large enterprises needing malware, Trojans, and so on while surfing the
perimeter defense and compliance for hosts Internet. Includes a comprehensive set of
(desktops, laptops, and so on). client-oriented protocols, such as HTTP, DNS, FTP,
IMAP, POP3, P2P, and IM (AIM, YMSG, MSN, and
IRC). Also includes worm signatures that target
clients.
Worm Mitigation For remote and branch offices of large Includes stream signatures and primarily focuses on
enterprises along with small/medium businesses providing comprehensive worm protection. Detects
to provide the most comprehensive defense server-to-client and client-to-server worm attacks for
against worm attacks. all protocols.

1.Due to memory allocation required for new enhancements, only DI signatures of critical severity are provided for NS-5XT/GT
devices.

Table 6 lists the predefined signatures packs with the corresponding URLs.

Table 6: URLs for Predefined Signature Packs

Signature Pack URL

Base (default) https://services.juniper.net/restricted/sigupdates
The security device uses this URL by default.
Server https://services.juniper.net/restricted/sigupdates/server
Client https://services.juniper.net/restricted/sigupdates/client
Worm-mitigation https://services.juniper.net/restricted/sigupdates/worm

Updating Signature Packs

Juniper Networks stores the four predefined signature packs on an attack object
database server at https://services.juniper.net/restricted/sigupdates. To gain access
to this database server, you must first subscribe to the DI signature service for your
device as described in the next section.

There are four ways to update the database:

 “Immediate Update” on page 124

 “Automatic Update” on page 125

 “Automatic Notification and Immediate Update” on page 126

 “Manual Update” on page 127

Attack Object Database Server  123

 Concepts & Examples ScreenOS Reference Guide

NOTE: You can also use NetScreen-Security Manager to download the signature packs.
For information, see the NetScreen-Security Manager Administration Guide.

Before You Start Updating Attack Objects

Before you start downloading and updating attack objects, you must do the
following:

1. Register your security device and obtain an authorization code.

2. Purchase a license key and activate a subscription for DI.

3. Verify that the system clock and the Domain Name System (DNS) settings on
your device are accurate.

For more information, see “Registration and Activation of Subscription Services” on

page 2-251.

WebUI
Configuration > Date/Time

Network > DNS > Host

4. Click the Update Now button.

Note that this option is only available after you retrieve a DI subscription key.

The security device then attempts to contact the server at the default URL:
https://services.juniper.net/restricted/sigupdates; or, if you have entered a
different URL in the Database Server field, it attempts to contact the URL that
you entered. Table 6 on page 123 lists the predefined signatures packs and the
corresponding URLs.

After a few moments, a message appears indicating whether the update was
successful. If the update was unsuccessful, then check the event log to
determine the cause of the failure.

NOTE: After you download the signature pack the first time, you must reset the security
device. Following each download thereafter, resetting the device is unnecessary.

Immediate Update
The Immediate Update option allows you to update the signature pack on the
security device immediately with the signature pack stores on the database server.
For this operation to work, you must first configure the attack object database
server settings.

In this example (see Figure 46), you save a predefined signature pack from the
attack object database server to the security device immediately.

You do not set a schedule for updating the database on the security device. Instead,
you save the database from the server to the security device immediately.

124  Attack Object Database Server

 Chapter 5: Deep Inspection

Figure 46: Updating DI Signatures Immediately

Attack Object
Local Security Device
Database Server
1. Update Request

Internet

Attack Object 2. Database Update Attack Object https://services.juniper.net/

Database Database restricted/sigupdates

WebUI
Configuration > Update > Attack Signature:
Signature Pack: Client
Click the Update Now button.

CLI
set attack db sigpack client
exec attack-db update
Loading attack database.............
Done.
Done.
Switching attack database...Done
Saving attack database to flash...Done.

Automatic Update
The Automatic Update option, downloads the signature pack at user-scheduled
times if the database on the server is a newer version than that previously loaded
on the device. Juniper Networks regularly updates the signature pack with newly
discovered attack patterns. Therefore, because of its changing nature, you must also
update the signature pack on your security device regularly. For this operation to
work, you must first configure the attack object database server settings.

In this example (see Figure 47), you set a schedule to update the database on the
security device every Monday at 04:00 AM. At that scheduled time, the device
compares the version of the database on the server with that on the device. If the
version on the server is more recent, the security device automatically replaces its
database with the newer version.

For example, select Server to update the server signature pack. See Table 6 on
page 123 for a list of predefined signatures packs and the corresponding URLs.

Attack Object Database Server  125

 Concepts & Examples ScreenOS Reference Guide

Figure 47: Updating DI Signatures Automatically

Attack Object
Local Security device Database Server
1. Automatic Update Check

S M T W T F S

Internet

Attack Object 2. Immediate Database Update Attack Object https://services.juniper.net/

Database Database restricted/sigupdates

WebUI
Configuration > Update > Attack Signature: Enter the following, then click OK:

Signature Pack: Server

Update Mode: Automatic Update
Schedule:
Weekly on: Monday
Time (hh:mm): 04:00

NOTE: If you schedule monthly updates and the date you choose does not occur in a
particular month (for example, 31), the security device uses the last possible date
of the month in its place.

CLI
set attack db sigpack server
set attack db mode update
set attack db schedule weekly monday 04:00
save

Automatic Notification and Immediate Update

The Automatic Notification and Immediate Update option allows you to check at
user-scheduled times if the data on the database server is more recent than that on
the security device. If the data on the server is more recent, a notice appears on the
Home page in the WebUI, and in the CLI after you log into the security device. You
can then enter the exec attack-db update command or click the Update Now button
on the Configuration > Update > Attack Signature page in the WebUI to save the
signature pack from the server to the device. For the server-checking operation
semi-automatic procedure to work, you must first configure the attack object
database server settings.

In this example (see Figure 48), you set a schedule to check the database on the
security device every day at 07:00 AM.

When you receive a notice that the database on the server has been updated, you
click the Update Now button on the Configuration > Update > Attack Signature
page in the WebUI or enter the exec attack-db update command to save the
database from the server to the device.

For example, do the following to update the Client signature pack. See Table 6 on
page 123 for a list of predefined signatures packs and the corresponding URLs.

126  Attack Object Database Server

 Chapter 5: Deep Inspection

Figure 48: Notifying Signature Updates

Local Security device Attack Object

Database Server
1. Automatic Update Check

S M T W T F S

Internet

https://services.juniper.net/
restricted/sigupdates
Attack Object 2. Immediate Database Update Attack Object
Database Database

WebUI
1. Scheduled Database Checking
Configuration > Update > Attack Signature: Enter the following, then click OK:

Signature Pack: Client

Update Mode: Automatic Notification
Schedule:
Daily
Time (hh:mm): 07:00
2. Immediate Database Update
When you receive a notice that the attack database on the server is more
current than the one on the security device, do the following:

Configuration > Update > Attack Signature

Signature pack: Client

Click the Update Now button.

CLI
1. Scheduled Database Checking
set attack db sigpack client
set attack db mode notification
set attack db schedule daily 07:00
2. Immediate Database Update
When you receive a notice that the attack database on the server is more
current than the one on the security device, do the following:

exec attack-db update

Manual Update
The Manual Update option, allows you to first use a browser to download the
signature pack to a local directory or TFTP server directory. You can then load the
signature pack on the security device using either the WebUI (from the local
directory) or CLI (from the TFTP server directory).

Attack Object Database Server  127

 Concepts & Examples ScreenOS Reference Guide

NOTE: Before performing an immediate database update, you can use the exec attack-db
check command to check if the attack object database on the server is more
recent than the one on the security device.

In this example (see Figure 49), you manually save the latest signature pack to the
local directory “C:\netscreen\attacks-db” (if you want to use the WebUI to load the
database) or C:\Program Files\TFTP Server (if you want to use the CLI to load it). You
then load the database on the security device from your local directory.

NOTE: After downloading the signature pack, you can also post it on a local server and
set it up for other security devices to access. The admins for the other devices
must then change the database server URL to that of the new location. They can
either enter the new URL in the Database Server field on the Configuration >
Update > Attack Signature page or use the following CLI command: set attack db
server url_string.

For an automatic update, the security device automatically adds the following
elements to the URL:

 Serial number of the security device

 Number of the major ScreenOS version running on the device

 Platform type

When you manually update the DI Signatures, you must add these elements
yourself. In this example, the serial number is 0043012001000213, the ScreenOS
version is 5.4, and the platform is NetScreen-208 (ns200). Consequently, the
resulting URL is:

https://services.juniper.net/restricted/sigupdates/5.4/ns200/attacks.bin?sn=0
043012001000213

Figure 49: Updating DI Signatures Manually

Attack Object
Database Server

Local Security device 1. Manual Database Download

Internet
2. Manual
Database URL = https://services.juniper.net/
Attack Object Update Attack Object /restricted/sigupdates/5.4/ns200/attacks
Database Database .bin?sn=0043012001000213
Admin: 10.1.1.5
C:\netscreen\attacks-db
C:\Program Files\TFTP Server

128  Attack Object Database Server

 Chapter 5: Deep Inspection

1. Downloading the Signature Pack

To save the signature pack to your local server, enter the following URL in the
address field of your browser. See Table 6 on page 123 for a list of predefined
signatures packs and the corresponding URLs.

https://services.juniper.net/restricted/sigupdates/5.4/ns200/attacks.bin?sn=0
043012001000213

Save attacks.bin to the local directory “C:\netscreen\attacks-db” (for loading via

the WebUI) or to your TFTP server directory C:\Program Files\TFTP Server
(when you want to use the CLI to load it).

2. Updating the Signature Pack

WebUI
Configuration > Update > Attack Signature: Enter the following, then click OK:

Deep Inspection Signature Update:

Load File: Enter C:\netscreen\attacks-db\attacks.bin

Or

Click Browse and navigate to that directory, select attacks.bin, then click
Open.

If you downloaded the server, client, or worm protection signature packs, then
enter the appropriate filename.

CLI
save attack-db from tftp 10.1.1.5 attacks.bin to flash

Updating DI Patterns from a Proxy Server

You can update the DI patterns from a proxy server. This update does not require
Internet connectivity and is done offline.

To configure a proxy server:

WebUI
Security > Proxy: Set the HTTP and SSL proxy addresses, then click Apply:

HTTP Proxy: 10.0.0.5:8080

SSL Proxy: 10.0.0.5:443

CLI
set pattern-update proxy http 10.0.0.5:8080
save

NOTE: You cannot configure an HTTPs proxy, because you cannot cache an HTTPs proxy.

Attack Object Database Server  129

 Concepts & Examples ScreenOS Reference Guide

Attack Objects and Groups

Attack objects are stateful signatures, stream signatures (on the NetScreen-5000
series), and protocol anomalies that a security device uses to detect attacks aimed
at compromising one or more hosts on a network. Attack objects are in groups
organized by protocol type and then by severity. When you add deep inspection (DI)
to a policy, the device inspects the traffic that the policy permits for any patterns
matching those in the referenced attack object group (or groups).

Figure 50: Attack Objects and Groups

set policy from untrust to dmz any Attack Group: HIGH:HTTP:SIGS
websrv1 http permit attack
HIGH:HTTP:SIGS action close /scripts/\.\.%c1%9c\.\./.* .*%255(c|C).* .*\[.asp::$data\].*
PUT \[/users/.*\.asp\].* /phorum/plugin/replace/pluring.php?*p
/\[scripts/iisadmin/ism\.dll\?http/dir\]. *revlog/.*

Remote Host Security device websrv1

1.1.1.3:25611 Untrust: ethernet3 1.1.1.1/24; DMZ: ethernet2 1.2.2.1/24 1.2.2.5:80
Untrust Zone DMZ Zone

SYN
SYN/ACK
ACK

SRC IP DST PT PROTO Match!

DST IP SRC PT
1.1.1.3 1.2.2.5 25611 80 HTTP
Payload: … revlog/.

The security device detects an attack object in the packet. It

drops the packet and closes the connection by sending TCP
RST notifications to the source and destination.

RST RST

The attack object groups that you reference in the DI component of a policy must
target the same service type that the policy permits. For example, if the policy
permits SMTP traffic, the attack object group must aim at attacks on SMTP traffic.
The following policy exemplifies a valid configuration:

set policy id 2 from trust to untrust any any smtp permit attack CRIT:SMTP:SIGS action
close

The next policy is erroneous because the policy permits SMTP traffic, but the attack
object group is for POP3 traffic:

set policy id 2 from trust to untrust any any smtp permit attack CRIT:POP3:SIGS action
close

130  Attack Objects and Groups

 Chapter 5: Deep Inspection

The second policy is configured incorrectly and, if implemented, would cause the
security device to expend unnecessary resources inspecting SMTP traffic for POP3
attack objects that it could never find. If policy 2 permits both SMTP and POP3
traffic, you can configure the DI component to check for SMTP attack objects, POP3
attack objects, or for both.

set group service grp1

set group service grp1 add smtp
set group service grp1 add pop3
set policy id 2 from trust to untrust any any grp1 permit attack CRIT:SMTP:SIGS action
close
set policy id 2 attack CRIT:POP3:SIGS action close

Supported Protocols
The deep inspection (DI) module supports stateful signature attack objects and
protocol anomaly attack objects for the following protocols and applications:

Table 7: Basic Network Protocols

Stateful Protocol
Protocol Signature Anomaly Definition
DNS Yes Yes Domain Name System (DNS) is a database system for translating domain names
to IP addresses, such as www.juniper.net = 207.17.137.68.
FTP Yes Yes File Transfer Protocol (FTP) is a protocol for exchanging files between computers
across a network.
HTTP Yes Yes HyperText Transfer Protocol (HTTP) is a protocol primarily used to transfer
information from webservers to web clients.
IMAP Yes Yes Internet Mail Access Protocol (IMAP) is a protocol that provides incoming email
storage and retrieval services, with the option that users can either download their
email or leave it on the IMAP server.
NetBIOS Yes Yes NetBIOS (Network Basic Input Output System) is an application interface that
allows applications on users’ workstations to access network services provided by
network transports such as NetBEUI, SPX/IPX, and TCP/IP.
POP3 Yes Yes Post Office Protocol, version 3 (POP3) is a protocol that provides incoming email
storage and retrieval services.
SMTP Yes Yes Simple Mail Transfer Protocol (SMTP) is a protocol for transferring email between
mail servers.
Chargen Yes Yes Character generator protocol
DHCP Yes Yes Dynamic Host Configuration Protocol is used to control vital networking
parameters of hosts (running clients) with the help of a server. DHCP is backward
compatible with BOOTP.
Discard Yes Yes Discard protocol is a useful debugging and measurement tool. A discard service
simply throws away any data it receives.
Echo Yes Yes Echo protocol is an internet protocol intended for testing and measurement
purposes. A host may connect to a server that supports the ECHO protocol, on
either TCP or UDP port 7. The server then sends back any data it receives.
Finger Yes Yes Finger User Information protocol is a simple protocol that provides an interface to
a remote user information program.
Gopher Yes Yes Gopher is an internet protocol designed for distributed document search and
retrieval.

Attack Objects and Groups  131

 Concepts & Examples ScreenOS Reference Guide

Stateful Protocol
Protocol Signature Anomaly Definition
ICMP Yes Yes Internet Control Message Protocol is a required protocol tightly integrated with IP.
ICMP messages, delivered in IP packets, are used for out-of-band messages
related to network operation.
IDENT Yes Yes Identification protocol provides a means to determine the identity of a user of a
particular TCP connection.
LDAP Yes Yes Lightweight Directory Access Protocol is a set of protocols for accessing
information directories.
LPR Yes Yes Line Printer spooler
NFS Yes Yes Network File System (NFS) protocol provides transparent remote access to shared
files across networks. The NFS protocol is designed to be portable across different
machines, operating systems, network architectures, and transport protocols.
NNTP Yes Yes Network News Transfer Protocol specifies a protocol for the distribution, inquiry,
retrieval, and posting of news articles using a reliable stream-based transmission
of news.
NTP Yes Yes Network Time Protocol and Simple Network Time Protocol is used to synchronize
the time of a computer client or server to another server or reference time source,
such as a radio or satellite receiver or modem.
Portmapper Yes Yes Port Mapper Program Protocol maps RPC program and version numbers to
transport- specific port numbers.
RADIUS Yes Yes Remote Authentication Dial In User Service, an authentication and accounting
system used by many Internet Service Providers (ISPs).
rexec Yes Yes Remote Execution
rlogin Yes Yes Remote Login occurs when a user connects to an Internet host to use its native
user interface.
rsh Yes Yes Remote shell
RTSP Yes Yes Real Time Streaming Protocol is a client-server application-level protocol for
controlling the delivery of data with real-time properties. It establishes and
controls either a single or several time-synchronized streams of continuous
media, such as audio and video.
SNMPTRAP Yes Yes Simple Network Management Protocol is an SNMP application that uses the
SNMP TRAP operation to send information to a network manager.
SSH Yes Yes Secure Shell Protocol is a protocol for secure remote login and other secure
network services over an insecure network.
SSL Yes Yes Secure Sockets Layer is a protocol used for transmitting private documents via the
Internet using a cryptographic system.
syslog Yes Yes System Logging Protocol is used for the transmission of event notification
messages across networks.
Telnet Yes Yes Telnet protocol is a terminal emulation program for TCP/IP networks. This
protocol enables you to communicate with other servers on the network.
TFTP Yes Yes Trivial File Transfer Protocol is a simple protocol used to transfer files. TFTP uses
the User Datagram Protocol (UDP) and provides no security features.
VNC Yes Yes Virtual Network Computing is a desktop protocol to remotely control another
computer.
Whois Yes Yes Network Directory Service Protocol is a TCP transaction based query/response
server that provides network-wide directory service to internet users.

132  Attack Objects and Groups

 Chapter 5: Deep Inspection

Table 8: Instant Messaging Applications

Stateful Protocol
Protocol Signature Anomaly Definition
AIM Yes Yes America Online Instant Messaging (AIM) is the instant messaging application for
America Online.
MSN Messenger Yes Yes Microsoft Network Messenger (MSN Messenger) is the instant messaging service
provided by Microsoft.
Yahoo! Yes Yes Yahoo! Messenger is the instant messaging service provided by Yahoo!.
Messenger
IRC Yes Yes Internet Relay Chat is a text-based protocol, with the simplest client being any
socket program capable of connecting to the server.

Table 9: Peer-to-Peer (P2P) Networking Applications

Stateful Protocol
Protocol Signature Anomaly Definition
BitTorrent Yes No BitTorrent is a P2P file distribution tool, designed to provide an efficient way to
distribute the same file to a large group by having everybody that downloads a
file also upload it to others.
DC Yes No DC (Direct Connect) is a P2P file-sharing application. A DC network uses hubs to
(Direct Connect) connect groups of users, often with a requirement that they share a certain
amount of bytes or files. Many hubs feature special areas of interest, creating
small communities for connected users.
eDonkey Yes No eDonkey is a decentralized P2P file-sharing application that uses the Multisource
File Transfer Protocol (MFTP). The eDonkey network supports two kinds of
applications: clients and servers. Clients connect to the network and share files.
Servers act as meeting hubs for the clients.
Gnutella Yes Yes Gnutella is a P2P file-sharing protocol and application without any centralized
servers. Some other applications using the Gnutella protocol are BearShare,
Limewire, Morpheus, and ToadNode.
KaZaa Yes No KaZaa is a decentralized P2P file-sharing application using the FastTrack protocol.
KaZaa is mainly used for sharing MP3 files.
MLdonkey Yes No MLdonkey is a P2P client application that can run on multiple platforms and can
access multiple P2P networks, such as BitTorrent, DC, eDonkey, FastTrack (KaZaa
and others), and Gnutella and Gnutella2.
Skype Yes No Skype is a free P2P Internet telephony service that allows users to talk with each
other over a TCP/IP network such as the Internet.
SMB Yes Yes SMB (Server Message Block) is a protocol for sharing such resources as files and
printers among computers. SMB operates on top of the NetBIOS protocol.
WinMX Yes No WinMX is a P2P file-sharing application that allows a client to connect to several
servers simultaneously

NOTE: Many of the listed P2P applications use their own proprietary protocols.

Table 10: Application Layer Gateways (ALGs)

Stateful Protocol
Protocol Signature Anomaly Definition
MSRPC Yes Yes MSRPC (Microsoft-Remote Procedure Call) is a mechanism for running
processes on a remote computer.

Attack Objects and Groups  133

 Concepts & Examples ScreenOS Reference Guide

If the security device has access to http://help.juniper.net/sigupdates/english, you

can see the contents of all the predefined attack object groups and descriptions of
the predefined attack objects. Open your browser, and enter one of the following
URLs in the Address field:

http://help.juniper.net/sigupdates/english/AIM.html
http://help.juniper.net/sigupdates/english/DNS.html
http://help.juniper.net/sigupdates/english/FTP.html
http://help.juniper.net/sigupdates/english/GNUTELLA.html
http://help.juniper.net/sigupdates/english/HTTP.html
http://help.juniper.net/sigupdates/english/IMAP.html
http://help.juniper.net/sigupdates/english/MSN.html
http://help.juniper.net/sigupdates/english/NBDS.html
http://help.juniper.net/sigupdates/english/NBNAME.html
http://help.juniper.net/sigupdates/english/POP3.html
http://help.juniper.net/sigupdates/english/SMTP.html
http://help.juniper.net/sigupdates/english/MSRPC.html
http://help.juniper.net/sigupdates/english/SMB.html
http://help.juniper.net/sigupdates/english/YMSG.html

Each of the above URLs links to an HTML page containing a list of all the predefined
attack objects—organized in groups by severity—for a particular protocol. To see a
description of an attack object, click its name.

Stateful Signatures
An attack signature is a pattern that exists when a particular exploit is in progress.
The signature can be a Layer 3 or 4 traffic pattern, such as when one address sends
lots of packets to different port numbers at another address (see “Port Scanning” on
page 9), or a textual pattern, such as when a malicious URL string appears in the
data payload of a single HTTP or FTP packet. The string can also be a specific
segment of code or a specific value in the packet header. However, when searching
for a textual pattern, the deep inspection (DI) module in a security device looks for
more than just a signature in a packet; it looks for the signature in a particular
portion of the packet (even if fragmented or segmented), in packets sent at a
particular time in the life of the session, and sent by either the connection initiator
or the responder.

NOTE: Because the DI module supports regular expressions, it can use wildcards when
searching for patterns. Thus, a single attack signature definition can apply to
multiple attack pattern variations. For information about regular expressions, see
“Regular Expressions” on page 158.

When the DI module checks for a textual pattern, it considers the roles of the
participants as client or server and monitors the state of the session to narrow its
search to just those elements relevant to the exploit for which attackers use the
pattern. Using contextual information to refine packet examination greatly reduces
false alarms—or “false positives”—and avoids unnecessary processing. The term
“stateful signatures” conveys this concept of looking for signatures within the
context of the participants’ roles and session state.

134  Attack Objects and Groups

 Chapter 5: Deep Inspection

To see the advantage of considering the context in which a signature occurs, note
the way the DI module examines packets when enabled to detect the EXPN Root
attack. Attackers use the EXPN Root attack to expand and expose mailing lists on a
mail server. To detect the EXPN Root attack, the security device searches for the
signature “expn root” in the control portion of a Simple Mail Transfer Protocol
(SMTP) session. The device examines only the control portion because that is only
where the attack can occur. If “expn root” occurs in any other portion of the
session, it is not an attack.

Using a simple textual packet signature detection technique, the signature “expn
root” triggers an alarm even if it appears in the data portion of the SMTP
connection; that is, in the body of an email message. If, for example, you were
writing to a colleague about EXPN Root attacks, a simple packet signature detector
would regard this as an attack. Using stateful signatures, the DI module can
distinguish between text strings that signal attacks and those that are harmless
occurrences.

NOTE: For a list of protocols for which there are predefined stateful signature attack
objects, see “Supported Protocols” on page 131.

TCP Stream Signatures

Like a stateful signature, a TCP stream signature is a pattern that exists when an
exploit is in progress. However, when the DI module examines traffic for stateful
signatures, it searches only within specific contexts. When the DI module examines
traffic for TCP stream signatures, it does so without regard for contexts. Another
distinction between the two types of signatures is that although stateful signatures
can be predefined or user-defined, TCP stream signatures must be user-defined.
After you add a stream signature attack object to an attack object group, you can
then reference that group in a policy that applies DI. (For more about TCP stream
signatures, see “TCP Stream Signature Attack Objects” on page 161.)

NOTE: You can define TCP stream signatures on the high-end systems only.

Stream signatures are independent of protocols and are therefore more flexible in
matching traffic. Stream signatures can examine traffic where protocols decoders
can’t inspect. However, this flexibility affects performance and resource
consumption.

Stream signatures consume resources and affect performance, so they must be

used sparingly. Stream256 signatures however, operate the same way, but rather
than matching over the entire stream, they only match on the first 256 bytes of the
stream. Therefore, they consume fewer resources and are less of a performance hit.

Protocol Anomalies
Attack objects that search for protocol anomalies detect traffic that deviates from
the standards defined in RFCs and common RFC extensions. With signature attack
objects, you must use a predefined pattern or create a new one; therefore, they can
only detect known attacks. Protocol anomaly detection is particularly useful for
catching new attacks or those attacks that cannot be defined by a textual pattern.

Attack Objects and Groups  135

 Concepts & Examples ScreenOS Reference Guide

NOTE: For a list of protocols for which there are predefined protocol anomaly attack
objects, see “Supported Protocols” on page 131.

Attack Object Groups

Predefined attack object groups contain attack objects for a specific protocol. For
each protocol, the groups are separated into protocol anomalies and stateful
signatures, and then roughly organized by severity. The five attack object group
severity levels are critical, high, medium, low, and info:

 Critical: Contains attack objects matching exploits that attempt to evade

detection, cause a network device to crash, or gain system-level privileges.

 High: Contains attack objects matching exploits that attempt to disrupt a

service, gain user-level access to a network device, or activate a Trojan horse
previously loaded on a device.

 Medium: Contains attack objects matching exploits that detect reconnaissance

efforts attempting to access vital information through directory traversal or
information leaks.

 Low: Contains attack objects matching exploits that attempt to obtain

non-critical information or scan a network with a scanning tool.

 Info: Contains attack objects matching normal, harmless traffic containing

URLs, DNS lookup failures, SNMP public community strings, and Peer-to-Peer
(P2P) parameters. You can use informational attack objects to obtain
information about your network.

Changing Severity Levels

Although attack object groups are classified by protocol and severity level (critical,
high, medium), each attack object has its own specific severity level: critical, high,
medium, low, info. These attack object severity levels map to severity levels for
event log entries as follows:

Table 11: Attack Object Severity Levels

Attack Object Severity Event Log Entry Severity

Level – Maps to – Level
Critical Critical
High Error
Medium Warning
Low Notification
Info Information

For example, if the security device detects an attack with the severity level
“Medium,” the corresponding entry that appears in the event log then has the
severity level “Warning.”

136  Attack Objects and Groups

 Chapter 5: Deep Inspection

It is possible to override the default severity level of all attack objects in one or more
attack object groups referenced in a policy. You do this at the policy level by
entering the context of an existing policy and then assigning a new severity level to
all the attack object groups that the policy references.

The following shows how to change the severity level of the attack object groups
referenced in a policy through the WebUI and CLI:

WebUI
Policies > Edit (for an existing policy): Do the following, then click OK:

> Deep Inspection: Select a severity option in the Severity drop-down list,
then click OK.

CLI
device-> set policy id number
device(policy:number)-> set di-severity { info | low | medium | high | critical }

To return the severity level for each attack object to its original setting, you again
enter the context of a policy and do either of the following:

WebUI
Policies > Edit (for an existing policy): Do the following, then click OK:

> Deep Inspection: Select Default in the Severity drop-down list, then click
OK.

CLI
device-> set policy id number
device(policy:number)-> unset di-severity

Example: Deep Inspection for P2P

In this example, you permit any host in the Trust zone to initiate a peer-to-peer
(P2P) session with any host in the Untrust zone using HTTP, DNS, and Gnutella
services. You then apply deep inspection (DI) to the permitted traffic to check for
stateful signatures and protocol anomalies as defined in the following attack object
groups:

 HIGH:HTTP:SIGS

 INFO:GNUTELLA:ANOM

 INFO:HTTP:SIGS

NOTE: For security reasons, you do not define a policy permitting any host in the Untrust
zone to initiate a P2P session with a host in the Trust zone.

If the security device detects a signature or anomalous behavior, it severs the

connection and sends a TCP RST to the client to close the session. You also enable
the logging of any discovered attack, which is the default behavior.

Attack Objects and Groups  137

 Concepts & Examples ScreenOS Reference Guide

NOTE: For information about the various attack actions that the security device can
perform, see “Attack Actions” on page 140. For information about logging
detected attacks, see “Attack Logging” on page 151.

WebUI
Policies > (From: Trust, To: Untrust) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), Any
Destination Address:
Address Book Entry: (select), Any
Service: DNS

> Click Multiple, select GNUTELLA and HTTP, then click OK to return to
the basic policy configuration page.

Action: Permit

> Click Deep Inspection, enter the following, click Add to enter each
attack object group, then click OK to return to the basic policy
configuration page:

Severity: Default
Group: HIGH:HTTP:SIGS
Action: Close Client
Log: (select)
Severity: Default
Group: INFO:GNUTELLA:ANOM
Action: Close Client
Log: (select)
Severity: Default
Group: INFO:HTTP:SIGS
Action: Close Client
Log: (select)

CLI
set policy id 1 from trust to untrust any any dns permit attack
HIGH:HTTP:SIGS action close-client
set policy id 1
device(policy:1)-> set service gnutella
device(policy:1)-> set service http
device(policy:1)-> set attack INFO:GNUTELLA:ANOM action close-client
device(policy:1)-> set attack INFO:HTTP:SIGS action close-client
device(policy:1)-> exit
save

NOTE: Because the logging of detected attacks is enabled by default, you do not have to
specify logging through CLI commands.

138  Attack Objects and Groups

 Chapter 5: Deep Inspection

Disabling Attack Objects

When you reference an attack object group in a policy, the security device checks
the traffic to which the policy applies for patterns matching any of the attack objects
in that group. At some point, you might not want to use a particular attack object if
it repeatedly produces false-positives; that is, if it erroneously interprets legitimate
traffic as an attack. If the problem stems from a custom attack object, you can
simply remove it from its custom attack object group. However, you cannot remove
a predefined attack object from a predefined attack object group. In that case, the
best course of action is to disable the object.

Note that a predefined attack object is disabled only within the root system or
virtual system (vsys) in which you disable it. For example, disabling a predefined
attack object in the root system does not automatically disable it in any virtual
systems. Likewise, disabling an attack object in one vsys does not affect that object
in any other vsys.

NOTE: Disabling attack objects does not improve throughput performance.

To disable an attack object:

WebUI
Security > Deep Inspection > Attacks > Predefined: Clear the check box in
the Configure column for the attack object that you want to disable.

CLI
set attack disable attack_object_name

To re-enable a previously disabled attack object:

WebUI
Security > Deep Inspection > Attacks > Predefined: Select the check box in
the Configure column for the attack object that you want to enable.

CLI
unset attack disable attack_object_name

Attack Objects and Groups  139

 Concepts & Examples ScreenOS Reference Guide

Attack Actions
When the security device detects an attack, it performs the action that you specify
for the attack group containing the object that matches the attack. The seven
actions are as follows, from most to least severe:

 Close (severs connection and sends RST to client and server)

NOTE: The client is always the initiator of a session; that is, the source address in a policy.
The server is always the responder, or the destination address.

Use this option for TCP connections. The security device drops the connection
and sends a TCP RST to both the client (source) and server (destination).
Because the delivery of RST notifications is unreliable, by sending a RST to both
client and server, there is a greater chance that at least one gets the RST and
closes the session.

 Close Server (severs connection and sends RST to server)

Use this option for inbound TCP connections from an untrusted client to a
protected server. If the client tries to launch an attack, the security device drops
the connection and sends a TCP RST only to the server for it to clear its
resources while the client is left hanging.

 Close Client (severs connection and sends RST to client)

Use this option for outbound TCP connections from a protected client to an
untrusted server. If, for example, the server sends a malicious URL string, the
security device drops the connection and sends a RST only to the client for it to
clear its resources while the server is left hanging.

 Drop (severs connection without sending anyone a RST)

Use this option for UDP or other non-TCP connections, such as DNS. The
security device drops all packets in a session, but does not send a TCP RST.

 Drop Packet (drops a particular packet, but does not sever connection)

This option drops the packet in which an attack signature or protocol anomaly
occurs but does not terminate the session itself. Use this option to drop
malformed packets without disrupting the entire session. For example, if the
security device detects an attack signature or protocol anomaly from an AOL
proxy, dropping everything would disrupt all AOL service. Instead, dropping just
the packet stops the problem packet without stopping the flow of all the other
packets.

 Ignore (after detecting an attack signature or anomaly, the security device

makes a log entry and stops checking—or ignores—the remainder of the
connection)

140  Attack Actions

 Chapter 5: Deep Inspection

If the security device detects an attack signature or protocol anomaly, it makes

an event log entry but does not sever the session itself. Use this option to tweak
false positives during the initial setup phase of your deep inspection (DI)
implementation. Also, use this option when a service uses a standard port
number for nonstandard protocol activities; for example, Yahoo Messenger uses
port 25 (SMTP port) for non-SMTP traffic. The security device logs the
occurrence once per session (so that it does not fill the log with false positives),
but takes no action.

 None (no action)

It is useful when first identifying attack types during the initial setup phase of
your DI implementation. When the security device detects an attack signature
or protocol anomaly, it makes an entry in the event log but takes no action on
the traffic itself. The security device continues to check subsequent traffic in
that session and make log entries if it detects other attack signatures and
anomalies.

You can create a policy referencing multiple attack object groups, each group having
a different action. If the security device simultaneously detects multiple attacks that
belong to different attack object groups, it applies the most severe action specified
by one of those groups.

Example: Attack Actions—Close Server, Close, Close Client

In this example, there are three zones: Trust, Untrust, and DMZ. You have finished
analyzing attacks and have concluded you need the following three policies:

 Policy ID 1: Permit HTTP, HTTPS, PING, and FTP-GET traffic from any address
in the Untrust zone to the webservers (websrv1 and websrv2) in the DMZ.

Attack Settings for Policy ID 1:

 CRITICAL:HTTP:ANOM, CRITICAL:HTTP:SIGS

 HIGH:HTTP:ANOM, HIGH:HTTP:SIGS

 MEDIUM:HTTP:ANOM, MEDIUM:HTTP:SIGS

 CRITICAL:FTP:SIGS

 Action for all attack object groups: Close Server

 Logging: Enabled (default setting)

You choose to drop the connection and send a TCP RST notification only to the
protected webservers so they can terminate sessions and clear resources. You
anticipate attacks coming from the Untrust zone.

 Policy ID 2: Permit HTTP, HTTPS, PING, and FTP traffic from any address in the
Trust zone to the webservers (websrv1 and websrv2) in the DMZ

Attack Settings for Policy ID 2:

Attack Actions  141

 Concepts & Examples ScreenOS Reference Guide

 CRITICAL:HTTP:ANOM, CRITICAL:HTTP:SIGS

 HIGH:HTTP:ANOM, HIGH:HTTP:SIGS

 MEDIUM:HTTP:ANOM, MEDIUM:HTTP:SIGS

 CRITICAL:FTP:SIGS

 Action for all attack object groups: Close

 Logging: Enabled (default setting)

You choose to drop the connection and send a TCP RST notification to both the
protected clients and servers so they both can terminate their sessions and
clear their resources regardless of the severity level of the attack.

 Policy ID 3: Permit FTP-GET, HTTP, HTTPS, PING traffic from any address in the
Trust zone to any address in the Untrust zone

Attack Settings for Policy ID 3:

 CRITICAL:HTTP:ANOM, CRITICAL:HTTP:SIGS

 HIGH:HTTP:ANOM, HIGH:HTTP:SIGS

 MEDIUM:HTTP:ANOM, MEDIUM:HTTP:SIGS

 CRITICAL:FTP:SIGS

 Action for all attack object groups: Close Client

 Logging: Enabled (default setting)

You choose to drop the connection and send a TCP RST notification to the
protected clients so they both can terminate their sessions and clear their
resources. In this case, you anticipate an attack coming from an untrusted
HTTP or FTP server.

Although the policies permit HTTP, HTTPS, Ping, and FTP-Get or FTP, the security
device activates DI only for HTTP and FTP traffic. All zones are in the trust-vr
routing domain.

142  Attack Actions

 Chapter 5: Deep Inspection

Figure 51: DI Attack Actions

Untrust Zone
DI (Untrust -> DMZ)
HTTP:Crit, High, Med;
FTP:Crit
ethernet3 Action:Close-server
1.1.1.1/24

DMZ Zone

DI (Trust -> Untrust)

HTTP: Crit, High,
Med; FTP: Crit; ethernet2 websrv1 websrv2
Action: Close-client 1.2.2.1/24 1.2.2.5/24 1.2.2.6/24

ethernet1 DI (Trust -> DMZ)

10.1.1.1/24 HTTP:Crit, High,
Med; FTP:Crit;
Trust Zone Action:Close

WebUI
1. Interfaces
Network > Interfaces > Edit (for ethernet1): Enter the following, then click
Apply:

Zone Name: Trust

Static IP: (select this option when present)
IP Address/Netmask: 10.1.1.1/24

Enter the following, then click OK:

Interface Mode: NAT

Service Options:
Management Services: (select all)
Other services: Ping

Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:

Zone Name: Untrust

Static IP: (select this option when present)
IP Address/Netmask: 1.1.1.1/24

Network > Interfaces > Edit (for ethernet2): Enter the following, then click
OK:

Zone Name: DMZ

Static IP: (select this option when present)
IP Address/Netmask: 1.2.2.1/24
2. Addresses
Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: websrv1

Attack Actions  143

 Concepts & Examples ScreenOS Reference Guide

IP Address/Domain Name:
IP/Netmask: (select), 1.2.2.5/32
Zone: DMZ

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: websrv2

IP Address/Domain Name:
IP/Netmask: (select), 1.2.2.6/32
Zone: DMZ
3. Route
Network > Routing > Routing Entries > trust-vr New: Enter the following,
then click OK:

Network Address/Netmask: 0.0.0.0/0

Gateway: (select)
Interface: ethernet3
Gateway IP Address: 1.1.1.250
4. Policy ID 1
Policies > (From: Untrust, To: DMZ) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), Any
Destination Address:
Address Book Entry: (select), websrv1

> Click Multiple, select websrv2, then click OK to return to the basic
policy configuration page.

Service: HTTP

> Click Multiple, select FTP-GET, HTTPS, PING, then click OK to return to
the basic policy configuration page.

Action: Permit

> Click Deep Inspection, enter the following, click Add to enter each
attack object group, then click OK to return to the basic policy
configuration page:

Group: CRITICAL:HTTP:ANOM
Action: Close Server
Log: (select)
Group: CRITICAL:HTTP:SIGS
Action: Close Server
Log: (select)
Group: HIGH:HTTP:ANOM
Action: Close Server
Log: (select)
Group: HIGH:HTTP:SIGS
Action: Close Server
Log: (select)
Group: MEDIUM:HTTP:ANOM
Action: Close Server
Log: (select)

144  Attack Actions

 Chapter 5: Deep Inspection

Group: MEDIUM:HTTP:SIGS
Action: Close Server
Log: (select)
Group: CRITICAL:FTP:SIGS
Action: Close Server
Log: (select)
5. Policy ID 2
Policies > (From: Trust, To: DMZ) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), Any
Destination Address:
Address Book Entry: (select), websrv1

> Click Multiple, select websrv2, then click OK to return to the basic
policy configuration page.

Service: HTTP

> Click Multiple, select FTP-GET, HTTPS, PING, then click OK to return to
the basic policy configuration page.

Action: Permit

> Click Deep Inspection, enter the following, click Add to enter each
attack object group, then click OK to return to the basic policy
configuration page:

Group: CRITICAL:HTTP:ANOM
Action: Close
Log: (select)
Group: CRITICAL:HTTP:SIGS
Action: Close
Log: (select)
Group: HIGH:HTTP:ANOM
Action: Close
Log: (select)
Group: HIGH:HTTP:SIGS
Action: Close
Log: (select)
Group: MEDIUM:HTTP:ANOM
Action: Close
Log: (select)
Group: MEDIUM:HTTP:SIGS
Action: Close
Log: (select)
Group: CRITICAL:FTP:SIGS
Action: Close
Log: (select)
6. Policy ID 3
Policies > (From: Trust, To: Untrust) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), Any
Destination Address:

Attack Actions  145

 Concepts & Examples ScreenOS Reference Guide

Address Book Entry: (select), Any

Service: HTTP

> Click Multiple, select FTP-GET, HTTPS, PING, then click OK to return to
the basic policy configuration page.

Action: Permit

> Click Deep Inspection, enter the following, click Add to enter each
attack object group, then click OK to return to the basic policy
configuration page:

Group: CRITICAL:HTTP:ANOM
Action: Close Client
Log: (select)
Group: CRITICAL:HTTP:SIGS
Action: Close Client
Log: (select)
Group: HIGH:HTTP:ANOM
Action: Close Client
Log: (select)
Group: HIGH:HTTP:SIGS
Action: Close Client
Log: (select)
Group: MEDIUM:HTTP:ANOM
Action: Close Client
Log: (select)
Group: MEDIUM:HTTP:SIGS
Action: Close Client
Log: (select)
Group: CRITICAL:FTP:SIGS
Action: Close Client
Log: (select)

146  Attack Actions

 Chapter 5: Deep Inspection

CLI
1. Interfaces
set interface ethernet1 zone trust
set interface ethernet1 ip 10.1.1.1/24
set interface ethernet1 manage
set interface ethernet3 zone untrust
set interface ethernet3 ip 1.1.1.1/24
set interface ethernet2 zone dmz
set interface ethernet2 ip 2.1.1.1/24
2. Addresses
set address dmz websrv1 1.2.2.5/32
set address dmz websrv2 1.2.2.6/32
3. Route
set vrouter trust-vr route 0.0.0.0/0 interface ethernet3 gateway 1.1.1.250
4. Policy ID 1
set policy id 1 from untrust to dmz any websrv1 http permit attack
CRITICAL:HTTP:ANOM action close-server
set policy id 1
device(policy:1)-> set dst-address websrv2
device(policy:1)-> set service ftp-get
device(policy:1)-> set service https
device(policy:1)-> set service ping
device(policy:1)-> set attack CRITICAL:HTTP:SIGS action close-server
device(policy:1)-> set attack HIGH:HTTP:ANOM action close-server
device(policy:1)-> set attack HIGH:HTTP:SIGS action close-server
device(policy:1)-> set attack MEDIUM:HTTP:ANOM action close-server
device(policy:1)-> set attack MEDIUM:HTTP:SIGS action close-server
device(policy:1)-> set attack CRITICAL:FTP:SIGS action close-server
device(policy:1)-> exit
5. Policy ID 2
set policy id 2 from trust to dmz any websrv1 http permit attack
CRITICAL:HTTP:ANOM action close
set policy id 2
device(policy:2)-> set dst-address websrv2
device(policy:2)-> set service ftp
device(policy:2)-> set service https
device(policy:2)-> set service ping
device(policy:2)-> set attack CRITICAL:HTTP:SIGS action close
device(policy:2)-> set attack HIGH:HTTP:ANOM action close
device(policy:2)-> set attack HIGH:HTTP:SIGS action close
device(policy:2)-> set attack MEDIUM:HTTP:ANOM action close
device(policy:2)-> set attack MEDIUM:HTTP:SIGS action close
device(policy:2)-> set attack CRITICAL:FTP:SIGS action close
device(policy:2)-> exit
6. Policy ID 3
set policy id 3 from trust to untrust any any http permit attack
CRITICAL:HTTP:ANOM action close-client
set policy id 3
device(policy:3)-> set service ftp-get
device(policy:3)-> set service https
device(policy:3)-> set service ping
device(policy:3)-> set attack CRITICAL:HTTP:SIGS action close-client

Attack Actions  147

 Concepts & Examples ScreenOS Reference Guide

device(policy:3)-> set attack HIGH:HTTP:ANOM action close-client

device(policy:3)-> set attack HIGH:HTTP:SIGS action close-client
device(policy:3)-> set attack MEDIUM:HTTP:ANOM action close-client
device(policy:3)-> set attack MEDIUM:HTTP:SIGS action close-client
device(policy:3)-> set attack CRITICAL:FTP:SIGS action close-client
device(policy:3)-> exit
save

Brute Force Attack Actions

A typical brute force attack is accomplished by sending lots of traffic with varying
source ports or IP in an attempt to obtain network access. In order to effectively
prevent future attempts, ScreenOS allows you to associate an IP action for each
attack group in a policy.

Brute force attack is detected based on the threshold values set for the DI supported
protocols. For example,

set di service protocol-name value

Apart from a DI action, brute force attack actions are configured with the IP action
command for a configured amount of time for a specified target. If your security
device detects a brute force attack, then select one of the following actions to
perform:

 Notify: The security device logs the event but does not take any action against
further traffic matching the target definition for the period of time specified in
the timeout setting.

 Block: The security device logs the event and drops all further traffic matching
the target definition for the period of time specified in the timeout setting.

 Close: The security device logs the event and drops all further traffic matching
the target definition for the period of time specified in the timeout setting, and
sends a Reset (RST) for TCP traffic to the source and destination addresses.

148  Attack Actions

 Chapter 5: Deep Inspection

Brute Force Attack Objects

Table 12 lists the brute force attack objects in ScreenOS 5.4 and the threshold
parameters that can be used with the IP actions.

Table 12: Brute Force Attack Objects

Brute Force Attack Name Parameter

HTTP Brute Force Login Attempt failed_logins
HTTP Brute Search Attempt brute_search
IMAP Brute Force Login Attempt failed_logins
LDAP Brute Force Login Attempt failed_logins
MS-RPC IsSystemActive request flood Not configurable—32 attempts
MS-SQL Login Brute Force Not configurable—4 attempts
POP3 Brute Force Login Attempt failed_login
RADIUS Brute Force Authentication Attempt failed_auth
SMB Brute Force Directory Create/Delete Not configurable—200 attempts
SMB Brute Force Login Attempt failed_login
FTP Brute Force Login Attempt failed_login
Telnet Brute Force Login Attempt failed_login
VNC Brute Force Login Attempt failed_login

Brute Force Attack Target

The target option specifies a set of elements that must match for the security device
to consider a packet part of a brute force attack. The specified set of elements in an
IP packet arriving during a specified timeout period must match that in the packet
that the security device detected as part of a brute force attack for the subsequent
packet to be considered part of the same attack. The default target definition is Serv.
You can select any of the following target definitions shown in Table 13.

Table 13: Target Options

Target option Matching elements

Serv source IP, destination IP, destination port, and
protocol
Src-IP source IP address
Zone-Serv source security zone, destination IP, destination port
number, and protocol
Dst-IP destination IP address
Zone source security zone
(The security zone to which the ingress interface is
bound; that is, the source security zone from which
the attacking packets originate)

Brute Force Attack Timeout

Timeout is a period of time following brute force attack detection during which the
security device performs an IP action on packets matching specified target
parameters. The default timeout is 60 seconds.

Attack Actions  149

 Concepts & Examples ScreenOS Reference Guide

Example 1
In this example, you configure an IP action along with the existing DI action for
each group in a policy. The following CLI commands block brute force attack
object—HTTP Brute Force Login Attempt or HTTP Brute Force Search for 45
seconds. All other attacks in the HIGH:HTTP:ANOM attack group are configured
with a DI action of close.

In this release of ScreenOS, S2C HTTP protocol decoding is performed only if you
configure server-to-client signature attacks. HTTP:Brute-Force, a server-to-client
anomaly attack is detected if you configure an HTTP server-to-client signature
attack in the policy. In the following example, HTTP:HIGH:SIGS has server-to-client
signature attacks, so add HTTP:HIGH:SIGS along with HTTP:HIGH:ANOM in a policy.

CLI
device>get attack group HIGH:HTTP:ANOM
GROUP "HIGH:HTTP:ANOM" is pre-defined. It has the following members
ID Name
1674 HTTP:INVALID:INVLD-AUTH-CHAR
1675 HTTP:INVALID:INVLD-AUTH-LEN
1711 HTTP:OVERFLOW:HEADER
1713 HTTP:OVERFLOW:INV-CHUNK-LEN
1717 HTTP:OVERFLOW:AUTH-OVFLW
5394 HTTP:EXPLOIT:BRUTE-FORCE
5395 HTTP:EXPLOIT:BRUTE-SEARCH
device> set policy id 1 from Untrust to DMZ Any Any Any permit attack
MEDIUM:HTTP:ANOM action none
device> set policy id 1 from Untrust to DMZ Any Any Any permit attack
MEDIUM:HTTP:HIGH:SIGS action none
device> set policy id 1
device(policy:1)-> set attack HIGH:HTTP:ANOM action close ip-action block
target dst-ip timeout 45

If the configured attack group does not have any brute force attack protocol
anomalies, IP action is not enforced.

Example 2
In this example, you associate an IP action for each attack group for a configured
amount of time from a specified host.

set policy id 1 from trust to untrust any any any permit attack HIGH:POP3:ANOM
action close ip-action notify target serv timeout 60

150  Attack Actions

 Chapter 5: Deep Inspection

Example 3
In this example, the default threshold value of FTP brute force login attempt is 8
attempts per minute. If a user at IP address 192.168.2.2 is launching a FTP brute
force login attempt to FTP server at 10.150.50.5 in order to figure out a user
account name and password, the attempt is detected when the attacker makes 8
FTP login attempts within a minute.

If an IP action is configured to “Block” for 120 seconds for target of “serv”, any
traffic coming from 192.168.2.2 (src IP) to 10.150.50.5 (dst IP) over TCP (protocol)
port 21 (dst port) is blocked for 120 seconds.

Note that some IP action targets may affect traffic matching another policy.

Attack Logging
You can enable the logging of detected attacks per attack group per policy. In other
words, within the same policy, you can apply multiple attack groups and selectively
enable the logging of detected attacks for just some of them.

By default, logging is enabled. You might want to disable logging for attacks that are
lower priority for you and about which you do not give much attention. Disabling
logging for such attacks helps prevent the event log from becoming cluttered with
entries that you do not plan to look at anyway.

Example: Disabling Logging per Attack Group

In this example, you reference the following five attack groups in a policy and
enable logging only for the first two:

 HIGH:IMAP:ANOM

 HIGH:IMAP:SIGS

 MEDIUM:IMAP:ANOM

 LOW:IMAP:ANOM

 INFO:IMAP:ANOM

The policy applies to IMAP traffic from all hosts in the Trust zone to a mail server
named “mail1” in the DMZ. If any of the predefined IMAP attack objects in the
above five groups match an attack, the security device closes the connection.
However, it only creates log entries for detected attacks matching attack objects in
the first two groups.

WebUI
1. Address
Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: mail1

IP Address/Domain Name:
IP/Netmask: (select), 1.2.2.10/32

Attack Logging  151

 Concepts & Examples ScreenOS Reference Guide

Zone: DMZ
2. Policy
Policies > (From: Trust, To: DMZ) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), Any
Destination Address:
Address Book Entry: (select), mail1
Service: IMAP
Action: Permit

> Click Deep Inspection, enter the following, click Add to enter each
attack object group, then click OK to return to the basic policy
configuration page:

Group: HIGH:IMAP:ANOM
Action: Close
Log: (select)

Group: HIGH:IMAP:SIGS
Action: Close
Log: (select)

Group: MEDIUM:IMAP:ANOM
Action: Close
Log: (clear)

Group: LOW:IMAP:ANOM
Action: Close
Log: (clear)
Group: INFO:IMAP:ANOM
Action: Close
Log: (clear)

CLI
1. Address
set address dmz mail1 1.2.2.10/32
2. Policy
device-> set policy id 1 from trust to dmz any mail1 imap permit attack
HIGH:IMAP:ANOM action close
device-> set policy id 1
device(policy:1)-> set attack HIGH:IMAP:SIGS action close
device(policy:1)-> set attack MEDIUM:IMAP:ANOM action close
device(policy:1)-> unset attack MEDIUM:IMAP:ANOM logging
device(policy:1)-> set attack LOW:IMAP:ANOM action close
device(policy:1)-> unset attack LOW:IMAP:ANOM logging
device(policy:1)-> set attack INFO:IMAP:ANOM action close
device(policy:1)-> unset attack INFO:IMAP:ANOM logging
device(policy:1)-> exit
device-> save

152  Attack Logging

 Chapter 5: Deep Inspection

Mapping Custom Services to Applications

When using a custom service in a policy with a deep inspection (DI) component,
you must explicitly specify the application that is running on that service so that the
DI module can function properly. For example, if you create a custom service for
FTP running on a nonstandard port number such as 2121 (see Figure 52), you can
reference that custom service in a policy as follows:

set service custom-ftp protocol tcp src-port 0-65535 dst-port 2121-2121

set policy id 1 from untrust to trust any ftp-srv1 custom-ftp permit

However, if you add a DI component to a policy that references a custom service,

the DI module cannot recognize the application because it is using a nonstandard
port number.

set policy id 1 from untrust to trust any ftp-srv1 custom-ftp permit attack
CRITICAL:FTP:SIGS action close-server

Figure 52: Mapping Custom Service

The firewall permits custom-ftp traffic
on port 2121.

Untrust Zone Trust Zone

custom-ftp (port 2121)

Internet

FTP (port 21) ftp-srv1

However, the DI module checks for CRITICAL:FTP attacks on port 21, which is not in use.

To avoid this problem, you must inform the DI module that the FTP application is
running on port 2121 (see Figure 53). Essentially, you must map the protocol in the
Application Layer to a specific port number in the Transport Layer. You can do this
binding at the policy level:

set policy id 1 application ftp

When you map the FTP application to the custom service “custom-ftp” and
configure DI to examine FTP traffic for the attacks defined in the
CRITICAL:FTP:SIGS attack object group in a policy that references custom-ftp, the
DI module perform its inspection on port 2121.

set policy id 1 from untrust to trust any ftp-srv1 custom-ftp permit attack
CRITICAL:FTP:SIGS action close-server
set policy id 1 application ftp

Mapping Custom Services to Applications  153

 Concepts & Examples ScreenOS Reference Guide

Figure 53: Mapping Custom Service to Attack Object Group

The firewall permits custom-ftp traffic on port 2121.

Untrust Zone Trust Zone

custom-ftp (port 2121)

Internet
The DI module checks for
CRITICAL:FTP:SIGS attacks on port 2121.
ftp-srv1

Example: Mapping an Application to a Custom Service

In this example, you define a custom service named “HTTP1” that uses destination
port 8080. You map the HTTP application to the custom service for a policy
permitting HTTP1 traffic from any address in the Untrust zone to a webserver
named “server1” in the DMZ zone. You then apply deep inspection (DI) to the
permitted HTTP traffic running on port 8080. The DI settings for this policy are as
follows:

 Attack Object Groups:

 CRITICAL:HTTP:ANOM, CRITICAL:HTTP:SIGS

 HIGH:HTTP:ANOM, HIGH:HTTP:SIGS

 MEDIUM:HTTP:ANOM, MEDIUM:HTTP:SIGS

 Action for all attack object groups: Close Server

 Logging: Enabled (default setting)

WebUI
1. Custom Service
Policy > Policy Elements > Services > Custom > New: Enter the following,
then click OK:

Service Name: HTTP1

Transport Protocol: TCP (select)
Source Port Low: 0
Source Port High: 65535
Destination Port Low: 8080
Destination Port High: 8080
2. Address
Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: server1

IP Address/Domain Name:
IP Address/Netmask: 1.2.2.5/32
Zone: DMZ

154  Mapping Custom Services to Applications

 Chapter 5: Deep Inspection

3. Policy
Policies > (From: Untrust, To: DMZ) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), Any
Destination Address:
Address Book Entry: (select), server1
Service: HTTP1
Application: HTTP
Action: Permit

> Click Deep Inspection, enter the following, click Add to enter each
attack object group, then click OK to return to the basic policy
configuration page:

Group: CRITICAL:HTTP:ANOM
Action: Close Server
Log: (select)

Group: CRITICAL:HTTP:SIGS
Action: Close Server
Log: (select)
Group: HIGH:HTTP:ANOM
Action: Close Server
Log: (select)

Group: HIGH:HTTP:SIGS
Action: Close Server
Log: (select)

Group: MEDIUM:HTTP:ANOM
Action: Close Server
Log: (select)
Group: MEDIUM:HTTP:SIGS
Action: Close Server
Log: (select)

CLI
1. Custom Service
set service HTTP1 protocol tcp src-port 0-65535 dst-port 8080-8080
2. Address
set address dmz server1 1.2.2.5/32
3. Policy
device-> set policy id 1 from untrust to dmz any server1 HTTP1 permit attack
CRITICAL:HTTP:ANOM action close-server
device-> set policy id 1
device(policy:1)-> set attack CRITICAL:HTTP:SIGS action close-server
device(policy:1)-> set attack HIGH:HTTP:ANOM action close-server
device(policy:1)-> set attack HIGH:HTTP:SIGS action close-server
device(policy:1)-> set attack MEDIUM:HTTP:ANOM action close-server
device(policy:1)-> set attack MEDIUM:HTTP:SIGS action close-server
device(policy:1)-> exit
device-> set policy id 1 application http
save

Mapping Custom Services to Applications  155

 Concepts & Examples ScreenOS Reference Guide

Example: Application-to-Service Mapping for HTTP Attacks

Some known HTTP attacks use TCP port 8000. At the time of this writing, there are
currently two such attacks in the deep inspection (DI) attack object database:

 3656, App: HP Web JetAdmin Framework Infoleak

DOS:NETDEV:WEBJET-FW-INFOLEAK (in the attack object group

MEDIUM:DOS:SIGS)

 3638, App: HP Web JetAdmin WriteToFile Vulnerability,

DOS:NETDEV:WEBJET-WRITETOFILE (in the attack object group

CRITICAL:HTTP:SIGS)

However, by default, ScreenOS considers only TCP traffic on port 80 to be HTTP.

Therefore, if the security device receives TCP traffic using port 8000, it does not
recognize it as HTTP. Consequently the DI engine does not scan such HTTP traffic
for these attacks and cannot detect them if they occur—unless you map HTTP as an
application to a custom service using port 8000.

In this example, you associate traffic using the nonstandard port of 8000 with HTTP
to detect the above attacks.

NOTE: In general, if you are running some services using nonstandard port numbers in
your network and you want the DI engine to scan that traffic, you must associate
the nonstandard port number to the service.

WebUI
1. Custom Service
Policy > Policy Elements > Services > Custom > New: Enter the following,
then click OK:

Service Name: HTTP2

Transport Protocol: TCP (select)
Source Port Low: 0
Source Port High: 65535
Destination Port Low: 8000
Destination Port High: 8000
2. Policy
Policies > (From: Untrust, To: DMZ) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), Any
Destination Address:
Address Book Entry: (select), Any
Service: HTTP2
Application: HTTP
Action: Permit

156  Mapping Custom Services to Applications

 Chapter 5: Deep Inspection

> Click Deep Inspection, enter the following, click Add to enter each
attack object group, then click OK to return to the basic policy
configuration page:

Group: CRITICAL:HTTP:SIGS
Action: Close
Log: (select)

Group: MEDIUM:DOS:SIGS
Action: Close
Log: (select)

CLI
1. Custom Service
set service HTTP2 protocol tcp src-port 0-65535 dst-port 8000-8000
2. Policy
device-> set policy id 1 from untrust to dmz any any HTTP2 permit attack
CRITICAL:HTTP:SIGS action close
device-> set policy id 1
device(policy:1)-> set attack MEDIUM:DOS:SIGS action close
device(policy:1)-> exit
device-> set policy id 1 application http
save

Customized Attack Objects and Groups

You can define new attack objects and object groups to customize the deep
inspection (DI) application to best meet your needs. User-defined attack objects can
be stateful signatures or—on the NetScreen-5000—TCP stream signatures. You can
also adjust various parameters to modify predefined protocol anomaly attack
objects.

User-Defined Stateful Signature Attack Objects

You can create a stateful signature attack object for FTP, HTTP, and SMTP. (For a
complete list of supported protocols, see “Contexts for User-Defined Signatures” on
page A-I.) When creating an attack object, you perform the following steps:

 Name the attack object. (All user-defined attack objects must begin with “CS:”.)

 Set the context for the DI search. (For a complete list of all the contexts that you
can use when creating attack objects, see “Contexts for User-Defined
Signatures” on page A-I.)

 Define the signature. (“Regular Expressions” on page 158 examines the regular
expressions that you can use when defining signatures.)

 Assign the attack object a severity level. (For information about severity levels,
see “Changing Severity Levels” on page 136.)

You must then put a user-defined attack object in a user-defined attack object group
for use in policies.

Customized Attack Objects and Groups  157

 Concepts & Examples ScreenOS Reference Guide

NOTE: A user-defined attack object group can only contain user-defined attack objects.
You cannot mix predefined and user-defined attack objects in the same attack
object group.

Regular Expressions
When entering the text string for a signature, you can enter an alphanumeric string
of ordinary characters to search for an exact character-to-character match, or you
can use regular expressions to broaden the search for possible matches to sets of
characters. ScreenOS supports the following regular expressions as shown in
Table 14.

Table 14: ScreenOS Supported Regular Expressions

Purpose Meta characters Example Meaning

Direct binary match (octal)1 \Ooctal_number \0162 Exactly match this octal
Matches: number: 162
162
Direct binary match \Xhexadecimal_number\X \X01 A5 00 00\X Exactly match these four
(hexadecimal)2 Matches: hexadecimal numbers:
01 A5 00 00 01 A5 00 00
Case-insensitive matches \[characters\] \[cat\] Match the characters in cat
Matches: regardless of the case of each
 Cat, cAt, caT
character

 CAt, CaT, CAT

 cat, cAt

Match any character . c.t Match c-any character-t

Matches:
 cat, cbt, cct, … czt
 cAt, cBt, cCt, … cZt
 c1t, c2t, c3t, … c9t

Match the previous character * a*b+c Match zero, one, or multiple

zero or more times, instead Matches: occurrences of a, followed by
of only once  bc
one or more occurrences of b,
followed by one occurrence of
 bbc c
 abc
 aaabbbbc

Match the previous character + a+b+c Match one or more

one or more times Matches: occurrences of a, followed by
 abc
one or more occurrences of b,
followed by one occurrence of
 aabc c
 aaabbbbc

Match the previous character ? drop-?packet Match either drop-packet or

zero times or one time Matches: droppacket
 drop-packet
 droppacket

Group expressions ()

158  Customized Attack Objects and Groups

 Chapter 5: Deep Inspection

Purpose Meta characters Example Meaning

Either the previous or the | (drop | packet) Match either drop or packet
following character— Matches:
typically used with ( )  drop
 packet

Character range [start-end] [c-f]a(d | t) Match everything that begins

Matches: with c, d, e, or f and that has
 cad, cat
the middle letter a and the last
letter d or t
 dad, dat
 ead, eat
 fad, fat

Negation of the following [^character] [^0-9A-Z] Match lowercase letters

character Matches:
a, b, c, d, e, … z

1.Octal is a base-8 number system that uses only the digits 0–7.
2. Hexadecimal is a base-16 number system that uses digits 0–9 as usual, and then the letters A–F representing hexadecimal
digits with decimal values of 10–15.

Example: User-Defined Stateful Signature Attack Objects

In this example, you have an FTP server, a webserver, and a mail server in the DMZ
zone. You define the following attack objects for the use-defined signature objects as
shown in Table 15.

Table 15: User-Defined Stateful Signature Attack Objects

Object Name Usage

cs:ftp-stor Block someone from putting files on an FTP server
cs:ftp-user-dm Deny FTP access to the user with the login name dmartin
cs:url-index Block HTTP packets with a defined URL in any HTTP request
cs:spammer Block email from any email address at “spam.com”

You then organize them into a user-defined attack object group named “DMZ DI”,
which you reference in a policy permitting traffic from the Untrust zone to the
servers in the DMZ zone.

WebUI
1. Attack Object 1: ftp-stor
Security > Deep Inspection> Attacks > Custom > New: Enter the following,
then click OK:

Attack Name: CS:ftp-stor

Attack Context: FTP Command
Attack Severity: Medium
Attack Pattern: STOR
2. Attack Object 2: ftp-user-dm
Security > Deep Inspection > Attacks > Custom > New: Enter the following,
then click OK:

Attack Name: CS:ftp-user-dm

Customized Attack Objects and Groups  159

 Concepts & Examples ScreenOS Reference Guide

Attack Context: FTP User Name

Attack Severity: Low
Attack Pattern: dmartin
3. Attack Object 3: url-index
Security > Deep Inspection > Attacks > Custom > New: Enter the following,
then click OK:

Attack Name: CS:url-index

Attack Context: HTTP URL Parsed
Attack Severity: High
Attack Pattern: .*index.html.*
4. Attack Object 4: spammer
Security > Deep Inspection > Attacks > Custom > New: Enter the following,
then click OK:

Attack Name: CS:spammer

Attack Context: SMTP Mail From
Attack Severity: Info
Attack Pattern: .*@spam.com
5. Attack Object Group
Security > Deep Inspection > Attacks > Custom Groups > New: Enter the
following group name, move the following custom attack objects, then click OK:

Group Name: CS:DMZ DI

Select cs:ftp-stor and use the << button to move the address from the
Selected Members column to the Selected Members column.

Select cs:ftp-user-dm and use the << button to move the address from
the Available Members column to the Selected Members column.

Select cs:url-index and use the << button to move the address from the
Available Members column to the Selected Members column.

Select cs:spammer and use the << button to move the address from the
Available Members column to the Selected Members column.

6. Policy
Policies > (From: Untrust, To: DMZ) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), Any
Destination Address:
Address Book Entry: (select), Any
Service: HTTP

> Click Multiple, select FTP, then click OK to return to the basic policy
configuration page.

Action: Permit

160  Customized Attack Objects and Groups

 Chapter 5: Deep Inspection

> Click Deep Inspection, enter the following, click Add to enter each
attack object group, then click OK to return to the basic policy
configuration page:

Group: CS:DMZ DI
Action: Close Server
Log: (select)

CLI
1. Attack Object 1: ftp-stor
set attack cs:ftp-stor ftp-command STOR severity medium
2. Attack Object 2: ftp-user-dm
set attack cs:ftp-user-dm ftp-username dmartin severity low
3. Attack Object 3: url-index
set attack cs:url-index http-url-parsed index.html severity high
4. Attack Object 4: spammer
set attack cs:spammer smtp-from .*@spam.com severity info
5. Attack Object Group
set attack group “CS:DMZ DI”
set attack group “CS:DMZ DI” add cs:ftp-stor
set attack group “CS:DMZ DI” add cs:ftp-user-dm
set attack group “CS:DMZ DI” add cs:url-index
set attack group “CS:DMZ DI” add cs:spammer
6. Policy
set policy id 1 from untrust to dmz any any http permit attack “CS:DMZ DI” action
close-server
set policy id 1
device(policy:1)-> set service ftp
device(policy:1)-> exit
save

TCP Stream Signature Attack Objects

The stateful signatures are context-based within specific applications, such as an
FTP username or an SMTP header field. TCP stream signatures look for patterns
anywhere in any kind of TCP traffic regardless of the application protocol in use.

NOTE: You can define TCP stream signatures on NetScreen-5000 series systems only.

Because there are no predefined TCP stream signature attack objects, you must
define them. When creating a signature attack object, you define the following
components:

 Attack object name (All user-defined attack objects must begin with “CS:”.)

 Object type (“stream”)

 Pattern definition

 Severity level

Customized Attack Objects and Groups  161

 Concepts & Examples ScreenOS Reference Guide

Figure 54: Example of a TCP Stream Signature Attack Object

set attack "CS:A1" stream ".*satori.*" severity critical

Name Type Definition Severity Level

Example: User-Defined Stream Signature Attack Object

In this example, you define a stream signature object “.*satori.*”. You name it
“CS:A1” and define its severity level as critical. Because a policy can reference only
attack object groups, you create a group named “CS:Gr1”, and then add this object
to it. Finally, you define a policy that references CS:Gr1 and that instructs the
security device to sever the connection and send TCP RST to the client if the pattern
appears in any traffic to which the policy applies.

WebUI
1. Stream Signature Attack Object
Security > Deep Inspection > Attacks > Custom > New: Enter the following,
then click OK:

Attack Name: CS:A1

Attack Context: Stream
Attack Severity: Critical
Attack Pattern: .*satori.*
2. Stream Signature Attack Object Group
Security > Deep Inspection > Attacks > Custom Groups > New: Enter the
following, then click OK:

Group Name: CS:Gr1

Select CS:A1 in the Available Members column and then click << to move
it to the Selected Members column.

3. Policy
Policies > (From: Trust, To: Untrust) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), Any
Destination Address:
Address Book Entry: (select), Any
Service: ANY
Action: Permit

> Click Deep Inspection, enter the following, click Add to enter each
attack object group; and then click OK to return to the basic policy
configuration page:

Group: CS:Gr1
Action: Close Client
Log: (select)

162  Customized Attack Objects and Groups

 Chapter 5: Deep Inspection

CLI
1. Stream Signature Attack Object
set attack “CS:A1” stream “.*satori.*” severity critical
2. Stream Signature Attack Group
set attack group “CS:Gr1”
set attack group “CS:Gr1” add “CS:A1”
3. Policy
set policy from trust to untrust any any any permit attack CS:Gr1 action close-client
save

Configurable Protocol Anomaly Parameters

You can modify certain parameters of a protocol anomaly attack object. Although
Juniper defines protocol anomaly attack objects to find deviations from protocol
standards defined in RFCs and common RFC extensions, not all implementations
adhere to these standards. If you find that the application of a certain protocol
anomaly attack object is producing numerous false positives, you can modify its
parameters to better match the accepted use of that protocol in your network.

NOTE: For a complete list of all configurable parameters, see the di command in
ScreenOS CLI Reference Guide: IPv4 Command Descriptions.

Example: Modifying Parameters

In this example, you set higher values for the following parameters to reduce the
number of false positives that occurred with the default settings:

Protocol Parameter Default New

SMB—Maximum number of login failures per minute 8 failures 10 failures
Gnutella—Maximum number of time-to-live (TTL) hops 8 hops 10 hops

For the following parameters, you set lower values to detect anomalous behavior
that the security device missed with the default settings:

Protocol Parameter Default New

AOL Instant Messenger (AIM)—Maximum OSCAR File 10,000 bytes 5,000 bytes
Transfer (OFT) file name length.
OSCAR = Open System for Communication in Real-time,
the protocol that AIM clients use.
AOL Instant Messenger—Maximum length of a FLAP frame 10,000 bytes 5,000 bytes
(FLAP header, which is always 6 bytes, plus data).
OSCAR makes use of a the FLAP protocol to make
connections and open channels between AIM clients.

WebUI
Security > Deep Inspection> Service Limits: Enter the following, then click
Apply:

Customized Attack Objects and Groups  163

 Concepts & Examples ScreenOS Reference Guide

Service: AIM (select)

Maximum Bytes in FLAP Length: 5000
Maximum Bytes in OFT Length: 5000

Service: GNUTELLA (select)

Maximum TTL Hops: 10

Service: SMB (select)

Maximum Number of Login Failures per Minute: 10

CLI
set di service smb failed_logins 10
set di service gnutella max_ttl_hops 10
set di service aim max_flap_length 5000
set di service aim max_oft_frame 5000
save

Negation
Typically, you use attack objects to match patterns that are indicative of malicious or
anomalous activity. However, you can also use them to match patterns indicative of
benign or legitimate activity. WIth this approach, something is amiss only if a type
of traffic does not match a particular pattern. To use attack objects in this way, you
apply the concept of negation.

A useful application of attack object negation would be to block all login attempts
other than those with the correct username and password. It would be difficult to
define all invalid usernames and passwords, but quite easy to define the correct
ones and then apply negation to reverse what the security device considers an
attack; that is, everything except the specified attack object.

Example: Attack Object Negation

In this example (see Figure 55), you define two attack objects: one specifying the
correct username required to log in to an FTP server, and another the correct
password. You then apply negation to both attack objects, so that the security
device blocks any login attempt to that server that uses any other username or
password than those defined in the attack objects.

The example uses the following settings:

 The correct username and password are admin1 and pass1.

 The FTP server is at 1.2.2.5 in the DMZ zone. Its address name is ftp1.

 You apply DI on FTP traffic to the server from all hosts in the Untrust and Trust
zones.

 All security zones are in the trust-vr routing domain.

You create the following two attack objects:

 Attack Object #1:

 Name: CS:FTP1_USR_OK

164  Negation
 Chapter 5: Deep Inspection

 Negation: enabled

 Context: ftp-username

 Pattern: admin1

 Severity: high

 Attack Object #2:

 Name: CS:FTP1_PASS_OK

 Negation: enabled

 Context: ftp-password

 Pattern: pass1

 Severity: high

You then put both objects into an attack object group named CS:FTP1_LOGIN and
reference that attack object group in two policies permitting FTP traffic from the
Trust and Untrust zones to ftp1 in the DMZ.

Figure 55: Attack Object Negation

Note: For simplicity, the external router in the

Untrust zone is not shown. Its address is
Untrust 1.1.1.250.

Login Attempt: Internet Login Attempt:

User Name: 123456 User Name: admin1
Password: 123456 Password: pass1

ethernet2
ethernet3 1.2.2.1/24
1.1.1.1/24 DMZ
FTP Server
“ftp1”
1.2.2.5
LAN
ethernet1
10.1.1.1/24

Login Attempt: Login Attempt:

User Name: anon User Name: admin1
Password: logos LAN Password: pass1

Trust

WebUI
1. Interfaces
Network > Interfaces > Edit (for ethernet1): Enter the following, then click
Apply:

Zone Name: Trust

Static IP: (select this option when present)
IP Address/Netmask: 10.1.1.1/24

Negation  165
 Concepts & Examples ScreenOS Reference Guide

Select the following, then click OK:

Interface Mode: NAT (select)

NOTE: By default, any interface that you bind to the Trust zone is in NAT mode.
Consequently, this option is already enabled for interfaces bound to the Trust
zone.

Network > Interfaces > Edit (for ethernet2): Enter the following, then click
OK:

Zone Name: DMZ

Static IP: (select this option when present)
IP Address/Netmask: 1.2.2.1/24

Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:

Zone Name: Untrust

Static IP: (select this option when present)
IP Address/Netmask: 1.1.1.1/24
2. Address
Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: ftp1

IP Address/Domain Name:
IP/Netmask: (select), 1.2.2.5/32
Zone: DMZ
3. Attack Object 1: CS:FTP1_USR_OK
Security > Deep Inspection > Attacks > Custom > New: Enter the following,
then click OK:

Attack Name: CS:FTP1_USR_OK

Attack Context: ftp-username
Attack Severity: High
Attack Pattern: admin1
Pattern Negation: (select)
4. Attack Object 2: CS:FTP1_PASS_OK
Security > Deep Inspection > Attacks > Custom > New: Enter the following,
then click OK:

Attack Name: CS:FTP1_PASS_OK

Attack Context: ftp-password
Attack Severity: High
Attack Pattern: pass1
Pattern Negation: (select)
5. Attack Object Group
Security > Deep Inspection > Attacks > Custom Groups > New: Enter the
following group name, move the following custom attack objects, then click OK:

Group Name: CS:FTP1_LOGIN

166  Negation
 Chapter 5: Deep Inspection

Select CS:FTP1_USR_OK and use the << button to move the address
from the Available Members column to the Selected Members column.

Select CS:FTP1_PASS_OK and use the << button to move the address
from the Available Members column to the Selected Members column.

6. Route
Network > Routing > Routing Entries > trust-vr New: Enter the following,
then click OK:

Network Address/Netmask: 0.0.0.0/0

Gateway: (select)
Interface: ethernet3
Gateway IP Address: (select) 1.1.1.250
7. Policies
Policies > (From: Untrust, To: DMZ) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), Any
Destination Address:
Address Book Entry: (select), ftp1
Service: FTP
Action: Permit

> Click Deep Inspection, enter the following, click Add to enter each
attack object group; and then click OK to return to the basic policy
configuration page:

Group: CS:FTP1_LOGIN
Action: Drop
Log: (select)

Policies > (From: Trust, To: DMZ) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), Any
Destination Address:
Address Book Entry: (select), ftp1
Service: FTP
Action: Permit

> Click Deep Inspection, enter the following, click Add to enter each
attack object group, then click OK to return to the basic policy
configuration page:

Group: CS:FTP1_LOGIN
Action: Drop
Log: (select)

Negation  167
 Concepts & Examples ScreenOS Reference Guide

CLI
1. Interfaces
set interface ethernet1 zone trust
set interface ethernet1 ip 10.1.1.1/24
set interface ethernet1 nat
set interface ethernet2 zone dmz
set interface ethernet2 ip 1.2.2.1/24
set interface ethernet3 zone untrust
set interface ethernet3 ip 1.1.1.1/24
2. Address
set address dmz ftp1 1.2.2.5/32
3. Attack Objects
set attack CS:FTP1_USR_OK ftp-username not admin1 severity high
set attack CS:FTP1_PASS_OK ftp-password not pass1 severity high
set attack group CS:FTP1_LOGIN
set attack group CS:FTP1_LOGIN add CS:FTP1_USR_OK
set attack group CS:FTP1_LOGIN add CS:FTP1_PASS_OK
4. Route
set vrouter trust-vr route 0.0.0.0/0 interface ethernet3 gateway 1.1.1.250
5. Policies
set policy from untrust to dmz any ftp1 ftp permit attack CS:FTP1_LOGIN action
drop
set policy from trust to dmz any ftp1 ftp permit attack CS:FTP1_LOGIN action drop
save

Granular Blocking of HTTP Components

A Juniper Networks security device can selectively block ActiveX controls, Java
applets, .zip files, and .exe files sent via HTTP. The danger that these components
pose to the security of a network is that they provide a means for an untrusted
party to load and then control an application on hosts in a protected network.

When you enable the blocking of one or more of these components in a security
zone, the security device examines every HTTP header that arrives at an interface
bound to that zone. It checks if the content type listed in the header indicates that
any of the targeted components are in the packet payload. If the content type is
Java, .exe, or .zip and you have configured the security device to block those HTTP
component types, the device blocks the packet. If the content type lists only “octet
stream” instead of a specific component type, then the device examines the file
type in the payload. If the file type is Java, .exe, or .zip and you have configured the
device to block those component types, the device blocks the packet.

When you enable the blocking of ActiveX controls, the device blocks all HTTP
packets containing any type of HTTP component in its payload—ActiveX controls,
Java applets, .exe files, or .zip files.

NOTE: When ActiveX-blocking is enabled, the security device blocks Java applets, .exe
files, and .zip files whether or not they are contained within an ActiveX control.

168  Granular Blocking of HTTP Components

 Chapter 5: Deep Inspection

ActiveX Controls
Microsoft ActiveX technology provides a tool for web designers to create dynamic
and interactive web pages. ActiveX controls are components that allow different
programs to interact with each other. For example, ActiveX allows your browser to
open a spreadsheet or display your personal account from a backend database.
ActiveX components might also contain other components such as Java applets, or
files such as .exe and .zip files.

When you visit an ActiveX-enabled website, the site prompts you to download
ActiveX controls to your computer. Microsoft provides a pop-up message displaying
the name of the company or programmer who authenticated the ActiveX code that
is offered for download. If you trust the source of the code, you can proceed to
download the controls. If you distrust the source, you can refuse them.

If you download an ActiveX control to your computer, it can then do whatever its
creator designed it to do. If it is malicious code, it can now reformat your hard drive,
delete all your files, send all your personal email to your boss, and so on.

Java Applets
Serving a similar purpose as ActiveX, Java applets also increase the functionality of
web pages by allowing them to interact with other programs. You download Java
applets to a Java Virtual Machine (VM) on your computer. In the initial version of
Java, the VM did not allow the applets to interact with other resources on your
computer. Starting with Java 1.1, some of these restrictions were relaxed to provide
greater functionality. As a result, Java applets can now access local resources
outside the VM. Because an attacker can program Java applets to operate outside
the VM, they pose the same security threat as ActiveX controls do.

EXE Files
If you download and run an executable file (that is, a file with a .exe extension)
obtained off the Web, you cannot guarantee that the file is uncontaminated. Even if
you trust the site from which you downloaded it, it is possible that somebody
sniffing download requests from that site has intercepted your request and
responded with a doctored .exe file that contains malicious code.

ZIP Files
A zip file (that is, a file with a .zip extension) is a type of file containing one or more
compressed files. The danger of downloading a .exe file presented in the previous
section about .exe files applies to .zip files, because a .zip file can contain one or
more .exe files.

Granular Blocking of HTTP Components  169

 Concepts & Examples ScreenOS Reference Guide

Example: Blocking Java Applets and .exe Files

In this example, you block any HTTP traffic containing Java applets and .exe files in
packets arriving at an Untrust zone interface.

WebUI
Screening > Screen (Zone: Untrust): Select Block Java Component and Block
EXE Component, then click Apply.

CLI
set zone untrust screen component-block jar
set zone untrust screen component-block exe
save

170  Granular Blocking of HTTP Components

Chapter 6
Intrusion Detection and Prevention

An Intrusion Prevention System (IPS), more commonly known as a firewall, is used

to detect and prevent attacks in network traffic. While firewalls provide perimeter
and boundary protection, allowed traffic can hide attacks that firewalls are not
designed to detect.

Juniper Networks Intrusion Detection and Prevention (IDP) technology can detect
and then stop attacks when deployed inline to your network. Unlike an IPS alone,
IDP uses multiple methods to detect attacks against your network and prevent
attackers from gaining access and doing damage. IDP can drop malicious packets or
connections before the attacks can enter your network. It is designed to reduce
false positives and ensure that only actual malicious traffic is detected and stopped.
You can also deploy IDP as a passive sniffer, similar to a traditional IPS but with
greater accuracy and manageability.

This chapter contains the following sections:

 “IDP-Capable Security Devices” on page 172

 “Traffic Flow in an IDP-Capable Device” on page 173

 “Configuring Intrusion Detection and Prevention” on page 175

 “Configuring Security Policies” on page 183

 “Using IDP Rulebases” on page 184

 “Enabling IDP in Firewall Rules” on page 186

 “Configuring IDP Rules” on page 188

 “Configuring Exempt Rules” on page 202

 “Configuring Backdoor Rules” on page 207

 “Configuring IDP Attack Objects” on page 211

 “Configuring the Device as a Standalone IDP Device” on page 229

 “Managing IDP” on page 232

 “ISG-IDP Devices” on page 236

 171
 Concepts & Examples ScreenOS Reference Guide

IDP-Capable Security Devices

ScreenOS supports IDP capabilities on some security devices. The security module
(SM), an optional component installed on these devices, provides IDP functionality.
For more information about how the security modules detects malicious packets,
see “Traffic Flow in an IDP-Capable Device” on page 173.

If you purchased a security device with only firewall or virtual private network
(VPN) capabilities, you can upgrade the device to an IDP-capable system by
performing the following steps:

 Installing the Advanced and IDP license keys

 Upgrading the boot loader

 Installing an IDP-capable version of ScreenOS

 Upgrading the system memory

 Installing security module(s)

NOTE: Installing the IDP license key disables the ScreenOS deep inspection (DI) feature.

See the ISG 2000 Field Upgrade Guide and the NetScreen-ISG 1000 Field Upgrade
Guide for instructions on how to upgrade the devices to include IDP capabilities.

You can use the IDP-capable security device as a fully integrated firewall/VPN/IDP
security system that not only screens traffic between the Internet and your private
network but also provides application-level security. You can also use this device as
a standalone IDP system to protect critical segments of your private network. For
more information, see “Configuring the Device as a Standalone IDP Device” on
page 229.

172  IDP-Capable Security Devices

 Chapter 6: Intrusion Detection and Prevention

Traffic Flow in an IDP-Capable Device

This section describes the packet flow on the IDP-capable security device. The ASIC
processor in the device receives the packet, checks the session table and if it
doesn’t find a match, forwards the packet to the management module. Figure 56
illustrates the packet flow from the management module to the security module.
The management module checks the packet against firewall policies. If IDP is
enabled, traffic is redirected to the least-loaded security module, which performs
IDP analysis on the packet.

Figure 56: Traffic Flow in the Security Device

Traffic Flow

No IDP Session is created and the

1. Route lookup packet leaves the device
2. Policy lookup IDP inline
IDP inline-tap
Management module
Packet is sent to the
least-loaded security
module for IDP inspection

PW R A LA R M TEM
P S TA T U S H A
Security module
FA N M O 1D M O 2D M O 3D F LA S H
ISG 2000

Security module
Juniper Networks
security device
Security module

Each security module, consisting of a dual processor, maintains its own session
table. The dual CPU allows each security module to run two instances of IDP per
module. The get sm status command shows the dual CPU for each security module
(see page 177).

The Inline-tap mode configuration enables the IDP security modules to monitor
traffic passively. In Inline-tap mode, an internal tap sends a copy of every packet in
the traffic flow to the security module for IDP processing; at the same time, the
ASIC module performs Firewall/VPN processing on the inline traffic.

If an attack object is detected, TCP reset occurs with “close” option to clear the
session table. For each attack that matches a rule, you can choose to ignore, drop, or
close the current attacking packets or connection. For more information about the
action to perform when an attack object is found, see “Defining Actions” on
page 196.

NOTE: The security module inspects traffic within IPSec tunnels that use Null
encryption method. It does not inspect the traffic that uses any other encryption.
For more information about configuring this feature in the security module using
NSM, see the NetScreen-Security Manager Administrator's Guide.

Traffic Flow in an IDP-Capable Device  173

 Concepts & Examples ScreenOS Reference Guide

When the PPU passes the IPSec ESP tunneled packet that uses Null-encryption
method to the IDP security device, the IDP security device checks if ESP-NULL
encrypted packet inspection feature is enabled. If the feature is enabled, IDP
performs packet sanity test and ESP-NULL packet check on the ESP-NULL packet. If
the packet does not conform to either of the tests, the security device drops the
packet. If the packet passes both the tests, IDP decapsulates the payload data of the
original IP ESP-NULL packet. It then checks if a session already exists for the
decapsulated data. If a session does not exist, it creates a session for the
decapsulated packet based on the decapsulated packet data header. The IDP device
then passes the packet to the IDP engine for inspection.

IDP limits the total number of internal sessions that is generated for the ESP-NULL
encrypted traffic. By default, the maximum value is set to 20000 sessions and the
user can define a value up to 40000 sessions. If the maximum session limit is
reached the IDP bypasses the packet without inspection and will generate an event
log.

NOTE: IDP supports inspection of both transparent mode and tunnel mode
ESP-NULL encrypted traffic. The transport mode is not supported currently.

For Tunnel mode ESP, IDP uses the new IP packet header's source IP address,
destination IP address, internal payload data's protocol id, source port and
destination port for policy look up.

IDP follows the normal packet processing on the decapsulated ESP-NULL packets.
But when an attack happens, IDP drops the corresponding internal session and
does not forward it to the outer session. Table 16 explains the actions taken by the
ESP-NULL encrypted traffic against the actions taken by the normal traffic for the
rule actions defined by the IDP.

Table 16: IDP Actions for ESP-NULL Traffic

Rule Action Normal Traffic ESP-NULL Traffic (Inner Session) ESP-NULL Traffic (Outer Session)
NONE NONE NONE NONE
RECOMMENDED Attack action Attack action NONE
IGNORE IGNORE IGNORE IGNORE
MARK_DIFFSERV MARK_DIFFSERV NONE MARK_DIFFSERV
DROP_PACKET DROP_PACKET DROP_PACKET DROP_PACKET
DROP drop packet/reject flow drop packet/reject flow drop packet
CLOSE_CLIENT reset client drop packet/reject flow none
CLOSE_SERVER reset server drop packet/reject flow none
CLOSE reset drop packet/reject flow none

When attacks happen on the ESP-NULL traffic, appropriate actions are taken on the
internal sessions based on the rule actions as explained in the Table 2. When there
are no attack objects, the traffic passes through the IDP successfully.

174  Traffic Flow in an IDP-Capable Device

 Chapter 6: Intrusion Detection and Prevention

Configuring Intrusion Detection and Prevention

This section presents three basic examples for configuring IDP on your security
device:

 “Example 1: Basic IDP Configuration” on page 176

 “Example 2: Configuring IDP for Active/Passive Failover” on page 178

 “Example 3: Configuring IDP for Active/Active Failover” on page 180

Preconfiguration Tasks
Before you start configuring IDP on the device, you need to ensure the following:

 Your security device is IDP-capable. For more information, see “IDP-Capable

Security Devices” on page 172.

 You have installed and configured a NetScreen-Security Manager (NSM) system

on a management station.

NOTE: Although you can perform basic device configuration using the ScreenOS CLI or
WebUI, you need NSM to configure and manage IDP on the security device.

NetScreen-Security Manager provides integrated policy management, where

each security device is linked to one security policy that contains rules defining
the types of traffic permitted on the network and the way that traffic is treated
inside the network.

 You have a security policy for the device. You can use the default security policy
provided in NetScreen-Security Manager, or you can create a custom security
policy for the firewall/VPN functions on the device.

NOTE: You cannot use the DSCP marking feature if you have enabled IDP on the security
device. The DSCP marking feature is disabled in IDP-capable security devices.

Configuring Intrusion Detection and Prevention  175

 Concepts & Examples ScreenOS Reference Guide

Example 1: Basic IDP Configuration

In this example, a Juniper Networks device is deployed with firewall/VPN/IDP
functionality. Before you start configuring, make sure your device is IDP-capable as
described in “IDP-Capable Security Devices” on page 172. Set up the device as
shown in Figure 57, then do the following:

1. Physically connect the network components.

2. Add the network components that you want IDP to protect using the CLI,
WebUI, or NetScreen-Security Manager UI.

Figure 57: Setting Up the Device for Basic IDP

Juniper Networks
security device
Untrust Zone Trust Zone

Internet
PW R A LA R M TEM
P S TA T U S H A

FA N M O 1D M O 2D M O 3D F LA S H
ISG 2000

FTP-Srv1

These components can be routers, servers, workstations, subnetworks, or any

other objects connected to your network. In NetScreen-Security Manager, these
network components are represented as address objects. You can also create
address object groups, which represent multiple address objects. For more
information about creating address objects, see the NetScreen-Security Manager
Administrator’s Guide.

3. Enable IDP (the default is inline mode) in the appropriate firewall rule for the
device.

This step can be performed using the CLI or NetScreen-Security Manager UI.
The CLI commands are shown below (to configure using NSM, see “Enabling
IDP in Firewall Rules” on page 186):

device-> get policy

Total regular policies 5, Default deny.
ID From To Src-address Dst-address Service Action State ASTLCB
9 Trust Untrust Any Any MAIL Permit enabled ---X-X
4 blade1 dmz2 Any Any ANY Permit enabled ---X-X
6 dmz2 blade1 Any Any ANY Permit enabled ---X-X
10 Untrust Trust Any MIP(172.24.~ HTTP Permit enabled ---X-X
HTTPS
device-> get policy id 4
name:"none" (id 4), zone blade1 -> dmz2,action Permit, status "enable
src "Any", dst "Any", serv "ANY"
Policies on this vpn tunnel: 0
nat off, Web filtering : disabled
vpn unknown vpn, policy flag 00010000, session backup: on
policy IDP mode : disable
traffic shapping off, scheduler n/a, serv flag 00
log yes, log count 0, alert no, counter no(0) byte rate(sec/min) 0/0
total octets 0, counter(session/packet/octet) 0/0/0
No Authentication
No User, User Group or Group expression set
device-> set policy id 4

176  Configuring Intrusion Detection and Prevention

 Chapter 6: Intrusion Detection and Prevention

device (policy:4)-> set idp

device (policy:4)-> exit
device-> get policy id 4
policy IDP mode : inline

4. Add the device using the Netscreen-Security Manager UI.

To add the device, do the following:

a. Select Device Manager > Security Devices > + (Device).

b. Enter a device name, then and click Next.

c. Enter the management IP address of the device, then click Finish.

The new device appears in the list of security devices.

5. Validate the security policy on your device.

Make sure you have a security policy for the device. You can use the default
security policy; or, if the device is deployed as an integrated firewall/VPN/IDP
device, you can create a custom security policy for the firewall/VPN functions
on the device. For more information, see “Configuring Security Policies” on
page 183. For more information about configuring security polices using NSM,
see the NetScreen-Security Manager Administrator’s Guide.

6. Import the device.

To import the device, right-click on the device that you added, then select
Import device. Importing the device copies the security-policy information
from the device to the NSM server so that the device can be managed. The
imported policy is displayed in NSM under Security Policy.

For more information about adding and configuring devices using NSM, see the
NetScreen-Security Manager Administrator’s Guide. Other configuration settings
include operational mode, administrative password, zone interface
assignments, and default route configurations.

7. Add and configure IDP rules in the security policy for the device.

You configure a security policy on the device to include IDP rules. When you
update the configuration on the device, the entire security policy, including IDP
rule additions or changes, is installed on the device. For more information
about enabling and configuring IDP rules, see “Configuring IDP Rules” on
page 188.

NOTE: If you are using the device as a standalone IDP system, you need to configure a
simple firewall rule that directs all traffic to be checked against the IDP rules. For
more information, see “Configuring the Device as a Standalone IDP Device” on
page 229.

8. Assign the security policy to the security device.

9. Allow traffic to flow and view the IDP sessions with the following command:

Configuring Intrusion Detection and Prevention  177

 Concepts & Examples ScreenOS Reference Guide

device->get sm status
SM CPU aval ena Sess_cnt
1 1 1 10 Security module 1
2 1 1 8
3 0 1 0 Security module 2
4 0 1 0
5 0 1 0 Security module 3
6 0 1 0

The above command shows one security module (SM1 and SM2) installed in
the device. The CPU column indicates that security modules 2 and 3 are not
installed in the device. The status on the two CPUs on each security module is
displayed in separate rows.

The management module in the device processes the traffic and then forwards
it for IDP inspection to the security modules. The traffic is load-balanced
between the two CPUs in the security module (see the Sess_Cnt column). If
your device has more than one security module, then the management module
load-balances the traffic between the security modules.

NOTE: When you have more than one security module installed in the device and one
module fails, then the IDP sessions are automatically transferred to the next
security module.

10. Periodically update the attack object database on the NetScreen-Security

Manager server.

See “Managing IDP” on page 232 for more information.

Example 2: Configuring IDP for Active/Passive Failover

In this example, set up your security device in high availability (HA) pairs to remove
a potential point of failure from your network design. Figure 58 illustrates device
setup for configuring IDP for Active/Passive failover. The two devices are in an
Active/Passive failover configuration; that is, the primary device is active, handling
all firewall and VPN activities; and the backup device is passive, waiting to take over
when the primary device fails.

178  Configuring Intrusion Detection and Prevention

 Chapter 6: Intrusion Detection and Prevention

Figure 58: Configuring IDP for Active/Passive Failover

Device A

Untrust Zone
PW R

FA N
A LA R M

M O 1D
TEM
P

M O 2D
S TA T U S

M O 3D
H A

F LA S H
ISG 2000
Trust Zone

Internet Device B

PW R

FA N
A LA R M

M O 1D
TEM
P

M O 2D
S TA T U S

M O 3D
H A

F LA S H
ISG 2000
FTP-Srv1

Active/Passive Failover
Device A (master)
VSD ID 0
Device B (backup)

Set up the device as shown in Figure 58, then do the following:

1. Configure Device A and Device B for IDP as described in “Example 1: Basic IDP
Configuration” on page 176.

2. To ensure continuous traffic flow, cable and configure two security devices in a
redundant cluster with Device A acting as a primary device and Device B acting
as its backup.

Cable e1/x on Device A to e1/x on Device B. Similarly cable the e2/x interfaces.
For more information about cabling the two devices together, setting up
managed IP addresses to manage a backup device, or removing other potential
points of failure by setting up redundant switches on either side of the HA pair,
see Volume 11: High Availability.

3. Configure the HA interfaces.

Specify the zones with HA interfaces. Bind e1/x and e2/x to the HA zone. Set
manage IP addresses for the Trust zone interfaces on both devices.

4. Configure an Active/Passive NetScreen Redundancy Protocol (NSRP) cluster.

Assign each device to NSRP cluster ID 0. When the devices become members
of the NSRP cluster, the IP addresses of their physical interfaces automatically
become the IP addresses of the Virtual Security Interfaces (VSIs) for Virtual
Security Device (VSD) group ID 0. Each VSD member has a default priority of
100. The device with the higher unit ID becomes the VSD group’s primary
device. For more information about VSDs, see Volume 11: High Availability.

For example, enter the following on each of the devices to configure an NSRP
cluster:

a. Add the device to an NSRP cluster and a VSD group.

set nsrp cluster id 0

b. Enable automatic Run-Time Object (RTO) synchronization.

set nsrp rto sync all

Configuring Intrusion Detection and Prevention  179

 Concepts & Examples ScreenOS Reference Guide

c. Select the ports that you want the devices to monitor.

If the device detects a loss of network connectivity on one of the monitored

ports, then it triggers a device failover.

set nsrp rto-mirror sync

set nsrp monitor interface ethernet1
set nsrp monitor interface ethernet3
set nsrp cluster id 0
save

Upon initial NSRP configuration, the VSD group members with the priority
number closest to 0 becomes the primary device. (The default is 100.) If Device
A and B have the same priority value, the device with the highest MAC address
becomes primary device.

The primary device propagates all its network and configuration settings and
the current session information to the backup device. Although the backup
device is passive, it is maintaining its synchronization with the information it
receives from the primary device. If the primary device fails, the backup device
is promoted to primary and takes over the traffic processing.

NOTE: Synchronization is maintained for firewall sessions only. Stateful failover does not
occur for IDP sessions.

Example 3: Configuring IDP for Active/Active Failover

In this example, set up your security devices in Route or Network Address
Translation (NAT) mode and configure them in a redundant cluster to be active,
sharing the traffic distributed between them. This is accomplished using NSRP to
create two VSD groups as shown in Figure 59. Device A acts as the primary device
in VSD group 1 and as the backup of VSD group 2. Device B acts as the primary
device in VSD group 2 and as the backup of VSD group 1. No single point of failure
exists in an Active/Active setup.

180  Configuring Intrusion Detection and Prevention

 Chapter 6: Intrusion Detection and Prevention

Figure 59: Configuring IDP for Active/Active Failover

Device A

Untrust Zone
Trust Zone
P W R A LA R M T E MP S TA T U S HA

FA N M O 1D M O 2D M O 3D F LA S H
ISG 2000

Internet Device B

P W R A LA R M

FA N
T E MP S TA T U S

M O 1D M O 2D M O 3D F LA S H
HA

ISG 2000
FTP-Srv1

Active/Active Failover

Device A (master)
VSD ID 0
Device B (backup)

Device A (backup)
VSD ID 1
Device B (master)

Set up the device as shown in Figure 59, then do the following:

NOTE: We recommend that the same number of security modules be installed on both
devices.

1. Configure Device A and Device B for IDP as described in “Example 1: Basic IDP
Configuration” on page 176.

2. To ensure continuous traffic flow, cable and configure two security devices in a
redundant cluster.

Cable e1/x on Device A to e1/x on Device B. Similarly cable the e2/x interfaces.
For more information about how to cable the two devices together, setting up
managed IP addresses to manage a backup device, or to remove other potential
points of failure by setting up redundant switches on either side of the HA pair,
see Volume 11: High Availability.

3. Configure the HA interfaces.

Specify the zones with HA interfaces. Bind e1/x and e2/x to the HA zone. Set
manage IP addresses for the trust zone interfaces on both devices.

4. Configure an Active/Active NSRP cluster.

Devices A and B are members of the same NSRP cluster and VSD group 0. For
Active/Active failover, create a second VSD group—group 1.

1. Assign Device A priority 1 in group 0 and the default priority (100) in

group 1.

2. Assign Device B priority 1 in group 1 and the default priority (100) in

group 0.

Configuring Intrusion Detection and Prevention  181

 Concepts & Examples ScreenOS Reference Guide

In both VSD groups, enable the preempt option on the primary device and set
the preempt hold-down time to 10 seconds. If both devices are active, Device A
is always the primary device of group 1 and Device B is always the primary
device of group 2.

Device A
set nsrp vsd-group id 0 priority 1
set nsrp vsd-group id 0 preempt hold-down 10
set nsrp vsd-group id 0 preempt
set nsrp vsd-group id 1
save

Device B
set nsrp vsd-group id 1 priority 1
set nsrp vsd-group id 1 preempt hold-down 10
set nsrp vsd-group id 1 preempt
save

For more information about creating two VSD groups, see Volume 11:
High Availability.

Devices A and B each receive 50 percent of the network and VPN traffic. When
Device A fails, Device B becomes the primary device of VSD group 1, as well as
continuing to be the primary device of VSD group 2, and handles 100 percent
of the traffic.

NOTE: Synchronization is maintained for firewall sessions only. Stateful failover does not
occur for IDP sessions.

182  Configuring Intrusion Detection and Prevention

 Chapter 6: Intrusion Detection and Prevention

Configuring Security Policies

A security policy defines how your managed devices handle network traffic. You
can configure multiple security policies in NetScreen-Security Manager, but a device
can only have one active security policy at a time. You can install the same security
policy on multiple devices, or you can install a unique security policy on each device
in your network.

About Security Policies

Each instruction in a security policy is called a rule. Security policies can contain
multiple rules. You create rules in rulebases, sets of rules that combine to define a
security policy. Each security policy contains the Zone and Global firewall rulebases,
which cannot be deleted. You can add or delete any other rulebase—Multicast, IDP,
Exempt, and Backdoor—in a security policy; however, a single policy can only
contain one instance of any type of rulebase. Each security policy (all rulebases
combined) can contain a maximum of 40,000 rules.

This section describes the IDP, Exempt, and Backdoor rulebases. For more
information about Zone and Global firewall rulebases and the Multicast rulebase,
see the information about configuring security policies in the NetScreen-Security
Manager Administrator’s Guide.

NOTE: In the ScreenOS WebUI and CLI, a security policy is a single statement that defines
a source, destination, zone, direction, and service. In NetScreen-Security Manager,
those same statements are known as rules, and a security policy is a collection of
rules.

Managing Security Policies

Within security policies, you can manage individual rules in each rulebase,
including:

 Determining the order in which rules are applied to network traffic

 Disabling a rule

 Negating source or destination addresses (ScreenOS 5.x devices only)

 Verifying the security policy

 Merging security policies

NOTE: The IDP, Exempt, and Backdoor rulebases are not included when you merge two
policies into a single policy.

For detailed information about managing your security policy, see the
NetScreen-Security Manager Administrator’s Guide.

Configuring Security Policies  183

 Concepts & Examples ScreenOS Reference Guide

Installing Security Policies

After you create a security policy by building rules in one or more rulebases, you
can assign, validate, and install that policy on specific managed devices. For
detailed information about installing security policies, see the NetScreen-Security
Manager Administrator’s Guide.

Using IDP Rulebases

After a firewall rule (intrazone or global) has permitted the network traffic, you can
direct the device to further inspect the traffic for known attacks. NetScreen-Security
Manager supports the following IDP rulebases:

 IDP: This rulebase protects your network from attacks by using attack objects to
detect known and unknown attacks. Juniper Networks provides predefined
attack objects that you can use in IDP rules. You can also configure your own
custom attack objects. For more information, see “Configuring IDP Attack
Objects” on page 211.

NOTE: Juniper Networks regularly updates predefined attack objects to keep current with
newly discovered attacks. For more information about updating attack objects, see
“Managing IDP” on page 232.

 Exempt: This rulebase works in conjunction with the IDP rulebase to prevent
unnecessary alarms from being generated. You configure rules in this rulebase
to exclude known false positives or to exclude a specific source, destination, or
source/destination pair from matching an IDP rule. If traffic matches a rule in
the IDP rulebase, IDP attempts to match the traffic against the Exempt rulebase
before performing the action specified.

 Backdoor Detection: This rulebase protects your network from mechanisms

installed on a host computer that facilitate unauthorized access to the system.
Attackers who have already compromised a system typically install backdoors
(such as Trojans) to make future attacks easier. When attackers send
information to and retrieve information from a backdoor program, they
generate interactive traffic that IDP can detect.

The rules in all rulebases, including the Zone, Global, and Multicast rulebases,
combine to create a security policy. To direct the device to process and execute
rules in the IDP rulebases, you need to enable IDP in a firewall rule. See “Enabling
IDP in Firewall Rules” on page 186.

NOTE: If you import the device into NetScreen-Security Manager, the imported device
configuration does not include the IDP, Exempt, or Backdoor rulebases.

184  Using IDP Rulebases

 Chapter 6: Intrusion Detection and Prevention

Role-Based Administration of IDP Rulebases

NetScreen-Security Manager’s role-based administration (RBA) allows you to create
custom roles for individual administrators to give them authority to view or edit IDP
rulebases. For more information about RBA, see the NetScreen-Security Manager
Administrator’s Guide. You can assign view or edit capabilities for a role based on a
IDP rulebase. For example, an administrator who can view and edit a firewall
rulebase may be able to only view IDP and Backdoor rulebases.

By default, the predefined roles System Administrator and Domain Administrator

can view and edit all rulebases, and the Read-Only System Administrator and
Read-Only Domain Administrator can only view rulebases. When you create a new
role, the New Role dialog box allows you to specify whether an administrator can
view or edit IDP or Backdoor rulebases.

Configuring Objects for IDP Rules

Objects are reusable logical entities that you can apply to rules. Each object that you
create is added to a database for the object type. You can use the following types of
objects:

 Address objects represent components of your network, such as host

machines, servers, and subnets. You use address objects in security policy rules
to specify the network components that you want to protect.

NOTE: You must create each object in the Address Object database. There are no default
address objects.

For information about creating address objects, see the NetScreen-Security

Manager Administrator’s Guide.

 Service objects represent network services that use Transport layer protocols
such as TCP, UDP, RPC, and ICMP. You use service objects in rules to specify the
service an attack uses to access your network. NetScreen-Security Manager
includes predefined service objects, a database of service objects that are based
on industry-standard services. If you need to add service objects that are not
included in the predefined service objects, you can create custom service
objects. For more information about creating service objects, see the
NetScreen-Security Manager Administrator’s Guide.

 IDP attack objects represent known and unknown attacks. IDP includes a
predefined attack object database that is periodically updated by Juniper
Networks (see “Managing IDP” on page 232). You can also add custom attack
objects to detect attacks that are unique to your network (see “Configuring IDP
Attack Objects” on page 211.)

Using IDP Rulebases  185

 Concepts & Examples ScreenOS Reference Guide

Using Security Policy Templates

When you create a new security policy, you have the following options:

 Create a security policy that contains a default firewall rule.

 Select a predefined template.

 Copy an existing security policy into a new policy, which you can then modify.

A template is a set of rules of a specific rulebase type that you can use as a starting
point when creating a security policy. For a list of templates, see the
NetScreen-Security Manager Administrator’s Guide.

Enabling IDP in Firewall Rules

The rules in all rulebases combine to create a security policy. Security devices
process and execute rules in each rulebase in the following order:

1. Zone-based firewall

2. Global firewall

3. Multicast

4. IDP

5. Exempt

6. Backdoor

Enabling IDP in a zone-based or global firewall rule directs traffic that matches the
firewall rule to be checked against the IDP rulebases.

NOTE: The firewall action must be permit. You cannot enable IDP for traffic that the
device denies or rejects.

To enable IDP in a firewall rule, right-click in the Rule Options column for the
zone-based or global firewall rule, then select DI Profile/Enable IDP. The DI
Profile/Enable IDP dialog box appears, as shown in Figure 60.

186  Enabling IDP in Firewall Rules

 Chapter 6: Intrusion Detection and Prevention

Figure 60: DI Profile/Enable IDP Dialog Box

NOTE: These attack-profile settings apply only to the Deep Inspection (DI) feature on
firewall/VPN devices. When you install the IDP license on the device, DI is disabled
on the device.

Enabling IDP
By default, the IDP option is disabled. Select Enable to enable IDP for traffic that
matches the firewall rule. When you enable IDP, you can also select whether the IDP
function is to operate inline or in inline tap mode on the device on which the
security policy is installed.

NOTE: If you do not enable IDP in a firewall rule for a target device, you can still configure
IDP rules for the device. However, you will not be able to apply the IDP rules when
you update the security policy on the device.

Specifying Inline or Inline Tap Mode

IDP on the target device can operate in one of two modes:

 In inline mode, IDP is directly in the path of traffic on your network and can
detect and block attacks. For example, you can deploy the security device with
integrated firewall/VPN/IDP capabilities between the Internet and an enterprise
LAN, WAN, or special zone such as the DMZ. This is the default mode.

 In inline tap mode, IDP receives a copy of a packet while the original packet is
forwarded on the network. IDP examines the copy of the packet and flags any
potential problems. IDP’s inspection of packets does not affect the forwarding
of the packet on the network.

NOTE: You must deploy the IDP-capable device inline. You cannot connect a device that
is in inline tap mode to an external TAP or SPAN port on a switch.

You specify the IDP mode as part of the security policy for the device.

Enabling IDP in Firewall Rules  187

 Concepts & Examples ScreenOS Reference Guide

Configuring IDP Rules

The IDP rulebase protects your network from attacks by using attack objects to
identify malicious activity and then by taking action to thwart the attacks. Avoid
creating too large number of IDP rules. It is important to balance the complexity
and number of IDP rules you configure against their potential to cause issues with
performance. For more information about performance issues, see the
NetScreen-Security Manager Administrator’s Guide.

When you create an IDP rule, you must specify the following:

 The type of network traffic you want IDP to monitor for attacks, using the
following characteristics:

 From Zone/To Zone: All traffic flows from a source to a destination zone.
You can select any zone for the source or destination; however, the zone
must be valid for the security devices you select in the Install On column of
the rule. You can also use zone exceptions to specify unique to and from
zones for each device.

 Source IP: The source IP address from which the network traffic originates.
You can set this to “any” to monitor network traffic originating from any IP
address. You can also specify “negate” to specify all sources except the
specified addresses.

 Destination IP: The destination IP address to which the network traffic is

sent. You can set this to “any” to monitor network traffic sent to any IP
address. You can also specify negate to specify all destinations except the
specified addresses.

 Service: The Application Layer protocols supported by the destination IP

address.

 Terminate Match: By default, rules in the IDP rulebase are nonterminal,

meaning that IDP examines all rules in the rulebase and executes all
matches. You can specify that a rule is terminal; if IDP encounters a match
for the source, destination, and service specified in a terminal rule, it does
not examine any subsequent rules for that connection. Note that the traffic
does not need to match the attacks specified in the terminal rule. Terminal
rules should appear near the top of the rulebase, before other rules that
would match the same traffic. Use caution when specifying terminal rules.

See Figure 70, “Set Terminal Rules,” on page 196. Note that, if you check
Terminate Match, rules below the Terminate Match Rule (Rule Shadowing)
are not evaluated.

If you do not check Terminate Match, multi-event logging/matching occur,

which results in one attack creating multiple entries in the logs and
multiple actions.

 The attack(s) you want IDP to match in the monitored network traffic. Each
attack is defined as an attack object, which represents a known pattern of
attack. Whenever this known pattern of attack is encountered in the monitored
network traffic, the attack object is matched. You can add attack objects
individually or by category, operating system, or severity.

188  Configuring IDP Rules

 Chapter 6: Intrusion Detection and Prevention

 The action you want IDP to take when the monitored traffic matches the rule’s
attack objects. You can specify the following:

 Action: The action you want IDP to perform against the current
connection.

 IP Actions: The action you want IDP to perform against future connections
that use the same IP address.

 Notification: Choose none; or enable logging, then select the appropriate

logging options for your network.

 Severity: Use the default severity settings of the selected attack objects, or
choose a specific severity for your rule.

NOTE: The ISG 1000 and ISG 2000 devices with IDP can inspect traffic that is
encapsulated in GPRS tunneling protocol (GTP) and generic routing encapsulation
(GRE).

IDP inspects only the following two GRE protocol types:

 IP

 PPP for CDMA A10 channel

For more information about how IDP inspects GRE and GTP packets, see the
Netscreen-Security Manager Administrator's Guide.

Adding the IDP Rulebase

Before you can configure a rule in the IDP rulebase, you need to add the IDP
rulebase to a security policy using the following steps:

1. In the main navigation tree, select Security Policies. Open a security policy
either by double-clicking on the policy name in the Security Policy window or
by clicking on the policy name and then selecting the Edit icon.

2. Click the Add icon in the upper right corner of the Security Policy window, then
select Add IDP Rulebase. See Figure 61.

Figure 61: Adding an IDP Rulebase

Configuring IDP Rules  189

 Concepts & Examples ScreenOS Reference Guide

The IDP rulebase tab appears. See Figure 62.

Figure 62: IDP Rulebase Added

3. To configure an IDP rule, click the Add icon on the left side of the Security Policy
window.

A default IDP rule appears. You can modify this rule as needed. See Figure 63.

Figure 63: IDP Rule Added

Matching Traffic
When creating your IDP rules, you must specify the type of network traffic that you
want IDP to monitor for attacks. These characteristics include the network
components that originate and receive the traffic and the firewall zones the traffic
passes through.

The Match columns From Zone, Source, To Zone, Destination, and Service are
required for all rules in the IDP rulebase. The Terminate Match selection allows you
to designate a rule as terminal; if IDP encounters a match for the other Match
columns in a terminal rule, no other rules in the rulebase are examined. The
matching traffic does not need to match the attacks specified in a terminal rule. (For
more information, see “Terminal Rules” on page 195.)

The following sections detail the Match columns of an IDP rule.

Source and Destination Zones

You can select multiple zones for the source and destination; however, these zones
must be available on the security devices on which you will install the policy. You
can specify “any” for the source or destination zones to monitor network traffic
originating from or destined for any zone.

190  Configuring IDP Rules

 Chapter 6: Intrusion Detection and Prevention

NOTE: You can create custom zones for some security devices. The list of zones from
which you can select source and destination zones includes the predefined and
custom zones that have been configured for all devices managed by
NetScreen-Security Manager. Therefore, you should only select zones that are
applicable for the device on which you will install the security policy.

Source and Destination Address Objects

In the NetScreen-Security Manager system, address objects are used to represent
components on your network: hosts, networks, servers, and so on. Typically, a
server or other device on your network is the destination IP for incoming attacks
and can sometimes be the source IP for interactive attacks (see “Configuring
Backdoor Rules” on page 207 for more information about interactive attacks). You
can specify “any” to monitor network traffic originating from any IP address. You
can also “negate” the address object(s) listed in the Source or Destination column to
specify all sources or destinations except the excluded object(s).

You can create address objects either before you create an IDP rule (see the
NetScreen-Security Manager Administrator’s Guide) or while creating or editing an
IDP rule. To select or configure an address object, right-click on either the Source or
the Destination column of a rule, then select Select Address. In the Select Source
Addresses dialog box, you can either select an already created address object or
click the Add icon to create a new host, network, or group object.

Example: Setting Source and Destination

You want to detect incoming attacks that target your internal network. Set the From
Zone to Untrust and the Source IP to any. Set the To Zone to dmz and trust. Select
the address object that represents the host or server you want to protect from
attacks as the Destination IP.

Your rule looks similar to the example shown in Figure 64.

Figure 64: Set Source and Destination

Example: Setting Multiple Sources and Destinations

You want to detect attacks between two networks. Select multiple address objects
for the Source and Destination.

Your rule looks similar to the example in Figure 65.

Configuring IDP Rules  191

 Concepts & Examples ScreenOS Reference Guide

Figure 65: Set Multiple Source and Destination Networks

The more specific you are in defining the source and destination of an attack, the
more you reduce false positives.

Services
Services are Application Layer protocols that define how data is structured as it
travels across the network. Because the services you support on your network are
the same services that attackers must use to attack your network, you can specify
which services are supported by the destination IP to make your rule more efficient.

NOTE: All services rely on a Transport Layer protocol to transmit data. IDP includes
services that use the TCP, UDP, RPC, and ICMP Transport Layer protocols.

Service objects represent the services running on your network. NetScreen-Security

Manager includes predefined service objects that are based on industry-standard
services. You use these service objects in rules to specify the service an attack uses
to access your network. You can also create custom service objects to represent
protocols that are not included in the predefined services. For more information
about configuring service objects, see the information about object configuration in
the NetScreen-Security Manager Administrator’s Guide.

In the Service column, you select the service of the traffic you want IDP to match:

 Select Default to accept the service specified by the attack object you select in
the Attacks column. When you select an attack object in the Attack column, the
service associated with that attack object becomes the default service for the
rule. To see the exact service, view the attack object details.

 Select Any to set any service.

 Select Select Service to choose specific services from the list of defined service
objects.

Example: Setting Default Services

You want to protect your FTP server from FTP attacks. Set the service to Default,
and add an attack object that detects FTP buffer overflow attempts. The Service
column in the rule still displays “Default”, but the rule actually uses the default
service of TCP-FTP, which is specified in the attack object.

Your rule looks similar to the example shown in Figure 66.

192  Configuring IDP Rules

 Chapter 6: Intrusion Detection and Prevention

Figure 66: Set Default Services

Example: Setting Specific Services

Your mail server supports POP3 and SMTP connections but does not support IMAP.
Set POP3 and SMTP service objects as services that can be used to attack the mail
server. Because IMAP is not supported, you do not need to add the IMAP service
object.

Your rule looks similar to the example in Figure 67.

Figure 67: Set Specific Services

If you are supporting services on nonstandard ports, you should choose a service
other than the default.

Example: Setting Nonstandard Services

You use a nonstandard port (8080) for your HTTP services. Use the Object Manager
to create a custom service object on port 8080.

Configuring IDP Rules  193

 Concepts & Examples ScreenOS Reference Guide

Figure 68: Add Nonstandard Services Object

Add this service object to your rule, then add several HTTP attack objects, which
have a default service of TCP/80. IDP uses the specified service, HTTP-8080, instead
of the default and looks for matches to the HTTP attacks in TCP traffic on port 8080.

Your rule looks similar to the example in Figure 69.

Figure 69: Set Nonstandard Service

You can create your own service objects to use in rules, such as service objects for
protocols that use nonstandard ports. However, you cannot match attack objects to
protocols they do not use.

194  Configuring IDP Rules

 Chapter 6: Intrusion Detection and Prevention

Terminal Rules
The normal IDP rule-matching algorithm starts from the top of the rulebase and
checks traffic against all rules in the rulebase that match the source, destination,
and service. A terminal rule is an exception to this normal rule-matching algorithm.
When a match is discovered in a terminal rule for the source, destination, and
service, IDP does not continue to check subsequent rules for the same source,
destination, and service. It does not matter whether or not the traffic matches the
attack objects in the matching rule.

You can use a terminal rule for the following purposes:

 To set different actions for different attacks for the same Source and
Destination. This is illustrated by rules 3 and 6 in the following section,
“Example: Setting Terminal Rules”.

 To disregard traffic that originates from a known trusted source. Typically, the
action is None for this type of terminal rule. This is illustrated by rule 1 in the
following section, “Example: Setting Terminal Rules”.

 To disregard traffic sent to a server that is only vulnerable to a specific set of

attacks. Typically, the action is Drop Connection for this type of terminal rule.

Use caution when defining terminal rules. An inappropriate terminal rule can leave
your network open to attacks. Remember that traffic matching the source,
destination, and service of a terminal rule is not compared to subsequent rules,
even if the traffic does not match an attack object in the terminal rule. Use a
terminal rule only when you want to examine a certain type of traffic for one
specific set of attack objects. Be particularly careful about terminal rules that use
“any” for both the source and destination.

Terminal rules should appear near the top of the rulebase before other rules that
would match the same traffic. You set a rule as terminal by selecting the box in the
Terminate Match column of the Security Policy window when you create or modify
the rule.

NOTE: In many cases, you can use an exempt rule instead of a terminal rule. You might
find it easier and more straightforward to configure an exempt rule than a
terminal rule. See “Configuring Exempt Rules” on page 202.

Example: Setting Terminal Rules

In the example IDP rulebase shown below, rules 1, 3, 4, and 5 are configured as
terminal rules:

 Rule 1 terminates the match algorithm if the source IP of the traffic originates
from the security network, a known trusted network. If this rule is matched,
IDP disregards traffic from the security network and does not continue
monitoring the session for malicious data.

 Rules 3 and 6 set different actions for different attacks when the destination IP
is the Corporate or Europe email server. Rule 3 terminates the match algorithm
when the attack is an email that uses the SMTP context Confidential. Rule 6
closes the server when the attack is an SMTP attack.

Configuring IDP Rules  195

 Concepts & Examples ScreenOS Reference Guide

 Rule 4 terminates the match algorithm when the destination is the webserver
and the attack is a Critical or High HTTP attack. The rule ensures that IDP drops
the most important HTTP attacks against the webserver and does not continue
to match the connection.

 Rule 5 terminates the match algorithm when the source is the internal network
and the attack is a critical, high, or medium trojan backdoor. The rule ensures
that IDP closes both the client and server and does not continue to match the
connection.

The default in the Service Column (see Figure 70 on page 196) means the rule is
dynamically built based on the service bindings of the attack objects of that rule. To
see the service bindings for a rule, right click on the attacks and select View
Services. Even if you select a broad category like HTTP Critical, use the View
Services for more details.

Figure 70: Set Terminal Rules

Defining Actions
You can specify which actions IDP is to take against attacks that match rules in your
security policy. For each attack that matches a rule, you can choose to ignore, drop,
or close the current attacking packets or connection. If the rule is triggered, IDP can
perform actions against the connection.

When IDP is configured for Drop Packet and finds a TCP attack, the security module
informs the management module that successive packets are attacks; consequently,
the IDP action is updated to a higher severity, Drop Connection.

196  Configuring IDP Rules

 Chapter 6: Intrusion Detection and Prevention

If a packet triggers multiple rule actions, the device will apply the most severe
action. For example, if the rules dictate that a packet will receive a diffserv marking
and be dropped, then the packet will be dropped.

Table 17 shows the actions you can specify for IDP rules.

Table 17: IDP Rule Actions

Action Description
None IDP inspects for attacks but IDP does not take action against the
connection. If a rule that contains None action is matched, the
corresponding log record displays "accept" in the action column of
the Log Viewer.
Ignore IDP does not inspect for attacks and ignores this connection.
Diffserv Marking Assigns the indicated service-differentiation value to packets in an
attack, then passes them on normally. Set the
service-differentiation value in the dialog box that appears when
you select this action in the rulebase.
Note that diffserv marking is not applied to the first packet that is
detected as an attack but is applied to subsequent packets. The
marking has no effect in tap mode or when using NSRP.
If there is a conflict in DSCP specified by the IDS rulebase and the
firewall policy, the setting in the IDS rulebase has priority.
Drop Packet IDP drops a matching packet before it can reach its destination but
does not close the connection. Use this action to drop packets for
attacks in traffic that is prone to spoofing, such as UDP traffic.
Closing a connection for such traffic could result in a denial of
service(Dos), which will prevent you from receiving traffic from
legitimate source IP addresses.
Drop Connection IDP drops all packets associated with the connection. Use this
action to drop connections for traffic that is not prone to spoofing.
Close Client and Server IDP closes the connection and sends an RST packet to both the
client and the server. If IDP is operating in inline tap mode, IDP
sends an RST packet to both the client and the server but does not
close the connection.
Close Client IDP closes the connection to the client but not to the server.
Close Server IDP closes the connection to the server but not to the client.
Recommended IDP takes the action recommended in individual attack objects. If
IDP detects multiple attacks in one packet and the rule action is
Recommended for all the attacks, IDP applies the most severe
action. For example, if two attacks match in the same packet and
have Drop Packet and Drop as their recommended actions,
respectively, Drop is applied.
Note: You cannot set Diffserv Marking as the recommended action.
Recommended actions in individual attack objects can be
overwritten by specifying explicit actions in policy rules. If you
specify an action within a policy rule, it will take precedence over
the recommended action. For more information about IDP rule
actions, see the NetScreen-Security Manager Administrator's Guide.

For more information about IDP Rule actions, see the NetScreen-Security Manager
Administrator’s Guide.

Configuring IDP Rules  197

 Concepts & Examples ScreenOS Reference Guide

Setting Attack Objects

Attack objects represent specific patterns of malicious activity within a connection,
and are a method for detecting attacks. Each attack object detects a known or an
unknown attack that can be used to compromise your network. From more
information about attack objects, see “Configuring IDP Attack Objects” on page 211.

You can add attack objects to your rule individually or in groups. Attack objects are
organized as follows:

 Attack List is an alphabetical list of all attack objects, including custom attack
objects.

 Dynamic Attack Group contains predefined and custom attack groups.

To add attack objects for a rule, right-click the Attacks column of the rule, then select
Select Attacks. The Add Attacks dialog box appears.

Adding Attack Objects Individually

The Attack List allows you to select one or more specific attack objects for your rule.
The Attack List contains attack objects displayed in alphabetical order. You can also
use the integrated search function in NetScreen-Security Manager to locate a
specific word or string in the attack object name. For more information about using
the search feature, see the NetScreen-Security Manager Administrator’s Guide.

For more information about attack objects and creating custom attack objects and
groups, see “Configuring IDP Attack Objects” on page 211.

Adding Attack Objects by Category

IDP groups attack objects into predefined service category groups. Services are
Application Layer protocols which define how data is structured as it travels across
the network.

To attack a system, an attacker must use a protocol supported on that system.

Therefore, When you create a rule to protect a system, you must select only the
categories that are used by the address objects you are protecting with the rule.

Example: Adding Attack Objects by Service

You rely on FTP and HTTP for extensive file transfer on your webserver. Choose the
FTP and HTTP category groups to carefully monitor all traffic that uses these
services.

If you do not want to choose an entire category group for a rule, you can select your
attack objects by severity.

Adding Attack Objects by Operating System

IDP groups attack objects for several predefined operating systems to help you
choose the attack objects that are the most dangerous to specific devices on your
network. You can choose BSD, Linux, Solaris, or Windows.

If you do not want to choose an entire operating system group for a rule, you can
select your attack objects by severity.

198  Configuring IDP Rules

 Chapter 6: Intrusion Detection and Prevention

Adding Attack Objects by Severity

IDP defines five severity levels, each with a recommended set of IDP actions and
notifications (see Table 18). You can add a severity level to the Attacks column in
your rule, then choose the recommended actions for the severity level in the Action
column. (For more information about the actions you can select, see “Defining
Actions” on page 196.) You can also choose the recommended notifications for the
severity level in the Notifications column. (For more information about the
notifications you can select, see “Setting Notification” on page 200.)

NOTE: To protect critical address objects or popular targets for attack, such as your mail
server, use multiple severity levels to ensure maximum protection.

Table 18 shows the IDP severity levels, along with their recommended actions and
notifications.

Table 18: Severity Levels with Recommended Actions and Notifications

Severity Recommended Recommended

Level Description Action Notification
Critical Attacks attempt to evade an IPS, crash a machine, or gain Drop Packet Logging
system-level privileges. Drop Connection Alert
Major Attacks attempt to crash a service, perform a denial of service, Drop Packet Logging
install or use a Trojan, or gain user-level access to a host. Drop Connection Alert
Minor Attacks attempt to obtain critical information through directory None Logging
traversal or information leaks.
Warning Attacks attempt to obtain noncritical information or scan the None Logging
network. They can also be obsolete attacks (but probably harmless)
traffic.
Info Attacks are normal, harmless traffic containing URLs, DNS lookup None None
failures, and SNMP public community strings. You can use
informational attack objects to obtain information about your
network.

Setting IP Action
The IP Action column appears only when you view the security policy in Expanded
mode. To change the security policy view from Compact to Expanded mode, select
View > Expanded Mode.

If the current network traffic matches a rule, IDP can perform an IP action against
future network traffic that uses the same IP address. IP actions are similar to other
actions; they direct IDP to drop or close the connection. However, because you now
also have the attacker’s IP address, you can choose to block the attacker for a
specified time. If attackers cannot immediately regain a connection to your
network, they might try to attack easier targets.

Use IP actions in conjunction with actions and logging to secure your network. In a
rule, first configure an action to detect and prevent current malicious connections
from reaching your address objects. Then, right-click in the IP Action column of the
rule and select Configure to bring up the Configure IP Action dialog box. Enable
and configure an IP action to prevent future malicious connections from the
attacker’s IP address.

Configuring IDP Rules  199

 Concepts & Examples ScreenOS Reference Guide

Choosing an IP Action
For each IP action option, an IP action is generated by the IDP system. The IP
action instructs IDP to perform the specified task. Select from the following options:

 IDP Notify. IDP does not take any action against future traffic, but logs the
event. This is the default.

 IDP Drop. IDP drops blocks future connections that match the criteria in the
Blocking Options box.

 IDP Close. IDP closes future connections that match the criteria in the Blocking
Options box.

Choosing a Blocking Option

Each blocking option follows the criteria you set in the Actions box. Blocking
options can be based on the following matches of the attack traffic:

 Source, Destination, Destination Port and Protocol. IDP blocks future traffic
based on the source, destination, destination port, and protocol of the attack
traffic. This is the default.

 Source. IDP blocks future traffic based on the source of the attack traffic.

 Destination. IDP blocks future traffic based on the destination of the attack
traffic.

 From Zone, Destination, Destination Port and Protocol. IDP blocks future
traffic based on the source zone, destination, destination port, and protocol of
the attack traffic.

 From Zone. IDP blocks future traffic based on the source zone of the attack
traffic.

Setting Logging Options

When IDP detects attack traffic that matches a rule and triggers an IP action, IDP
can log information about the IP action or create an alert in the Log Viewer. By
default, no logging options are set.

Setting Timeout Options

You can set the number of seconds that you want the IP action to remain in effect
after a traffic match. For permanent IP actions, the default timeout value is 0.

Setting Notification
The first time you design a security policy, you might be tempted to log all attacks
and let the policy run indefinitely. Do not do this! Some attack objects are
informational only, and others can generate false positives and redundant logs. If
you become overloaded with data, you can miss something important. Remember
that security policies that generate too many log records are hazardous to the
security of your network, as you might discover an attack too late or miss a security

200  Configuring IDP Rules

 Chapter 6: Intrusion Detection and Prevention

breach entirely if you have to sift through hundreds of log records. Excessive logging
can also affect IDP throughput, performance, and available disk space. A good
security policy generates enough logs to fully document only the important security
events on a network.

Setting Logging
In the Configure Notification dialog box, select Logging, then click OK. Each time
the rule is matched, the IDP system creates a log record that appears in the Log
Viewer.

Logging an attack creates a log record that you can view in realtime in the Log
Viewer. For more critical attacks, you can also set an alert flag to appear in the log
record.

To log an attack for a rule, right-click the Notification column of the rule, then select
Configure. The Configure Notification dialog box appears.

Setting an Alert
In the Configure Notification dialog box, select Alert, then click OK. If Alert is
selected and the rule is matched, IDP places an alert flag in the Alert column of the
Log Viewer for the matching log record.

Logging Packets
You can record individual packets in network traffic that match a rule by capturing
the packet data for the attack. Viewing the packets used in an attack on your
network can help you determine the extent of the attempted attack and its purpose,
whether or not the attack was successful, and any possible damage to your
network.

NOTE: To improve IDP performance, log only the packets received after the attack.

If multiple rules with packet capture enabled match the same attack, IDP captures
the maximum specified number of packets. For example, you configure rule 1 to
capture 10 packets before and after the attack, and you configure rule 2 to capture 5
packets before and after the attack. If both rules match the same attack, IDP
attempts to capture 10 packets before and after the attack.

NOTE: Packet captures are restricted to 256 packets before and after an attack.

Setting Severity
The Severity column appears only when you view the security policy in Expanded
mode. To change the security policy view from Compact to Expanded mode, from
the menu bar, select View > Expanded Mode.

You can override the inherent severity for an attack in a rule within the IDP
rulebase. You can set the severity level to Default, Info, Warning, Minor, Major, or
Critical.

Configuring IDP Rules  201

 Concepts & Examples ScreenOS Reference Guide

To change the severity for a rule, right-click the Severity column of the rule, then
select a severity.

Setting Targets
For each rule in the IDP rulebase, you can select the security device that will use
that rule to detect and prevent attacks. When you install the security policy to which
the rule belongs, the rule becomes active only on the device(s) you selected in the
Install On column of the rulebase.

Entering Comments
You can enter notations about the rule in the Comments column. The information
in the Comments column is not pushed to the target device(s). To enter a comment,
right-click on the Comments column, then select Edit Comments. The Edit
Comments dialog box appears. You can enter a comment of up to 1024 characters.

Configuring Exempt Rules

The Exempt rulebase works in conjunction with the IDP rulebase. Before you can
create exempt rules, you must first create rules in the IDP rulebase. If traffic
matches a rule in the IDP rulebase, IDP attempts to match the traffic against the
Exempt rulebase before performing the specified action or creating a log record for
the event.

NOTE: If you delete the IDP rulebase, the Exempt rulebase is also deleted.

You might want to use an exempt rule under the following conditions:

 When an IDP rule uses an attack object group that contains one or more attack
objects that produce false positives or irrelevant log records.

 When you want to exclude a specific source, destination, or source/destination

pair from matching an IDP rule. This prevents IDP from generating unnecessary
alarms.

You can also use an exempt rule if the IDP rulebase uses static or dynamic
attack-object groups containing one or more attack objects that produce false
positives or irrelevant log records.

When you create an exempt rule, you must specify the following:

 Source and destination for traffic you want to exempt. You can set the source or
destination to “any” to exempt network traffic originating from any source or
sent to any destination. You can also specify “negate” to specify all sources or
destinations except specified addresses.

 The attack(s) you want IDP to exempt for the specified source/destination
addresses. You must include at least one attack object in an exempt rule.

202  Configuring Exempt Rules

 Chapter 6: Intrusion Detection and Prevention

NOTE: The Exempt rulebase is a nonterminal rulebase. That is, IDP attempts to match
traffic against all rules in the Exempt rulebase and executes all matches.

Adding the Exempt Rulebase

Before you can configure a rule in the Exempt rulebase, you need to add the
Exempt rulebase to a security policy with the following steps:

1. In the main navigation tree, select Security Policies. Open a security policy
either by double-clicking on the policy name in the Security Policies window, or
by clicking on the policy name, then selecting the Edit icon.

2. Click the Add icon in the upper right corner of the Security Policy window, then
select Add Exempt Rulebase.

Figure 71: Adding an Exempt Rulebase

The Add Exempt Rulebase tab appears.

Figure 72: Exempt Rulebase Added

3. To configure an exempt rule, click the Add icon on the left side of the Security
Policy window.

A default exempt rule appears. You can modify this rule as needed.

Configuring Exempt Rules  203

 Concepts & Examples ScreenOS Reference Guide

Figure 73: Exempt Rule Added

Defining a Match
Specify the traffic you want to exempt from attack detection. The Match columns
From Zone, Source, To Zone, and Destination are required for all rules in the exempt
rulebase.

The following sections detail the Match columns of an exempt rule.

Source and Destination Zones

You can select multiple zones for the source and destination, however these zones
must be available on the devices on which you will install the policy. You can specify
“any” for the source or destination zones to monitor network traffic originating
from or destined for any zone.

NOTE: You can create custom zones for some security devices. The list of zones from
which you can select source and destination zones includes the predefined and
custom zones that have been configured for all devices managed by
NetScreen-Security Manager. Therefore, you should only select zones that are
applicable for the device on which you will install the security policy.

Source and Destination Address Objects

In the NetScreen-Security Manager system, address objects are used to represent
components on your network: hosts, networks, servers, and so on. You can specify
“any” to monitor network traffic originating from any IP address. You can also
negate the address object(s) listed in the Source or Destination column of a rule to
specify all sources or destinations except the excluded object.

You can create address objects either before you create an exempt rule (see the
NetScreen-Security Manager Administrator’s Guide) or while creating or editing an
exempt rule. To select or configure an address object, right-click on either the
Source or Destination column of a rule, then select Select Address. In the Select
Source Addresses dialog box, you can either select an already created address
object, or you can click the Add icon to create a new host, network, or group object.

204  Configuring Exempt Rules

 Chapter 6: Intrusion Detection and Prevention

Example: Exempting a Source/Destination Pair

To improve performance and eliminate false positives between your Internal Lab
devices and your Engineering desktops, you want to exempt attack detection. Your
exempt rule looks similar to Figure 74:

Figure 74: Exempting Source and Destination

Setting Attack Objects

You specify the attack(s) you want IDP to exempt for the specified
source/destination addresses. You must include at least one attack object in an
exempt rule.

Example: Exempting Specific Attack Objects

You consistently find that your security policy generates false positives for the
attack HTTP Buffer Overflow: Header on your internal network. You want to exempt
attack detection for this attack when the source IP is from your internal network.
Your exempt rule looks similar to Figure 75:

Figure 75: Exempting Attack Object

Setting Targets
For each rule in the Exempt rulebase, you can select the IDP-capable device that will
use that rule to detect and prevent attacks. When you install the security policy to
which the rule belongs, the rule becomes active only on the device(s) you select in
the Install On column of the rulebase.

Configuring Exempt Rules  205

 Concepts & Examples ScreenOS Reference Guide

Entering Comments
You can enter notations about the rule in the Comments column. The information
in the Comments column is not pushed to the target device(s). To enter a comment,
right-click on the Comments column, then select Edit Comments. The Edit
Comments dialog box appears. You can enter a comment of up to 1024 characters.

Creating an Exempt Rule from the Log Viewer

You can also create a rule in the Exempt rulebase directly from the
NetScreen-Security Manager Log Viewer. You might want to use this method to
quickly eliminate rules that generate false positive log records. (For more
information about viewing IDP logs, see “Managing IDP” on page 232. For more
information about using the Log Viewer, see the NetScreen-Security Manager
Administrator’s Guide.)

To create an exempt rule from the Log Viewer, perform the following steps:

1. View the IDP/DI logs in the Log Viewer.

2. Right-click a log record that contains an attack you want to exempt, then select
Exempt.

Figure 76: Exempting a Log Record Rule

The Exempt rulebase for the security policy that generated the log record is
displayed, with the exempt rule that is associated with the log entry. The
source, destination, and attack settings for the rule are automatically filled in
based on the information in the log record.

NOTE: If the Exempt rulebase does not already exist when you create an exempt rule
from the Log Viewer, the rulebase is automatically created and the rule is added.

You can modify, reorder, or merge an exempt rule created from the Log Viewer in
the same manner as any other exempt rule that you create directly in the Exempt
rulebase.

206  Configuring Exempt Rules

 Chapter 6: Intrusion Detection and Prevention

Configuring Backdoor Rules

A backdoor is a mechanism installed on a host computer that facilitates
unauthorized access to a system. Attackers who have already compromised a
system can install a backdoor to make future attacks easier. When attackers type
commands to control a backdoor, they generate interactive traffic.

Unlike antivirus software, which scans for known backdoor or executable files on
the host system, IDP detects the interactive traffic that is produced when backdoors
are used. If interactive traffic is detected, IDP can perform IP actions against the
connection to prevent an attacker from further compromising your network.

When you configure a backdoor rule, you must specify the following:

 Source and destination addresses for traffic you want to monitor. To detect
incoming interactive traffic, set the Source to “any” and the Destination to the
IP address of network device you want to protect. To detect outgoing interactive
traffic, set the Source to the IP address of the network device you want to
protect and the Destination to “any.”

 Services that are offered by the Source or Destination as well as interactive

services that can be installed and used by attackers.

NOTE: Do not include Telnet, SSH, RSH, NetMeeting, or VNC, as these services are often
used to legitimately control a remote system and their inclusion might generate
false positives.

 Action that the IDP is to perform if interactive traffic is detected. Set the
Operation to “detect.” If you are protecting a large number of network devices
from interactive traffic, you can create a rule that ignores accepted forms of
interactive traffic from those devices, then create another rule that detects all
interactive traffic from those devices.

NOTE: The Backdoor rulebase is a terminal rulebase. That is, when IDP finds a match on
a rule in the Backdoor rulebase, it does not execute successive rules.

Adding the Backdoor Rulebase

Before you can configure a rule in the Backdoor rulebase, you need to add the
Backdoor rulebase to a security policy with the following steps:

1. In the main navigation tree, select Security Policies. Open a security policy
either by double-clicking on the policy name in the Security Policy window, or
by clicking on the policy name, then selecting the Edit icon.

2. To configure a backdoor rule, click the Add icon in the upper right corner of the
Security Policy window (see Figure 77).

Configuring Backdoor Rules  207

 Concepts & Examples ScreenOS Reference Guide

Figure 77: Adding the Backdoor Rulebase

3. Select Add Backdoor Rulebase.

A default backdoor rule appears as shown in Figure 78. You can modify this
rule as needed.

Figure 78: Backdoor Rule Added

Defining a Match
You specify the traffic you want IDP to monitor for indications of backdoors or
Trojans. The Match columns From Zone, Source, To Zone, Destination, and Service
are required for all rules in the Backdoor rulebase.

The following sections detail the Match columns of a backdoor rule.

Source and Destination Zones

You can select multiple zones for the source and destination. However, these zones
must be available on the security devices on which you will install the policy. You
can specify “any” for the source or destination zones to monitor network traffic
originating from or destined for any zone.

NOTE: You can create custom zones for some security devices. The list of zones from
which you can select source and destination zones includes the predefined and
custom zones that have been configured for all devices managed by
NetScreen-Security Manager. Therefore, you should only select zones that are
applicable for the device on which you will install the security policy.

208  Configuring Backdoor Rules

 Chapter 6: Intrusion Detection and Prevention

Source and Destination Address Objects

In the NetScreen-Security Manager system, address objects are used to represent
components on your network: hosts, networks, servers, and so on. Typically, a
server or other device on your network is the destination IP for incoming attacks
and it can sometimes be the source IP for interactive attacks. You can specify “any”
to monitor network traffic originating from any IP address. You can also negate the
address object(s) listed in the Source or Destination column to specify all sources or
destinations except the excluded address object.

You can create address objects either before you create a backdoor rule (see the
NetScreen-Security Manager Administrator’s Guide) or while creating or editing a
backdoor rule. To select or configure an address object, right-click on either the
Source or Destination column of a rule, then select Select Address. In the Select
Source Addresses dialog box, you can either select an already created address
object or you can click the Add icon to create a new host, network, or group object.

Services
Select interactive service objects. Be sure to include services that are offered by the
source or destination IP as well as interactive services that are not; attackers can
use a backdoor to install any interactive service. Do not include Telnet, SSH, RSH,
NetMeeting, or VNC, as these services are often used to control a remote system
legitimately, and their inclusion might generate false positives.

Setting the Operation

Set the Operation to detect or ignore. If you select detect, choose an action to
perform if backdoor traffic is detected. If you are protecting a large number of
address objects from interactive traffic, you can create a rule that ignores accepted
forms of interactive traffic from those objects, then create a succeeding rule that
detects all interactive traffic from those objects.

Setting Actions
Use the following steps to configure an action to perform if IDP detects interactive
traffic:

Table 19: Actions for Backdoor Rule

Action Description
Accept IDP accepts the interactive traffic.
Drop Connection IDP drops the interactive connection without sending an RST packet to the sender, preventing the traffic
from reaching its destination. Use this action to drop connections for traffic that is not prone to spoofing.
Close Client and IDP closes the interactive connection and sends an RST packet to both the client and the server. If the
Server IDP is in sniffer mode, IDP sends an RST packet to both the client and server but does not close the
connection.
Close Client IDP closes the interactive connection to the client but not to the server.
Close Server IDP closes the interactive connection to the server but not to the client.

Configuring Backdoor Rules  209

 Concepts & Examples ScreenOS Reference Guide

Setting Notification
The first time you design a security policy, you might be tempted to log all attacks
and let the policy run indefinitely. Do not do this! Some attack objects are
informational only, and others can generate false positives and redundant logs. If
you become overloaded with data, you might miss something important.
Remember that security policies that generate too many log records are hazardous
to the security of your network, as you might discover an attack too late or miss a
security breach entirely if you have to sift through hundreds of log records.
Excessive logging can also affect IDP throughput, performance, and available disk
space. A good security policy generates enough logs to fully document only the
important security events on a network.

Setting Logging
In the Configure Notification dialog box, select Logging, then click OK. Each time
the rule is matched, the IDP system creates a log record that appears in the Log
Viewer.

Logging an attack creates a log record that you can view real time in the Log Viewer.
For more critical attacks, you can also set an alert flag to appear in the log record,
notify you immediately by email, have IDP run a script in response to the attack, or
set an alarm flag to appear in the log record. Your goal is to fine tune the attack
notifications in your security policy to your individual security needs.

To log an attack for a rule, right-click the Notification column of the rule, then select
Configure. The Configure Notification dialog box appears.

Setting an Alert
In the Configure Notification dialog box, select Alert, then click OK. If Alert is
selected and the rule is matched, IDP places an alert flag in the Alert column of the
Log Viewer for the matching log record.

Logging Packets
You can record the individual packets in network traffic that matched a rule by
capturing the packet data for the attack. Viewing the packets used in an attack on
your network can help you determine the extent of the attempted attack and its
purpose, whether or not the attack was successful, and any possible damage to your
network.

NOTE: To improve IDP performance, log only the packets following the attack.

If multiple rules with packet capture enabled match the same attack, IDP captures
the maximum specified number of packets. For example, you configure rule 1 to
capture 10 packets before and after the attack, and you can configure rule 2 to
capture 5 packets before and after the attack. If both rules match the same attack,
IDP attempts to capture 10 packets before and after the attack.

NOTE: Packet captures are restricted to 256 packets before and after the attack.

210  Configuring Backdoor Rules

 Chapter 6: Intrusion Detection and Prevention

Setting Severity
You can override the inherent attack severity for a rule within the Backdoor
rulebase. You can set the severity to Default, Info, Warning, Minor, Major, or Critical.

To change the severity for a rule, right-click the Severity column, then select a
severity.

Setting Targets
For each rule in the Backdoor rulebase, you can select the security device that will
use that rule to detect and prevent attacks. When you install the security policy to
which the rule belongs, the rule becomes active only on the devices you select in
the Install On column of the rulebase.

Entering Comments
You can enter notations about the rule in the Comments column. The information
in the Comments column is not pushed to the target device(s). To enter a comment,
right-click on the Comments column, then select Edit Comments. The Edit
Comments dialog box appears. You can enter a comment of up to 1024 characters.

Configuring IDP Attack Objects

Attack objects contain patterns for known attacks that attackers can use to
compromise your network. Attack objects do not work on their own—they need to
be part of a rule before they can start detecting known attacks and preventing
malicious traffic from entering your network. To use attack objects in your IDP
rules, add the IDP rulebase in your security policy, then add an IDP rule to the
rulebase. See “Configuring Security Policies” on page 183.

NOTE: IDP is supported only on security devices with IDP capabilities.

About IDP Attack Object Types

In a security policy, you can select the attack object that a device uses to detect
attacks against your network. If an attack is detected, the device generates an
attack log entry that appears in the Log Viewer. For more information, see
“Configuring IDP Rules” on page 188.

NetScreen-Security Manager supports three types of IDP attack objects:

 Signature attack objects

 Protocol anomaly attack objects

 Compound attack objects

The following sections detail each attack object type.

Configuring IDP Attack Objects  211

 Concepts & Examples ScreenOS Reference Guide

Signature Attack Objects

An attack signature is a pattern that always exists within an attack; if the attack is
present, so is the attack signature. IDP uses stateful signatures to detect attacks.
Stateful signatures are more specific than regular signatures. With stateful
signatures, IDP can look for the specific protocol or service used to perpetrate the
attack, the direction and flow of the attack, and the context in which the attack
occurs. ScreenOS combines the attack pattern with service, context, and other
information into the attack object. Stateful signatures produce few false positives
because the context of the attack is defined, eliminating huge sections of network
traffic in which the attack would not occur.

Protocol Anomaly Attack Objects

Protocol anomaly attack objects detect abnormal or ambiguous messages within a
connection according to the set of rules for the particular protocol being used.
Protocol anomaly detection works by finding deviations from protocol standards,
most often defined by RFCs and common RFC extensions. Most legitimate traffic
adheres to established protocols. Traffic that does not produces an anomaly, which
may be created by attackers for specific purposes, such as evading an IPS.

Compound Attack Objects

A compound attack object combines multiple signatures and/or protocol anomalies
into a single object. Traffic must match all of the combined signatures and/or
protocol anomalies to match the compound attack object; you can specify the order
in which signatures or anomalies must match. Use compound attack objects to
refine your security policy rules, reduce false positives, and increase detection
accuracy.

A compound attack object enables you to be very specific about the events that
need to occur before IDP identifies traffic as an attack. For example, you might want
to take action only if an FTP session includes a failed login attempt for specific
users.

Viewing Predefined IDP Attack Objects and Groups

Juniper Networks provides predefined attack objects and attack object groups that
you can use in security policies to match traffic against known attacks. Juniper
Networks regularly updates the predefined attack objects and groups. While you
cannot create, edit, or delete predefined attack objects, you can update the list of
attack objects that you can use in security policies. The revised attack objects and
groups are available as part of an attack database update, which is downloaded to
the NetScreen-Security Manager GUI Server. See “Managing IDP” on page 232 for
information about attack-database updates.

To view predefined attack objects and groups perform the following steps:

1. In the Object Manager, click Attack Objects > IDP Objects. The IDP Objects
dialog box appears.

2. Click the Predefined Attacks or Predefined Attack Groups tab to view predefined
attack objects or groups.

212  Configuring IDP Attack Objects

 Chapter 6: Intrusion Detection and Prevention

Viewing Predefined Attacks

The Predefined Attacks tab displays all attacks in a table format and includes the
following information:

 Name of the attack object

 Severity of the attack: critical, major, minor, warning, info

 Category

 Keywords for the attack

 CVE number, which identifies the attack’s number in the Common

Vulnerabilities and Exposures database

 Bugtraq number, which identifies the equivalent attack in the Security Focus
Bugtraq database

Initially, attack objects are listed alphabetically by Category name but you can view
attacks in different orders by clicking on a column heading.

To locate all rules that use a predefined attack object, right-click the attack object,
then select View Usages.

To display a detailed description of an attack object, double-click on the attack.

Figure 79: Attack Viewer

Viewing Predefined Groups

The Predefined Attack Group tab displays the following predefined attack groups:

Configuring IDP Attack Objects  213

 Concepts & Examples ScreenOS Reference Guide

 Recommended — a list of all attack object objects that Juniper Networks

considers to be serious threats, organized into categories.

 Attack Type groups attack objects by type (anomaly or signature). Within

each type, attack objects are grouped by severity.

 Category groups attack objects by predefined categories. Within each

category, attack objects are grouped by severity.

 Operating System groups attack objects by the operating system to which

they apply: BSD, Linux, Solaris, or Windows. Within each operating system,
attack objects are grouped by services and severity.

 Severity groups attack objects by the severity assigned to the attack. IDP
has five severity levels: Info, Warning, Minor, Major, Critical. Within each
severity, attack objects are grouped by category.

To locate all rules that use a predefined attack object group, right-click the attack
object group, then select View Usages.

To display a detailed description of an attack object, double-click on the attack.

For more information about predefined groups, see the NetScreen-Security Manager
Administrator’s Guide.

Creating Custom IDP Attack Objects

You can create custom attack objects to detect new attacks or otherwise meet the
unique needs of your network.

To create a custom attack object, perform the following steps:

1. In the Object Manager, click Attack Objects > IDP Objects. The IDP Objects
dialog box appears.

2. Click the Custom Attacks tab.

3. Click the Add icon. The Custom Attack dialog box appears with the General tab
selected.

214  Configuring IDP Attack Objects

 Chapter 6: Intrusion Detection and Prevention

Figure 80: Custom Attack Dialog Box

a. Enter a name for the attack. The name is used to display the attack object
in the UI. You might want to include the protocol the attack uses as part of
the attack name.

b. Enter a description for the attack. The description provides details about
the attack. Entering a description is optional when creating a new attack
object, but it can help you remember important information about the
attack. View the attack descriptions for predefined attacks for examples. To
display details about a predefined attacks, see “Viewing Predefined
Attacks” on page 213.

c. Select a severity for this attack: Info, Warning, Minor, Major, or Critical.
Critical attacks are the most dangerous—typically these attacks attempt to
crash your server or gain control of your network. Informational attacks are
the least dangerous and typically are used by network administrators to
discover holes in their own security system.

d. Enter a category for this attack. You can use a predefined category or
define a new category

e. Enter one or more keywords for this attack that can help you find it later. A
keyword is a unique identifier used to display the attack object in log
records. Keywords indicate the important words that relate to the attack
and the attack object.

f. Check the check box if you want this attack object to be part of your
highest-risk set of attack objects. Later, when you add this attack object to
dynamic groups, you can specify whether only recommended attack
objects will be included. For more information about recommended attack
objects, see the NetScreen-Security Manager Administrator’s Guide.

4. Click the Platforms tab in the Custom Attack dialog box to specify the security
platform on which the attack detection is to occur.

a. Click the Add icon. The Custom Attack dialog box appears.

b. Select the platform on which the attack detection is to occur.

Configuring IDP Attack Objects  215

 Concepts & Examples ScreenOS Reference Guide

c. Select the type of attack—Signature, Protocol Anomaly, or Compound

Attack—then click Next.

If you are configuring a new attack object, the attack object editor leads you through
the screens to configure the specific type of attack:

 For signature attack objects, see the following section, “Creating a Signature
Attack Object”.

 For protocol anomaly attack objects, see “Protocol Anomaly Attack Objects” on
page 212.

 For compound attack objects, see “Compound Attack Objects” on page 212.

Creating a Signature Attack Object

To configure a signature attack in the Custom Attack dialog box, perform the
following steps:

1. Configure general parameters for the attack perform the following steps:

 False-Positives indicates the frequency (Unknown, Rarely, Occasionally,

Frequently) that the attack object produces a false positive when used in a
security policy. By default, all compound attack objects are set to Unknown,
as you fine tune your IDP system to your network traffic, you can change
this setting to help you track false positives.

 Service Binding allows you to select a protocol that the attack uses to enter
your network. Depending upon the protocol you select, additional fields
might appear. You can select the following protocol types:

 Any allows IDP to match the signature in all services (attacks can use
multiple services to attack your network).

 IP (specify protocol number) allows IDP to match the signature for a

specified IP protocol type.

 TCP (specify port ranges) allows IDP to match the signature for
specified TCP port(s).

 UDP (specify port ranges) allows IDP to match the signature for
specified UDP port(s).

 ICMP (specify ID) allows IDP to match the signature for specified ICMP
ID.

 RPC (specify program number) allows IDP to match the signature for a
specified remote procedure call program number.

 Service (specify service) allows IDP to match the signature for a

specified service.

 Time Binding allows IDP to detect a sequence of the same attacks over a
period of time. If you select Time Binding, you can specify the following
attributes which are bound to the attack object for one minute:

216  Configuring IDP Attack Objects

 Chapter 6: Intrusion Detection and Prevention

 Scope specifies whether the counting of the attack is from the same
source IP address, the same destination IP address, or a peer. If you
select Source, IDP detects attacks from a given source IP address for
the specified number of times, regardless of the destination IP address.
If you select Destination, IDP detects attacks to a given destination IP
address for the specified number of times, regardless of the source IP
address. If you select Peer, IDP detects attacks between source and
destination IP addresses of the sessions for the specified number of
times.

 Count specifies the number of times that IDP detects the attack within
the specified scope before triggering an event.

2. Click Next.

3. Configure detection parameters for the signature attack:

 The attack pattern is the signature of the attack you want to detect. The
signature is a pattern that always exists within an attack; if the attack is
present, so is the signature. When creating a new signature attack object,
you must analyze the attack to detect a pattern (such as a segment of code,
a URL, or a value in a packet header) and then use that pattern to create a
signature. You can also negate an entered pattern.

Table 20 shows the regular expressions you can use in the attack pattern:

Table 20: Attack Pattern Expressions

Regular Expression Description

\0<octal-number> For a direct binary match
\X<hexadecimal-number>\X For a direct binary match
\[<character-set>\] For case-insensitive matches
. To match any symbol
* To match 0 or more symbols
+ To match 1 or more symbols
? To match 0 or 1 symbols
( ) Grouping of expressions
| Denotes alternate, typically used with ( )
[<start>-<end>] Character range
[^<start>-<end>] Negation of range

 Offset is the starting place from the specified service context where IDP
should look for the attack. If there is no offset, you can specify None;
otherwise, you can specify a decimal value.

 Context defines the location where IDP should look for the attack in a
specific Application Layer protocol. When creating a signature attack
object, you should choose a service context, if possible. Because the service
context is very specific, your chances of detecting a false positive are
greatly reduced. However, choosing a service context overrides any
protocol you previously specified in the Service Binding general parameter.

Configuring IDP Attack Objects  217

 Concepts & Examples ScreenOS Reference Guide

Table 21 lists the service contexts you can use for the attacks.

Table 21: Service Context for Signature Attacks

Service Description RFC

AIM AOL Instant Messenger
DHCP Dynamic Host Configuration Protocol 2131, 2132
DNS Domain Name System 1034, 1035
Finger Finger Information Protocol 1128
FTP File Transfer Protocol 959
Gnutella Gnutella
Gopher Gopher 1436
HTTP Hypertext Transfer Protocol 2616
IMAP Internet Message Access Protocol 2060
IRC Internet Relay Chat 2810, 2811, 2812, 2813
LDAP Lightweight Directory Access Protocol 2251, 2252, 2253, 3377
LPR Line Printer Protocol 1179
MSN Microsoft Instant Messenger
NBNAME/ NetBios Name Service 1001, 1002
NBDS
NFS Network File System
NNTP Network News Transfer Protocol 977
NTP Network Time Protocol 1305
POP3 Post Office Protocol, version 3 1081
RADIUS Remote Authentication Dial-In User Service 2865, 2866, 2867, 2868,
3575
REXEC
RLOGIN Remote Login (rlogin) 1258, 1282
RSH Remote Shell (rsh)
RUSERS
SMB Server Message Block
SMTP Simple Mail Transfer Protocol 821
SNMP Simple Network Management Protocol 1067
SNMPTRAP SNMP trap 1067
SSH Secure Shell Proprietary
SSL Secure Sockets Layer
Telnet Telnet TCP protocol 854
TFTP Trivial File Transfer Protocol 783
VNC Virtual Network Computing
YMSG Yahoo! Messenger

218  Configuring IDP Attack Objects

 Chapter 6: Intrusion Detection and Prevention

 Direction defines the connection direction of the attack:

 Client to Server detects the attack only in client-to-server traffic.

 Server to Client detects the attack only in server-to-client traffic.

 Any detects the attack in either direction.

 Flow defines the connection flow of the attack: Control, Auxiliary, or Both.

4. Click Next.

5. Configure the header match information for the signature attack. The header
match configuration allows you to specify that IDP search a packet for a pattern
match only for certain header information for the following protocols:

 Internet Protocol (IP)

 Type-of-service. Specify an operand (none, =, !, >, <) and a decimal

value.

 Total length. Specify an operand (none, =, !, >, <) and a decimal

value.

 ID. Specify an operand (none, =, !, >, <) and a decimal value.

 Time-to-live. Specify an operand (none, =, !, >, <) and a decimal

value.

 Protocol. Specify an operand (none, =, !, >, <) and a decimal value.

 Source. Specify the IP address of the attacking device.

 Destination. Specify the IP address of the attack target.

 Reserved Bit. Specifies that IDP looks for a pattern match whether or
not the IP flag is set (none), only if the flag is set (set), or only if the flag
is not set (unset).

 More Fragments. Specifies that IDP looks for a pattern match whether
or not the IP flag is set (none), only if the flag is set (set), or only if the
flag is not set (unset).

 Don’t Fragment. Specifies that IDP looks for a pattern match whether
or not the IP flag is set (none), only if the flag is set (set), or only if the
flag is not set (unset).

 Transmission Control Protocol (TCP)

 Source Port. The port number on the attacking device.

 Destination Port. The port number of the attack target.

Configuring IDP Attack Objects  219

 Concepts & Examples ScreenOS Reference Guide

 Sequence Number. The sequence number of the packet. This number

identifies the location of the data in relation to the entire data
sequence.

 ACK Number. The ACK number of the packet. This number identifies
the next sequence number; the ACK flag must be set to activate this
field.

 Header Length. The number of bytes in the TCP header.

 Window Size. The number of bytes in the TCP window size.

 Urgent Pointer. Indicates that the data in the packet is urgent; the URG
flag must be set to activate this field.

 Data Length. The number of bytes in the data payload. For SYN, ACK,
and FIN packets, this field should be empty.

You can also specify the following TCP flag options as none, set, or unset:

 URG. When set, the urgent flag indicates that the packet data is
urgent.

 ACK. When set, the acknowledgment flag acknowledges receipt of

a packet.

 PSH. When set, the push flag indicates that the receiver should
push all data in the current sequence to the destination application
(identified by the port number) without waiting for the remaining
packets in the sequence.

 RST. When set, the reset flag resets the TCP connection, discarding
all packets in an existing sequence.

 FIN. When set, the final flag indicates that the packet transfer is
complete and the connection can be closed.

 User Datagram Protocol (UDP)

 Source Port. The port number on the attacking device. Specify an

operand (none, =, !, >, <) and a decimal value.

 Destination Port. The port number of the attack target. Specify an

operand (none, =, !, >, <) and a decimal value.

 Data Length. The number of bytes in the data payload. Specify an

operand (none, =, !, >, <) and a decimal value.

 Internet Control Message Protocol

 ICMP Type. The primary code that identifies the function of the
request/reply.

 ICMP Code. The secondary code that identifies the function of the
request/reply within a given type.

220  Configuring IDP Attack Objects

 Chapter 6: Intrusion Detection and Prevention

 Sequence Number. The sequence number of the packet. This number

identifies the location of the request/reply in relation to the entire
sequence.

 ICMP ID. The identification number is a unique value used by the

destination system to associate requests and replies.

 Data Length. The number of bytes in the data payload.

6. Click Finish.

Creating a Protocol Anomaly Attack

Perform the following steps to configure a protocol anomaly attack in the Custom
Attack dialog box:

1. Configure general parameters for the attack:

 False-Positives indicates the frequency (Unknown, Rarely, Occasionally,

Frequently) that the attack object produces a false positive when used in a
security policy. As you finetune your IDP system to your network traffic,
you can change this setting to help you track false positives.

 Anomaly allows you to select a protocol anomaly from a list of known

protocol anomalies. NetScreen-Security Manager detects anomalies for the
following protocols:

AIM DHCP IDENT RUSERS TFTP

FINGER CHARGEN IMAP Gnutella RLOGIN
FTP DISCARD IP Packet Gopher RPC
HTTP DNS POP3 IRC RSH
ICMP ECHO REXEC MSN RTSP
MSN LPR NFS VNC NNTP
SNMP SMTP SMB SNMP TRAP YMSG
TCP segment SYSLOG SSH TELNET

 Time Binding allows IDP to detect a sequence of the same attacks over a
specified period. If you select Time Binding, you can specify the following
attributes that are bound to the attack object for one minute:

 Scope specifies whether the counting of the attack is from the same
source IP address, the same destination IP address, or a peer. If you
select Source, IDP detects attacks from a given source IP address for
the specified number of times, regardless of the destination IP address.
If you select Destination, IDP detects attacks to a given destination IP
address for the specified number of times, regardless of the source IP
address. If you select Peer, IDP detects attacks between source and
destination IP addresses of the sessions for the specified number of
times.

 Count specifies the number of times that IDP detects the attack within
the specified scope before an event is triggered.

Configuring IDP Attack Objects  221

 Concepts & Examples ScreenOS Reference Guide

2. Click Finish.

Creating a Compound Attack

Note the following when creating a custom compound attack object:

 All members of the compound attack object must use the same service setting
or service binding, such as FTP, Telnet, YMSG, TCP/80, and so on.

 You cannot add predefined or custom signature attack objects to a compound

attack object. Instead, you specify the signature directly within the compound
attack object, including such details as service (or service binding), service
context, attack pattern, and direction. You can add protocol anomaly attack
objects to a compound attack object.

 You can add between 2 and 32 protocol anomaly attack objects and/or
signatures as members of the compound attack object. However, all members
must use the same service setting or service binding.

Perform the following steps to configure a compound attack in the Custom Attack
dialog box:

1. Configure general parameters for the attack:

 False-Positives indicates the frequency (Unknown, Rarely, Occasionally,

Frequently) that the attack object produces a false positive when used in a
security policy. By default, all compound attack objects are set to
Unknown. As you finetune IDP to your network traffic, you can change this
setting to help you track false positives.

 Service Binding allows you to select a protocol that the attack uses to enter
your network. Depending upon the protocol you select, additional fields
may appear. You can select the following protocol types:

 Any allows IDP to match the signature in all services (attacks can use
multiple services to attack your network).

 IP (specify protocol number) allows IDP to match the signature in a

specified IP protocol type.

 TCP (specify port ranges) allows IDP to match the signature for
specified TCP port(s).

 UDP (specify port ranges) allows IDP to match the signature for
specified UDP port(s).

 ICMP (specify ID) allows IDP to match the signature for specified ICMP
ID.

 RPC (specify program number) allows IDP to match the signature for a
specified remote procedure call program number.

 Service (specify service) allows IDP to match the signature for a

specified service.

222  Configuring IDP Attack Objects

 Chapter 6: Intrusion Detection and Prevention

 Time Binding allows IDP to detect a sequence of the same attacks over a
specified period. If you select Time Binding, you can specify the following
attributes that are bound to the attack object for one minute:

 Scope specifies whether the counting of the attack is from the same
source IP address, the same destination IP address, or a peer. If you
select Source, IDP detects attacks from a given source IP address for
the specified number of times, regardless of the destination IP address.
If you select Destination, IDP detects attacks to a given destination IP
address for the specified number of times, regardless of the source IP
address. If you select Peer, IDP detects attacks between source and
destination IP addresses of the sessions for the specified number of
times.

 Count specifies the number of times that IDP detects the attack within
the specified scope before an event is triggered.

2. Click Next.

3. Perform the following steps to configure the compound attack members:

 Scope specifies whether the match should occur over a single session or
can be made across multiple transactions within a session:

 Select Session to allow multiple matches for the object within the same
session.

 Select Transaction to match the object across multiple transactions

that occur within the same session.

 Select Reset if the compound attack should be matched more than once
within a single session or transaction. If Reset is selected, multiple matches
can be made within a single session or transaction.

 Select Ordered Match to create a compound attack object that must match
each member signature or protocol anomaly in the order you specify. If you
do not specify an ordered match, the compound attack object still must
match all members, but the attacks or protocol anomalies can appear in
random order.

You can now add signature or protocol anomaly attack objects to the compound
attack, as described in the following sections.

Configuring IDP Attack Objects  223

 Concepts & Examples ScreenOS Reference Guide

Adding a Signature to the Compound Attack Object

1. To add an attack pattern to the compound attack object, click the Add icon,
then select Signature. The New Member dialog box appears.

2. Double-click the newly created signature member of the compound attack

object. Configure the attack pattern settings:

 DFA Pattern. Specify the pattern IDP should match. You construct the
attack pattern just as you would when creating a new signature attack
object.

To exclude the specified pattern from being matched, select the Negate
check box.

 Context. Specify the context in which the IDP should look for the pattern.
The context displays only contexts that are appropriate for the specified
service. If you selected a service binding of any, you are restricted to the
service contexts packet and first packet.

 Direction. Specify whether IDP should match the pattern in traffic flowing
in any direction, from client-to-server, or from server-to-client.

Examine the traffic before you determine the direction. We recommend

client-to-server direction for better performance. There is a performance hit
on the device if you select server-to-client and the risk of attack objects is
lower with client-to-server.

3. Click OK.

Adding a Protocol Anomaly to the Compound Attack Object

1. To add a protocol anomaly to the compound attack object, click the Add icon,
then select Anomaly. The New Member dialog box appears.

2. Select an anomaly.

3. Click OK.

Deleting a Member from the Compound Attack Object

To remove a member signature or an anomaly, select the member in the list, then
click the Delete icon. A confirmation window asks you to verify that you want to
delete the item. Click OK.

Editing a Custom Attack Object

To modify a custom attack object, double-click the object in the Custom Attacks tab
in the IDP Objects dialog box. The Custom Attacks dialog box appears with the
previously configured information in the General and Platforms tabs. You can enter
optional information in the References and Extended tabs. Enter any changes you
want to make, then click Apply. To close the dialog box, click OK.

Deleting a Custom Attack Object

To delete a custom attack object, right-click the object in the Custom Attacks tab in
the IDP Objects dialog box, then select Delete. A confirmation window asks you to
verify that you want to delete the item. Click OK.

224  Configuring IDP Attack Objects

 Chapter 6: Intrusion Detection and Prevention

Creating Custom IDP Attack Groups

The IDP system contains hundreds of predefined attack objects, and you can create
additional custom attack objects. When you create your security policy rules, you
can add attack objects individually or by the predefined or the custom attack group.
To help keep your security policies organized, you can organize attack objects into
groups.

You can create static groups, which contain only the groups or attack objects you
specify, or dynamic groups, which contain attack objects based on criteria you
specify.

Configuring Static Groups

A static group contains a specific, finite set of attack objects or groups. There are
two types of static groups: predefined static groups and custom static groups.

A predefined static group can include the following members:

 Predefined attack objects

 Predefined static groups

 Predefined dynamic groups

A custom static group can include the same members as a predefined static group,
plus the following members:

 Custom attack objects

 Custom dynamic groups

 Other custom static groups

You use static groups to do the following:

 Define a specific set of attacks to which you know your network is vulnerable

 Group custom attack objects

 Define a specific set of informational attack objects that you use to keep you
aware of what is happening on your network

Static groups require more maintenance than dynamic groups because you must
manually add or remove attack objects in a static group in order to change the
members. However, you can include a dynamic group within a static group to
automatically update some attack objects. For example, the predefined attack
object group Operating System is a static group that contains four predefined static
groups: BSD, Linux, Solaris, and Windows. The BSD group contains the predefined
dynamic group BSD-Services-Critical, to which attack objects can be added during
an attack database update.

Configuring IDP Attack Objects  225

 Concepts & Examples ScreenOS Reference Guide

To create a custom static group:

1. In Object Manager, click Attack Objects > IDP Objects. The IDP Objects dialog
box appears.

2. Click the Custom Attack Groups tab.

3. Click the Add icon, then select Add Static Group. The New Static Group dialog
box appears.

4. Enter a name and description for the static group. Select a color for the group
icon.

5. To add an attack or a group to the static group, select the attack or group from
the Attacks/Group list, then click Add.

6. Click OK.

Configuring Dynamic Groups

A dynamic group contains a dynamic set of attack objects that are automatically
added or deleted based on specified criteria for the group. For example, an attack
database update can add or remove attack objects from a dynamic group based on
the group criteria. This eliminates the need for you to review each new signature to
determine if you need to use it in your existing security policy.

A predefined or custom dynamic group can only contain attack objects, not attack
groups. Dynamic group members can be either predefined or custom attack
objects.

Perform the following steps to create a custom dynamic group:

1. In the Object Manager, click Attack Objects > IDP Objects. The IDP Objects
dialog box appears.

2. Click the Custom Attack Groups tab.

3. Click the Add icon, then select Add Dynamic Group. The New Dynamic Group
dialog box appears.

4. Enter a name and description for the static group. Select a color for the group
icon.

5. In the Filters tab, click the Add icon, then select one of the following:

 Add Products Filter adds attack objects based on the application that is
vulnerable to the attack

 Add Severity Filter adds attack objects based on the attack severity.

NOTE: All predefined attack objects are assigned a severity level by Juniper Networks.
However, you can edit this setting to match the needs of your network.

 Add Category Filter adds attack objects based on category

226  Configuring IDP Attack Objects

 Chapter 6: Intrusion Detection and Prevention

 Add Last Modified Filter adds attack objects based on their last
modification date

 Add Recommended Filter includes only attacks designated to be the most

serious threats to the dynamic group. In the future, Juniper Networks will
designate only attacks it considers to be serious threats as recommended.
These settings will be updated with new attack object updates. In addition,
you can designate custom attack objects as recommended or not. For more
information about recommended actions, see the NetScreen-Security
Manager Administrator’s Guide.

You create filters one at a time; as you add each criteria, IDP compares it to the
attributes for each attack object and immediately filters out any attack object that
does not match. If you create a filter with attributes that no attack object can match,
a message appears warning you that your dynamic group has no members.

From the resulting list of matching attack objects, you can then exclude any attack
objects that produce false positives on your network or that detect an attack to
which your network is not vulnerable.

NOTE: A dynamic group cannot contain another group (predefined, static, or dynamic).
However, you can include a dynamic group as a member of a static group.

Example: Creating a Dynamic Group

Perform the following steps to create a dynamic group:

1. In the Custom Attack Groups tab, click the Add icon, then select Add Dynamic
Group. The New Dynamic Group dialog box appears.

2. Enter a name and description for the group. Select a color for the group icon.

Figure 81: New Dynamic Group

3. In the Filters tab, click the Add icon, then add the filters that determine which
attack objects should be in the group:

a. Add a Products filter to add attack objects that detect attacks against all
Microsoft Windows operating systems.

b. Add a Severity filter to add attack objects that have a severity level of
Critical or Major.

Configuring IDP Attack Objects  227

 Concepts & Examples ScreenOS Reference Guide

IDP automatically applies all filters to the entire attack object database,
identifies the attack objects that meet the defined criteria, and adds the
matching objects as members of the group.

4. View the members of the group by clicking on the Members tab as shown in
Figure 82:

Figure 82: New Dynamic Group Members

5. Click OK to save the dynamic group.

Updating Dynamic Groups

When you are satisfied with the group criteria and its members, use the group in a
security policy. The next time you update your attack objects, the following tasks are
performed automatically:

 For all new attack objects, the update compares the predefined attributes of
each attack object to each dynamic group criteria and adds the attack objects
that match.

 For all updated attack objects, the update removes attack objects that no longer
meet their dynamic group criteria. The update also reviews updated attack
objects to determine if they now meet any other dynamic group criteria and
adds them to those groups as necessary.

 For all deleted attack objects, the update removes the attack objects from their
dynamic groups.

You can also edit a dynamic group manually, adding new filters or adjusting existing
filters to get the type of attack objects you want. You can also edit a dynamic group
from within a security policy (see “Configuring Security Policies” on page 183).

228  Configuring IDP Attack Objects

 Chapter 6: Intrusion Detection and Prevention

Editing a Custom Attack Group

To modify a custom attack group, double-click the group in the Custom Attack
Groups tab in the IDP Objects dialog box. The Static Group or Dynamic Group dialog
box appears with the previously configured information displayed. Enter any
changes you want to make, then click Apply; to close the dialog box, click OK.

Deleting a Custom Attack Group

To delete a custom attack group, right-click the group in the Custom Attack Groups
tab in the IDP Objects dialog box, then select Delete. A confirmation window asks
you to verify that you want to delete the item. Click OK.

Configuring the Device as a Standalone IDP Device

You can deploy the IDP-capable device as a standalone IDP security system
protecting critical segments of your private network. For example, you might
already have a security device actively screening traffic between the Internet and
your private network (some devices can optionally use Deep Inspection to inspect
this traffic). But you still need to protect internal systems, such as mail servers, from
attacks that might originate from user machines in an otherwise trusted network. In
this case, you need a security system that provides IDP instead of firewall functions.

This section describes how to configure the security device to provide standalone
IDP functions.

NOTE: Juniper Networks offers standalone IDP appliances that provide IDP functionality
without integrated firewall/VPN capabilities. You can use the NetScreen-Security
Manager system to manage these appliances as well as IDP-capable firewall/VPN
devices.

Enabling IDP
To enable IDP, you need to configure a firewall rule in a security policy that directs
traffic between the applicable zones to be checked against IDP rulebases. You can
make this firewall rule very simple in that it can match all traffic from all sources to
all destinations for all services.

1. Create a firewall rule that permits traffic from any source to any destination for
any service.

2. Right-click in the Rule Options column for the firewall rule, then select DI
Profile/Enable IDP.

3. In the DI Profile/Enable IDP dialog box, click the button to enable IDP, then
select OK.

4. Configure IDP rules, creating IDP rulebases as needed.

For more information about configuring security policies that include IDP rules, see
“Configuring Security Policies” on page 183.

Configuring the Device as a Standalone IDP Device  229

 Concepts & Examples ScreenOS Reference Guide

Example: Configuring a Firewall Rule for Standalone IDP

In this example, you are deploying an IDP/firewall/VPN device as a standalone IDP
security system between the Trust zone and the custom Data_Center zone in your
network. Your company’s file, mail, and database servers reside in the Data_Center
zone. While you want to allow users in the Trust zone to be able to access the
servers in the Data_Center zone, you also need to protect the servers from attacks
that inadvertently might have been introduced into a user machine in the Trust
zone. You create a firewall rule from the Trust to the Data_Center zone that allows
traffic from any source to any destination for any service, then enable IDP in the
Rule Options column, as shown in Figure 83.

Figure 83: Firewall Rule for Standalone IDP

You would then add and configure IDP rulebases for the security policy to detect
possible attacks against servers in the Data_Center zone, as shown in Figure 84.

Figure 84: IDP Rules for Standalone IDP

Configuring Role-Based Administration

NetScreen-Security Manager’s role-based administration (RBA) allows the super
administrator (superadmin) to create a custom role and administrator for the
standalone IDP device. This gives the IDP administrator permission to perform only
those tasks that are specific to configuring and administering IDP functions; the IDP
administrator does not need to create, edit, delete, view, or update device
configurations. When the IDP administrator logs into the NetScreen-Security
Manager UI, he or she only sees the menus and options that are applicable to IDP.

230  Configuring the Device as a Standalone IDP Device

 Chapter 6: Intrusion Detection and Prevention

Example: Configuring an IDP-Only Administrator

In this example, you (the superadmin) create a custom role and an IDP
administrator who can only perform tasks that are specific to configuring and
administering IDP on the standalone IDP device.

1. Log into the global domain as the superadmin. From the menu bar, select Tools
> Manage Administrators and Domains.

2. Click the Roles tab, then click the Add icon to create a role called IDP_Only.
Select tasks that are specific for IDP configuration and administration, such as:

 Attack Update

 Create/View/Edit/Delete Policies

 Create/View/Edit/Delete Backdoor and IDP Rulebases

 View Firewall Rulebases

 Create/Edit/Delete Shared Objects and Groups

Select any other tasks that might be helpful for the IDP administrator; for
example, you can select the options to view Jobs and the System Status
Monitor.

3. Click OK in the New Role dialog box to return to the Manage Administrators
and Domains dialog box.

4. Click the Administrators tab, then click the Add icon to create an administrator
called IDP_Administrator. The New Admin dialog box appears with the General
tab selected.

5. In the Name field, enter IDP_Administrator. You can enter contact information
for the administrator.

6. Click the Authorization tab. Select the authorization method and the local
password for the administrator.

7. Click the Permissions tab, then click the Add icon to select the role IDP_Only for
this administrator.

8. Click OK to close the New Select Role and Domains dialog box. Click OK to
close the New Admin dialog box. Click OK to close the Manage Administrators
and Domains dialog box.

The administrator for the standalone IDP device can now log into
NetScreen-Security Manager as IDP_Administrator. Upon login, the
NetScreen-Security Manager UI displays a limited navigation tree and menu options
for this user, as shown in Figure 85. Note that the UI displays only the security
policy and Object Manager options in the navigation tree; the Devices >
Configuration options are not available for this user.

Configuring the Device as a Standalone IDP Device  231

 Concepts & Examples ScreenOS Reference Guide

Figure 85: UI Display for IDP_Administrator

Managing IDP
This section describes IDP management on the IDP-capable device.

About Attack Database Updates

Juniper Networks periodically provides attack database updates, in the form of a
download file, on the Juniper website. Attack database updates can include the
following:

 New or modified predefined IDP attack objects and groups

 New or modified signatures used by the Deep Inspection (DI) feature

 Updates to the IDP engine, which runs in the security device

In a new attack database update, the version number increments by 1. When you
download a version of an attack database update from the Juniper Networks
website, NetScreen-Security Manager stores the version number of the attack
database update. You can check to see if there is a more recent update available
than the last one you downloaded.

Downloading Attack Database Updates

The attack database updates are downloaded to the NetScreen-Security Manager
GUI server. Perform the following steps to download an attack database update file:

1. From the menu bar, select Tools > View/Update NSM Attack Database. The
Attack Update Manager wizard appears.

2. Follow the instructions in the Attack Update Manager to download the attack
database update file to the NetScreen-Security Manager GUI server.

232  Managing IDP

 Chapter 6: Intrusion Detection and Prevention

NOTE: The Juniper Networks website is set by default in the New Preferences dialog box,
which you access by selecting Tools > Preferences. The GUI Server must have
Internet access.

Using Updated Attack Objects

You cannot create, edit, or delete predefined IDP attack objects or groups, but you
can update the attack object database installed in the NetScreen-Security Manager
GUI server. Updates to predefined IDP attack objects and groups can include the
following:

 New descriptions or severities for existing attack objects

 New attack objects or groups

 Deletion of obsolete attack objects

When you download updated IDP attack objects and groups to the GUI server, any
new attack objects in the update are available for selection in an IDP rulebase in a
security policy. When you install a security policy on your managed device, only the
attack objects that are used in IDP rules for the device are pushed from the GUI
server to the device.

NOTE: For the DI feature, all updated signatures are pushed to your managed device. For
more information about updating the attack object database for DI on your
managed device, see the NetScreen-Security Manager Administrator’s Guide.

Updating the IDP Engine

The IDP engine is dynamically changeable firmware that runs on the firewall/VPN
device. There are two ways that the IDP engine can be updated on the device:

 When you upgrade the firmware on an IDP/firewall/VPN device, the upgraded

firmware will typically include a recent version of the IDP engine as well as a
new version of ScreenOS. (For information about upgrading the firmware on a
security device, see the NetScreen-Security Manager Administrator’s Guide.)

 You can update the IDP engine on a managed device from an attack database
update on the GUI server. Because attack database updates are available more
often than firmware releases, an attack database update may include a more
recent version of the IDP engine than is available on the latest firmware release.
For example, an attack database update might contain updated IDP attack
objects that can only be used with an updated version of the IDP engine.

Managing IDP  233

 Concepts & Examples ScreenOS Reference Guide

Perform the following steps to see the version of the IDP engine that is currently
running on the device:

1. Select Tools > View/Update NSM Attack Database. The Attack Update
Manager wizard appears.

2. Click Next.

The Attack Update Summary, as shown in Figure 86, displays information

about the current version downloaded on the GUI server and the latest version
available from Juniper Networks.

Figure 86: Attack Update Summary

3. Click Finish to continue downloading the latest attack database update, or click
Cancel to exit the Attack Update Manager.

To update the IDP engine on the device:

1. Select Devices > IDP Detector Engine > IDP Detector Engine. The Change
Device Sigpack dialog box appears.

NOTE: The IDP engine version you install on the security device must be compatible with
the version of the firmware that is running in the device. You cannot downgrade
the IDP engine version on the device.

2. Click Next, then select the managed devices on which you want to install the
IDP engine update.

3. Follow the instructions in the Change Device Manager to update the IDP engine
on the selected device.

234  Managing IDP

 Chapter 6: Intrusion Detection and Prevention

NOTE: Updating the IDP engine on a device does not require a reboot of the device.

Viewing IDP Logs

When attack objects are matched in an IDP rule, IDP log entries appear in the
NetScreen-Security Manager Log Viewer. Perform the following steps to receive IDP
log entries in the Log Viewer:

1. Enable the device to send log entries with the desired severity settings to
NetScreen-Security Manager:

a. In Device Manager, open the device configuration for the device.

b. In the device navigation tree, select Report Settings > General > NSM.

c. Select the severity settings you want logged to NetScreen-Security Manager.

d. Click OK.

2. Enable IDP detection and logging in the security policy installed on the device.
For detailed information about configuring IDP logging in the security policy,
see “Configuring Security Policies” on page 183.

IDP alarm log entries appear in the Log Viewer and display the following columns of
information:

 Source and Destination Address

 Action

 Protocol

 Category (Anomaly, Custom, or Signature)

 Subcategory

 Severity

 Device

Managing IDP  235

 Concepts & Examples ScreenOS Reference Guide

ISG-IDP Devices
Juniper Networks Integrated Security Gateway–Intrusion Detection and Prevention
(ISG-IDP) devices protect your networks from traffic anomalies and malicious
attacks. You can configure IDP policies for the traffic flowing through your network
based on your network’s security requirements. The ISG-IDP device loads the IDP
policy data and applies the policy to the network traffic.

Compiling a Policy
You use NetScreen-Security Manager (NSM) to remotely manage ISG-IDP devices.
NSM compiles the policies you define and transfers them to the ISG-IDP device. The
following section explains the steps involved in compiling and loading a policy on
the ISG-IDP device. Figure 87 illustrates an ISG-IDP policy compilation.

Figure 87: ISG-IDP Policy Compilation

NetScreen-Security Manager

Policy input Compile message

Security module 1
1 3
2 Security module 2
policy.gz.v Management module
Security module 3

Security device
Security module 1

Management module Security module 2

4
Security module 3
Install message

1. NSM compiles the policy you defined and generates a policy.gz.v file.

2. NSM transfers the policy.gz.v file to the management module of the ISG-IDP
device.

3. The management module sends a compile message along with the policy.gz.v
file to each ISG-IDP security module.

4. After all the security modules compile the policy file, the management module
sends an install message to each security module.

The management module sends the policy to the security module and waits for a
reply with a timeout of 60 seconds. If the security module does not respond with a
reply within the 60 seconds, the management module treats it as a policy push
failure and notifies NSM. NSM sends an error message to the user reporting the
policy push failure.

Policy Size Multiplier

When the security module attempts to compile the policy.gz.v file but does not
have enough memory to do so, the security module runs out of memory and enters
an irrecoverable state.

236  ISG-IDP Devices

 Chapter 6: Intrusion Detection and Prevention

To avoid entering the irrecoverable state, the security module estimates the
memory required to compile the policy by multiplying the size of the policy.gz.v
file by the configurable parameter sc_policy_size_multiplier. If the security module
determines that the available memory is less than the estimated memory, the
security module does not compile the file and the policy push operation fails.

By default, sc_policy_size_multiplier is set to 100. In this case, a security module

requires 500 MB of memory to compile a 5 MB file.

You need to configure sc_policy_size_multiplier for each security module by using

the CLI command:

exec sm 2 ksh “scio const set sc_policy_size_multiplier 300”

This command sets sc_policy_size_multiplier for security module 2 to 300. The

security module requires 900 MB of memory to compile a 3 MB file. If the memory
available is less than 900 MB, the security module does not compile the file and the
policy push fails.

Unloading Existing Policies

The ISG-IDP device cannot share memory for a new policy when its CPU usage is
high for a long time. In such cases, the policy compilation fails by default. You can
configure the security module to unload the current active policy whenever
memory is required to load a new policy. Use the
sc_pcomp_unload_cur_on_low_mem parameter to unload the active policy and
load the new policy.

By default, sc_pcomp_unload_cur_on_low_mem is set to 0. In this case, the

security module does not unload the existing policy when loading a new policy.
Therefore, the policy compilation fails if free memory available is insufficient for
compiling a new policy.

If you set sc_pcomp_unload_cur_on_low_mem to 1, the security module unloads

the current active policy when free memory available is insufficient for compiling
the new policy. The security module uses the freed memory to compile and load the
new policy.

Configure the sc_pcomp_unload_cur_on _low_mem parameter with the following

CLI command:

exec sm 2 ksh "scio const set sc_pcomp_unload_cur_on_low_mem 1"

This command sets sc_pcomp_unload_cur_on_low_mem of security module 2 to

1.

ISG-IDP Devices  237

 Concepts & Examples ScreenOS Reference Guide

238  ISG-IDP Devices

Chapter 7
Suspicious Packet Attributes

As shown in the other chapters in this volume, attackers can craft packets to
perform reconnaissance or launch denial of service (DoS) attacks. Sometimes it is
unclear what the intent of a crafted packet is, but the very fact that it is crafted
suggests that its being put to some kind of insidious use. All of the SCREEN options
presented in this chapter block suspicious packets that might contain hidden
threats:

 “ICMP Fragments” on page 240

 “Large ICMP Packets” on page 241

 “Bad IP Options” on page 242

 “Unknown Protocols” on page 243

 “IP Packet Fragments” on page 244

 “SYN Fragments” on page 245

 239
 Concepts & Examples ScreenOS Reference Guide

ICMP Fragments
Internet Control Message Protocol (ICMP) provides error reporting and network
probe capabilities. Because ICMP packets contain very short messages, there is no
legitimate reason for ICMP packets to be fragmented. If an ICMP packet is so large
that it must be fragmented, something is amiss. When you enable the ICMP
Fragment Protection SCREEN option, the security device blocks any ICMP packet
that has the More Fragments flag set or that has an offset value indicated in the
offset field.

Figure 88: Blocking ICMP Fragments

If the protocol type and the More or there is a non-zero value in
is 1 for ICMP... Fragments flag is set... the Fragment Offset field...

IP Header Header Total Packet Length (in Bytes)

Version Type of Service
Length
Identification 0 D M Fragment Offset

Time to Live (TTL) Protocol (ICMP = 1) Header Checksum

Source Address

Destination Address

Options

ICMP Header Type Code Checksum

(IP Packet
Payload) Identifier Sequence Number

Data

...the security device blocks the packet.

To block fragmented ICMP packets, do either of the following, where the specified
security zone is the one from which the fragments originate:

WebUI
Screening > Screen (Zone: select a zone name): Select ICMP Fragment
Protection, then click Apply.

CLI
set zone zone screen icmp-fragment

240  ICMP Fragments

 Chapter 7: Suspicious Packet Attributes

Large ICMP Packets

As stated in “ICMP Fragments” on page 240, Internet Control Message Protocol
(ICMP) provides error reporting and network probe capabilities. Because ICMP
packets contain very short messages, there is no legitimate reason for large ICMP
packets. If an ICMP packet is unusually large, something is wrong. For example, the
Loki program uses ICMP as a channel for transmitting covert messages. The
presence of large ICMP packets might expose a compromised machine acting as a
Loki agent. It also might indicate some other kind of questionable activity.

Figure 89: Blocking Large ICMP Packets

When the protocol type is 1 for ICMP... and this value is >1024...

IP Header Header
Version Type of Service Total Packet Length (in Bytes)
Length
Identification 0 D M Fragment Offset

Time to Live (TTL) Protocol (ICMP = 1) Header Checksum

Source Address

Destination Address

Options

ICMP Header Type Code Checksum

(IP Packet
Payload) Identifier Sequence Number

Data

...the security device blocks the packet.

When you enable the Large Size ICMP Packet Protection SCREEN option, the
security device drops ICMP packets with a length greater than 1024 bytes.

To block large ICMP packets, do either of the following, where the specified security
zone is the one from which the ICMP packets originate:

WebUI
Screening > Screen (Zone: select a zone name): Select Large Size ICMP Packet
(Size > 1024) Protection, then click Apply.

CLI
set zone zone screen icmp-large

Large ICMP Packets  241

 Concepts & Examples ScreenOS Reference Guide

Bad IP Options
The Internet Protocol standard RFC 791, Internet Protocol, specifies a set of eight
options that provide special routing controls, diagnostic tools, and security.
Although the original, intended uses for these options served worthy ends, people
have figured out ways to twist these options to accomplish less commendable
objectives. (For a summary of the exploits that attackers can initiate from IP
options, see “Network Reconnaissance Using IP Options” on page 10.)

Either intentionally or accidentally, attackers sometimes configure IP options

incorrectly, producing either incomplete or malformed fields. Regardless of the
intentions of the person who crafted the packet, the incorrect formatting is
anomalous and potentially harmful to the intended recipient.

Figure 90: Incorrectly Formatted IP Options

IP Header Version Header Type of Service Total Packet Length (in Bytes)
Length
Identification 0 D M Fragment Offset

Time to Live (TTL) Protocol Header Checksum

Source Address

Destination Address

Options

Payload

If the IP options are incorrectly formatted, the security device

records the event in the SCREEN counters for the ingress interface.

When you enable the Bad IP Option Protection SCREEN option, the security device
blocks packets when any IP option in the IP packet header is incorrectly formatted.
The security device records the event in the event log.

To detect and block IP packets with incorrectly formatted IP options, do either of

the following, where the specified security zone is the one from which the packets
originate:

WebUI
Screening > Screen (Zone: select a zone name): Select Bad IP Option
Protection, then click Apply.

CLI
set zone zone screen ip-bad-option

242  Bad IP Options

 Chapter 7: Suspicious Packet Attributes

Unknown Protocols
These protocol types with ID numbers of 137 or greater are reserved and undefined
at this time. Precisely because these protocols are undefined, there is no way to
know in advance if a particular unknown protocol is benign or malicious. Unless
your network makes use of a nonstandard protocol with an ID number of 137 or
greater, a cautious stance is to block such unknown elements from entering your
protected network.

Figure 91: Unknown Protocols

If the ID number of the protocol is 137 or greater,
the security device blocks the packet.

IP Header Version Header Type of Service Total Packet Length (in Bytes)
Length
Identification 0 D M Fragment Offset

Time to Live (TTL) Protocol Header Checksum

Source Address

Destination Address

Options

Payload

If the IP options are incorrectly formatted, the security device records

the event in the SCREEN counters for the ingress interface.

When you enable the Unknown Protocol Protection SCREEN option, the security
device drops packets when the protocol field is contains a protocol ID number of
137 or greater.

To drop packets using an unknown protocol, do either of the following, where the
specified security zone is the one from which the packets originate:

WebUI
Screening > Screen (Zone: select a zone name): Select Unknown Protocol
Protection, then click Apply.

CLI
set zone zone screen unknown-protocol

Unknown Protocols  243

 Concepts & Examples ScreenOS Reference Guide

IP Packet Fragments
As packets traverse different networks, it is sometimes necessary to break a packet
into smaller pieces (fragments) based upon the maximum transmission unit (MTU)
of each network. IP fragments might contain an attacker's attempt to exploit the
vulnerabilities in the packet reassembly code of specific IP stack implementations.
When the victim receives these packets, the results can range from processing the
packets incorrectly to crashing the entire system.

Figure 92: IP Packet Fragments

If the More Fragments or there is a non-zero value in
flag is set... the Fragment Offset field...

Header
IP Header Version Type of Service Total Packet Length (in Bytes)
Length
Identification 0 D M Fragment Offset

Time to Live (TTL) Protocol Header Checksum

Source Address

Destination Address

Options

Payload

...the security device blocks the packet.

When you enable the security device to deny IP fragments on a security zone, the
device blocks all IP packet fragments that it receives at interfaces bound to that
zone.

To drop fragmented IP packets, do either of the following, where the specified

security zone is the one from which the fragments originate:

WebUI
Screening > Screen (Zone: select a zone name): Select Block Fragment Traffic,
then click Apply.

CLI
set zone zone screen block-frag

244  IP Packet Fragments

 Chapter 7: Suspicious Packet Attributes

SYN Fragments
The Internet Protocol (IP) encapsulates a Transmission Control Protocol (TCP) SYN
segment in the IP packet that initiates a TCP connection. Because the purpose of
this packet is to initiate a connection and invoke a SYN/ACK segment in response,
the SYN segment typically does not contain any data. Because the IP packet is
small, there is no legitimate reason for it to be fragmented. A fragmented SYN
packet is anomalous, and as such suspect. To be cautious, block such unknown
elements from entering your protected network.

When you enable the SYN Fragment Detection SCREEN option, the security device
detects packets when the IP header indicates that the packet has been fragmented
and the SYN flag is set in the TCP header. The security device records the event in
the SCREEN counters list for the ingress interface.

To drop IP packets containing SYN fragments, do either of the following, where the
specified security zone is the one from which the packets originate:

WebUI
Screening > Screen (Zone: select a zone name): Select SYN Fragment
Protection, then click Apply.

CLI
set zone zone screen syn-frag

Figure 93: SYN Fragments

If the More Fragments or there is a non-zero value in
flag is set... the Fragment Offset field...

IP Header Version Header Type of Service Total Packet Length (in Bytes)
Length
Identification 0 D M Fragment Offset

Time to Live (TTL) Protocol Header Checksum

Source Address

Destination Address

Options (if any)

ICMP Header 16-bit Source Port Number 16-bit Destination Port Number

32-bit Sequence Number

32-bit Acknowledgement Number

4-bit Header Reserved U A P R S F

R C S S Y I 16-bit Window Size
Length (6 bits)
G K H T N N

16-bit TCP Checksum 16-bit Urgent Pointer

Options (if any)

Data (if any)

...and the SYN flag is set... ...the device drops the packet.

SYN Fragments  245

 Concepts & Examples ScreenOS Reference Guide

246  SYN Fragments

Appendix A
Contexts for User-Defined Signatures

The context defines the location in the packet where the Deep Inspection (DI)
module searches for a signature matching the attack object pattern. When defining
a stateful signature attack object, you can specify any of the contexts in the
following lists. After you define an attack object, you must then put it in a
user-defined attack object group for use in policies.

NOTE: A user-defined attack object group can contain only user-defined attack objects.
You cannot mix predefined and user-defined attack objects in the same attack
object group.

When the DI module examines traffic for TCP stream signatures, it does so without
regard for contexts. TCP stream signatures look for patterns anywhere in any kind
of TCP traffic regardless of the application protocol in use. Stream signatures are
defined on NetScreen-5000 and 2000 series systems only. Stream256, however,
looks for patterns in the first 256 bytes of data.

Table 22: Contexts for User-Defined Signatures (page 1 of 3)

Protocol Context Description (Sets the Context As...)

AIM aim-chat-room-desc The description of a chat room in an America Online Instant Messenger (AIM) or ICQ
(I Seek You) session.
aim-chat-room-name The name of a chat room in an AIM or ICQ session.
aim-get-file The name of a file that a user is transferring from a peer.
aim-nick-name The nickname of an AIM or ICQ user.
aim-put-file The name of a file that a user is transferring to a peer.
aim-screen-name The screen name of an AIM or ICQ user.
DNS dns-cname The CNAME (canonical name) in a Domain Name System (DNS) request or response,
as defined in RFC 1035, Domain Names—Implementation and Specification).
FTP ftp-command One of the FTP commands specified in RFC 959, File Transfer Protocol (FTP).
ftp-password An FTP login password.
ftp-pathname A directory or file name in any FTP command.
ftp-username The name that a user enters when logging in to an FTP server.
Gnutella gnutella-http- The name of a file that a Gnutella client intends to retrieve.
get-filename

 A-I
 Concepts & Examples ScreenOS Reference Guide

Table 22: Contexts for User-Defined Signatures (page 2 of 3)

Protocol Context Description (Sets the Context As...)

HTTP http-authorization The username and password decoded from an Authorization: Basic header in an
HyperText Transfer Protocol (HTTP) request, as specified in RFC 1945, HyperText
Transfer Protocol—HTTP/1.0.
http-header-user-agent The user-agent field in the header of an HTTP request. (When users visit a website,
they provide information about their browsers in this field.)
http-request An HTTP request line.
http-status The status line in an HTTP reply. (The status line is a three-digit code that a webserver
sends a client to communicate the state of a connection. For example, 401 means
“Unauthorized” and 404 means “Not found”.)
http-text-html The text, or HyperText Markup Language (HTML) data, in an HTTP transaction.
http-url The uniform resource locator (URL) in an HTTP request as it appears in the data
stream.
http-url-parsed A “normalized” text string decoded from a unicode string that comprises a URL used
in HTTP.
http-url- A decoded common gateway interface (CGI) variable in the URL of an HTTP-GET
variable-parsed request.
IMAP imap-authenticate an argument in an Internet Mail Access Protocol (IMAP) AUTHENTICATE command.
The argument indicates the type of authentication mechanism that the IMAP client
proposes to the server. Examples are KERBEROS_V4, GSSAPI (see RFC 1508, Generic
Security Service Application Program Interface), and SKEY.
For information about IMAP, see RFC 1730, Internet Message Access Protocol - Version
4, and RFC 1731, IMAP4 Authentication Mechanisms.
imap-login Either the username or plaintext password in an IMAP LOGIN command.
imap-mailbox The mailbox text string in an IMAP SELECT command.
imap-user The username in an IMAP LOGIN command.
MSN msn-display-name The display name of a user in a Microsoft Network (MSN) Instant Messaging session.
Messenger
msn-get-file The name of a file that a client is downloading from a peer.
msn-put-file The name of a file that a client is sending to a peer.
msn-sign-in-name The screen name (login name) of an MSN Instant Messaging user.
POP3 pop3-auth The AUTH command in a Post Office Protocol, version 3 (POP3) session. For
information about POP3, see RFC 1939, Post Office Protocol—Version 3.
pop3-header-from The text string in the “From:” header of an email in a POP3 transaction.
pop3-header-line The text string in any header line of an email in a POP3 transaction.
pop3-header-subject The text string in the “Subject:” header of an email in a POP3 transaction.
pop3-header-to The text string in the “To:” header of an email in a POP3 transaction.
pop3-mime- The content file name of a Multipurpose Internet Mail Extensions (MIME) attachment
content-filename in a POP3 session.
pop3-user The username in a POP3 session.
SMB smb-account-name The name of a Server Message Blocks (SMB) account in a SESSION_SETUP_ANDX
request in an SMB session.
smb-connect-path The connect path in the TREE_CONNECT_ANDX request in an SMB session.
smb-connect-service The name of the connect service in the TREE_CONNECT_ANDX request in an SMB
session.

A-II 
 Appendix A: Contexts for User-Defined Signatures

Table 22: Contexts for User-Defined Signatures (page 3 of 3)

Protocol Context Description (Sets the Context As...)

smb-copy-filename The name of a file in a COPY request in an SMB session.
smb-delete-filename The name of a file in a DELETE request in an SMB session.
smb-open-filename The name of a file in the NT_CREATE_ANDX and OPEN_ANDX requests in an SMB
session.
SMTP smtp-from The text string in a “MAIL FROM” command line in a Simple Mail Transfer Protocol
(SMTP) session, as described in RFC 2821, Simple Mail Transfer Protocol.
smtp-header-from The text string in the “From:” header in an SMTP session.
smtp-header-line The text string in any header line in an SMTP session.
smtp-header-subject The text string in the “Subject:” header in an SMTP session.
smtp-header-to The text string in the “To:” header in an SMTP session.
smtp-mime- The content file name of a Multipurpose Internet Mail Extensions (MIME) attachment
content-filename in an SMTP session.
smtp-rcpt The text string in a “RCPT TO” command line in an SMTP session.
– stream256 The first 256 bytes of a reassembled, normalized TCP data stream.
Yahoo! ymsg-alias The alternate identifying name associated with the main username of a Yahoo!
Messenger Instant Messaging user.
ymsg-chatroom- The text in messages exchanged in a Yahoo! Instant Messaging chatroom.
message
ymsg-chatroom- The name of a Yahoo! Instant Messaging chatroom.
name
ymsg-nickname The nickname of a Yahoo! Instant Messaging user.

 A-III
 Concepts & Examples ScreenOS Reference Guide

A-IV 
Index
A stateful signatures .................................................134
ActiveX controls, blocking ..........................................169 stream signatures ..................................................135
address sweep..................................................................8 TCP stream signatures ..........................................161
agents, zombie .........................................................27, 29 attack protection
aggressive aging .......................................................31–36 policy level .................................................................4
AIM ................................................................................133 security zone level .....................................................4
ALGs ................................................................................59 attacks
America Online Instant Messaging common objectives ...................................................1
See AIM detection and defense options ............................2–4
Application Layer Gateways DOS .....................................................................27–56
See ALGs ICMP
attack actions .......................................................140–148 floods ...................................................................50
close ........................................................................140 fragments ..........................................................240
close client .............................................................140 IP packet fragments ..............................................244
close server ............................................................140 land ...........................................................................52
drop ........................................................................140 large ICMP packets ................................................241
drop packet ............................................................140 Ping of Death ...........................................................53
ignore......................................................................140 session table floods ...........................................17, 28
none ........................................................................141 stages of .....................................................................2
attack database updates SYN floods ..........................................................38–43
downloading ..........................................................232 SYN fragments .......................................................245
overview .................................................................232 teardrop ....................................................................54
attack object database ........................................122–129 UDP floods ...............................................................51
auto notification and manual update..................126 unknown MAC addresses .......................................43
automatic update ..................................................125 unknown protocols ...............................................243
changing the default URL .....................................128 WinNuke ...................................................................55
immediate update .................................................124 AV objects, timeout ........................................................89
manual update...............................................127, 128 AV scanning
attack object groups ....................................................136 AV resources per client ...........................................83
applied in policies .................................................130 content
changing severity ..................................................136 size .......................................................................85
Help URLs...............................................................134 decompression ........................................................90
logging ....................................................................151 fail-mode ..................................................................84
severity levels ........................................................136 file extensions ..........................................................91
attack objects ...............................................119, 130–135 FTP ............................................................................72
brute force......................................................148, 149 HTTP .........................................................................74
custom ....................................................................214 HTTP keep-alive .......................................................85
disabling .................................................................139 HTTP trickling ..........................................................86
IDP ..........................................................................185 IMAP .........................................................................76
negation .................................................................164 message drop...........................................................85
overview .................................................................211 MIME .........................................................................75
protocol anomalies .......................................135, 163 POP3 .........................................................................76
protocol anomaly ..................................................212 SMTP .........................................................................77
re-enabling .............................................................139 subscription..............................................................80
signature.................................................................212 using pattern files in ...............................................85

Index  IX-I
 Concepts & Examples ScreenOS Reference Guide

B DI pattern files .............................................................129

backdoor rulebase Discard ..........................................................................131
adding to Security Policy...................................... 207 DNS ...............................................................................131
overview ................................................................. 207 DoS
backdoor rules ..................................................... 207–211 firewall ................................................................28–37
configuring actions ............................................... 209 network ..............................................................38–52
configuring Match columns ................................. 208 OS-specific .........................................................53–56
configuring operation ........................................... 209 session table floods ...........................................17, 28
configuring services .............................................. 209 DoS attacks ...............................................................27–56
configuring severity .............................................. 211 drop-no-rpf-route ...........................................................19
configuring source and destination .................... 209 dynamic packet filtering .................................................3
configuring targets ................................................ 211
configuring zones .................................................. 208 E
blacklists, contents and creating ................................. 33 Echo ..............................................................................131
brute force attacks ....................................................... 148 evasion ......................................................................15–25
exe files, blocking ........................................................169
C exempt rulebase
Chargen ........................................................................ 131 adding to security policies ...................................203
content overview .................................................................202
filtering ............................................................. 57–115 exempt rules ........................................................202–206
content size .................................................................... 85 exempt rules, configuring ...........................................203
cookies, SYN .................................................................. 48 attacks ....................................................................205
CPU protection and utilization ..................................... 33 from the Log Viewer .............................................206
Match columns ......................................................204
D source and destination .........................................204
DDoS ............................................................................... 27 targets .....................................................................205
decompression .............................................................. 90 zones ......................................................................204
deep inspection (DI) ............................................ 137–161 exploits
attack actions ................................................ 140–148 See attacks
attack object database .................................. 122–129
attack object groups.............................................. 136 F
attack object negation .......................................... 164 fail-mode.........................................................................84
attack objects ......................................................... 119 file extensions, AV scanning .........................................91
changing severity .................................................. 136 FIN scans ........................................................................15
context ........................................................................ I FIN without ACK flag .....................................................13
custom attack objects ........................................... 157 Finger ............................................................................131
custom services ............................................. 153–157 floods
custom signatures ......................................... 158–161 ICMP .........................................................................50
disabling attack objects ........................................ 139 session table ............................................................28
license keys............................................................ 120 SYN ...............................................................38–43, 48
logging attack object groups ................................ 151 UDP ...........................................................................51
overview ................................................................. 118 fragment reassembly ..............................................58–61
pattern files, using ................................................ 120
protocol anomalies ............................................... 135 G
reenabling attack objects ..................................... 139 Gopher ..........................................................................131
regular expressions ....................................... 158–159
signature packs ..................................................... 122 H
stateful signatures ................................................. 134 high-watermark threshold ............................................31
stream signatures.................................................. 135 HTTP
denial of service blocking components ...................................168–170
See DoS keep-alive .................................................................85
deny messages ............................................................ 103 session timeout .......................................................32
deny messages, creating and editing ........................ 103 trickling ....................................................................86
DHCP ............................................................................ 131

IX-II  Index
 Index

I record route .............................................................11

ICMP ..............................................................................132 security ...............................................................10, 11
fragments ...............................................................240 source route .............................................................23
large packets ..........................................................241 stream ID..................................................................11
ICMP floods ....................................................................50 strict source route........................................11, 23–25
IDENT............................................................................132 timestamp ................................................................11
IDP IP packet fragments.....................................................244
attack objects .........................................................185 IP spoofing................................................................18–23
basic configuration ................................................175 drop-no-rpf-route .....................................................19
configuring device for standalone IDP ...............229 Layer 2 ................................................................19, 22
configuring inline or inline tap mode .................187 Layer 3 ................................................................18, 20
enabling in firewall rule ........................................186 IRC .................................................................................133
rulebase, overview ................................................188 ISG-IDP ..........................................................................236
IDP engine
updating .................................................................233 J
IDP modes ....................................................................187 Java applets, blocking ..................................................169
IDP rulebases
adding to security policies ...................................189 L
role-based administration ....................................185 land attacks ....................................................................52
types .......................................................................184 LDAP ..............................................................................132
IDP rules .......................................................................188 license keys
IDP rules, configuring..................................................190 advanced mode .....................................................120
actions ....................................................................196 attack pattern update............................................120
address objects ......................................................185 log entries
attack severity .......................................................201 enabling in IDP rules .............................................235
attacks ....................................................................198 Log Viewer
IDP attack objects .................................................185 creating an exempt rule .......................................206
IP actions ................................................................199 logging
Match columns ......................................................190 attack object groups ..............................................151
notifications ...........................................................201 loose source route IP option .............................11, 23–25
service objects .......................................................185 low-watermark threshold ..............................................31
services ...................................................................192 LPR spooler ..................................................................132
source and destination .........................................191
targets .....................................................................202 M
terminal rules.........................................................195 malicious URL protection........................................58–61
IDP rules, entering comments ...................202, 206, 211 message drop .................................................................85
IDP-capable system .....................................................172 messages
inline mode ..................................................................187 deny ........................................................................103
inline tap mode ............................................................187 deny, creating and editing ...................................103
inspections .......................................................................3 Microsoft Network Instant Messenger
Instant Messaging ........................................................133 See MSN Instant Messenger
AIM..........................................................................133 Microsoft-Remote Procedure Call
IRC ..........................................................................133 See MS-RPC
MSN Messenger .....................................................133 MIME, AV scanning ........................................................75
Yahoo! Messenger .................................................133 MSN Messenger ...........................................................133
Integrated Surf Control .........................................99, 108 MS-RPC .........................................................................133
Integrated SurfControl, predefined profile ...............104
intrusion detection and prevention, defined ............171 N
IP addresses negation, deep inspection (DI) ...................................164
adding to a blacklist ................................................33 NetBIOS ........................................................................133
IP options .................................................................10–11 NFS ................................................................................132
attributes ............................................................10–11 NNTP .............................................................................132
incorrectly formatted ............................................242 NSRP
loose source route .......................................11, 23–25 VSD groups.............................................................182

Index  IX-III
 Concepts & Examples ScreenOS Reference Guide

NTP ............................................................................... 132 IP options .................................................................10

port scan ....................................................................9
O SYN and FIN flags set .............................................12
objects TCP packet without flags ........................................14
attack objects ......................................................... 211 record route IP option ...................................................11
attack objects, creating custom ........................... 214 regular expressions .............................................158–159
attack objects, protocol anomaly ........................ 212 rexec..............................................................................132
attack objects, signature ...................................... 212 RFCs
operating systems, probing hosts for .................... 12–14 1038, Revised IP Security Option ........................10
791, Internet Protocol .........................................10
P 793, Transmission Control Protocol .....................13
P2P ................................................................................ 133 rlogin .............................................................................132
BitTorrent ............................................................... 133 role-based administration
DC ........................................................................... 133 configuring IDP-only administrator ....................230
eDonkey ................................................................. 133 IDP rulebases .........................................................185
FastTrack................................................................ 133 rsh..................................................................................132
Gnutella .................................................................. 133 RTSP ..............................................................................132
KaZaa...................................................................... 133
MLdonkey .............................................................. 133 S
Skype ...................................................................... 133 SCREEN
SMB ......................................................................... 133 address sweep ...........................................................8
WinMX ................................................................... 133 bad IP options, drop .............................................242
pattern files .................................................................. 120 drop unknown MAC addresses..............................43
updating from a proxy server.............................. 129 FIN with no ACK......................................................15
using in AV scanning .............................................. 85 FIN without ACK flag, drop ....................................13
Peer-to-Peer ICMP
See P2P fragments, block ..............................................240
Ping of Death ................................................................. 53 ICMP floods ..............................................................50
policies IP options .................................................................10
context ................................................................... 122 IP packet fragments, block ..................................244
core section ..................................................... 17, 120 IP spoofing .........................................................18–23
policy push ................................................................... 236 land attacks ..............................................................52
policy.gz.v ..................................................................... 236 large ICMP packets, block ....................................241
port scan ........................................................................... 9 loose source route IP option, detect .....................25
Portmapper .................................................................. 132 Ping of Death ...........................................................53
probes port scan ....................................................................9
network ...................................................................... 8 source route IP option, deny .................................25
open ports .................................................................. 9 strict source route IP option, detect ......................25
operating systems ............................................. 12, 14 SYN and FIN flags set .............................................12
protocol anomalies ...................................................... 135 SYN floods ..........................................................38–43
ALGs........................................................................ 133 SYN fragments, detect ..........................................245
basic network protocols ....................................... 131 SYN-ACK-ACK proxy floods ...................................36
configuring parameters ........................................ 163 TCP packet without flags, detect ...........................14
Instant Messaging applications ........................... 133 teardrop ....................................................................54
P2P applications .................................................... 133 UDP floods ...............................................................51
supported protocols ...................................... 131–134 unknown protocols, drop .....................................243
proxy servers VLAN and MGT zones ...............................................2
configuring for DI pattern updates ..................... 129 WinNuke attacks .....................................................55
security IP option ....................................................10, 11
R Security Policies ...........................................................183
RADIUS ......................................................................... 132 security policies
reconnaissance .......................................................... 7–25 rulebase execution ................................................186
address sweep ........................................................... 8 rulebases ................................................................183
FIN scans.................................................................. 15 rules ........................................................................183

IX-IV  Index
 Index

templates................................................................186 session timeouts ......................................................31

Server Message Block stream signatures ..................................................161
See SMB teardrop attacks .............................................................54
services Telnet .............................................................................132
custom ....................................................................153 templates
session limits ............................................................28–31 security policy ........................................................186
destination-based ..............................................29, 30 TFTP ..............................................................................132
source-based ......................................................28, 30 three-way handshakes...................................................38
session table floods .................................................17, 28 threshold
session timeout low-watermark.........................................................31
HTTP .........................................................................32 thresholds
session timeouts high-watermark .......................................................31
TCP............................................................................31 timestamp IP option ......................................................11
UDP ...........................................................................32 traffic
signature packs, DI ......................................................122 prioritizing ................................................................33
signatures traffic, prioritizing critical .............................................35
stateful ....................................................................134 Transparent mode
SMB drop unknown MAC addresses ..............................43
NetBIOS ..................................................................133
SNMPTRAP ...................................................................132 U
SSH ................................................................................132 UDP session timeouts ...................................................32
SSL .................................................................................132 unknown protocols ......................................................243
stateful ..............................................................................3 updating IDP engine ....................................................233
inspection ...................................................................3
signatures ...............................................................134 V
stream ID IP option .......................................................11 VNC ...............................................................................132
stream signatures ........................................................135 VSD groups ...................................................................182
strict source route IP option .............................11, 23–25
SurfControl .............................................................99, 108 W
SYN and FIN flags set ....................................................12 Web filtering ...................................................98, 108–115
SYN checking .....................................................15, 15–18 applying profiles to policies .................................105
asymmetric routing.................................................16 blocked URL message ...........................................112
reconnaissance hole ...............................................17 blocked URL message type ..................................112
session interruption ................................................17 cache .......................................................................100
session table floods .................................................17 communication timeout .......................................111
SYN cookies....................................................................48 integrated .................................................................99
SYN floods ................................................................38–43 profiles ....................................................................103
alarm threshold .......................................................42 redirect ...................................................................108
attack threshold .......................................................41 routing ....................................................................113
attacks ......................................................................38 server status ...........................................................113
destination threshold ..............................................42 servers per vsys .....................................................109
drop unknown MAC addresses..............................43 SurfControl
queue size ................................................................43 CPA servers .........................................................99
source threshold ......................................................42 SCFP...................................................................110
SYN cookies .............................................................48 server name ......................................................111
threshold ..................................................................39 server port.........................................................111
timeout .....................................................................43 SurfControl servers................................................100
SYN fragments .............................................................245 URL categories .......................................................102
SYN-ACK-ACK proxy floods ..........................................36 Websense server name and server port .............111
syslog ............................................................................132 Whois ............................................................................132
WinNuke attacks ............................................................55
T
TCP Y
packet without flags ................................................14 Yahoo! Messenger ........................................................133

Index  IX-V
 Concepts & Examples ScreenOS Reference Guide

Z
zip files, blocking ......................................................... 169
zombie agents.......................................................... 27, 29

IX-VI  Index
Concepts & Examples
ScreenOS Reference Guide

Volume 5:
Virtual Private Networks

Release 6.1.0, Rev. 03

Juniper Networks, Inc.

1194 North Mathilda Avenue
Sunnyvale, CA 94089
USA
408-745-2000
www.juniper.net
 Copyright Notice
Copyright © 2009 Juniper Networks, Inc. All rights reserved.

Juniper Networks, the Juniper Networks logo, JUNOS, NetScreen, ScreenOS, and Steel-Belted Radius are registered trademarks of Juniper Networks, Inc.
in the United States and other countries. JUNOSe is a trademark of Juniper Networks, Inc. All other trademarks, service marks, registered trademarks, or
registered service marks are the property of their respective owners.

All specifications are subject to change without notice. Juniper Networks assumes no responsibility for any inaccuracies in this document or for any
obligation to update information in this document. Juniper Networks reserves the right to change, modify, transfer, or otherwise revise this publication
without notice.

FCC Statement
The following information is for FCC compliance of Class A devices: This equipment has been tested and found to comply with the limits for a Class A
digital device, pursuant to part 15 of the FCC rules. These limits are designed to provide reasonable protection against harmful interference when the
equipment is operated in a commercial environment. The equipment generates, uses, and can radiate radio-frequency energy and, if not installed and
used in accordance with the instruction manual, may cause harmful interference to radio communications. Operation of this equipment in a residential
area is likely to cause harmful interference, in which case users will be required to correct the interference at their own expense.

The following information is for FCC compliance of Class B devices: The equipment described in this manual generates and may radiate radio-frequency
energy. If it is not installed in accordance with Juniper Networks’ installation instructions, it may cause interference with radio and television reception.
This equipment has been tested and found to comply with the limits for a Class B digital device in accordance with the specifications in part 15 of the FCC
rules. These specifications are designed to provide reasonable protection against such interference in a residential installation. However, there is no
guarantee that interference will not occur in a particular installation.

If this equipment does cause harmful interference to radio or television reception, which can be determined by turning the equipment off and on, the user
is encouraged to try to correct the interference by one or more of the following measures:

 Reorient or relocate the receiving antenna.

 Increase the separation between the equipment and receiver.

 Consult the dealer or an experienced radio/TV technician for help.

 Connect the equipment to an outlet on a circuit different from that to which the receiver is connected.

Caution: Changes or modifications to this product could void the user's warranty and authority to operate this device.

Disclaimer
THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED
WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED
WARRANTY, CONTACT YOUR JUNIPER NETWORKS REPRESENTATIVE FOR A COPY.

ii 
Table of Contents
About This Volume vii
Document Conventions................................................................................. viii
Web User Interface Conventions ........................................................... viii
Command Line Interface Conventions ................................................... viii
Naming Conventions and Character Types .............................................. ix
Illustration Conventions ............................................................................ x
Requesting Technical Support .......................................................................... x
Self-Help Online Tools and Resources....................................................... xi
Opening a Case with JTAC ........................................................................ xi
Document Feedback ....................................................................................... xi

Chapter 1 Internet Protocol Security 1

Introduction to Virtual Private Networks .......................................................... 2
IPSec Concepts ................................................................................................3
Modes........................................................................................................ 4
Transport Mode .................................................................................. 4
Tunnel Mode ....................................................................................... 4
Protocols ................................................................................................... 5
Authentication Header ........................................................................ 6
Encapsulating Security Payload........................................................... 6
Key Management ...................................................................................... 7
Manual Key ......................................................................................... 7
AutoKey IKE........................................................................................ 7
Security Associations ................................................................................. 8
Tunnel Negotiation........................................................................................... 8
Phase 1...................................................................................................... 9
Main and Aggressive Modes ................................................................ 9
Diffie-Hellman Exchange................................................................... 10
Phase 2.................................................................................................... 11
Perfect Forward Secrecy ................................................................... 11
Replay Protection.............................................................................. 12
IKE and IPSec Packets.................................................................................... 12
IKE Packets ............................................................................................. 12
IPSec Packets .......................................................................................... 15
IKE Version 2........................................................................................... 17
Initial Exchanges............................................................................... 17
CREATE_CHILD_SA Exchange .......................................................... 19
Informational Exchanges .................................................................. 19
Enabling IKEv2 on a Security Device ....................................................... 19
Example: Configuring an IKEv2 Gateway .......................................... 20
Authentication Using Extensible Authentication Protocol .................. 24
IKEv2 EAP Passthrough ........................................................................... 25
Example............................................................................................ 25

Table of Contents  iii

 Concepts & Examples ScreenOS Reference Guide

Chapter 2 Public Key Cryptography 29

Introduction to Public Key Cryptography ....................................................... 30
Signing a Certificate................................................................................. 30
Verifying a Digital Signature .................................................................... 30
Public Key Infrastructure................................................................................ 32
Certificates and CRLs ..................................................................................... 34
Requesting a Certificate Manually............................................................ 36
Loading Certificates and Certificate Revocation Lists ............................... 38
Configuring CRL Settings ......................................................................... 39
Obtaining a Local Certificate Automatically ............................................. 40
Automatic Certificate Renewal.................................................................43
Key-Pair Generation................................................................................. 44
Online Certificate Status Protocol................................................................... 44
Specifying a Certificate Revocation Check Method .................................. 45
Viewing Status Check Attributes .............................................................. 46
Specifying an Online Certificate Status Protocol Responder URL ............. 46
Removing Status Check Attributes........................................................... 46
Self-Signed Certificates................................................................................... 47
Certificate Validation ............................................................................... 48
Manually Creating Self-Signed Certificates ............................................... 49
Setting an Admin-Defined Self-Signed Certificate .................................... 50
Certificate Auto-Generation...................................................................... 54
Deleting Self-Signed Certificates .............................................................. 55

Chapter 3 Virtual Private Network Guidelines 57

Cryptographic Options ................................................................................... 58
Site-to-Site Cryptographic Options ........................................................... 58
Dialup VPN Options................................................................................. 65
Route-Based and Policy-Based Tunnels .......................................................... 72
Packet Flow: Site-to-Site VPN ......................................................................... 73
Tunnel Configuration Guidelines .................................................................... 79
Route-Based Virtual Private Network Security Considerations ........................ 81
Null Route................................................................................................ 81
Dialup or Leased Line .............................................................................. 83
VPN Failover to Leased Line or Null Route............................................... 84
Decoy Tunnel Interface ........................................................................... 86
Virtual Router for Tunnel Interfaces......................................................... 87
Reroute to Another Tunnel ...................................................................... 87

Chapter 4 Site-to-Site Virtual Private Networks 89

Site-to-Site VPN Configurations ...................................................................... 90
Route-Based Site-to-Site VPN, AutoKey IKE ............................................. 96
Policy-Based Site-to-Site VPN, AutoKey IKE ...........................................105
Route-Based Site-to-Site VPN, Dynamic Peer .........................................111
Policy-Based Site-to-Site VPN, Dynamic Peer.........................................119
Route-Based Site-to-Site VPN, Manual Key.............................................128
Policy-Based Site-to-Site VPN, Manual Key.............................................134
Dynamic IKE Gateways Using FQDN ...........................................................139
Aliases ...................................................................................................140
Setting AutoKey IKE Peer with FQDN ....................................................141
VPN Sites with Overlapping Addresses.........................................................150
Transparent Mode VPN ................................................................................161

iv  Table of Contents
 Table of Contents

Chapter 5 Dialup Virtual Private Networks 169

Dialup ..........................................................................................................170
Policy-Based Dialup VPN, AutoKey IKE..................................................170
Route-Based Dialup VPN, Dynamic Peer................................................176
Policy-Based Dialup VPN, Dynamic Peer ...............................................183
Bidirectional Policies for Dialup VPN Users............................................188
Group IKE ID................................................................................................193
Group IKE ID with Certificates ...............................................................193
Wildcard and Container ASN1-DN IKE ID Types....................................195
Creating a Group IKE ID (Certificates) ....................................................197
Setting a Group IKE ID with Preshared Keys..........................................202
Shared IKE ID ..............................................................................................208

Chapter 6 Layer 2 Tunneling Protocol 215

Introduction to L2TP ....................................................................................215
Packet Encapsulation and Decapsulation .....................................................218
Encapsulation ........................................................................................218
Decapsulation........................................................................................219
Setting L2TP Parameters ..............................................................................221
L2TP and L2TP-over-IPSec ...........................................................................223
Configuring L2TP...................................................................................223
Configuring L2TP-over-IPSec .................................................................228
Bidirectional L2TP-over-IPSec ................................................................235

Chapter 7 Advanced Virtual Private Network Features 241

NAT-Traversal ..............................................................................................242
Probing for NAT.....................................................................................243
Traversing a NAT Device .......................................................................245
UDP Checksum......................................................................................247
Keepalive Packets..................................................................................247
Initiator/Responder Symmetry ..............................................................247
Enabling NAT-Traversal .........................................................................249
Using IKE IDs with NAT-Traversal..........................................................250
VPN Monitoring ...........................................................................................252
Rekey and Optimization Options...........................................................253
Source Interface and Destination Address .............................................254
Policy Considerations ............................................................................255
Configuring the VPN Monitoring Feature ...............................................255
SNMP VPN Monitoring Objects and Traps .............................................263
Multiple Tunnels per Tunnel Interface ..........................................................265
Route-to-Tunnel Mapping ......................................................................265
Remote Peers’ Addresses ......................................................................267
Manual and Automatic Table Entries .....................................................268
Manual Table Entries.......................................................................268
Automatic Table Entries ..................................................................268
Setting VPNs on a Tunnel Interface to Overlapping Subnets............270
Binding Automatic Route and NHTB Table Entries ..........................288
Using OSPF for Automatic Route Table Entries ...............................300
Redundant VPN Gateways............................................................................301
VPN Groups ...........................................................................................302
Monitoring Mechanisms ........................................................................303
IKE Heartbeats ................................................................................304
Dead Peer Detection .......................................................................304

Table of Contents  v
 Concepts & Examples ScreenOS Reference Guide

IKE Recovery Procedure..................................................................305

TCP SYN-Flag Checking .........................................................................307
Creating Redundant VPN Gateways.................................................308
Creating Back-to-Back VPNs .........................................................................314
Creating Hub-and-Spoke VPNs .....................................................................321

Chapter 8 AutoConnect-Virtual Private Networks 331

Overview .....................................................................................................331
How It Works...............................................................................................331
NHRP Messages.....................................................................................332
AC-VPN Tunnel Initiation .......................................................................333
Configuring AC-VPN ..............................................................................334
Network Address Translation ..........................................................334
Configuration on the Hub................................................................334
Configuration on Each Spoke ..........................................................335
Example ................................................................................................336

Index..........................................................................................................................IX-I

vi  Table of Contents
About This Volume

Volume 5: Virtual Private Networks describes virtual private network (VPN) concepts
and ScreenOS VPN-specific features.

This volume contains the following chapters:

 Chapter 1, “Internet Protocol Security,” provides background information about

IPSec, presents a flow sequence for Phase 1 in IKE negotiations in Aggressive
and Main modes, and concludes with information about IKE and IPSec packet
encapsulation.

 Chapter 2, “Public Key Cryptography,” provides an introduction to public key

cryptography, certificate use, and certificate revocation list (CRL) use within the
context of Public Key Infrastructure (PKI).

 Chapter 3, “Virtual Private Network Guidelines,” offers some useful information

to help in the selection of the available VPN options. It also presents a packet
flow chart to demystify VPN packet processing.

 Chapter 4, “Site-to-Site Virtual Private Networks,” provides extensive examples

of VPN configurations connecting two private networks.

 Chapter 5, “Dialup Virtual Private Networks,” provides extensive examples of

client-to-LAN communication using AutoKey IKE. It also details group IKE ID
and shared IKE ID configurations.

 Chapter 6, “Layer 2 Tunneling Protocol,” explains Layer 2 Tunneling Protocol

(L2TP) and provides configuration examples for L2TP and L2TP-over-IPSec.

 Chapter 7, “Advanced Virtual Private Network Features,” contains information

and examples for the more advanced VPN configurations, such as
NAT-Traversal, VPN monitoring, binding multiple tunnels to a single tunnel
interface, and hub-and-spoke and back-to-back tunnel designs.

 Chapter 8, “AutoConnect-Virtual Private Networks,” describes how ScreenOS

uses Next Hop Resolution Protocol (NHRP) messages to enable security devices
to set up AutoConnect VPNs as needed. The chapter provides an example of a
typical scenario in which AC-VPN might be used.

 vii
 Concepts & Examples ScreenOS Reference Guide

Document Conventions
This document uses the conventions described in the following sections:

 “Web User Interface Conventions” on page viii

 “Command Line Interface Conventions” on page viii

 “Naming Conventions and Character Types” on page ix

 “Illustration Conventions” on page x

Web User Interface Conventions

The Web user interface (WebUI) contains a navigational path and configuration
settings. To enter configuration settings, begin by clicking a menu item in the
navigation tree on the left side of the screen. As you proceed, your navigation path
appears at the top of the screen, with each page separated by angle brackets.

The following example shows the WebUI path and parameters for defining an
address:

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: addr_1

IP Address/Domain Name:
IP/Netmask: (select), 10.2.2.5/32
Zone: Untrust

To open Online Help for configuration settings, click the question mark (?) in the
upper left of the screen.

The navigation tree also provides a Help > Config Guide configuration page to help
you configure security policies and Internet Protocol Security (IPSec). Select an
option from the list, and follow the instructions on the page. Click the ? character in
the upper left for Online Help on the Config Guide.

Command Line Interface Conventions

The following conventions are used to present the syntax of command line
interface (CLI) commands in text and examples.

In text, commands are in boldface type and variables are in italic type.

In examples:

 Variables are in italic type.

 Anything inside square brackets [ ] is optional.

 Anything inside braces { } is required.

viii  Document Conventions

 About This Volume

 If there is more than one choice, each choice is separated by a pipe ( | ). For
example, the following command means “set the management options for the
ethernet1, the ethernet2, or the ethernet3 interface”:

set interface { ethernet1 | ethernet2 | ethernet3 } manage

NOTE: When entering a keyword, you only have to type enough letters to identify the
word uniquely. Typing set adm u whee j12fmt54 will enter the command set
admin user wheezer j12fmt54. However, all the commands documented in this
guide are presented in their entirety.

Naming Conventions and Character Types

ScreenOS employs the following conventions regarding the names of objects—such
as addresses, admin users, auth servers, IKE gateways, virtual systems, VPN
tunnels, and zones—defined in ScreenOS configurations:

 If a name string includes one or more spaces, the entire string must be
enclosed within double quotes; for example:

set address trust “local LAN” 10.1.1.0/24

 Any leading spaces or trailing text within a set of double quotes are trimmed;
for example, “ local LAN ” becomes “local LAN”.

 Multiple consecutive spaces are treated as a single space.

 Name strings are case-sensitive, although many CLI keywords are

case-insensitive. For example, “local LAN” is different from “local lan”.

ScreenOS supports the following character types:

 Single-byte character sets (SBCS) and multiple-byte character sets (MBCS).

Examples of SBCS are ASCII, European, and Hebrew. Examples of MBCS—also
referred to as double-byte character sets (DBCS)—are Chinese, Korean, and
Japanese.

 ASCII characters from 32 (0x20 in hexadecimals) to 255 (0xff), except double

quotes ( “ ), which have special significance as an indicator of the beginning or
end of a name string that includes spaces.

NOTE: A console connection only supports SBCS. The WebUI supports both SBCS and
MBCS, depending on the character sets that your browser supports.

Document Conventions  ix
 Concepts & Examples ScreenOS Reference Guide

Illustration Conventions
Figure 1 shows the basic set of images used in illustrations throughout this volume.

Figure 1: Images in Illustrations

Autonomous System Local Area Network (LAN)
or with a Single Subnet
Virtual Routing Domain or
Security Zone

Dynamic IP (DIP) Pool

Internet

Policy Engine
Security Zone Interfaces:
White = Protected Zone Interface
(example = Trust Zone)
Black = Outside Zone Interface
(example = Untrust Zone)
Generic Network Device

Tunnel Interface

Server

VPN Tunnel

Router

Juniper Networks
Switch Security Devices

Hub

Requesting Technical Support

Technical product support is available through the Juniper Networks Technical
Assistance Center (JTAC). If you are a customer with an active J-Care or JNASC
support contract, or are covered under warranty, and need postsales technical
support, you can access our tools and resources online or open a case with JTAC.

 JTAC policies—For a complete understanding of our JTAC procedures and

policies, review the JTAC User Guide located at
http://www.juniper.net/customers/support/downloads/710059.pdf.

 Product warranties—For product warranty information, visit

http://www.juniper.net/support/warranty/.

 JTAC hours of operation—The JTAC centers have resources available 24 hours a

day, 7 days a week, 365 days a year.

x  Requesting Technical Support

 About This Volume

Self-Help Online Tools and Resources

For quick and easy problem resolution, Juniper Networks has designed an online
self-service portal called the Customer Support Center (CSC) that provides you with
the following features:

 Find CSC offerings—http://www.juniper.net/customers/support/

 Find product documentation—http://www.juniper.net/techpubs/

 Find solutions and answer questions using our Knowledge Base—

http://kb.juniper.net/

 Download the latest versions of software and review your release notes—
http://www.juniper.net/customers/csc/software/

 Search technical bulletins for relevant hardware and software notifications—

http://www.juniper.net/alerts/

 Join and participate in the Juniper Networks Community Forum—

http://www.juniper.net/company/communities/

 Open a case online in the CSC Case Manager—

http://www.juniper.net/customers/cm/

 To verify service entitlement by product serial number, use our Serial Number
Entitlement (SNE) Tool—
https://tools.juniper.net/SerialNumberEntitlementSearch/

Opening a Case with JTAC

You can open a case with JTAC on the Web or by telephone.

 Use the Case Manager tool in the CSC at http://www.juniper.net/customers/cm/.

 Call 1-888-314-JTAC (1-888-314-5822—toll free in USA, Canada, and Mexico).

For international or direct-dial options in countries without toll-free numbers, visit

us at http://www.juniper.net/customers/support/requesting-support/.

Document Feedback
If you find any errors or omissions in this document, contact Juniper Networks at
[email protected].

Document Feedback  xi
 Concepts & Examples ScreenOS Reference Guide

xii  Document Feedback

Chapter 1
Internet Protocol Security

This chapter introduces elements of Internet Protocol Security (IPSec) and describes
how they relate to virtual private network (VPN) tunneling. This chapter contains
the following sections:

 “Introduction to Virtual Private Networks” on page 2

 “IPSec Concepts” on page 3

 “Modes” on page 4

 “Protocols” on page 5

 “Key Management” on page 7

 “Security Associations” on page 8

 “Tunnel Negotiation” on page 8

 “Phase 1” on page 9

 “Phase 2” on page 11

 “IKE and IPSec Packets” on page 12

 “IKE Packets” on page 12

 “IPSec Packets” on page 15

 “IKE Version 2” on page 17

 “Enabling IKEv2 on a Security Device” on page 19

 “IKEv2 EAP Passthrough” on page 25

 1
 Concepts & Examples ScreenOS Reference Guide

Introduction to Virtual Private Networks

A virtual private network (VPN) provides a means for securely communicating
between remote computers across a public wide area network (WAN), such as the
Internet.

A VPN connection can link two local area networks (LANs) or a remote dialup user
and a LAN. The traffic that flows between these two points passes through shared
resources such as routers, switches, and other network equipment that make up the
public WAN. To secure VPN communication while passing through the WAN, the
two participants create an IP Security (IPSec) tunnel.

NOTE: The term tunnel does not denote either Transport or Tunnel mode (see “Modes”
on page 4). It refers to the IPSec connection.

An IPSec tunnel consists of a pair of unidirectional Security Associations (SAs)—one

at each end of the tunnel—that specify the security parameter index (SPI),
destination IP address, and security protocol (Authentication Header or
Encapsulating Security Payload) employed.

For more information about SPIs, see “Security Associations” on page 8. For more
information about IPSec security protocols, see “Protocols” on page 5.

Through the SA, an IPSec tunnel can provide the following security functions:

 Privacy (through encryption)

 Content integrity (through data authentication)

 Sender authentication and—if using certificates—nonrepudiation (through data

origin authentication)

The security functions you employ depend on your needs. If you only need to
authenticate the IP packet source and content integrity, you can authenticate the
packet without applying any encryption. On the other hand, if you are only
concerned with preserving privacy, you can encrypt the packet without applying
any authentication mechanisms. Optionally, you can both encrypt and authenticate
the packet. Most network security designers choose to encrypt, authenticate, and
replay-protect their VPN traffic.

ScreenOS supports IPSec technology for creating VPN tunnels with two kinds of key
creation mechanisms:

 Manual Key

 AutoKey IKE with a preshared key or a certificate

2  Introduction to Virtual Private Networks

 Chapter 1: Internet Protocol Security

IPSec Concepts
IP Security (IPSec) is a suite of related protocols for cryptographically securing
communications at the IP Packet Layer. IPSec consists of two modes and two main
protocols:

 Transport and tunnel modes

 The Authentication Header (AH) protocol for authentication and the

Encapsulating Security Payload (ESP) protocol for encryption (and
authentication)

IPSec also provides methods for the manual and automatic negotiation of Security
Associations (SAs) and key distribution, all the attributes for which are gathered in a
Domain of Interpretation (DOI). Refer to RFC 2407 and RFC 2408.

Figure 2: IPSec Architecture

Transport Mode Tunnel Mode

Note: ScreenOS does

not support Transport
Mode with AH.

AH Protocol
ESP Protocol

Authentication Algorithm Encryption Algorithm

(MD5, SHA-1) (DES, 3DES)

Domain of Interpretation
(DOI)

SA and Key Management

(Manual and Automatic)

NOTE: The IPSec Domain of Interpretation (DOI) is a document containing definitions for
all the security parameters required for the successful negotiation of a VPN
tunnel—essentially, all the attributes required for SA and IKE negotiations.

IPSec Concepts  3
 Concepts & Examples ScreenOS Reference Guide

Modes
IPSec operates in one of two modes—Transport or Tunnel. When both ends of the
tunnel are hosts, you can use either mode. When at least one of the endpoints of a
tunnel is a security gateway, such as a router or firewall, you must use Tunnel mode.
Juniper Networks security devices always operate in Tunnel mode for IPSec tunnels
and Transport mode for L2TP-over-IPSec tunnels.

Transport Mode
The original IP packet is not encapsulated within another IP packet, as shown in
Figure 3. The entire packet can be authenticated (with AH), the payload can be
encrypted (with ESP), and the original header remains in plaintext as it is sent
across the WAN.

Figure 3: Transport Modes

IP Packets
Transport Mode--AH
Original AH Payload

Authenticated

Transport Mode--ESP
Original ESP Payload

Encrypted
Authenticated

Tunnel Mode
The entire original IP packet—payload and header—is encapsulated within another
IP payload and a new header is prepended to it, as shown in Figure 4. The entire
original packet can be encrypted, authenticated, or both. With AH, the AH and new
headers are also authenticated. With ESP, the ESP header can also be authenticated.

Figure 4: Tunnel Modes

IP Packets
The original packet is encapsulated.
Tunnel Mode--AH New AH Original
Header Header Header Payload

Authenticated

Tunnel Mode--ESP New ESP Original

Header Header Header Payload

Encrypted
Authenticated

In a site-to-site VPN, the source and destination addresses used in the new header
are the IP addresses of the outgoing interface (in NAT or Route mode) or the VLAN1
IP address (in Transparent mode); the source and destination addresses of the
encapsulated packets are the addresses of the ultimate endpoints of the connection.

4  IPSec Concepts
 Chapter 1: Internet Protocol Security

Figure 5: Site-to-Site VPN in Tunnel Mode

Device A Device B
Tunnel Gateway Tunnel Gateway

Internet

LAN LAN
Tunnel

1 2
B
A
A B Payload 1 2 A B Payload A B Payload

The original packet is encapsulated.

In a dialup VPN, there is no tunnel gateway on the VPN dialup client end of the
tunnel; the tunnel extends directly to the client itself. In this case, on packets sent
from the dialup client, both the new header and the encapsulated original header
have the same IP address: that of the client’s computer.

NOTE: Some VPN clients such as the NetScreen-Remote allow you to define a virtual
inner IP address. In such cases, the virtual inner IP address is the source IP
address in the original packet header of traffic originating from the client, and the
IP address that the ISP dynamically assigns the dialup client is the source IP
address in the outer header.

Figure 6: Dialup VPN in Tunnel Mode

Device B
Tunnel Gateway
Internet
VPN Dialup Client
LAN
Tunnel
A=1
2 B

A B Payload 1 2 A B Payload A B Payload

The original packet is encapsulated.

Protocols
IPSec uses two protocols to secure communications at the IP Layer:

 Authentication Header (AH)—A security protocol for authenticating the source

of an IP packet and verifying the integrity of its content

 Encapsulating Security Payload (ESP)—A security protocol for encrypting the

entire IP packet (and authenticating its content)

IPSec Concepts  5
 Concepts & Examples ScreenOS Reference Guide

Authentication Header
The Authentication Header (AH) protocol provides a means to verify the
authenticity/integrity of the content and origin of a packet. You can authenticate the
packet by the checksum calculated through a hash-based message authentication
code (HMAC) using a secret key and either MD5 or SHA-1 hash functions.

 Message Digest version 5 (MD5)—An algorithm that produces a 128-bit hash

(also called a digital signature or message digest) from a message of arbitrary
length and a 16-byte key. The resulting hash is used, like a fingerprint of the
input, to verify content and source authenticity and integrity.

 Secure Hash Algorithm-1 (SHA-1)—An algorithm that produces a 160-bit hash

from a message of arbitrary length and a 20-byte key. It is generally regarded as
more secure than MD5 because of the larger hashes it produces. Because the
computational processing is done in the ASIC, the performance cost is
negligible.

NOTE: For more information about MD5 and SHA-1 hashing algorithms, refer to the
following RFCs: (MD5) 1321, 2403; (SHA-1) 2404. For information about HMAC,
refer to RFC 2104.

Encapsulating Security Payload

The Encapsulating Security Payload (ESP) protocol provides a means to ensure
privacy (encryption) and source authentication and content integrity
(authentication). ESP in tunnel mode encapsulates the entire IP packet (header and
payload) and then appends a new IP header to the now-encrypted packet. This new
IP header contains the destination address needed to route the protected data
through the network.

With ESP, you can both encrypt and authenticate, encrypt only, or authenticate
only. For encryption, you can choose one of the following encryption algorithms:

 Data Encryption Standard (DES)—A cryptographic block algorithm with a

56-bit key.

 Triple DES (3DES)—A more powerful version of DES in which the original DES
algorithm is applied in three rounds, using a 168-bit key. DES provides a
significant performance savings but is considered unacceptable for many
classified or sensitive material transfers.

 Advanced Encryption Standard (AES)—An emerging encryption standard

which, when adopted by Internet infrastructures worldwide, will offer greater
interoperability with other network security devices. ScreenOS supports AES
with 128-bit, 192-bit, and 256-bit keys.

For authentication, you can use either MD5 or SHA-1 algorithms.

NOTE: Even though it is possible to select NULL for authentication, it has been
demonstrated that IPSec might be vulnerable to attack under such circumstances.
Therefore, it is inadvisable to select NULL for authentication.

6  IPSec Concepts
 Chapter 1: Internet Protocol Security

Key Management
The distribution and management of keys are critical to using VPNs successfully.
IPSec supports both manual and automatic key-distribution methods.

Manual Key
With manual keys, administrators at both ends of a tunnel configure all the security
parameters. This is a viable technique for small, static networks where the
distribution, maintenance, and tracking of keys are not difficult. However, safely
distributing manual-key configurations across great distances poses security issues.
Aside from passing the keys face-to-face, you cannot be completely sure that the
keys have not been compromised while in transit. Also, whenever you want to
change the key, you are faced with the same security issues as when you initially
distributed it.

AutoKey IKE
When you need to create and manage numerous tunnels, you need a method that
does not require you to configure every element manually. IPSec supports the
automated generation and negotiation of keys and security associations using the
Internet Key Exchange (IKE) protocol. ScreenOS refers to such automated tunnel
negotiation as AutoKey IKE and supports AutoKey IKE with preshared keys and
AutoKey IKE with certificates.

AutoKey IKE with Preshared Keys

With AutoKey IKE using preshared keys to authenticate the participants in an IKE
session, each side must configure and securely exchange the preshared key in
advance. In this regard, the issue of secure key distribution is the same as that with
manual keys. However, once distributed, an autokey, unlike a manual key, can
automatically change its keys at predetermined intervals using the IKE protocol.
Frequently changing keys greatly improves security, and automatically doing so
greatly reduces key-management responsibilities. However, changing keys increases
traffic overhead; therefore, doing so too often can reduce data transmission
efficiency.

NOTE: A preshared key is a key for both encryption and decryption, which both
participants must have before initiating communication.

AutoKey IKE with Certificates

When using certificates to authenticate the participants during an AutoKey IKE
negotiation, each side generates a public/private key pair (see “Public Key
Cryptography” on page 29) and acquires a certificate (see “Certificates and CRLs”
on page 34). As long as the issuing certificate authority (CA) is trusted by both sides,
the participants can retrieve the peer’s public key and verify the peer’s signature.
There is no need to keep track of the keys and SAs; IKE does it automatically.

NOTE: For examples of both manual key and AutoKey IKE tunnels, see “Site-to-Site
Virtual Private Networks” on page 89.

IPSec Concepts  7
 Concepts & Examples ScreenOS Reference Guide

Security Associations
A security association (SA) is a unidirectional agreement between the VPN
participants regarding the methods and parameters to use in securing a
communication channel. Full bidirectional communication requires at least two
SAs, one for each direction.

An SA groups together the following components for securing communications:

 Security algorithms and keys

 Protocol mode (Transport or Tunnel)

 Key-management method (manual key or AutoKey IKE)

 SA lifetime

For outbound VPN traffic, the policy invokes the SA associated with the VPN tunnel.
For inbound traffic, the security device looks up the SA by using the following
triplet:

 Destination IP

 Security protocol (AH or ESP)

 Security parameter index (SPI) value

Tunnel Negotiation
For a manual key IPSec tunnel, because all of the SA parameters have been
previously defined, there is no need to negotiate which SAs to use. In essence, the
tunnel has already been established. When traffic matches a policy using that
manual key tunnel or when a route involves the tunnel, the security device simply
encrypts and authenticates the data, as you determined, and forwards it to the
destination gateway.

To establish an AutoKey IKE IPSec tunnel, two phases of negotiations are required:

 In Phase 1, the participants establish a secure channel in which to negotiate the

IPSec SAs.

 In Phase 2, the participants negotiate the IPSec SAs for encrypting and
authenticating the ensuing exchanges of user data.

NOTE: Juniper Networks security devices support the newer version of the IKE protocol
known as IKEv2. For more information about IKEv2 and how security devices
establish security associations (SAs) using the IKEv2 protocol, see “IKE Version 2”
on page 17.

8  Tunnel Negotiation
 Chapter 1: Internet Protocol Security

Phase 1
Phase 1 of an AutoKey IKE tunnel negotiation consists of the exchange of proposals
for how to authenticate and secure the channel. The exchange can be in one of two
modes: Aggressive or Main. Using either mode, the participants exchange proposals
for acceptable security services such as:

 Encryption algorithms (DES and 3DES) and authentication algorithms (MD5

and SHA-1). For more information about these algorithms, see “Protocols” on
page 5.

 A Diffie-Hellman Group (see “Diffie-Hellman Exchange” on page 10).

 Preshared Key or RSA/DSA certificates (see “AutoKey IKE” on page 7).

A successful Phase 1 negotiation concludes when both ends of the tunnel agree to
accept at least one set of the Phase 1 security parameters proposed and then
process them. Juniper Networks security devices support up to four proposals for
Phase 1 negotiations, allowing you to define how restrictive a range of security
parameters for key negotiation you will accept.

The predefined Phase 1 proposals that ScreenOS provides are as follows:

 Standard: pre-g2-aes128-sha and pre-g2-3des-sha

 Compatible: pre-g2-3des-sha, pre-g2-3des-md5, pre-g2-des-sha, and

pre-g2-des-md5

 Basic: pre-g1-des-sha and pre-g1-des-md5

You can also define custom Phase 1 proposals.

Main and Aggressive Modes

Phase 1 can take place in either Main or Aggressive mode. The two modes are
described below.

Main mode: The initiator and recipient send three two-way exchanges (six
messages total) to accomplish the following services:

 First exchange (messages 1 and 2): Propose and accept the encryption and
authentication algorithms.

 Second exchange (messages 3 and 4): Execute a Diffie-Hellman exchange, and

the initiator and recipient each provide a pseudo-random number.

 Third exchange (messages 5 and 6): Send and verify their identities.

The information transmitted in the third exchange of messages is protected by the

encryption algorithm established in the first two exchanges. Thus, the participants’
identities are not transmitted in the clear.

Tunnel Negotiation  9
 Concepts & Examples ScreenOS Reference Guide

Aggressive Mode: The initiator and recipient accomplish the same objectives, but
only in two exchanges, with a total of three messages:

 First message: The initiator proposes the SA, initiates a Diffie-Hellman

exchange, and sends a pseudo-random number and its IKE identity.

 Second message: The recipient accepts the SA; authenticates the initiator; and
sends a pseudo-random number, its IKE identity, and, if using certificates, the
recipient’s certificate.

 Third message: The initiator authenticates the recipient, confirms the exchange,
and, if using certificates, sends the initiator’s certificate.

Because the participants’ identities are exchanged in the clear (in the first two
messages), Aggressive mode does not provide identity protection.

NOTE: When a dialup VPN user negotiates an AutoKey IKE tunnel with a preshared key,
Aggressive mode must be used. Note also that a dialup VPN user can use an email
address, a fully qualified domain name (FQDN), or an IP address as its IKE ID. A
dynamic peer can use either an email address or FQDN, but not an IP address.

Diffie-Hellman Exchange
A Diffie-Hellman (DH) exchange allows the participants to produce a shared secret
value. The strength of the technique is that it allows the participants to create the
secret value over an unsecured medium without passing the secret value through
the wire. ScreenOS supports DH groups 1, 2, 5, and 14 for IKEv1 and IKEv2. The
size of the prime modulus used in each group’s calculation differs as follows:

 DH Group 1: 768-bit

 DH Group 2: 1024-bit

 DH Group 5: 1536-bit

 DH Group 14: 2048-bit

NOTE: The strength of DH Group 1 security has depreciated, and we do not recommend
its use.

The larger the modulus, the more secure the generated key is considered to be;
however, the larger the modulus, the longer the key-generation process takes.
Because the modulus for each DH group is a different size, the participants must
agree to use the same group.

NOTE: If you configure multiple (up to four) proposals for Phase 1 negotiations, you can
use different Diffie-Hellman groups in all proposals. The same guideline applies to
multiple proposals for Phase 2 negotiations.

10  Tunnel Negotiation
 Chapter 1: Internet Protocol Security

Phase 2
After the participants have established a secure and authenticated channel, they
proceed through Phase 2, in which they negotiate the SAs to secure the data to be
transmitted through the IPSec tunnel.

Like the process for Phase 1, the participants exchange proposals to determine
which security parameters to employ in the SA. A Phase 2 proposal also includes a
security protocol—either Encapsulating Security Payload (ESP) or Authentication
Header (AH)—and selected encryption and authentication algorithms. The proposal
can also specify a DH group, if Perfect Forward Secrecy (PFS) is desired.

Regardless of the mode used in Phase 1, Phase 2 always operates in Quick mode
and involves the exchange of three messages.

Juniper Networks security devices support up to four proposals for Phase 2

negotiations, allowing you to define how restrictive a range of tunnel parameters
you will accept. ScreenOS also provides a replay protection feature. Use of this
feature does not require negotiation because packets are always sent with sequence
numbers. You simply have the option of checking or not checking the sequence
numbers. (For more information about replay protection, see “Replay Protection”
on page 12.)

The predefined Phase 2 proposals that ScreenOS provides are as follows:

 Standard: g2-esp-3des-sha and g2-esp-aes128-sha

 Compatible: nopfs-esp-3des-sha, nopfs-esp-3des-md5, nopfs-esp-des-sha, and

nopfs-esp-des-md5

 Basic: nopfs-esp-des-sha and nopfs-esp-des-md5

You can also define custom Phase 2 proposals.

In Phase 2, the peers also exchange proxy IDs. A proxy ID is a three-part tuple
consisting of local IP address–remote IP address–service. The proxy ID for both
peers must match, which means that the service specified in the proxy ID for both
peers must be the same, and the local IP address specified for one peer must be the
same as the remote IP address specified for the other peer.

The CREATE_CHILD_SA exchange in an IKEv2 exchange corresponds to the Phase 2

negotiations in IKEv1. For more information, see “Initial Exchanges” on page 17.

Perfect Forward Secrecy

Perfect Forward Secrecy (PFS) is a method for deriving Phase 2 keys independent
from and unrelated to the preceding keys. Alternatively, the Phase 1 proposal
creates the key (the SKEYID_d key) from which all Phase 2 keys are derived. The
SKEYID_d key can generate Phase 2 keys with a minimum of CPU processing.
Unfortunately, if an unauthorized party gains access to the SKEYID_d key, all your
encryption keys are compromised.

PFS addresses this security risk by forcing a new Diffie-Hellman key exchange to
occur for each Phase 2 tunnel. Using PFS is thus more secure, although the rekeying
procedure in Phase 2 might take slightly longer with PFS enabled.

Tunnel Negotiation  11
 Concepts & Examples ScreenOS Reference Guide

Replay Protection
A replay attack occurs when somebody intercepts a series of packets and uses them
later either to flood the system, causing a denial of service (DoS), or to gain entry to
the trusted network. The replay-protection feature enables security devices to check
every IPSec packet to see if it has been received previously. If packets arrive outside
a specified sequence range, the security device rejects them.

IKE and IPSec Packets

An IPSec VPN tunnel consists of two major elements:

 Tunnel Setup: The peers first establish security associations (SAs), which define
the parameters for securing traffic between themselves. The admins at each
end can define the SAs manually, or the SAs can be defined dynamically
through IKE Phase 1 and Phase 2 negotiations. Phase 1 can occur in either
Main mode or Aggressive mode. Phase 2 always occurs in Quick mode.

 Applied Security: IPSec protects traffic sent between the two tunnel endpoints
by using the security parameters defined in the SAs that the peers agreed to
during the tunnel setup. IPSec can be applied in one of two modes—Transport
or Tunnel. Both modes support the two IPSec protocols—Encapsulating
Security Payload (ESP) and Authentication Header (AH).

For an explanation of the packet processing that occurs during the IKE and IPSec
stages of a VPN tunnel, see “IKE Packets” on page 12 and “IPSec Packets” on
page 15. These sections show the packet headers for IKE and IPSec, respectively.

IKE Packets
When a clear-text packet arrives at the security device that requires tunneling and
no active Phase 2 SA exists for that tunnel, the security device begins IKE
negotiations (and drops the packet). The source and destination addresses in the IP
packet header are those of the local and remote IKE gateways, respectively. In the
IP packet payload, there is a UDP segment encapsulating an Internet Security
Association and Key Management Protocol (ISAKMP), or IKE, packet. The format for
IKE packets is the same for Phase 1 and Phase 2.

NOTE: When the initial IP packet is dropped, the source host resends it. Typically, by the
time the second packet reaches the security device, IKE negotiations are complete
and the security device protects it—and all subsequent packets in the
session—with IPSec before forwarding it.

12  IKE and IPSec Packets

 Chapter 1: Internet Protocol Security

Figure 7: IKE Packet for Phases 1 and 2

IP UDP ISAKMP
Header Header Header Payload

Note: ISAKMP is the packet format that IKE uses.

IP Header
Header
Version Type of Service Total Packet Length (in Bytes)
Length
Identification 0 D M Fragment Offset

Time to Live (TTL) Protocol (17 for UDP) Header Checksum

Source Address (Local Peer’s Gateway)

Destination Address (Remote Peer’s Gateway)

IP Options (if any) Padding

IP Payload

UDP Header

Source Port (500 for IKE) Destination Port (500 for IKE)

Length Checksum

UDP Payload

ISAKMP Header (for IKE)

Initiator’s Cookie

Responder’s Cookie
(0000 for the first packet)

Next Payload Maj Ver Min Ver Exchange Type Flags

Message ID
Message Length

ISAKMP Payload

The Next Payload field contains a number indicating one of the following payload
types:

 0002—SA Negotiation Payload: contains a definition for a Phase 1 or Phase 2

SA.

 0004—Proposal Payload: can be a Phase 1 or Phase 2 proposal.

 0008—Transform Payload: the transform payload gets encapsulated in a

proposal payload which gets encapsulated in an SA payload.

 0010—Key Exchange (KE) Payload: contains information necessary to perform

a key exchange, such as a Diffie-Hellman public value.

 0020—Identification (IDx) Payload.

IKE and IPSec Packets  13

 Concepts & Examples ScreenOS Reference Guide

 In Phase 1, IDii indicates the initiator ID, and IDir indicates the responder
ID.

 In Phase 2, IDui indicates the user initiator, and IDur indicates the user
responder.

The IDs are IKE ID types such as FQDN, U-FQDN, IP address, and
ASN.1_DN.

 0040—Certificate (CERT) Payload.

 0080—Certificate Request (CERT_REQ) Payload.

 0100—Hash (HASH) Payload: contains the digest output of a particular hash

function.

 0200—Signature (SIG) Payload: contains a digital signature.

 0400—Nonce (Nx) Payload: contains some pseudo-random information

necessary for the exchange).

 0800—Notify Payload.

 1000—ISAKMP Delete Payload.

 2000—Vendor ID (VID) Payload: can be included anywhere in Phase 1

negotiations. ScreenOS uses it to mark support for Network Address
Translation-Traversal (NAT-T).

Each ISAKMP payload begins with the same generic header, as shown in Figure 8.

Figure 8: Generic ISAKMP Payload Header

Next Header Reserved Payload Length (in bytes)

Payload

There can be multiple ISAKMP payloads chained together, with each subsequent
payload type indicated by the value in the Next Header field. A value of 0000
indicates the last ISAKMP payload. See Figure 9 on page 15 for an example.

14  IKE and IPSec Packets

 Chapter 1: Internet Protocol Security

Figure 9: ISAKMP Header with Generic ISAKMP Payloads

Initiator’s SPI

Responder’s SPI (0000 for the first packet)

Next Payload ISAKMP
Maj Ver Min Ver Exchange Type Flags Header
(0002 for SA)
Message ID

Total Message Length

Next Header Reserved SA Payload Length
(0004 for Proposal) SA
Payload
SA Payload
Next Header
(0008 for Transform) Reserved Proposal Payload Length
Proposal
Payload
Proposal Payload
Next Header Reserved Transform Payload Length
(0000 for End) Transform
Payload
Transform Payload

IPSec Packets
After IKE negotiations complete and the two IKE gateways have established Phase 1
and Phase 2 security associations (SAs), the security device applies IPSec protection
to subsequent clear-text IP packets that hosts behind one IKE gateway send to hosts
behind the other gateway (assuming that policies permit the traffic). If the Phase 2
SA specifies the Encapsulating Security Protocol (ESP) in Tunnel mode, the packet
looks like the one shown below. The security device adds two additional headers to
the original packet that the initiating host sends.

NOTE: For information about ESP, see “Encapsulating Security Payload” on page 6. For
information about Tunnel mode, see “Tunnel Mode” on page 4.

Figure 10: IPSec Packet—Encapsulating Security Payload (ESP) in Tunnel Mode

IPSec Packet
Sent by IKE Gateway Original Packet
Sent by Initiating Host
IP2 ESP IP1 TCP
Header Header Header Header Payload

The local gateway adds

these headers to the packet.

As shown in Figure 10, the packet that the initiating host constructs includes the
payload, the TCP header, and the inner IP header (IP1).

The outer IP header (IP2), which the security device adds, contains the IP address of
the remote gateway as the destination IP address and the IP address of the local
security device as the source IP address. The security device also adds an ESP
header between the outer and inner IP headers. The ESP header contains
information that allows the remote peer to properly process the packet when it
receives it. This is illustrated in Figure 11 on page 16.

IKE and IPSec Packets  15

 Concepts & Examples ScreenOS Reference Guide

Figure 11: Outer IP Header (IP2) and ESP Header

Outer IP Header (IP2)

Version Header Type of Service Total Packet Length (in Bytes)

Identification 0 D M Fragment Offset

Time to Live (TTL) Protocol (50 for ESP) Header Checksum

Source Address (Local Peer’s Gateway)

Destination Address (Remote Peer’s Gateway)

IP Options (if any) Padding

Payload

ESP Header

Remote Peer’s Security Parameters Index (SPI)*

Sequence Number*

Initialization Vector* (IV) - First 8 octets of data field Authenticated

Payload Data** (variable)
Encrypted
Padding** (0-255 bytes) Padding Length** Next Header (4 for IP)**

Authentication Data (variable)

* = Authenticated sections of the packet

** = Encrypted sections of the packet

The Next Header field indicates the type of data in the payload field. In Tunnel
mode, this value is 4, indicating IP-in-IP. If ESP is applied in Transport mode, this
value indicates a Transport Layer protocol such as 6 for TCP or 17 for UDP.

16  IKE and IPSec Packets

 Chapter 1: Internet Protocol Security

Figure 12: Inner IP Header (IP1) and TCP Header

Inner IP Header (IP1)

Version Header Type of Service Total Packet Length (in Bytes)

Length
Identification 0 D M Fragment Offset

Time to Live (TTL) Protocol (6 for TCP) Header Checksum

Source Address (Initiating Host)

Destination Address (Receiving Host)

IP Options (if any) Padding

Payload

TCP Header

Source Port Destination Port

Sequence Number

Acknowledgement Number

Header U A P R S F
Length Reserved R C S S Y I Window Size
G K H T N N

Checksum Urgent Pointer

Padding
Options (if any) Padding

Data

IKE Version 2
Juniper Networks security devices support a newer version of the Internet Key
Exchange protocol (IKE), known as IKE version 2 (IKEv2). IKEv2 brings together
various aspects of exchanging keys between IPSec endpoints, such as NAT-T,
extended authentication (xauth), and ISAKMP configuration, into a single protocol
and preserves most of the features of the earlier version, including identity hiding,
PFS, two phases of establishing SAs, and cryptographic negotiation.

IKEv2 performs mutual authentication between two IPSec endpoints and

establishes an IKE SA known as IKE_SA, in which the IPSec endpoints share secret
information to establish SAs for Encapsulating Security Payload (ESP) protocol,
Authentication Header (AH), and a set of cryptographic algorithms to be used to
protect IKE traffic. The SAs for ESP or AH that get set up through the IKE_SA are
called CHILD_SAs.

IKEv2 supports three types of exchanges: initial, CREATE_CHILD_SA, and

informational. Conceptually, IKEv2 IKE_SA and CHILD_SA are equivalent to IKEv1
Phase 1 SA and Phase 2 SA, respectively.

Initial Exchanges
The IPSec endpoints start an IKEv2 SA through an initial exchange. This consists of
two exchanges: IKE_SA_INIT and IKE_AUTH.

IKE and IPSec Packets  17

 Concepts & Examples ScreenOS Reference Guide

IKE_SA_INIT Exchange
An IKE_SA_INIT exchange negotiates security suites, establishes the IKE_SA, and
generates the SKEYSEED from which all keys are derived for the IKE_SA. Separate
keys are computed for each direction. The initiator sends the following:

 HDR—Initiator’s IKE header. The header contains the security parameter

indexes (SPIs), version, and flags.

 SAi1—Cryptographic algorithms the initiator supports for the IKE_SA.

 KEi—Initiator’s Diffie-Hellman value

 Ni—Initiator’s nonce

The responder sends the response to the initiator request with the following:

 HDR—Responder’s header

 SAr1—Cryptographic algorithms the responder supports for the IKE_SA.

 KEr—Responder’s Diffie-Hellman value

 Nr—Responder’s nonce

 [CERTREQ]—[Optional] Certificate request

IKE_AUTH Exchange
The IKE_AUTH exchange authenticates IKE endpoints and establishes the
CHILD_SA. This exchange consists of a single request/response pair. The initiator
starts using the new CHILD_SA immediately after receiving the responder's
response; similarly, the responder starts using the new CHILD_SA immediately after
sending the response to the initiator.

All messages following the initial exchange are cryptographically protected using
the cryptographic algorithms and keys negotiated in the first two messages of the
key exchange. These subsequent messages use the syntax of the encrypted
payload. During the IKE_AUTH exchange, the endpoints exchange the following:

 HDR—Initiator’s header

 IDi—Initiator’s ID

 [CERT]—[Optional] Certificate

 [CERTREQ]—[Optional] Certificate Request

 IDr—Responder’s ID

 AUTH—Authenticates the previous message and the initiator’s identity

 SAi2—Initiator’s SA

 TSi—Initiator’s traffic selector

 TSr—Responder’s traffic selector

18  IKE and IPSec Packets

 Chapter 1: Internet Protocol Security

The responder sends the following response:

 HDR—Responder’s header

 IDr—Initiator’s ID

 [CERT]—[Optional] Certificate

 AUTH—Authenticates the previous message and the initiator’s identity

 SAr2—Responder's SA

 TSi—Initiator’s traffic selector

 TSr—Responder’s traffic selector

Of these messages, except the Header, all other payload are encrypted with the
secret key generated by the endpoints.

CREATE_CHILD_SA Exchange
After the IPSec endpoints complete the initial exchanges, either endpoint can
initiate the CREATE_CHILD_SA. This exchange rekeys a CHILD_SA or IKE_SA. This
exchange consists of a single request/response pair and was referred to as a Phase 2
exchange in IKEv1.

All messages following the initial exchange are cryptographically protected using
the cryptographic algorithms and keys negotiated in the first two messages of the
IKE.

Informational Exchanges
IKEv2 uses informational exchanges to send and receive control messages,
including dead peer detection (DPD).

Enabling IKEv2 on a Security Device

You can configure an existing IKEv1 gateway to support IKEv2. Such a converted
gateway configuration functions only with IKEv2 peers, not IKEv1. When you
configure your security device to support IKEv2, you should note the following
differences between IKEv1 and IKEv2:

 Unlike IKEv1, where the IPSec endpoints negotiate the Diffie-Hellman (DH)
group before agreeing on the DH group number, the IKEv2 initiator sends the
DH group number in the first message of the IKE_INIT_SA exchange. If the
initiator has multiple DH group proposals in its SA payload, the DH group that
the initiator sends may not match the DH group the responder expects. In such
cases, the responder notifies the initiator with the expected DH group number.
The initiator responds to this message with the correct DH group number and
restarts the IKE_INIT_SA exchange.

 The two endpoints in an IKEv2 SA do not negotiate the IKE_SA and CHILD_SA
lifetimes; each endpoint can have its own lifetime. The endpoint with the
shorter lifetime will rekey before the current IKE_SA or CHILD_SA expires (by
default, 10 seconds earlier for IKE_SA and 60 seconds earlier for CHILD_SA), as
long as the connection between the endpoints still needs this IKE_SA or

IKE and IPSec Packets  19

 Concepts & Examples ScreenOS Reference Guide

CHILD_SA. A CHILD_SA is considered no longer needed when there has been

no traffic since the last rekey or the SA has timed out. An IKE_SA is no longer
needed when all its CHILD_SAs are no longer needed.

 Authentication methods between the two negotiating IKE peers can be

different; the endpoints do not negotiate the authentication methods.

 All CHILD_SAs close if their parent IKE_SA is closed.

 The two endpoints maintain only one IKE_SA; all other exchanges are carried
out through CHILD_SAs.

Example: Configuring an IKEv2 Gateway

In the example shown in Figure 13, you create two VPN tunnels that use IKEv2 for
automatic generation and negotiation of keys and security associations (SAs). These
tunnels provide a secure connection between the two devices - Device B and Device
A. A policy-based VPN is configured on Device A, while a route-based VPN is
configured on Device B. For the Phase 1 and Phase 2 security levels, you specify
standard and basic predefined proposals, respectively, on both the devices.

Figure 13: IKEv2 Gateway Connecting Two Security Devices

Trust:10.10.0.1/16 Untrust: 201.23.0.3/24

Tunnel.10
Ethernet3/1 Ethernet3/2

External Router

Internet
LAN LAN
Device A Device B

External Router
Ethernet0/1
Ethernet0/2
Tunnel.10

Untrust: 201.12.0.1/24 Trust: 10.30.0.3/16

20  IKE and IPSec Packets

 Chapter 1: Internet Protocol Security

WebUI (Device A)
1. Configuring the IKEv2 Gateway
VPNs > AutoKey Advanced > Gateway > New: Enter the following, then click
OK:

Gateway Name: Device B

Version:
IKEv2: (select)
Remote Gateway:
Static IP Address: (select), IPv4 Address/Hostname: 201.23.0.3

> Advanced: Enter the following, then click Return to set the advanced
options and return to the basic configuration page:

IKEv2 Auth Method: Enable

Self: rsa-sig
Peer: preshare
Preshared Key: GsbBPO0MNXYgXGsOetCXf8qaR8n5AUVlLQ==
Outgoing interface: ethernet3/2
Security Level:
Predefined: (select, Standard)
Preferred Certificate (optional)
Local cert: CN=but CN=nsisg2000.netscreen.com.CN=rsa-key.CN
Peer CA: OU=Secure Server Certification Authority.O=RSA
Peer Type: X509-SIG
2. Configuring the VPN
VPNs > Autokey IKE > New: Enter the following, then click Advanced:

VPN Name: Device B

Remote Gateway: (select)
Predefined: (select), Device B

> Advanced: Enter the following advanced settings, then click Return to set
the advanced options and return to the basic configuration page:

Security Level
Predefined: (select, Basic)
3. Configuring the Route
Network > Routing > Routing Entries > Configuration: Enter the following,
then click OK:

Virtual Router name: untrust-vr

IP Address / Netmask: 10.30.0.3/16
Next Hop: Gateway (select)
Interface: ethernet3/2
4. Creating Policies
Policy > Policies (From: Untrust, To: Trust) New: Enter the following, then click
OK:

Source Address:
New Address: 10.30.0.3/16
Destination Address:
New address: 10.10.0.1/16
Service: (select), Any

IKE and IPSec Packets  21

 Concepts & Examples ScreenOS Reference Guide

Action: (select), Tunnel

Tunnel: (select), Device B

Policy > Policies (From: Trust, To: Untrust) New: Enter the following, then click
OK:

Source Address:
New Address: 10.10.0.1/16
Destination Address:
New address: 10.30.0.3/16
Service: (select), Any
Action: (select), Tunnel
Tunnel: (select), Device B

WebUI (Device B)
1. Configuring the IKEv2 Gateway
VPNs > AutoKey Advanced > Gateway > New: Enter the following, then click
OK:

Gateway Name: Device A

Version:
IKEv2: (select)
Remote Gateway:
Static IP Address: (select), IPv4 Address/Hostname: 201.12.0.1

> Advanced: Enter the following, then click Return to set the advanced
options and return to the basic configuration page:

IKEv2 Auth Method: Enable

Self: preshare
Peer: rsa-sig
Preshared Key: 3to5BAFpNn3thBsncQCmBYF5ThnQVfMlEQ==
Outgoing interface: ethernet0/2
Security Level:
Predefined: (select, Standard)
Preferred Certificate (optional)
Local cert: None
Peer CA: CN=netscreen.OU=qa
Peer Type: X509-SIG
2. Configuring the Tunnel Interface
Network > Interfaces > New: Enter the following, then click OK:

Tunnel Interface Name: tunnel.10

Zone (VR): Untrust (trust-vr)
Unnumbered: (select)
Interface: ethernet0/2 (trust-vr)
3. Configuring the VPN and Proxy-ID
VPNs > Autokey IKE > New: Enter the following, then click Advanced:

VPN Name: Device A

Remote Gateway: (select)
Predefined: (select), Device A

> Advanced: Enter the following advanced settings, then click Return to set
the advanced options and return to the basic configuration page:

22  IKE and IPSec Packets

 Chapter 1: Internet Protocol Security

Security Level
Predefined: (select, Basic)
Bind to: Tunnel Interface (select): Select tunnel.10, Untrust-Tun from the
drop-down list

Proxy-ID: (select)
Local IP / Netmask: 10.30.0.0/16
Remote IP / Netmask: 10.10.0.0/16
Service: ANY
4. Configuring the Route
Network > Routing > Routing Entries > Configuration: Enter the following,
then click OK:

Virtual Router name: trust-vr

IP Address / Netmask: 10.10.0.1/16
Next Hop: Gateway (select)
Interface: tunnel.10

CLI (Device A)
1. Configuring Addresses
set address trust 10.10.0.1 10.10.0.1/16
set address untrust 10.30.0.3 10.30.0.3/16
2. Configuring the IKEv2 Gateway
set ike gateway ikev2 "Device B" address 201.23.0.3 outgoing-interface
"ethernet3/2" preshare "GsbBPO0MNXYgXGsOetCXf8qaR8n5AUVILQ=="
proposal "standard"
set ike gateway ikev2 "Device B" auth-method self rsa-sig peer preshare
set ike gateway ikev2 "Device B" cert my-cert-hash
361A26F4CDE8696D10FF1C767D00AD8CCC3BF4CE
set ike gateway ikev2 "Device B" cert peer-ca-hash
0E9290B27AA8BAF65D3C9229AFE8F31DB953B2DA

NOTE: The local and peer certificates are generated by the device. The certificates will not
work if you copy this part to the device.

3. Setting the IKE_SA Soft Lifetime

set ike ikev2 ike-sa-soft-lifetime 60
4. Configuring the VPN
set vpn "Device B" gateway "Device B" no-replay tunnel idletime 0 proposal
"basic"
5. Configuring the Route
set route 10.30.0.3/16 interface ethernet3/2
6. Configuring Policies
set policy id 4 from untrust to trust 10.30.0.3 10.10.0.1 any tunnel vpn
"Device B" id 0x1 pair-policy 3
set policy id 3 from trust to untrust 10.10.0.1 10.30.0.3 any tunnel vpn
"Device B" id 0x1 pair-policy 4

IKE and IPSec Packets  23

 Concepts & Examples ScreenOS Reference Guide

CLI (Device B)
1. Configuring the IKEv2 Gateway
set ike gateway ikev2 "Device A" address 201.12.0.1 outgoing-interface
"ethernet0/2" preshare "3to5BAFpNn3thBsncQCmBYF5ThnQVfMlEQ=="
proposal "standard"
set ike gateway ikev2 "Device A" auth-method self preshare peer rsa-sig
set ike gateway ikev2 "Device A" cert peer-ca-hash
5BA819E4775F1DBAB039C48A0DAE21583DC5A916
2. Configuring the VPN
set vpn "Device A" gateway "Device A" no-replay tunnel idletime 0 proposal
"basic"
3. Binding the VPN to a Tunnel
set vpn "Device A" id 0x2 bind interface tunnel.10
4. Creating a VPN Proxy Configuration
set vpn "Device A" proxy-id local-ip 10.30.0.0/16 remote-ip 10.10.0.0/16 any
5. Configuring the Route
set route 10.10.0.1/16 interface tunnel.10
6. Setting Policy Permit
set policy id 4 from untrust to trust 10.30.0.3 10.10.0.1 any permit
set policy id 3 from trust to untrust 10.10.0.1 10.30.0.3 any permit

Authentication Using Extensible Authentication Protocol

In addition to supporting authentication using public key signatures and shared
secrets, IKEv2 supports authentication using Extensible Authentication Protocol
(EAP). By using EAP, IKEv2 can leverage existing authentication infrastructure and
credential databases, because EAP allows users to choose a method suitable for
existing credentials and provides an easy means of separation of the IKEv2
responder (VPN gateway) from the RADIUS server that acts as the EAP
authentication endpoint.

Juniper Networks security devices support authentication using EAP in the following
ways:

 Security device as the VPN gateway—When the security device acts as the
VPN gateway, it provides only EAP passthrough and supports a RADIUS server
as the authentication server. In this implementation, the security device
supports EAP-Message Digest 5 (EAP-MD5), EAP-Transport Layer Security
(EAP-TLS), EAP-Tunneled TLS (EAP-TTLS), and EAP-Protected EAP (EAP-PEAP)
passthrough. The security device neither times out for the connections nor
provides accounting support.

 Security device as the VPN client—When the security device acts as the VPN
client, it supports only the EAP-MD5 supplicant (client) functionality for IKEv2.

24  IKE and IPSec Packets

 Chapter 1: Internet Protocol Security

IKEv2 EAP Passthrough

When you enable a Juniper Networks security device to use EAP to authenticate a
client with a RADIUS authentication server, the security device acts as a proxy
(authenticator) and passes the EAP messages between the client (supplicant) and
the RADIUS (authentication) server. During EAP exchanges, the security device
decapsulates the EAP messages in IKEv2 messages from the peer, encapsulates
them into RADIUS messages, and sends them to the RADIUS server.

When the RADIUS server responds to the authentication requests, the security
device decapsulates the EAP messages, encapsulates them into IKEv2 messages,
and sends them to the peer. After the RADIUS server has authenticated the client, if
there is a shared secret generated during the exchange, the security device extracts
the shared secret from the RADIUS Access-Accept message and uses it to generate
the AUTH payload. In this way, the security device passes the EAP messages
between a client and an authentication server.

Example
The following example explains the steps involved in setting up IKEv2 EAP
authentication for an authenticator and a supplicant.

Figure 14: Setting Up IKEv2 EAP Authentication

RADIUS

PKI

2.2.2.1

Authenticator (M)

20.20.20.1

PC 1 1.1.1.1 Supplicant 10.10.10.1 PC 2

Internet HA
10.10.10.2
1.1.1.100 Authenticator (B) 2.2.2.100

20.20.20.2

You can set up the IKEv2 EAP using the WebUI or the CLI.

WebUI (Authenticator)
1. Setting Up Auth-Server
Select Configuration > Auth > Auth Servers > New: Enter the following, then
click OK:

Name: rad1
Auth-server IP address: 10.155.43.201
RADIUS secret: netscreen
Account Type: IKEv2EAP (check)

IKE and IPSec Packets  25

 Concepts & Examples ScreenOS Reference Guide

2. Setting Up IKE
Select VPN >AutoKey Advanced >Gateway >New: Enter the following, then
click OK:

Gateway Name: v2-gw3

Version: IKEv2 (select)
IP address of the remote gateway: 10.10.10.1

> Click Advanced. Configure the following advanced setting, then click
Return to return to the basic Gateway configuration page:

Phase1 Proposal (select): rsa-g2-3des-sha

Select VPN >AutoKey Advanced >Gateway >EAP: Perform the following

actions:

IKEv2 EAP authentication: (check)

Authenticator: (select)
Auth-server name: rad1
Send-id-Req: (check)

Select VPN >AutoKey Advanced > Gateway >Edit: Perform the following
actions, then click OK:

edit on the gateway (select)

> Click Advanced. Configure the following advanced settings, then click
Return to return to the basic Gateway configuration page:

IKEv2 Auth: (check)

self: rsa-sig
peer:eap
Outgoing interface: loopback.3
Local cert: my-cert 1

CLI (Authenticator)
1. Auth-Server Configuration
set auth-server "rad1" server-name "10.155.43.201"
set auth-server "rad1" account-type eap-ikev2
set auth-server "rad1" radius secret netscreen
2. IKE Configuration
set ike gateway ikev2 "v2-gw3" dialup "Peer2" outgoing-interface "loopback.3"
preshare abcd1234 proposal "rsa-g2-3des-sha"
set ike gateway ikev2 "v2-gw3" cert my-cert 1
set ike gateway ikev2 "v2-gw3" cert peer-ca all
set ike gateway ikev2 v2-gw3 eap authenticator passthrough rad1 send-id-req
set ike gateway ikev2 "v2-gw3" auth-method self rsa-sig peer eap
set vpn "v2-vpn3" gateway "v2-gw3" no-replay tunnel idletime 0 proposal
"g2-esp-3des-sha"

WebUI (Supplicant)
1. Setting Up IKE
Select VPN > AutoKey Advanced > Gateway>New: Enter the following, then
click OK:

26  IKE and IPSec Packets

 Chapter 1: Internet Protocol Security

Gateway Name: v2-gw3

Version: IKEv2 (select)
IP address of the remote gateway: 20.20.20.1

> Click Advanced. Configure the following advanced setting, then click
Return to return to the basic Gateway configuration page:

Phase1 Proposal (select): rsa-g2-3des-sha

Select VPN >AutoKey Advanced > Gateway > Edit: Perform the following
actions, then click OK:

Gateway: (select)

> Click Advanced. Configure the following advanced setting, then click
Return to return to the basic Gateway configuration page:

IKEv2 Auth: (check)

self: eap
peer: rsa-sig
Outgoing interface: loopback.3
Local cert: my-cert 1

CLI (Supplicant)
IKE Configuration
set ike gateway ikev2 "v2-gw3" address 203.203.203.1 local-id
"[email protected]" outgoing-interface "loopback.3" preshare abcd1234
proposal "rsa-g2-3des-sha"
set ike gateway ikev2 "v2-gw3" cert my-cert 1
set ike gateway ikev2 "v2-gw3" cert peer-ca all
set ike gateway ikev2 v2-gw3 eap supplicant md5 username test1 password abcd1
set ike gateway ikev2 "v2-gw3" auth-method self eap peer rsa-sigset vpn “v2-vpn3”
gateway “v2-gw3” no-replay tunnel idleitem 0 proposal “g2-esp-3des-sha”

IKE and IPSec Packets  27

 Concepts & Examples ScreenOS Reference Guide

28  IKE and IPSec Packets

Chapter 2
Public Key Cryptography

This chapter provides an introduction to public key cryptography and the use of
certificates and certificate revocation lists (CRLs) within the context of Public Key
Infrastructure (PKI). This chapter includes the following topics:

 “Introduction to Public Key Cryptography” on page 30

 “Signing a Certificate” on page 30

 “Verifying a Digital Signature” on page 30

 “Public Key Infrastructure” on page 32

 “Certificates and CRLs” on page 34

 “Loading Certificates and Certificate Revocation Lists” on page 38

 “Configuring CRL Settings” on page 39

 “Obtaining a Local Certificate Automatically” on page 40

 “Automatic Certificate Renewal” on page 43

 “Online Certificate Status Protocol” on page 44

 “Key-Pair Generation” on page 44

 “Specifying a Certificate Revocation Check Method” on page 45

 “Specifying an Online Certificate Status Protocol Responder URL” on

page 46

 “Self-Signed Certificates” on page 47

 “Removing Status Check Attributes” on page 46

 “Manually Creating Self-Signed Certificates” on page 49

 “Setting an Admin-Defined Self-Signed Certificate” on page 50

 “Deleting Self-Signed Certificates” on page 55

 29
 Concepts & Examples ScreenOS Reference Guide

Introduction to Public Key Cryptography

In public key cryptography, a public/private key pair is used to encrypt and decrypt
data. Data encrypted with a public key, which the owner makes available to the
public, can only be decrypted with the corresponding private key, which the owner
keeps secret and protected. For example, if Alice wants to send Bob an encrypted
message, Alice can encrypt it with Bob’s public key and send it to him. Bob then
decrypts the message with his private key.

The reverse is also useful; that is, encrypting data with a private key and decrypting
it with the corresponding public key. This is known as creating a digital signature.
For example, if Alice wants to present her identity as the sender of a message, she
can encrypt the message with her private key and send the message to Bob. Bob
then decrypts the message with Alice’s public key, thus verifying that Alice is indeed
the sender.

Public/private key pairs also play an important role in the use of digital certificates.
The procedure for signing a certificate (by a CA) and then verifying the signature (by
the recipient) works as shown in the following subsections.

Signing a Certificate
1. The Certificate Authority (CA) that issues a certificate hashes the certificate by
using a hash algorithm (MD5 or SHA-1) to generate a digest.

2. The CA then “signs” the certificate by encrypting the digest with its private key.
The result is a digital signature.

3. The CA then sends the digitally signed certificate to the person who requested
it.

Verifying a Digital Signature

1. When the recipient gets the certificate, the recipient also generates another
digest by applying the same hash algorithm (MD5 or SHA-1) on the certificate
file.

2. The recipient uses the CA’s public key to decrypt the digital signature.

3. The recipient compares the decrypted digest with the digest just generated. If
the two match, the recipient can confirm the integrity of the CA’s signature and,
by extension, the integrity of the accompanying certificate.

30  Introduction to Public Key Cryptography

 Chapter 2: Public Key Cryptography

Figure 15: Digital Signature Verification

Sender (CA)

1. Using either the MD5 or SHA-1 hash algorithm, the CA makes Digest A
digest A from the certificate. Cert
Hash Algorithm
2. Using the its private key, the CA encrypts digest A. The result is (MD5 or SHA-1)
digest B, the digital signature.

3. The CA sends the digitally signed certificate to the person who

requested it. Digest B

CA’s Private Key

Recipient

1. Using either MD5 or SHA-1, the recipient makes digest A from the Digest A Cert
certificate.
Compare Hash Algorithm
2. Using the CA’s public key, the recipient decrypts digest B. (MD5 or SHA-1)
3. The recipient compares digest A with digest B. If they match, the
recipient knows that the certificate has not been tampered with.
Digest B

CA’s Private Key

The procedure for digitally signing messages sent between two participants in an
IKE session works very similarly, with the following differences:

 Instead of making a digest from the CA certificate, the sender makes it from the
data in the IP packet payload.

 Instead of using the CA’s public/private key pair, the participants use the
sender’s public/private key pair.

Introduction to Public Key Cryptography  31

 Concepts & Examples ScreenOS Reference Guide

Public Key Infrastructure

Public Key Infrastructure (PKI) refers to the hierarchical structure of trust required
for the successful implementation of public key cryptography. To verify the
trustworthiness of a certificate, you must be able to track a path of certified CAs
from the one issuing your local certificate back to a root authority of a CA domain.

Figure 16: PKI Hierarchy of Trust—CA Domain

The root-level CA validates subordinate CAs.

Subordinate CAs validate

local certificates and other
CAs.

Local certificates contain

the user’s public key.

32  Public Key Infrastructure

 Chapter 2: Public Key Cryptography

If certificates are used solely within an organization, that organization can have its
own CA domain within which a company CA issues and validates certificates
among its employees. If that organization later wants its employees to be able to
exchange their certificates with those from another CA domain (for example, with
employees at another organization that also has its own CA domain), the two CAs
can develop cross-certification; that is, they can agree to trust the authority of each
other. In this case, the PKI structure does not extend vertically but does extend
horizontally.

Figure 17: Cross-Certification

CA Domain – A CA Domain – B

Cross-certification

Users in CA domain A can use their certificates and key pairs with users
in CA domain B because the CAs have cross-certified each other.

For convenience and practicality, the PKI must be transparently managed and
implemented. Toward this goal, ScreenOS does the following:

1. Generates a public/private key pair when you create a certificate request.

2. Supplies that public key as part of the certificate request in the form of a text
file for transmission to a Certificate Authority (CA) for certificate enrollment
(PKCS10 file).

3. Supports loading the local certificate, the CA certificate, and the certificate
revocation list (SubinterfaceCRL) into the unit.

NOTE: The Certificate Authority usually provides a CRL. Although you can load a CRL into
the security device, you cannot view it once loaded.

You can also specify an interval for refreshing the CRL online. For more
information about CRLs, see “Certificates and CRLs” on page 34.

4. Provides certificate delivery when establishing an IPSec tunnel.

5. Supports certificate path validation upward through eight levels of CA

authorities in the PKI hierarchy.

Public Key Infrastructure  33

 Concepts & Examples ScreenOS Reference Guide

6. Supports the PKCS #7 cryptographic standard, which means the security device
can accept X.509 certificates and CRLs packaged within a PKCS #7 envelope.
PKCS #7 support allows you to submit multiple X.509 certificates within a
single PKI request. You can now configure PKI to validate all the submitted
certificates from the issuing CA at one time.

NOTE: ScreenOS supports a PKCS #7 file size of up to 7 Kilobytes.

7. Supports online CRL retrieval through LDAP or HTTP.

Certificates and CRLs

A digital certificate is an electronic means for verifying your identity through the
word of a trusted third party, known as a Certificate Authority (CA). The CA server
you use can be owned and operated by an independent CA or by your own
organization, in which case you become your own CA. If you use an independent
CA, you must contact them for the addresses of their CA and CRL servers (for
obtaining certificates and certificate revocation lists) and for the information they
require when submitting personal certificate requests. When you are your own CA,
you determine this information yourself.

NOTE: ScreenOS supports the following CAs: Baltimore, Entrust, Microsoft, Netscape, RSA
Keon, and Verisign.

ScreenOS contains a CA certificate for authenticating downloads from the

antivirus (AV) pattern file server and the Deep Inspection (DI) attack object
database server. For more information about the AV pattern file server, see
“Antivirus Scanning” on page 4-62. For more information about the DI attack
object database server, see “Attack Object Database Server” on page 4-122.

To use a digital certificate to authenticate your identity when establishing a secure

VPN connection, you must first do the following:

 Generate a key in the security device, send it to a CA to obtain a personal

certificate (also known as a local certificate), and load the certificate in the
security device.

 Obtain a CA certificate for the CA that issued the personal certificate (basically
verifying the identity of the CA verifying you), and load the CA certificate in the
security device. You can perform this task manually, or you can perform this
task automatically using Simple Certificate Enrollment Protocol (SCEP).

 If the certificate does not contain a certificate distribution point (CDP)

extension, and you cannot automatically retrieve the CRL through LDAP or
HTTP, you can retrieve a CRL manually and load that in the security device.

34  Certificates and CRLs

 Chapter 2: Public Key Cryptography

During the course of business, there are several events that make it necessary to
revoke a certificate. You might wish to revoke a certificate if you suspect that it has
been compromised or when a certificate holder leaves a company. Managing
certificate revocations and validation can be accomplished locally (which is a
limited solution) or by referencing a CA’s CRL, which you can automatically access
online at daily, weekly, or monthly intervals or at the default interval set by the CA.

To obtain a signed digital certificate using the manual method, you must complete
several tasks in the following order:

1. Generate a public/private key pair.

2. Fill out the certificate request.

3. Submit your request to your CA of choice.

4. After you receive your signed certificate, you must load it into the security
device along with the CA certificate.

You now have the following items for the following uses:

 A local certificate for the security device, to authenticate your identity with each
tunnel connection

 A CA Certificate (their public key), to be used to verify the peer’s certificate

 If the Certificate Revocation List (CRL) was included with the CA certificate, a
CRL to identify invalid certificates

NOTE: A CRL might accompany a CA certificate and be stored in the ScreenOS database.
Alternatively, the CA certificate might contain the CRL URL (either LDAP or HTTP)
for a CRL that is stored in the CA’s database. If the CRL is unobtainable by either
method, you can manually enter a CRL URL in the security device, as explained in
“Configuring CRL Settings” on page 39.

When you receive these files (the certificate files typically have the extension .cer,
and the CRL typically has the extension .crl), load them into your security device
using the procedure described in “Requesting a Certificate Manually” on page 36.

NOTE: If you are planning to use email to submit a PKCS10 file to obtain your certificates,
you must properly configure your ScreenOS settings so that you can send email to
your system administrator. You have to set your primary and secondary DNS
servers and specify the SMTP server and email address settings.

Certificates and CRLs  35

 Concepts & Examples ScreenOS Reference Guide

Requesting a Certificate Manually

When you request a certificate, the security device generates a key pair. The public
key becomes incorporated in the request itself and, eventually, in the digitally
signed local certificate you receive from the CA.

In the following example, the security administrator is making a certificate request

for Michael Zhang in the Development department at Juniper Networks in
Sunnyvale, California. The certificate is going to be used for a security device at IP
address 10.10.5.44. The administrator instructs the security device to send the
request through email to the security administrator at [email protected]. The
security administrator then copies and pastes the request in the certificate request
text field at the CA’s certificate enrollment site. After the enrollment process is
complete, the CA usually sends the certificates through email back to the security
administrator.

NOTE: A special certificate identity string, called domain-component, is available only

through the CLI. Devices can use this value in certificates for IPSec logon to VPN
gateways. For example, the device could use this as a Group IKE ID, accepting
ASN1_DN type IKE identities containing "DC=Engineering, DC=NewYork".

Before generating a certificate request, make sure that you have set the system
clock and assigned a hostname and domain name to the security device. (If the
security device is in an NSRP cluster, replace the hostname with a cluster name.
For more information, see “Creating an NSRP Cluster” on page 11-29.)

WebUI
1. Certificate Generation
Objects > Certificates > New: Enter the following, then click Generate:

Name: Michael Zhang

Phone: 408-730-6000
Unit/Department: Development
Organization: Juniper Networks
County/Locality: Sunnyvale
State: CA
Country: US
E-mail: [email protected]
IP Address: 10.10.5.44
Write to file: (select)
RSA: (select)
Create new key pair of 1024 length: (select)

The device generates a PKCS #10 file and prompts you to send the file through
email, save the file to disk, or automatically enroll through the Simple
Certificate Enrollment Protocol (SCEP).

Select the E-mail to option, type [email protected], then click OK.

36  Certificates and CRLs

 Chapter 2: Public Key Cryptography

NOTE: Some CAs do not support an email address in a certificate. If you do not include an
email address in the local certificate request, you cannot use an email address as
the local IKE ID when configuring the security device as a dynamic peer. Instead,
you can use a fully qualified domain name (if it is in the local certificate), or you
can leave the local ID field empty. By default the security device sends its
hostname.domainname. If you do not specify a local ID for a dynamic peer, enter
the hostname.domainname of that peer on the device at the other end of the IPSec
tunnel in the peer ID field.

The value 1024 indicates the bit length of the key pair. If you are using the
certificate for SSL (see “Secure Sockets Layer” on page 3-5), be sure to use a bit
length that your browser also supports.

Using the email address assumes that you have already configured the IP address
for your SMTP server: set admin mail server-name { ip_addr | dom_name }.

2. Certificate Request
The security administrator opens the file and copies its contents, taking care to
copy the entire text but not any blank spaces before or after the text. (Start at
“-----BEGIN CERTIFICATE REQUEST-----”, and end at “-----END CERTIFICATE
REQUEST-----”.)

The security administrator then follows the certificate request directions at the
CA’s website, pasting the PKCS #10 file in the appropriate field when required.

3. Certificate Retrieval
When the security administrator receives the certificate from the CA through
email, the administrator forwards it to you. Copy it to a text file, and save it to
your workstation (to be loaded to the security device later through the WebUI)
or to a TFTP server (to be loaded later through the CLI).

CLI
1. Certificate Generation
set pki x509 dn country-name US
set pki x509 dn email [email protected]
set pki x509 dn ip 10.10.5.44
set pki x509 dn local-name “Santa Clara”
set pki x509 dn name “Michael Zhang”
set pki x509 dn org-name “Juniper Networks”
set pki x509 dn org-unit-name Development
set pki x509 phone 408-730-6000
set pki x509 dn state-name CA
set pki x509 default send-to [email protected]
exec pki rsa new-key 1024

NOTE: Using the email address assumes that you have already configured the IP address
for your SMTP server: set admin mail server-name { ip_addr | dom_name }.

The certificate request is sent through email to [email protected].

Certificates and CRLs  37

 Concepts & Examples ScreenOS Reference Guide

2. Certificate Request
The security administrator opens the file and copies its contents, taking care to
copy the entire text but not any blank spaces before or after the text. (Start at
“-----BEGIN CERTIFICATE REQUEST-----”, and end at “-----END CERTIFICATE
REQUEST-----”.)

The security administrator then follows the certificate request directions at the
CA’s website, pasting the PKCS #10 file in the appropriate field when required.

3. Certificate Retrieval
When the security administrator receives the certificate from the CA through
email, the administrator forwards it to you. Copy it to a text file, and save it to
your workstation (to be loaded to the security device later through the WebUI)
or to a TFTP server (to be loaded later through the CLI).

Loading Certificates and Certificate Revocation Lists

The CA returns the following three files to you for loading onto the security device:

 A CA certificate, which contains the CA’s public key

 A local certificate that identifies your local machine (your public key)

 A CRL, which lists any certificates revoked by the CA

For the WebUI example, you have downloaded the files to a directory named
C:\certs\ns on the administrator’s workstation. For the CLI example, you have
downloaded the TFTP root directory on a TFTP server with IP address 198.168.1.5.

NOTE: Juniper Networks security devices (including virtual systems) configured with
ScreenOS 2.5 or later support loading multiple local certificates from different
CAs.

This example illustrates how to load two certificate files named auth.cer (CA
certificate) and local.cer (your public key), along with the CRL file named
distrust.crl.

WebUI
1. Objects > Certificates: Select Load Cert, then click Browse.

2. Navigate to the C:\certs directory, select auth.cer, then click Open.

The directory path and filename (C:\certs\ns\auth.cer) appear in the File Browse
field.

3. Click Load.

The auth.cer certificate file loads.

4. Objects > Certificates: Select Load Cert, then click Browse.

38  Certificates and CRLs

 Chapter 2: Public Key Cryptography

5. Navigate to the C:\certs directory, select local.cer, then click Open.

The directory path and filename (C:\certs\ns\local.cer) appear in the File Browse
field.

6. Click Load.

The auth.cer certificate file loads.

7. Objects > Certificates: Select Load CRL, then click Browse.

8. Navigate to the C:\certs directory, select distrust.crl, then click Open.

9. Click Load.

The distrust.crl CRL file loads.

CLI
exec pki x509 tftp 198.168.1.5 cert-name auth.cer
exec pki x509 tftp 198.168.1.5 cert-name local.cer
exec pki x509 tftp 198.168.1.5 crl-name distrust.crl

Configuring CRL Settings

In Phase 1 negotiations, participants check the CRL list to see if certificates received
during an IKE exchange are still valid. If a CRL is not loaded in the ScreenOS
database, the security device tries to retrieve the CRL through the LDAP or HTTP
CRL location defined within the certificate itself. If there is no URL defined in the
certificate, the security device uses the URL of the server that you define for that CA
certificate. If you do not have the CA certificate loaded in the device (for example,
an intermediate CA of the certificate chain received during IKE exchange), you
cannot resolve the CRL server URL for that CA. In this case, you can specify the CRL
server URL in the Default Cert Validation Settings section of the WebUI (see the next
page). A CRL server URL entered here is used only when the CA certificate is not
present in the device. There is no pre-defined default URL.

NOTE: The CRL distribution point extension (.cdp) in an X509 certificate can be either an
HTTP URL or an LDAP URL.

With ScreenOS 2.5 and later, you can disable the checking of a CRL’s digital
signature when you load the CRL. However, disabling CRL certificate checking
compromises the security of your device.

In this example, you first configure the Entrust CA server to check the CRL daily by
connecting to the LDAP server at 2.2.2.121 and locating the CRL file. You then
configure default certificate-validation settings to use the company’s LDAP server at
10.1.1.200, also checking the CRL every day.

NOTE: The index (IDX) number for the Entrust CA certificate is 1. To view a list of the IDX
numbers for all the CA certificates loaded on a security device, use the following
CLI command: get pki x509 list ca-cert.

Certificates and CRLs  39

 Concepts & Examples ScreenOS Reference Guide

WebUI
Objects > Certificates (Show: CA) > Server Settings (for NetScreen): Enter the
following, then click OK:

X509 Cert_Path Validation Level: Full

CRL Settings:
URL Address: ldap:///CN=Entrust,CN=en2001,CN=PublicKeyServices,
CN=Services,CN=Configuration,DC=EN2001,DC=com?CertificateRevocati
onList?base?objectclass=CRLDistributionPoint
LDAP Server: 2.2.2.121
Refresh Frequency: Daily

Objects > Certificates > Default Cert Validation Settings: Enter the following,
then click OK:

X509 Certificate Path Validation Level: Full

Certificate Revocation Settings:
Check Method: CRL
URL Address:
ldap:///CN=NetScreen,CN=safecert,CN=PublicKeyServices,
CN=Services,CN=Configuration,DC=SAFECERT,DC=com?CertificateRevoc
ationList?base?objectclass=CRLDistributionPoint
LDAP Server: 10.1.1.200

CLI
set pki authority 1 cert-path full
set pki authority 1 cert-status crl url “ldap:///CN=Entrust,CN=en2001,
CN=PublicKeyServices,CN=Services,CN=Configuration,DC=EN2000,DC=com?
CertificateRevocationList?base?objectclass=CRLDistributionPoint”
set pki authority 1 cert-status crl server-name 2.2.2.121
set pki authority 1 cert-status crl refresh daily
set pki authority default cert-path full
set pki authority default cert-status crl url “ldap:///CN=NetScreen,
CN=safecert,CN=PublicKeyServices,CN=Services,CN=Configuration,DC=SAFE
CERT,
DC=com?CertificateRevocationList?base?objectclass=CRLDistributionPoint”
set pki authority default cert-status crl server-name 10.1.1.200
set pki authority default cert-status crl refresh daily
save

Obtaining a Local Certificate Automatically

To use a digital certificate to authenticate your identity when establishing a secure
VPN connection, you must first do the following:

 Obtain a certificate authority (CA) certificate from which you intend to obtain a
personal certificate, and then load the CA certificate in the security device.

 Obtain a local certificate (also known as a personal certificate) from the CA

whose CA certificate you have previously loaded, and then load the local
certificate in the security device. You can perform this task manually, or
automatically using Simple Certificate Enrollment Protocol (SCEP).

Because the manual method of requesting local certificates has steps requiring you
to copy information from one certificate to another, it can be a somewhat lengthy
process. To bypass these steps, you can use the automatic method.

40  Certificates and CRLs

 Chapter 2: Public Key Cryptography

Note that, before using SCEP, you must perform the following tasks:

 Configure and enable DNS. (See “Domain Name System Support” on

page 2-217.)

 Set the system clock. (See “System Clock” on page 2-253.)

 Assign a hostname and domain name to the security device. (If the security
device is in an NSRP cluster, replace the hostname with a cluster name. For
more information, see “Creating an NSRP Cluster” on page 11-29.)

In this example, you use the automatic method to request a local certificate. You use
SCEP with the Verisign CA. You set the following CA settings:

 Full certificate path validation

 RA CGI: http://ipsec.verisign.com/cgi-bin/pkiclient.exe

NOTE: The Common Gateway Interface (CGI) is a standard way for a webserver to pass a
user request to an application program and to receive data back. CGI is part of the
HyperText Transfer Protocol (HTTP). You must specify an RA CGI path even if the
RA does not exist. If the RA does not exist, use the value specified for the CA CGI.

 CA CGI: http://ipsec.verisign.com/cgi-bin/pkiclient.exe

 Automatic integrity confirmation of CA certificates

 CA ID, which identifies a SCEP server, where Verisign SCEP server uses a
domain name, such as juniper.net or a domain set up by Verisign for your
company

 Challenge password

 Automatic certificate polling every 30 minutes (the default is no polling)

You then generate an RSA key pair, specifying a key length of 1024 bits, and initiate
the SCEP operation to request a local certificate from the Verisign CA with the above
CA settings.

When using the WebUI, you refer to CA certificates by name. When using the CLI,
you refer to CA certificates by index (IDX) number. In this example, the IDX number
for the Verisign CA is “1.” To see the IDX numbers for CA certificates, use the
following command: get pki x509 list ca-cert. The output displays an IDX number
and an ID number for each certificate. Note the IDX number and use that when
referencing the CA certificate in commands.

Certificates and CRLs  41

 Concepts & Examples ScreenOS Reference Guide

WebUI
1. CA Server Settings
Objects > Certificates > Show CA > Server Settings (for Verisign): Enter the
following, then click OK:

X509 certificate path validation level: Full

SCEP Settings:
RA CGI: http://ipsec.verisign.com/cgi-bin/pkiclient.exe
CA CGI: http://ipsec.verisign.com/cgi-bin/pkiclient.exe

> Advanced: Enter the following advanced settings, then click Return to
return to the basic CA Server Settings configuration page:

Polling Interval: 30
Certificate Authentication: Auto
Certificate Renew: 14
2. Local Certificate Request
Objects > Certificates > New: Enter the following, then click Generate:

Name: Michael Zhang

Phone: 408-730-6000
Unit/Department: Development
Organization: Juniper Networks
County/Locality: Sunnyvale
State: CA
Country: US
Email: [email protected]
IP Address: 10.10.5.44
Key Pair Information
RSA: (select)
Create new key pair of 1024 length.

NOTE: The value 1024 indicates the bit length of the key pair. If you are using the
certificate for SSL, be sure to use a bit length that your browser also supports.

Issue the get pki x509 pkcs CLI command to have the security device generate
a PKCS #10 file and then, do one of the following:

 Send the PKCS #10 certificate request file to an email address

 Save it to disk

 Automatically enroll by sending the file to a CA that supports the Simple

Certificate Enrollment Protocol (SCEP)

3. Automatic Enrollment
Select the Automatically enroll to option, select the Existing CA server
settings option, then select Verisign from the drop-down list.

Contact Verisign to inform them of your certificate request. They must

authorize the certificate request before you can download the certificate.

42  Certificates and CRLs

 Chapter 2: Public Key Cryptography

CLI
1. CA Server Settings
set pki authority 1 cert-path full
set pki authority 1 scep ca-cgi “http://ipsec.verisign.com/cgi-bin
/pkiclient.exe”
set pki authority 1 scep ra-cgi “http://ipsec.verisign.com/cgi-bin
/pkiclient.exe”
set pki authority 1 scep polling-int 30
set pki authority 1 scep renew-start 14

NOTE: The Common Gateway Interface (CGI) is a standard way for a webserver to pass a
user request to an application program, and to receive data back. CGI is part of the
HyperText Transfer Protocol (HTTP).

You must specify an RA CGI path even if the RA does not exist. If the RA does not
exist, use the value specified for the CA CGI.

2. Local Certificate Request

set pki x509 dn country-name US
set pki x509 dn email [email protected]
set pki x509 dn ip 10.10.5.44
set pki x509 dn local-name “Santa Clara”
set pki x509 dn name “Michael Zhang”
set pki x509 dn org-name “Juniper Networks”
set pki x509 dn org-unit-name Development
set pki x509 phone 408-730-6000
set pki x509 dn state-name CA
exec pki rsa new 1024
3. Automatic Enrollment
exec pki x509 scep 1

If this is the first certificate request from this CA, a prompt appears presenting a
fingerprint value for the CA certificate. You must contact the CA to confirm that this
is the correct CA certificate.

Contact Verisign to inform them of your certificate request. They must authorize the
certificate request before you can download the certificate.

Automatic Certificate Renewal

You can enable the security device to automatically renew certificates it acquired
through Simple Certificate Enrollment Protocol (SCEP). This feature saves you from
having to remember to renew certificates on the security device before they expire,
and, by the same token, helps maintain valid certificates at all times.

This feature is disabled by default. You can configure the security device to
automatically send out a request to renew a certificate before it expires. You can set
the time when you want the security device to send out the certificate renewal
request in number of days and minutes before the expiration date. By setting
different times for each certificate, you prevent the security device from having to
renew all certificates at the same time.

Certificates and CRLs  43

 Concepts & Examples ScreenOS Reference Guide

For this feature to work, the security device must be able to reach the SCEP server,
and the certificate must be present on the security device during the renewal
process. Furthermore, for this feature to work, you must also ensure that the CA
issuing the certificate can do the following:

 Support automatic approval of certificate requests.

 Return the same DN (Domain Name). In other words, the CA cannot modify the
subject name and SubjectAltName extension in the new certificate.

You can enable and disable the automatic SCEP certificate-renewal feature for all
SCEP certificates or for individual certificates.

Key-Pair Generation
A security device holds pregenerated keys in memory. The number of pregenerated
keys depends on the device model. During normal operation, the security device
can manage to have enough keys available to renew certificates by generating a
new key every time it uses one. The process of generating a key usually goes
unnoticed as the device has time to generate a new key before one is needed. In the
event that the security device renews a great number of certificates at once, thus
using up keys rapidly, it might run out of pregenerated keys and have to generate
them promptly for each new request. In this case, the generation of keys might
affect the performance of the security device, especially in a high-availability (HA)
environment where the performance of the security device might slow down for a
number of minutes.

The number of pregenerated key pairs on a security device depends on the model.
For more information, refer to the datasheet for your Juniper Networks security
product.

Online Certificate Status Protocol

When a security device performs an operation that uses a certificate, it is usually
important to verify the validity of that certificate. Certificates might have become
invalid through expiration or revocation. The default way to check the status of
certificates is to use certificate revocation lists (CRLs). The Online Certificate Status
Protocol (OCSP) is an alternative way to check the status of certificates. OCSP can
provide additional information about certificates and provide status checks in a
more timely manner.

When a security device uses OCSP, it is referred to as the OCSP client (or requester).
This client sends a verification request to a server device called the OCSP responder.
ScreenOS supports RSA Keon and Verisign as OCSP responders. The client’s request
contains the identity of the certificate to check. Before the security device can
perform any OCSP operation, you must configure it to recognize the location of the
OCSP responder.

NOTE: We have also successfully tested with the Valicert OCSP responder during an
extensive evaluation in the past.

44  Online Certificate Status Protocol

 Chapter 2: Public Key Cryptography

After receiving the request, the OCSP responder confirms that the status
information for the certificate is available, then returns the current status to the
security device. The response of the OCSP responder contains the certificate’s
revocation status, the name of the responder, and the validity interval of the
response. Unless the response is an error message, the responder signs the
response using the responder’s private key. The security device verifies the validity
of the responder’s signature by using the certificate of the responder. The certificate
of the responder may either be embedded in the OCSP response, or stored locally
and specified in the OCSP configuration. If the certificate is stored locally, use the
following command to specify the locally stored certificate:

set pki authority id_num1 cert-status ocsp cert-verify id id_num2

id_num1 identifies the CA certificate that issued the certificate being verified,
and id_num2 identifies the locally stored certificate the device uses to verify the
signature on the OCSP response.

If the certificate of the responder is not embedded in the OCSP response or stored
locally, then the security device verifies the signature by using the CA certificate that
issued the certificate in question.

You can use CLI commands to configure a security device for OCSP. Most of these
commands use an identification number to associate the revocation reference URL
with the CA certificate. You can obtain this ID number using the following CLI
command:

get pki x509 list ca-cert

NOTE: The security device dynamically assigns the ID number to the CA certificate when
you list the CA certificates. This number might change after you modify the
certificate store.

Specifying a Certificate Revocation Check Method

To specify the revocation check method (CRL, OCSP, or none) for a certificate of a
particular CA, use the following CLI syntax:

set pki authority id_num cert-status revocation-check { CRL | OCSP | none }

where id_num is the identification number for the certificate.

The following example specifies OCSP revocation checking:

set pki authority 3 cert-status revocation-check ocsp

The ID number 3 identifies the certificate of the CA.

Online Certificate Status Protocol  45

 Concepts & Examples ScreenOS Reference Guide

Viewing Status Check Attributes

To display the status check attributes for a particular CA, use the following CLI
syntax:

get pki authority id_num cert-status

where id_num is the identification number for the certificate issued by the CA.

To display the status check attributes for the CA that issued certificate 7:

get pki authority 7 cert-status

Specifying an Online Certificate Status Protocol Responder URL

To specify the URL string of an OCSP responder for a particular certificate, use the
following CLI syntax:

set pki authority id_num cert-status ocsp url url_str

To specify the URL string of an OCSP responder (http:\\192.168.10.10) for the CA

with certificate at index 5, use the following CLI syntax:

set pki authority 5 cert-status ocsp url http:\\192.168.10.10

To remove the URL (http:\\192.168.2.1) of a CRL server for a certificate 5:

unset pki authority 5 cert-status ocsp url http:\\192.168.2.1

Removing Status Check Attributes

To remove all certificate status check attributes for a CA that issued a particular
certificate, use the following syntax:

unset pki authority id_num cert-status

To remove all revocation attributes related to certificate 1:

unset pki authority 1 cert-status

46  Online Certificate Status Protocol

 Chapter 2: Public Key Cryptography

Self-Signed Certificates
A self-signed certificate is a certificate that is signed by and issued to the same
entity; that is, the issuer and the subject of the certificate are the same. For
example, the CA certificates of all root certificate authorities (CAs) are self-signed.

A security device automatically generates a self-signed certificate when powering

up—if there is no certificate already configured for Secure Sockets Layer (SSL),
which is the case when you first power it up. The security device that creates an
auto-generated self-signed certificate is the only device that uses it. The device
never exports this certificate outside itself. Even if the security device is in a
NetScreen Redundancy Protocol (NSRP) cluster, it does not include the
auto-generated self-signed certificate with other types of certificates when
synchronizing PKI objects among other members in the cluster. (NSRP members do
exchange manually generated self-signed certificates. For information about
manually generating self-signed certificates, see “Manually Creating Self-Signed
Certificates” on page 49.)

Although you cannot export an auto-generated self-signed certificate, you can copy
its subject name and fingerprint. You can then deliver this to a remote admin who
can later use the subject name and fingerprint to verify the self-signed certificate
received during SSL negotiations. Checking the subject name and fingerprint is an
important precaution against man-in-the-middle attacks in which someone
intercepts an SSL connection attempt and pretends to be the targeted security
device by responding with his own self-signed certificate. (For more information
about verifying a self-signed certificate, see “Certificate Validation” on page 48.)

You can use a self-signed certificate when making a Secure Sockets Layer (SSL)
connection to the security device. When you manage the device through the WebUI,
SSL can provide authentication and encryption to secure your administrative traffic.
You can even configure a security device to redirect an administrative connection
attempt using HTTP (default port 80) to SSL (default port 443).

NOTE: For more information about SSL, including the HTTP-to-SSL redirect mechanism,
see “Secure Sockets Layer” on page 3-5.

By default, the security device makes the auto-generated self-signed certificate

available for use with SSL negotiations. It is the default SSL certificate. If you later
install a CA-signed certificate or you configure the security device to generate
another self-signed certificate, you can use one of these other certificates for SSL. If
you delete the auto-generated self-signed certificate and do not assign another
certificate for SSL use, the security device automatically generates another
self-signed certificate the next time the device reboots.

NOTE: To learn how to create another self-signed certificate, see “Manually Creating
Self-Signed Certificates” on page 49. To learn how to delete an auto-generated
self-signed certificate, see “Deleting Self-Signed Certificates” on page 55.

Self-Signed Certificates  47
 Concepts & Examples ScreenOS Reference Guide

Certificate Validation
During an SSL handshake, the security device authenticates itself by sending a
certificate to the SSL client. When the security device sends a self-signed certificate,
the SSL client cannot validate it by checking the issuing CA’s signature because no
CA issued it. When the security device presents a self-signed certificate for use in
establishing an SSL session, the browser on the admin’s computer tries to validate it
with a CA certificate in its CA store. When it fails to find such an authority, the
browser displays a message such as that shown in Figure 18, prompting the admin
to accept or refuse the certificate.

Figure 18: Security Alerts for Self-Signed Certificates

If this is the first time connecting to the security device after its initial bootup, the
system clock might be inaccurate. Consequently, the validity period on the
certificate might also be inaccurate. Even if you set the system clock and then
regenerate a self-signed certificate, the browser can never find an authenticating
CA, so the administrator must be prepared to see one of the above messages each
time the security device uses a self-signed certificate for an SSL connection.

Without recourse to the certificate validation of an impartial third-party CA, the

administrator logging in through SSL might wonder if the received self-signed
certificate is indeed from the security device to which he is attempting to connect.
(After all, the certificate might be from an interloper using a man-in-the-middle
attack in an attempt to masquerade as the security device.) The admin can validate
the certificate by using the subject name and fingerprint of the self-signed
certificate. You can deliver the subject name and fingerprint to the admin so that
the admin can validate the self-signed certificate when the security device later
provides it to authenticate itself.

48  Self-Signed Certificates
 Chapter 2: Public Key Cryptography

To see the subject name and fingerprint of an auto-generated self-signed certificate,

use the following command:

device-> get pki x509 cert system

...
CN=0043022002000186,CN=system generated,CN=self-signed,
...
finger print (md5) <e801eae4 56699fbc 324e38f2 4cfa5d47>
finger print (sha) <0113f5ec 6bd6d32b 4ef6ead9 f809eead 3a71435b>

NOTE: You cannot view the details of an auto-generated self-signed certificate through the
WebUI.

After viewing the subject name and fingerprint, you can copy and deliver them
(using a secure out-of-band method of your choice) to the admin that is later going
to connect to the security device through SSL. When the admin’s SSL client receives
the certificate from the security device during the SSL handshake, the admin can
compare the subject name and fingerprint in the received certificate with those that
received earlier out-of-band. If they match, the admin knows that the certificate is
authentic. Because there is no trusted third-party CA authority to authenticate the
certificate, wIthout the subject name and fingerprint to compare, the remote admin
cannot know for sure if the certificate is genuine.

Manually Creating Self-Signed Certificates

The security device automatically generates a self-signed certificate when you first
power up the device so that it can support SSL for the initial connection. However,
you might want to generate a different self-signed certificate from the one that the
security device automatically generates. The following are some possible reasons
for replacing the auto-generated self-signed certificate with an admin-defined
self-signed certificate:

 The auto-generated self-signed certificate uses a fixed key size of 1024 bits.
Your needs might require a larger or smaller key size, which you can control
when generating your own self-signed key.

 You might want to use a certificate with a different subject name from the one
that is automatically created.

 You might have a need for multiple self-signed certificates. On security devices
that support virtual systems, the root system can share the auto-generated
self-signed certificate with all the virtual systems. However, vsys administrators
might prefer to generate their own self-signed certificates and then require their
administrators to check the subject name and fingerprint of these specific
certificates instead of the attributes of a shared certificate.

NOTE: Unlike an auto-generated self-signed certificate, which never passes outside the
device in which it is created, a manually generated self-signed certificate is
included with other certificates when a security device in an NSRP cluster
synchronizes PKI objects with other members in the cluster.

Self-Signed Certificates  49
 Concepts & Examples ScreenOS Reference Guide

Although you can configure various components of a self-signed certificate—such

as the distinguished name (DN) fields, the subject alternative name, and the key
size—the following common name (CN) elements always appear at the end of the
DN:

“CN = dev_serial_num, CN = NetScreen self-signed”

Although the primary intended use of a self-signed certificate is to provide

immediate out-of-the-box support for making a Secure Sockets Layer (SSL)
connection to a security device, you can potentially use this certificate as you would
any other CA-signed certificate. The uses for a self-signed certificate can include the
following:

 Making a Secure Sockets Layer (SSL) connection to protect administrative traffic

to a security device

 Securing traffic between the NetScreen-Security Manager (NSM) and a security

device

 Authenticating IKE peers when establishing VPN tunnels

NOTE: For the current ScreenOS release, we support self-signed certificates only for use
with SSL.

Setting an Admin-Defined Self-Signed Certificate

In this example, you define the following components of a self-signed certificate for
use with SSL:

 Distinguished Name/Subject Name:

 Name: 4ssl

 Organization: jnpr

 FQDN: www.juniper.net

 Key type and length: RSA, 1024 bits

After defining it, you generate the certificate and view it. You can then copy the
subject name and fingerprint (also referred to as a “thumbprint”) for distribution to
other admins logging in through SSL to manage the security device.

When an admin attempts to log in using SSL, the security device sends him this
certificate. The admin can open the certificate and compare the subject name and
fingerprint in the certificate with the information received previously. If they match,
the admin knows that the certificate is authentic.

50  Self-Signed Certificates
 Chapter 2: Public Key Cryptography

WebUI
1. Define the Certificate Attributes
Objects > Certificates > New: Enter the following, then click Generate:

Certificate Subject Information:

Name: 4ssl
Organization: jnpr
FQDN: www.juniper.net
Key Pair Information:
RSA: (select)
Create new key pair of 1024 length.
2. Generate the Self-Signed Certificate
After the security device completes the key generation it composes a certificate
request. Click Generate Self-Signed Cert.

3. View the Self-Signed Certificate

Objects > Certificates > Show Local: Click Detail for the certificate that you just
created.

The Certificate Details page appears, as shown in Figure 19.

Figure 19: Certificate Details

You can copy the subject name and fingerprint from this page and communicate it
to other administrators who intend to use SSL when managing the security device.
When they initiate an SSL connection, they can then use this information to ensure
that the certificate they receive is indeed from the security device.

Self-Signed Certificates  51
 Concepts & Examples ScreenOS Reference Guide

CLI
1. Define the Certificate Attributes
set pki x509 dn name 4ssl
set pki x509 dn org-name jnpr
set pki x509 cert-fqdn www.juniper.net
save
2. Generate the Self-Signed Certificate
To generate a public/private key pair, which the Juniper Networks security device
uses in its certificate request, enter the following command:

exec pki rsa new-key 1024

After the security device generates a key pair, it composes the following certificate
request:

-----BEGIN CERTIFICATE REQUEST-----

MIIB0jCCATsCAQAwZTENMAsGA1UEChMESk5QUjEZMBcGA1UEAxMQMDA0MzAyMj
Aw
MjAwMDE4NjEQMA4GA1UEAxMHcnNhLWtleTEYMBYGA1UEAxMPd3d3Lmp1bmlwZ
XIu
bmV0MQ0wCwYDVQQDEwQ1c3NsMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQK
BgQDP
aAtelkL4HxQmO1w1jv9NMmrWnzdVYnGrKrXnw2MaB3xEgouWrlymEkZetA2ouKeA
D24SL0h1YvJ7Sd9PvkhwHOnvP1zkOCWA84TgvxBzcAyeBnS1UpSwcC0admX0Da6
T
80EUuGrmUWodddRFUc8o5d2VGTUOM7WgcFDZRSGQGwIDAQABoC0wKwYJKoZIh
vcN
AQkOMR4wHDAaBgNVHREEEzARgg93d3cuanVuaXBlci5uZXQwDQYJKoZIhvcNAQEF
BQADgYEAgvDXI4H905y/2+k4omo9Y4XQrgq44Rj3jqXAYYMgQBd0Q8HoyL5NE3+i
QUkiYjMTWO2wIWzEr4u/tdAISEVTu03achZa3zIkUtn8sD/VYKhFlyPCBVvMiaHd
FzIHUgBuMrr+awowJDG6wARhR75w7pORXy7+aAmvIjew8YRre9s=
-----END CERTIFICATE REQUEST-----

To learn the ID number for the key pair, use the following command:

get pki x509 list key-pair

Getting OTHER PKI OBJECT ...

IDX ID num X509 Certificate Subject Distinguish Name
========================================================
0000 176095259
CN=4ssl,CN=www.juniper.net,CN=rsa-key,CN=0043022002000186,
O=jnpr,
========================================================

To generate the self-signed certificate, enter the following command, referencing

the key-pair ID number that you learned from the output of the previous command:

exec pki x509 self-signed-cert key-pair 176095259

52  Self-Signed Certificates
 Chapter 2: Public Key Cryptography

3. View the Self-Signed Certificate

To view the self-signed certificate that you have just created, enter the following
command:

get pki x509 list local-cert

Getting LOCAL CERT ...

IDX ID num X509 Certificate Subject Distinguish Name
========================================================
0000 176095261 LOCAL CERT friendly name <29>
LOCAL CERT friendly name <29>
CN=self-signed,CN=4ssl,CN=www.juniper.net,CN=rsa-key,CN=004302200200
0186,
O=jnpr,
Expire on 10-19-2009 17:20, Issued By:
CN=self-signed,CN=4ssl,CN=www.juniper.net,CN=rsa-key,CN=004302200200
0186,
O=jnpr,
========================================================

To view the certificate in more detail, enter the following command using the ID
number of the certificate:

get pki x509 cert 176095261

-0001 176095261 LOCAL CERT friendly name <29>

CN=self-signed,CN=4ssl,CN=www.juniper.net,CN=rsa-key,CN=0043022002
000186,
O=jnpr,
Expire on 10-19-2009 17:20, Issued By:
CN=self-signed,CN=4ssl,CN=www.juniper.net,CN=rsa-key,CN=004302200200
0186,
O=jnpr,
Serial Number: <9d1c03365a5caa172ace4f82bb5ec9da>
subject alt name extension:
email(1): (empty)
fqdn(2): (www.juniper.net)
ipaddr(7): (empty)
no renew
finger print (md5) <be9e0280 02bdd9d1 175caf23 6345198e>
finger print (sha) <87e0eee0 c06f9bac 9098bd02 0e631c1b 26e37e0e>
subject name hash: <d82be8ae 4e71a576 2e3f06fc a98319a3 5c8c6c27>
use count: <1>
flag <00000000>

You can copy the subject name and fingerprint from this output and communicate
it to other administrators who intend to use SSL when managing the security
device. When they initiate an SSL connection, they can then use this information to
ensure that the certificate they receive is indeed from the security device.

Self-Signed Certificates  53
 Concepts & Examples ScreenOS Reference Guide

Certificate Auto-Generation
The first time the security device powers up, it automatically generates a self-signed
certificate. The primary purpose of this certificate is to support SSL immediately
after the initial bootup of a security device. To see this certificate, use the following
CLI command:

get pki x509 cert system

CN=0010062001000021,CN=system generated,CN=self-signed,
Expire on 08- 3-2014 16:19, Issued By:
CN=0010062001000021,CN=system generated,CN=self-signed,
Serial Number: <c927f2044ee0cf8dc931cdb1fc363119>
finger print (md5) <fd591375 83798574 88b3e698 62890b5d>
finger print (sha) <40a1bda8 dcd628fe e9deaee1 92a2783c 817e26d9>
subject name hash: <0324d38d 52f814fe 647aba3a 86eda7d4 a7834581>

By default, the security device automatically generates a self-signed certificate

during the bootup process if the following conditions are met:

 No automatically generated self-signed certificate exists on the device.

 No certificate has been assigned for use with SSL.

You can use the following command to see if a certificate is already configured for
SSL:

get ssl
web SSL enable.
web SSL port number(443).
web SSL cert: Default - System Self-Signed Cert.
web SSL cipher(RC4_MD5).

In the above output, you can see that SSL is using the automatically generated
(“System”) self-signed certificate.

Figure 20 shows the decision path for certificate generation that the security device
takes when booting up.

54  Self-Signed Certificates
 Chapter 2: Public Key Cryptography

Figure 20: Decision Path for Certificate Auto-Generation

Bootup Process
Starts

Auto-gen
self-signed Yes
cert exists

Yes

Do not automatically
Cert for SSL generate a self-signed
exists Yes certificate.

No

Automatically generate a
self-signed certificate.

If you delete the automatically generated self-signed certificate, assign another

certificate for use with SSL, and then reset the device, the security device does not
regenerate another self-signed certificate during the bootup process. If you next
change the SSL configuration so that no certificate is assigned to it and then reset
the device, the security device does automatically regenerate a new self-signed
certificate during the next bootup process.

Deleting Self-Signed Certificates

You can delete a self-signed certificate that is automatically or manually generated
as you can with any type of certificate. Perhaps you obtain a CA-signed certificate
that you prefer to use for SSL instead of a self-signed certificate. For whatever
reason, to delete the auto-generated self-signed certificate, use the following CLI
command:

delete pki object-id system

To delete an admin-configured self-signed certificate, use the following command,

where id_num is the ID number of the certificate that you want to delete:

delete pki object-id id_num

If you delete the auto-generated self-signed certificate and then later want the
security device to generate another one, do the following:

 Assign no other certificate for SSL (You can use the following command: unset
ssl cert).

 Reset the security device.

Self-Signed Certificates  55
 Concepts & Examples ScreenOS Reference Guide

The security device can redirect HTTP traffic (default port 80) sent to the device
itself to SSL (default port 443). Therefore, to ensure that a certificate is available for
SSL, during the bootup process, the security device always checks if an
auto-generated self-signed certificate exists or if another certificate has been
assigned for SSL to use. If there is no auto-generated self-signed certificate and no
other certificate is assigned for SSL use, the security device automatically generates
a self-signed certificate.

NOTE: You can only delete an automatically generated self-signed certificate through the
CLI.

To learn the ID number for a certificate, use the following command: get pki x509
list local-cert.

For information about the redirection of HTTP traffic to SSL, see “Redirecting
HTTP to SSL” on page 3-8.

56  Self-Signed Certificates
Chapter 3
Virtual Private Network Guidelines

ScreenOS offers a variety of cryptographic options when you configure a virtual

private network (VPN) tunnel. Even when configuring a simple tunnel, you must
make choices. The goals of the first half of this chapter are to first summarize all the
choices for a basic site-to-site VPN and a basic dialup VPN and to then present one
or more reasons for choosing one option or another.

The second half of the chapter explores the difference between policy-based and
route-based VPN tunnels. It also examines the packet flow for a route-based and
policy-based site-to-site AutoKey IKE VPN tunnel to see the outbound and inbound
processing stages that a packet undergoes. The chapter concludes with some VPN
configuration tips to keep in mind when configuring a tunnel.

This chapter contains the following sections:

 “Cryptographic Options” on page 58

 “Site-to-Site Cryptographic Options” on page 58

 “Dialup VPN Options” on page 65

 “Route-Based and Policy-Based Tunnels” on page 72

 “Packet Flow: Site-to-Site VPN” on page 73

 “Tunnel Configuration Guidelines” on page 79

 “Route-Based Virtual Private Network Security Considerations” on page 81

 “Null Route” on page 81

 “Dialup or Leased Line” on page 83

 “VPN Failover to Leased Line or Null Route” on page 84

 “Decoy Tunnel Interface” on page 86

 “Virtual Router for Tunnel Interfaces” on page 87

 “Reroute to Another Tunnel” on page 87

 57
 Concepts & Examples ScreenOS Reference Guide

Cryptographic Options
When configuring a VPN, you must make many decisions about the cryptography
you want to use. Questions arise about which Diffie-Hellman group is the right one
to choose, which encryption algorithm provides the best balance between security
and performance, and so on. This section presents all the cryptographic options
required to configure a basic site-to-site VPN tunnel and a basic dialup VPN tunnel
and explains one or more benefits about each one to help you make your decisions.

The first decision that you must make is whether the tunnel is for a site-to-site VPN
tunnel (between two security devices) or whether it is for a dialup VPN (from the
NetScreen-Remote VPN client to a security device). Although this is a networking
decision, the distinction between the two types of tunnels affects some
cryptographic options. Therefore, the options are presented in two different figures:

 “Site-to-Site Cryptographic Options” explains Figure 21, “Cryptographic

Options for a Site-to-Site VPN Tunnel,” on page 59.

 “Dialup VPN Options” explains Figure 22, “Cryptographic Options for a Dialup
VPN Tunnel,” on page 65.

After you decide whether you are going to configure a site-to-site tunnel or a dialup
tunnel, you can refer to either Figure 21 on page 59 or Figure 22 on page 65 for
guidance. Each figure presents the cryptographic choices that you must make while
configuring the tunnel. Following each figure are reasons for choosing each option
that appears in the figure.

NOTE: Examples for configuring both kinds of tunnels are in Chapter 4, “Site-to-Site
Virtual Private Networks,” and Chapter 5, “Dialup Virtual Private Networks.”

Site-to-Site Cryptographic Options

When configuring a basic site-to-site VPN tunnel, you must choose among the
cryptographic options shown in Figure 21. Advantages for each option follow the
figure.

NOTE: Figure 21 on page 59 shows recommended options in boldface. For background

information about the different IPSec options, see “Internet Protocol Security” on
page 1.

58  Cryptographic Options
 Chapter 3: Virtual Private Network Guidelines

Figure 21: Cryptographic Options for a Site-to-Site VPN Tunnel

1. Key Method: Manual Key or AutoKey IKE?
AutoKey IKE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . or . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Manual Key?

2. Mode:
Aggressive or Main?

6. IKE Diffie-Hellman 13. IPSec Protocol:

3. Authentication Type: ESP . . . . . . . . or . . . . . . . . AH?
Certificates or Preshared Key? Group: 1 or 2 or 5?

14. Mode:
4. Certificate Type: 7. IKE Encryption and Tunnel or Transport
RSA or DSA? Authentication Algorithms:
AES or DES or 3DES 15. ESP Options:
5. Bit Length: and
512 or 768 Encrypt or Encrypt/Auth or
MD5 or SHA-1?
or 1024 or 2048?
16. Encrypt Algorithms: 17. Auth Algorithms:
AES or DES or 3DES? MD5 or SHA-1?
8. Local IKE ID: 9. Remote IKE ID: 10. Anti-Replay
IP Address or U-FQDN IP Address or U-FQDN Checking:
or FQDN or ASN1-DN? or FQDN or ASN1-DN?
11. Perfect Forward Secrecy:
Yes or No?

12. IPSec Diffie-Hellman Group:

1 or 2 or 5?

Phase 1--IKE Gateway Phase 2--VPN Tunnel

1. Key Method: Manual Key or AutoKey IKE?

AutoKey IKE
 Recommended

 Provides automatic key renewal and key freshness, thereby increasing security

Manual Key
 Useful for debugging IKE problems

 Eliminates IKE negotiation delays when establishing a tunnel

2. Mode: Aggressive or Main?

Aggressive
Required when the IP address of one of the IPSec peers is dynamically assigned and
a preshared key is used

Main
 Recommended

 Provides identity protection

 Can be used when the dialup user has a static IP address or if certificates are
used for authentication

Cryptographic Options  59
 Concepts & Examples ScreenOS Reference Guide

3. Authentication Type: Preshared Key or Certificates?

Certificates
 Recommended

 Greater security than provided by preshared keys because you can validate
certificates with a certificate authority (CA). (For more information, see “Public
Key Cryptography” on page 29.)

Preshared Key
Easier to use and faster to set up because it does not require a Public Key
Infrastructure (PKI)

4. Certificate Type: RSA or DSA?

This depends on the CA from whom you get your certificates. There is no advantage
of one certificate type over the other.

5. Bit Length: 512 or 768 or 1024 or 2048?

512
Incurs the least processing overhead

768
 Provides more security than 512 bits

 Incurs less processing overhead than 1024 and 2048 bits

1024
 Recommended

 Provides more security than 512 and 768 bits

 Incurs less processing overhead than 2048 bits

2048
Provides the most security

6. IKE Diffie-Hellman Group: 1 or 2 or 5 or 14?

Diffie-Hellman Group 1
 Incurs less processing overhead than Diffie-Hellman Groups 2, 5, and 14

 Processing acceleration provided in Juniper Networks security hardware

Diffie-Hellman Group 2
 Recommended

 Incurs less processing overhead than Diffie-Hellman Groups 5 and 14

 Provides more security than Diffie-Hellman Group 1

 Processing acceleration provided in Juniper Networks security hardware

Diffie-Hellman Group 5
 Provides more security that Diffie-Hellman Groups 1 and 2

60  Cryptographic Options
 Chapter 3: Virtual Private Network Guidelines

 Incurs less processing overhead than Diffie-Hellman Group 14

Diffie-Hellman Group 14
 Provides the most security

7. IKE Encrypt and Auth Algorithms: AES or DES or 3DES and MD5 or SHA-1?
AES
 Recommended

 Cryptographically stronger than DES and 3DES if key lengths are all equal

 Processing acceleration provided in Juniper Networks security hardware

 Approved encryption algorithm for Federal Information Processing Standards

(FIPS) and Common Criteria EAL4 standards

DES
 Incurs less processing overhead than 3DES and AES

 Useful when the remote peer does not support AES

3DES
 Provides more cryptographic security than DES

 Processing acceleration provided in Juniper Networks security hardware

MD5
Incurs less processing overhead than SHA-1

SHA-1
 Recommended

 Provides more cryptographic security than MD5

 The only authentication algorithm that FIPS accepts

8. Local IKE ID: IP Address (Default) or U-FQDN or FQDN or ASN1-DN?

IP Address
 Recommended

 Can only be used if the local security device has a static IP address

 Default IKE ID when using a preshared key for authentication

 Can be used with a a certificate if the IP address appears in the SubjectAltName

field

U-FQDN
User-Fully Qualified Domain Name (U-FQDN—an email address): Can be used with
a preshared key or a certificate if the U-FQDN appears in the SubjectAltName field

FQDN
 Fully Qualified Domain Name (FQDN): Can be used with a preshared key or a
certificate if the FQDN appears in the SubjectAltName field

Cryptographic Options  61
 Concepts & Examples ScreenOS Reference Guide

 Useful for VPN gateways that have dynamic IP addresses

 Default IKE ID when using RSA or DSA certificates for authentication

ASN1-DN
 Can be used only with certificates

 Useful if the CA does not support the SubjectAltName field in the certificates it
issues

9. Remote IKE ID: IP Address (Default) or U-FQDN or FQDN or ASN1-DN?

IP Address
 Recommended

 Does not require you to enter a remote IKE ID for a peer at a static IP address
when using preshared keys for authentication and the peer is a security device

 Can be used for a device with a static IP address

 Can be used with a preshared key or a certificate if the IP address appears in

the SubjectAltName field

U-FQDN
User-Fully Qualified Domain Name (U-FQDN—an email address): Can be used with
a preshared key or a certificate if the U-FQDN appears in the SubjectAltName field

FQDN
 Fully Qualified Domain Name (FQDN): Can be used with a preshared key or a
certificate if the FQDN appears in the SubjectAltName field

 Useful for VPN gateways that have dynamic IP addresses

 Does not require you to enter a remote IKE ID when using certificates for
authentication and the peer is a security device

ASN1-DN
 Can be used only with certificates

 Useful if the CA does not support the SubjectAltName field in the certificates it
issues

10. Anti-Replay Checking: No or Yes?

Yes
 Recommended

 Enables the recipient to check sequence numbers in packet headers to prevent

denial of service (DoS) attacks caused when a malefactor resends intercepted
IPSec packets

No
Disabling this might resolve compatibility issues with third-party peers

62  Cryptographic Options
 Chapter 3: Virtual Private Network Guidelines

11. Perfect Forward Secrecy: No or Yes?

Yes
 Recommended

 Perfect Forward Secrecy (PFS): Provides increased security because the peers
perform a second Diffie-Hellman exchange to produce the key used for IPSec
encryption/decryption

No
 Provides faster tunnel setup

 Incurs less processing during Phase 2 IPSec negotiations

12. IPSec Diffie-Hellman Group: 1 or 2 or 5 or 14?

Diffie-Hellman Group 1
 Incurs less processing overhead than Diffie-Hellman Groups 2, 5, and 14

 Processing acceleration provided in Juniper Networks security hardware

Diffie-Hellman Group 2
 Recommended

 Incurs less processing overhead than Diffie-Hellman Groups 5 and 14

 Provides more security than Diffie-Hellman Group 1

 Processing acceleration provided in Juniper Networks security hardware

Diffie-Hellman Group 5
 Provides more security that Diffie-Hellman Groups 1 and 2

 Incurs less processing overhead than Diffie-Hellman Group 14

Diffie-Hellman Group 14
 Provides the most security

13. IPSec Protocol: ESP or AH?

ESP
 Recommended

 Encapsulating Security Payload (ESP): Can provide both confidentiality through

encryption and encapsulation of the original IP packet and integrity through
authentication

 Can provide either encryption alone or authentication alone

AH
Authentication Header (AH): Provides authentication of the entire IP packet,
including the IPSec header and outer IP header

14. Mode: Tunnel or Transport?

Tunnel
 Recommended

Cryptographic Options  63
 Concepts & Examples ScreenOS Reference Guide

 Conceals the original IP header, thereby increasing privacy

Transport
Required for L2TP-over-IPSec tunnel support

15. ESP Options: Encrypt or Encrypt/Auth or Auth?

Encrypt
 Provides faster performance and incurs less processing overhead than using
encrypt/auth

 Useful when you require confidentiality but do not require authentication

Encrypt/Auth
 Recommended

 Useful when you want confidentiality and authentication

Auth
Useful when you want authentication but do not require confidentiality. Perhaps
when the information is not secret, but it is important to establish that the
information truly comes from the person who claims to send it and that nobody
tampered with the content while in transit.

16. Encrypt Algorithms: AES or DES or 3DES?

AES
 Recommended

 Cryptographically stronger than DES and 3DES if key lengths are all equal

 Processing acceleration provided in Juniper Networks security hardware

 Approved encryption algorithm for FIPS and Common Criteria EAL4 standards

DES
 Incurs less processing overhead than 3DES and AES

 Useful when the remote peer does not support AES

3DES
 Provides more cryptographic security than DES

 Processing acceleration provided in Juniper Networks security hardware

17. Auth Algorithms: MD5 or SHA-1?

MD5
Incurs less processing overhead than SHA-1

SHA-1
 Recommended

 Provides more cryptographic security than MD5

64  Cryptographic Options
 Chapter 3: Virtual Private Network Guidelines

Using the recommended options from the previous list, a generic site-to-site VPN
configuration between two security devices with static IP addresses would consist
of the following components:

 AutoKey IKE  Perfect Forward Secrecy (PFS) = yes

 Main mode  Phase 2 Diffie-Hellman Group 2

 1024-bit certificates (RSA or DSA)  Encapsulating Security Payload (ESP)

 Phase 1 Diffie-Hellman Group 2  Tunnel mode

 Encryption = AES  Encryption/Authentication

 Authentication = SHA-1  Encryption = AES

 IKE ID = IP address (default)  Authentication = SHA-1

 Anti-replay protection = yes

Dialup VPN Options

When configuring a basic dialup VPN tunnel, you must choose among the
cryptographic options shown in Figure 22. Advantages for each option follow the
figure.

NOTE: Figure 22 shows recommended options in boldface. For background information

about the different IPSec options, see “Internet Protocol Security” on page 1.

Figure 22: Cryptographic Options for a Dialup VPN Tunnel

Key Method = AutoKey IKE

1. Mode:
Aggressive or Main?

2. Authentication Type: 5. IKE Diffie-Hellman 12. IPSec Protocol:

Certificates or Preshared Key? Group: 1 or 2 or 5? ESP . . . . . . . . or . . . . . . . . AH?

3. Certificate Type: 13. Mode:

RSA or DSA? Tunnel or Transport
6. IKE Encryption and
Authentication Algorithms: 14. ESP Options:
4. Bit Length: AES or DES or 3DES
512 or 768 Encrypt or Encrypt/Auth or Auth?
and
or 1024 or 2048? MD5 or SHA-1?
15. Encrypt Algorithms: 16. Auth Algorithms:
AES or DES or 3DES? MD5 or SHA-1?
7. Local IKE ID: 8. Remote IKE ID:
IP Address (Default) or IP Address (Default) or 9. Anti-Replay Checking: Yes
U-FQDN or FQDN or ASN1-DN? U-FQDN or FQDN or ASN1-DN? or No?

10. Perfect Forward Secrecy:

Yes or No?

11. IPSec Diffie-Hellman Group:

1 or 2 or 5?

Phase 1--IKE Gateway Phase 2--VPN Tunnel

Cryptographic Options  65
 Concepts & Examples ScreenOS Reference Guide

1. Mode: Aggressive or Main?

Aggressive
 Recommended

 Required when the IP address of one of the IPSec peers is dynamically assigned
and a preshared key is used

 Can be used with either certificates or preshared keys for authentication

Main
Provides identity protection

2. Authentication Type: Preshared Key or Certificates?

Certificates
 Recommended

 Greater security than provided by preshared keys because you can validate
certificates with a certificate authority (CA). (For more information, see “Public
Key Cryptography” on page 29.)

Preshared Key
Easier to use and faster to set up because it does not require a Public Key
Infrastructure (PKI)

3. Certificate Type: RSA or DSA?

This depends on the CA from whom you get your certificates. There is no advantage
of one certificate type over the other.

4. Bit Length: 512 or 768 or 1024 or 2048?

512
Incurs the least processing overhead

768
 Provides more security than 512 bits

 Incurs less processing overhead than 1024 and 2048 bits

1024
 Recommended

 Provides more security than 512 and 768 bits

 Incurs less processing overhead than 2048 bits

2048
Provides the most security

5. IKE Diffie-Hellman Group: 1 or 2 or 5 or 14?

Diffie-Hellman Group 1
 Incurs less processing overhead than Diffie-Hellman Groups 2, 5, and 14

 Processing acceleration provided in Juniper Networks security hardware

66  Cryptographic Options
 Chapter 3: Virtual Private Network Guidelines

Diffie-Hellman Group 2
 Recommended

 Incurs less processing overhead than Diffie-Hellman Groups 5 and 14

 Provides more security than Diffie-Hellman Group 1

 Processing acceleration provided in Juniper Networks security hardware

Diffie-Hellman Group 5
 Provides more security that Diffie-Hellman Groups 1 and 2

 Incurs less processing overhead than Diffie-Hellman Group 14

Diffie-Hellman Group 14
 Provides the most security

6. IKE Encrypt and Auth Algorithms: AES or DES or 3DES and MD5 or SHA-1?
AES
 Recommended

 Cryptographically stronger than DES and 3DES if key lengths are all equal

 Processing acceleration provided in Juniper Networks security hardware

 Approved encryption algorithm for FIPS and Common Criteria EAL4 standards

DES
 Incurs less processing overhead than 3DES and AES

 Useful when the remote peer does not support AES

3DES
 Provides more cryptographic security than DES

 Processing acceleration provided in Juniper Networks security hardware

MD5
Incurs less processing overhead than SHA-1

SHA-1
 Recommended

 Provides more cryptographic security than MD5

7. Local IKE ID: IP Address (Default) or U-FQDN or FQDN or ASN1-DN?

IP Address (Default)
 Does not require you to enter an IKE ID for a device with a static IP address

 Can be used for a device with a static IP address

 Can be used with a preshared key or a certificate if the IP address appears in

the SubjectAltName field

Cryptographic Options  67
 Concepts & Examples ScreenOS Reference Guide

U-FQDN
 Recommended

 User-Fully Qualified Domain Name (U-FQDN—an email address): Can be used

with a preshared key or a certificate if the U-FQDN appears in the
SubjectAltName field

FQDN
 Fully Qualified Domain Name (FQDN): Can be used with a preshared key or a
certificate if the FQDN appears in the SubjectAltName field

 Useful for VPN gateways that have dynamic IP addresses

ASN1-DN
 Can be used only with certificates

 Useful if the CA does not support the SubjectAltName field in the certificates it
issues

8. Remote IKE ID: IP Address (Default) or U-FQDN or FQDN or ASN1-DN?

IP Address (Default)
 Does not require you to enter an IKE ID for a device with a static IP address

 Can be used for a device with a static IP address

 Can be used with a preshared key or a certificate if the IP address appears in

the SubjectAltName field

U-FQDN
 Recommended

 User-Fully Qualified Domain Name (U-FQDN—an email address): Can be used

with a preshared key or a certificate if the U-FQDN appears in the
SubjectAltName field

FQDN
 Fully Qualified Domain Name (FQDN): Can be used with a preshared key or a
certificate if the FQDN appears in the SubjectAltName field

 Useful for VPN gateways that have dynamic IP addresses

ASN1-DN
 Can be used only with certificates

 Useful if the CA does not support the SubjectAltName field in the certificates it
issues

68  Cryptographic Options
 Chapter 3: Virtual Private Network Guidelines

9. Anti-Replay Checking: No or Yes?

Yes
 Recommended

 Enables the recipient to check sequence numbers in packet headers to prevent

denial of service (DoS) attacks caused when a malefactor resends intercepted
IPSec packets

No
Disabling this might resolve compatibility issues with third-party peers

10. Perfect Forward Secrecy: No or Yes?

Yes
 Recommended

 Perfect Forward Secrecy (PFS): Provides increased security because the peers
perform a second Diffie-Hellman exchange to produce the key used for IPSec
encryption/decryption

No
 Provides faster tunnel setup

 Incurs less processing during Phase 2 IPSec negotiations

11. IPSec Diffie-Hellman Group: 1 or 2 or 5 or 14?

Diffie-Hellman Group 1
 Incurs less processing overhead than Diffie-Hellman Groups 2, 5, and 14

 Processing acceleration provided in Juniper Networks security hardware

Diffie-Hellman Group 2
 Recommended

 Incurs less processing overhead than Diffie-Hellman Groups 5 and 14

 Provides more security than Diffie-Hellman Group 1

 Processing acceleration provided in Juniper Networks security hardware

Diffie-Hellman Group 5
 Provides more security that Diffie-Hellman Groups 1 and 2

 Incurs less processing overhead than Diffie-Hellman Group 14

Diffie-Hellman Group 14
 Provides the most security

Cryptographic Options  69
 Concepts & Examples ScreenOS Reference Guide

12. IPSec Protocol: ESP or AH?

ESP
 Recommended

 Encapsulating Security Payload (ESP): Can provide both confidentiality through

encryption and encapsulation of the original IP packet and integrity through
authentication

 Can provide either encryption alone or authentication alone

AH
Authentication Header (AH): Provides authentication of the entire IP packet,
including the IPSec header and outer IP header.

13. Mode: Tunnel or Transport?

Tunnel
 Recommended

 Conceals the original IP header, thereby increasing privacy

Transport
Required for L2TP-over-IPSec tunnel support

14. ESP Options: Encrypt or Encrypt/Auth or Auth?

Encrypt
 Provides faster performance and incurs less processing overhead than using
encrypt/auth

 Useful when you require confidentiality but do not require authentication

Encrypt/Auth
 Recommended

 Useful when you want confidentiality and authentication

Auth
Useful when you want authentication but do not require confidentiality. Perhaps
when the information is not secret, but it is important to establish that the
information truly comes from the person who claims to send it and that nobody
tampered with the content while in transit.

70  Cryptographic Options
 Chapter 3: Virtual Private Network Guidelines

15. Encrypt Algorithms: AES or DES or 3DES?

AES
 Recommended

 Cryptographically stronger than DES and 3DES if key lengths are all equal

 Processing acceleration provided in Juniper Networks security hardware

 Approved encryption algorithm for FIPS and Common Criteria EAL4 standards

DES
 Incurs less processing overhead than 3DES and AES

 Useful when the remote peer does not support AES

3DES
 Provides more cryptographic security than DES

 Processing acceleration provided in Juniper Networks security hardware

16. Auth Algorithms: MD5 or SHA-1?

MD5
Incurs less processing overhead than SHA-1

SHA-1
 Recommended

 Provides more cryptographic security than MD5

Using the recommended options from the above list, a generic dialup VPN
configuration between two security devices with static IP addresses would consist
of the following components:

 Aggressive mode  Perfect Forward Secrecy (PFS) = yes

 1024-bit certificates (RSA or DSA)  Phase 2 Diffie-Hellman Group 2

 Phase 1 Diffie-Hellman Group 2  Encapsulating Security Payload (ESP)

 Encryption = AES  Tunnel mode

 Authentication = SHA-1  Encryption/Authentication

 IKE ID = U-FQDN (email address)  Encryption = AES

 Anti-replay protection = yes  Authentication = SHA-1

Cryptographic Options  71
 Concepts & Examples ScreenOS Reference Guide

Route-Based and Policy-Based Tunnels

The configuration of a security device for VPN support is particularly flexible. You
can create route-based and policy-based VPN tunnels. Additionally, each type of
tunnel can use Manual Key or AutoKey IKE to manage the keys used for encryption
and authentication.

With policy-based VPN tunnels, a tunnel is treated as an object (or a building block)
that together with source, destination, service, and action, comprises a policy that
permits VPN traffic. (Actually, the VPN policy action is tunnel, but the action permit
is implied, if unstated). In a policy-based VPN configuration, a policy specifically
references a VPN tunnel by name.

With route-based VPNs, the policy does not specifically reference a VPN tunnel.
Instead, the policy references a destination address. When the security device does
a route lookup to find the interface through which it must send traffic to reach that
address, it finds a route through a tunnel interface, which is bound to a specific VPN
tunnel.

NOTE: Typically, a tunnel interface is bound to a single tunnel. You can also bind a tunnel
interface to multiple tunnels. For more information, see “Multiple Tunnels per
Tunnel Interface” on page 265.

Thus, with a policy-based VPN tunnel, you can consider a tunnel as an element in
the construction of a policy. With a route-based VPN tunnel, you can consider a
tunnel as a means for delivering traffic, and the policy as a method for either
permitting or denying the delivery of that traffic.

The number of policy-based VPN tunnels that you can create is limited by the
number of policies that the device supports. The number of route-based VPN
tunnels that you create is limited by the number of route entries or the number of
tunnel interfaces that the device supports—whichever number is lower.

A route-based VPN tunnel configuration is a good choice when you want to

conserve tunnel resources while setting granular restrictions on VPN traffic.
Although you can create numerous policies referencing the same VPN tunnel, each
policy creates an individual IPSec security association (SA) with the remote peer,
each of which counts as an individual VPN tunnel. With a route-based approach to
VPNs, the regulation of traffic is not coupled to the means of its delivery. You can
configure dozens of policies to regulate traffic flowing through a single VPN tunnel
between two sites, and there is just one IPSec SA at work. Also, a route-based VPN
configuration allows you to create policies referencing a destination reached
through a VPN tunnel in which the action is deny, unlike a policy-based VPN
configuration, in which—as stated earlier—the action must be tunnel, implying
permit.

Another advantage that route-based VPNs offer is the exchange of dynamic routing
information through VPN tunnels. You can enable an instance of a dynamic routing
protocol, such as Border Gateway Protocol (BGP), on a tunnel interface that is bound
to a VPN tunnel. The local routing instance exchanges routing information through
the tunnel with a neighbor enabled on a tunnel interface bound to the other end.

72  Route-Based and Policy-Based Tunnels

 Chapter 3: Virtual Private Network Guidelines

When a tunnel does not connect large networks running dynamic routing protocols
and you do not need to conserve tunnels or define various policies to filter traffic
through the tunnel, a policy-based tunnel makes sense. Also, because there is no
network beyond a dialup VPN client, policy-based VPN tunnels can be a good
choice for dialup VPN configurations.

That said, when the dialup client supports a virtual internal IP address—which the
NetScreen-Remote does—there are also compelling reasons for using a route-based
VPN configuration. A route-based dialup VPN tunnel offers the following benefits:

 You can bind its tunnel interface to any zone to require or not require policy
enforcement.

 You can define routes to force traffic through the tunnel, unlike a policy-based
VPN configuration.

 A route-based VPN tunnel simplifies the addition of a spoke to a hub-and-spoke

configuration (see “Creating Hub-and-Spoke VPNs” on page 321).

 You can adjust the proxy ID to accept any IP address from the dialup VPN client
by configuring the remote client’s address as 255.255.255.255/32.

 You can define one or more mapped IP (MIP) addresses on the tunnel interface.

NOTE: For an example of a route-based VPN configuration for a dialup client, see
“Route-Based Dialup VPN, Dynamic Peer” on page 176.

Packet Flow: Site-to-Site VPN

To better understand how the various components comprising the creation of an
IPSec tunnel work in relation to each other, this section looks at the processing of a
packet flow through a tunnel—both when a security device sends outbound VPN
traffic and when it receives inbound VPN traffic. The processing for a route-based
VPN is presented, followed by an addendum noting the two places in the flow that
differ for a policy-based VPN.

A company based in Tokyo has just opened a branch office in Paris and needs to
connect the two sites through an IPSec tunnel. The tunnel uses AutoKey IKE, the
ESP protocol, AES for encryption, SHA-1 for authentication using a preshared key,
and has anti-replay checking enabled. The security devices protecting each site are
in NAT mode, and all the zones are in the trust-vr routing domain. The addresses
are as shown in Figure 23 on page 74.

Packet Flow: Site-to-Site VPN  73

 Concepts & Examples ScreenOS Reference Guide

Figure 23: Site-to-Site VPN Tunnel

Trust Zone Tokyo Untrust Zone

Office

tunnel.1, 10.1.2.1/24
Outgoing Interface: ethernet3, 1.1.1.1/24
ethernet1
10.1.1.1/24 External Router: 1.1.1.250
10.1.1.5
Internet Paris
Tokyo
LAN VPN1 LAN

10.2.2.5
External Router: 2.2.2.250
ethernet1
Outgoing Interface: ethernet3, 2.2.2.2/24 10.2.2.1/24

tunnel.2, 10.2.1.1/24

Paris
Untrust Zone Office Trust Zone

The path of a packet coming from 10.1.1.5/32 in the Tokyo LAN and going to
10.2.2.5/32 in the Paris LAN through an IPSec tunnel proceeds as described in the
following subsections.

Tokyo (Initiator)
1. The host at 10.1.1.5 sends a packet destined for 10.2.2.5 to 10.1.1.1, which is
the IP address ethernet1 and is the default gateway configured in the TCP/IP
settings of host.

2. The packet arrives at ethernet1, which is bound to the Trust zone.

3. If you have enabled SCREEN options such as IP spoof detection for the Trust
zone, the security device activates the SCREEN module at this point. SCREEN
checking can produce one of the following three results:

 If a SCREEN mechanism detects anomalous behavior for which it is

configured to block the packet, the security device drops the packet and
makes an entry in the event log.

 If a SCREEN mechanism detects anomalous behavior for which it is

configured to record the event but not block the packet, the security device
records the event in the SCREEN counters list for ethernet1 and proceeds to
the next step.

 If the SCREEN mechanisms detect no anomalous behavior, the security

device proceeds to the next step.

If you have not enabled any SCREEN options for the Trust zone, the security
device immediately proceeds to the next step.

74  Packet Flow: Site-to-Site VPN

 Chapter 3: Virtual Private Network Guidelines

4. The session module performs a session lookup, attempting to match the packet
with an existing session.

If the packet does not match an existing session, the security device performs
First Packet Processing, a procedure involving the remaining steps.

If the packet matches an existing session, the security device performs Fast
Processing, using the information available from the existing session entry to
process the packet. Fast Processing bypasses the route and policy lookups
because the information generated by the bypassed steps has already been
obtained during the processing of the first packet in the session.

5. The address-mapping module checks if a mapped IP (MIP) configuration uses

the destination IP address 10.2.2.5. Because 10.2.2.5 is not used in a MIP
configuration, the security device proceeds to the next step. (For information
about packet processing when MIPs, VIPs, or destination address translation
[NAT-dst] is involved, see “Packet Flow for NAT-Dst” on page 8 -29.)

6. To determine the destination zone, the route module does a route lookup for
10.2.2.5. (The route module uses the ingress interface to determine which
virtual router to use for the route lookup.) It finds a route entry directing traffic
to 10.2.2.5 through the tunnel.1 interface bound to a VPN tunnel named
“vpn1”. The tunnel interface is in the Untrust zone. By determining the ingress
and egress interfaces, the security device has thereby determined the source
and destination zones and can now do a policy lookup.

7. The policy engine does a policy lookup between the Trust and Untrust zones (as
determined by the corresponding ingress and egress interfaces). The action
specified in the policy matching the source address and zone, destination
address and zone, and service is permit.

8. The IPSec module checks if an active Phase 2 security association (SA) exists
with the remote peer. The Phase 2 SA check can produce either of the following
results:

 If the IPSec module discovers an active Phase 2 SA with that peer, it

proceeds to step 10.

 If the IPSec module does not discover an active Phase 2 SA with that peer,
it drops the packet and triggers the IKE module.

9. The IKE module checks if an active Phase 1 SA exists with the remote peer. The
Phase 1 SA check can produce either of the following results:

 If the IKE module discovers an active Phase 1 SA with the peer, it uses this
SA to negotiate a Phase 2 SA.

 If the IKE module does not discover an active Phase 1 SA with that peer, it
begins Phase 1 negotiations in Main mode, and then Phase 2 negotiations.

Packet Flow: Site-to-Site VPN  75

 Concepts & Examples ScreenOS Reference Guide

10. The IPSec module puts an ESP header and then an outer IP header on the
packet. Using the address specified as the outgoing interface, it puts 1.1.1.1 as
the source IP address in the outer header. Using the address specified for
remote gateway, it puts 2.2.2.2 as the destination IP address in the outer
header. Next, it encrypts the packet from the payload to the next header field in
the original IP header. Then, it authenticates the packet from the ESP trailer to
the ESP header.

11. The security device sends the encrypted and authenticated packet destined for
2.2.2.2 through the outgoing interface (ethernet3) to the external router at
1.1.1.250.

Paris (Recipient)
1. The packet arrives at 2.2.2.2, which is the IP address of ethernet3, an interface
bound to the Untrust zone.

2. Using the SPI, destination IP address, and IPSec protocol contained in the outer
packet header, the IPSec module attempts to locate an active Phase 2 SA with
the initiating peer along with the keys to authenticate and decrypt the packet.
The Phase 2 SA check can produce one of the following three results:

 If the IPSec module discovers an active Phase 2 SA with the peer, it

proceeds to step 4.

 If the IPSec module does not discover an active Phase 2 SA with the peer
but it can match an inactive Phase 2 SA using the source IP address but not
the SPI, it drops the packet, makes an event log entry, and sends a
notification that it received a bad SPI to the initiating peer.

 If the IPSec module does not discover an active Phase 2 SA with that peer,
it drops the packet and triggers the IKE module.

3. The IKE module checks if an active Phase 1 SA exists with the remote peer. The
Phase 1 SA check can produce either of the following results:

 If the IKE module discovers an active Phase 1 SA with the peer, it uses this
SA to negotiate a Phase 2 SA.

 If the IKE module does not discover an active Phase 1 SA with that peer, it
begins Phase 1 negotiations in Main mode, and then Phase 2 negotiations.

4. The IPSec module performs an anti-replay check. This check can produce one
of two results:

 If the packet fails the anti-replay check, because it detects a sequence

number that the security device has already received, the security device
drops the packet.

 If the packet passes the anti-replay check, the security device proceeds to
the next step.

76  Packet Flow: Site-to-Site VPN

 Chapter 3: Virtual Private Network Guidelines

5. The IPSec module attempts to authenticate the packet. The authentication

check can produce one of two results:

 If the packet fails the authentication check, the security device drops the
packet.

 If the packet passes the authentication check, the security device proceeds
to the next step.

6. Using the Phase 2 SA and keys, the IPSec module decrypts the packet,
uncovering its original source address (10.1.1.5) and its ultimate destination
(10.2.2.5). It learns that the packet came through vpn1, which is bound to
tunnel.1. From this point forward, the security device treats the packet as if its
ingress interface is tunnel.1 instead of ethernet3. It also adjusts the anti-replay
sliding window at this point.

7. If you have enabled SCREEN options for the Untrust zone, the security device
activates the SCREEN module at this point. SCREEN checking can produce one
of the following three results:

 If a SCREEN mechanism detects anomalous behavior for which it is

configured to block the packet, the security device drops the packet and
makes an entry in the event log.

 If a SCREEN mechanism detects anomalous behavior for which it is

configured to record the event but not block the packet, the security device
records the event in the SCREEN counters list for ethernet3 and proceeds to
the next step.

 If the SCREEN mechanisms detect no anomalous behavior, the security

device proceeds to the next step.

8. The session module performs a session lookup, attempting to match the packet
with an existing session. It then either performs First Packet Processing or Fast
Processing.

If the packet matches an existing session, the security device performs Fast
Processing, using the information available from the existing session entry to
process the packet. Fast Processing bypasses all but the last two steps
(encrypting the packet and forwarding it) because the information generated by
the bypassed steps has already been obtained during the processing of the first
packet in the session.

9. The address-mapping module checks if a mapped IP (MIP) or virtual IP (VIP)

configuration uses the destination IP address 10.2.2.5. Because 10.2.2.5 is not
used in a MIP or VIP configuration, the security device proceeds to the next
step.

Packet Flow: Site-to-Site VPN  77

 Concepts & Examples ScreenOS Reference Guide

10. The route module first uses the ingress interface to determine the virtual router
to use for the route lookup; in this case, the trust-vr. It then performs a route
lookup for 10.2.2.5 in the trust-vr and discovers that it is accessed through
ethernet1. By determining the ingress interface (tunnel.1) and the egress
interface (ethernet1), the security device can thereby determine the source and
destination zones. The tunnel.1 interface is bound to the Untrust zone, and
ethernet1 is bound to the Trust zone. The security device can now do a policy
lookup.

11. The policy engine checks its policy list from the Untrust zone to the Trust zone
and finds a policy that grants access.

12. The security device forwards the packet through ethernet1 to its destination at
10.2.2.5.

Addendum: Policy-Based VPN

The packet flow for a policy-based VPN configuration differs from that of a
route-based VPN configuration at two points: the route lookup and the policy
lookup.

Tokyo (Initiator)
The first stages of the outbound packet flow are the same for both route-based and
policy-based VPN configurations until the route lookup and subsequent policy
lookup occur:

 Route Lookup: To determine the destination zone, the route module does a
route lookup for 10.2.2.5. Not finding an entry for that specific address, the
route module resolves it to a route through ethernet3, which is bound to the
Untrust zone. By determining the ingress and egress interfaces, the security
device has thereby determined the source and destination zones, and can now
perform a policy lookup.

 Policy Lookup: The policy engine does a policy lookup between the Trust and
Untrust zones. The lookup matches the source address and zone, destination
address and zone, and service and finds a policy that references a VPN tunnel
named vpn1.

The security device then forwards the packet through ethernet1 to its destination at
10.2.2.5.

Paris (Recipient)
Most stages of the inbound packet flow on the recipient’s end are the same for both
route-based and policy-based VPN configurations except that the tunnel is not
bound to a tunnel interface, but to a tunnel zone. The security device learns that the
packet came through vpn1, which is bound to the Untrust-Tun tunnel zone, whose
carrier zone is the Untrust zone. Unlike route-based VPNs, the security device
considers ethernet3 to be the ingress interface of the decrypted packet—not
tunnel.1.

78  Packet Flow: Site-to-Site VPN

 Chapter 3: Virtual Private Network Guidelines

The flow changes after packet decryption is complete. At this point, the route and
policy lookups differ:

 Route Lookup: The route module performs a route lookup for 10.2.2.5 and
discovers that it is accessed through ethernet1, which is bound to the Trust
zone. By learning that the Untrust zone is the source zone (because vpn1 is
bound to the Untrust-Tun tunnel zone, whose carrier zone is the Untrust zone)
and by determining the destination zone based on the egress interface
(ethernet1 is bound to the Trust zone), the security device can now check for a
policy from the Untrust to the Trust zones that references vpn1.

 Policy Lookup: The policy engine checks its policy list from the Untrust zone to
the Trust zone and finds a policy that references a VPN tunnel named vpn1 and
that grants access to 10.2.2.5.

The security device then forwards the packet to its destination.

Tunnel Configuration Guidelines

This section offers some guidelines for configuring VPN tunnels. When configuring
an IPSec VPN tunnel, you might want to consider the following:

 ScreenOS supports up to four proposals for Phase 1 negotiations and up to four

proposals for Phase 2 negotiations. A peer must be configured to accept at least
one Phase 1 proposal and one Phase 2 proposal proffered by the other peer. For
information about Phase 1 and Phase 2 IKE negotiations, see “Tunnel
Negotiation” on page 8.

 If you want to use certificates for authentication and there is more than one
local certificate loaded on the security device, you must specify which
certificate you want each VPN tunnel configuration to use. For more
information about certificates, see “Public Key Cryptography” on page 29.

 For a basic policy-based VPN:

 Use user-defined addresses in the policy, not the pre-defined address “Any”.

 The addresses and service specified in policies configured at both ends of

the VPN must match.

 Use symmetric policies for bidirectional VPN traffic.

 The proxy ID for both peers must match, which means that the service
specified in the proxy ID for both peers is the same, and the local IP address
specified for one peer is the same as the remote IP address specified for the
other peer.

NOTE: The proxy ID is a three-part tuple consisting of local IP address–remote IP

address–service.

Tunnel Configuration Guidelines  79

 Concepts & Examples ScreenOS Reference Guide

 For a route-based VPN configuration, the proxy ID is user-configurable.

 For a policy-based VPN configuration, the security device—by

default—derives the proxy ID from the source address, destination address,
and service specified in the policy that references that VPN tunnel in the
policy list. You can also define a proxy ID for a policy-based VPN that
supersedes the derived proxy ID.

The simplest way to ensure that the proxy IDs match is to use 0.0.0.0/0 for the local
address, 0.0.0.0/0 for the remote address, and “any” for the service. Instead of
using the proxy ID for access control, you use policies to control the traffic to and
from the VPN. For examples of VPN configurations with user-configurable proxy
IDs, see the route-based VPN examples in “Site-to-Site Virtual Private Networks” on
page 89.

NOTE: When the remote address is the virtual internal address of a dialup VPN client, use
255.255.255.255/32 for the remote IP address /netmask in the proxy ID.

 As long as the peers’ proxy ID settings match, it does not matter if one peer
defines a route-based VPN and the other defines a policy-based VPN. If peer-1
uses a policy-based VPN configuration and peer-2 uses a route-based VPN
configuration, then peer-2 must define a proxy ID that matches the proxy ID
derived from peer-1’s policy. If peer-1 performs Source Network Address
Translation (NAT-src) using a DIP pool, use the address and netmask for the DIP
pool as the remote address in peer-2’s proxy ID. For example:

When the DIP Pool Is: Use This in the Proxy ID:
1.1.1.8 – 1.1.1.8 1.1.1.8/32
1.1.1.20 – 1.1.1.50 1.1.1.20/26
1.1.1.100 – 1.1.1.200 1.1.1.100/25
1.1.1.0 – 1.1.1.255 1.1.1.0/24

For more information about proxy IDs when used with NAT-src and NAT-dst, see
“VPN Sites with Overlapping Addresses” on page 150.

NOTE: Peer-1 can also define a proxy ID that matches peer-2’s proxy ID. Peer-1’s
user-defined proxy ID supersedes the proxy ID that the security device derives
from the policy components.

 Because proxy IDs support either a single service or all services, the service in a
proxy ID derived from a policy-based VPN referencing a service group is
considered as “any”.

 When both peers have static IP addresses, they can each use the default IKE ID,
which is their IP addresses. When a peer or dialup user has a dynamically
assigned IP address, that peer or user must use another type of IKE ID. An
FQDN is a good choice for a dynamic peer and a U-FQDN (email address) is a
good choice for a dialup user. You can use both FQDN and U-FQDN IKE ID
types with preshared keys and certificates (if the FQDN or U-FQDN appears in

80  Tunnel Configuration Guidelines

 Chapter 3: Virtual Private Network Guidelines

the SubjectAltName field in the certificate). If you use certificates, the dynamic
peer or dialup user can also use all or part of the ASN1-DN as the IKE ID.

Route-Based Virtual Private Network Security Considerations

Although route changes do not affect policy-based VPNs, route-based VPNs are a
different matter. The security device can route packets through a route-based VPN
tunnel with a combination of static routes and dynamic routing protocols. As long
as no route change occurs, the security device consistently encrypts and forwards
packets destined for tunnel interfaces bound to route-based VPN tunnels.

However, when using VPN monitoring with a route-based VPN tunnel configuration,
the state of a tunnel might change from up to down. When this occurs, all route
table entries referencing the tunnel interface bound to that tunnel change to
inactive. Then, when the security device does a route lookup for traffic originally
intended to be encrypted and sent through a tunnel bound to that tunnel interface,
it bypasses the route referencing the tunnel interface and searches for a route with
the next longest match. The route that it finds might be the default route. Using this
route, the security device would then send the traffic unencrypted (that is, in clear
or plain text) out through a non-tunnel interface to the public WAN.

To avoid rerouting traffic originally intended for a VPN tunnel to the public WAN in
clear text, you can configure the security device to reroute such traffic to another
tunnel, reroute it to a leased line, or just drop it, by using one of the following
work-arounds:

 “Null Route” on page 81 (drops traffic when the route to the tunnel interface
becomes inactive)

 “Dialup or Leased Line” on page 83 (reroutes traffic to an alternate secure path

when the route to the tunnel interface becomes inactive)

 “Decoy Tunnel Interface” on page 86 (drops traffic when the route to the tunnel
interface becomes inactive)

 “Virtual Router for Tunnel Interfaces” on page 87 (drops traffic when the route
to the tunnel interface becomes inactive)

 “Reroute to Another Tunnel” on page 87 (reroutes traffic to an alternate VPN

tunnel when the route to the tunnel interface becomes inactive)

Null Route
If the state of a VPN tunnel changes to “down,” the security device changes any
route referencing that tunnel interface to “inactive.” If the route to the tunnel
interface becomes unavailable and the next choice is the default route (for
example), then the security device uses the default route to forward the traffic
originally intended for the VPN tunnel. To avoid sending traffic in plain text out to
the public WAN when a route change occurs, you can make use of a null route. A
null route targets the same destination address as the route through the tunnel
interface, but it instead points the traffic to the Null interface. The Null interface is a
logical interface that drops traffic sent to it. You give the null route a higher metric
(farther from zero) than the route using the tunnel interface so that the null route is
less preferred.

Route-Based Virtual Private Network Security Considerations  81

 Concepts & Examples ScreenOS Reference Guide

NOTE: Releases prior to ScreenOS 5.1.0 do not support a null interface. However, you can
use a decoy tunnel interface to accomplish the same objective. For information,
see “Decoy Tunnel Interface” on page 86.

For example, if you create a static route through tunnel.1 to a remote LAN with the
IP address 10.2.2.0/24, it automatically receives the default value of 1 for its metric:

set vrouter trust-vr route 10.2.2.0/24 interface tunnel.1

get route
…
Dest-Routes for <trust-vr> (4 entries)

ID IP-Prefix Interface Gateway P Pref Mtr Vsys

* 3 0.0.0.0/0 eth3 1.1.1.250 S 20 1 Root
* 2 1.1.1.0/24 eth3 0.0.0.0 C 0 0 Root
* 1 10.1.1.0/24 eth1 0.0.0.0 C 0 0 Root
* 4 10.2.2.0/24 tun.1 0.0.0.0 S 20 1 Root

In the above routing table, an asterisk ( * ) indicates that a route is active, S

indicates a static route, and “C” indicates a connected route.

In the routing table above, the security device has two routes to reach any address
in the 10.2.2.0/24 subnet. The first choice is route #4 because it has the longest
match with that address. The second choice is the default route (0.0.0.0/0).

If you then add another route to 10.2.2.0/24 through the Null interface and give it a
value greater than 1, that route becomes the second routing choice to any address
in the 10.2.2.0/24 subnet. If the route to 10.2.2.0/24 through tunnel.1 becomes
inactive, then the security device uses the route to the Null interface. The security
device forwards traffic for 10.2.2.0/24 to that interface, and then drops it.

set vrouter trust-vr route 10.2.2.0/24 interface null metric 10

get route
…
Dest-Routes for <trust-vr> (5 entries)

ID IP-Prefix Interface Gateway P Pref Mtr Vsys

* 3 0.0.0.0/0 eth3 1.1.1.250 S 20 1 Root
* 2 1.1.1.0/24 eth3 0.0.0.0 C 0 0 Root
* 1 10.1.1.0/24 eth1 0.0.0.0 C 0 0 Root
4 10.2.2.0/24 tun.1 0.0.0.0 S 20 1 Root
* 5 10.2.2.0/24 null 0.0.0.0 S 20 10 Root

In the routing table above, the route to 10.2.2.0/24 through tunnel.1 is inactive
(indicated by the absence of an asterisk in the far left column). Therefore, the
security device searches for the next route that has the longest match to the
destination address, and it finds route #5. (The next choice after route #5 is the

82  Route-Based Virtual Private Network Security Considerations

 Chapter 3: Virtual Private Network Guidelines

default route with ID #3.) The security device then forwards traffic for 10.2.2.0/24 to
the null interface, which drops the traffic. As a result, if the route using tunnel.1
becomes inactive, the security device drops traffic for 10.2.2.0/24 rather than using
route #3 to forward it out ethernet3 as clear text to the router at 1.1.1.250.

Dialup or Leased Line

If you do not want to drop traffic to a remote peer when the tunnel to that peer
becomes inactive, you can add an alternate route to that peer that flows over a
dialup or leased line. This alternate route uses the same destination IP address as
that in the route through the VPN tunnel, but it has a different egress interface and
a less-preferred metric. If the route through the VPN tunnel becomes inactive, then
the security device reroutes traffic to the remote peer through the dialup or leased
line.

When using a dialup or leased line as the next-choice route, there is still the
possibility that both the first- and second-choice routes can become inactive at the
same time. Then the security device resorts to the third choice, which might be the
default route. In anticipation of such a situation, you can make the dialup or leased
line route the second choice and the null route the third choice (see “Null Route” on
page 81). Figure 24 shows how these options for handling a routing failover can
work together.

Figure 24: Routing Failover Alternatives for VPN Traffic

First Choice: A VPN tunnel to

the remote peer. Local
Security
ethernet1 10.1.1.1/24 Device
Trust Zone Untrust Zone
ethernet3 1.1.1.1/24
Local
LAN tunnel.1 Internet Remote VPN Peer
Remote LAN
VPN Tunnel
Second Choice: A static route over a
dialup or leased line to the VPN peer. Its ethernet4
metric is greater than that of the route 1.2.2.1/24
using the VPN tunnel. This routing option Dialup or
forwards the traffic in clear text over the Null Lease Line
protected line to the peer. Interface

Drop
Third Choice: A null route with a metric Traffic
greater than that of the dialup or leased
line. This option drops the traffic.

Route-Based Virtual Private Network Security Considerations  83

 Concepts & Examples ScreenOS Reference Guide

VPN Failover to Leased Line or Null Route

In this example, you want traffic from the branch office behind Device A to reach
the corporate network behind Device B over a secure VPN connection. If the tunnel
fails, you then want traffic to flow over a leased line to the corporate office. If both
the VPN tunnel and the leased line fail, you want Device A to drop the traffic rather
than send it out onto the Internet in cleartext.

You create three routes on Device A to reach 10.2.2.0/24 and assign each a different
metric:

 Preferred Route—use tunnel.1, which is bound to vpn1 (metric = 1)

 Secondary Route—use ethernet4 and the gateway at 1.2.2.5 to use the leased
line (metric = 2)

 Tertiary Route—use the null interface to drop traffic (metric = 10)

When you create the preferred route, you use the default metric for a static route,
which is 1. You assign a metric of 2 to the secondary route; that is, the backup route
over the leased line (shown in Figure 25 on page 84). The metric is less than that of
the preferred route through the VPN tunnel. The security device does not use the
secondary route unless the preferred route through the VPN tunnel fails.

Finally, you add a NULL route with a metric of 10. If the preferred route fails and
then the secondary route fails, the security device drops all packets. All the security
zones are in the trust-vr routing domain.

NOTE: This example shows only the configuration for four routes—three for the failovers
plus the default route—on Device A.

Figure 25: Routing Failover to a Leased Line and Then to a Null Route

Traffic flows from the branch to

the corporate office.
Route Preferences:
1. tunnel.1 -> vpn1
2. ethernet4 -> leased line
3. null interface -> drop ethernet3 Gateway ethernet3
1.1.1.1/24 1.1.1.250 2.2.2.2/24
tunnel.1 tunnel.1

Device A Internet Device B

LAN LAN
10.1.1.0/24 10.2.2.0/24
vpn1

Leased Line (Back-Up Route)

NULL Route
Gateway: 1.2.2.5/24
ethernet4 ethernet4
1.2.2.1/24 2.3.3.2/24

84  Route-Based Virtual Private Network Security Considerations

 Chapter 3: Virtual Private Network Guidelines

WebUI (Device A)
Network > Routing > Routing Entries > trust-vr New: Enter the following,
then click OK:

Network Address/Netmask: 0.0.0.0/0

Gateway: (select)
Interface: ethernet3
Gateway IP Address: 1.1.1.250
Metric: 1

Network > Routing > Routing Entries > trust-vr New: Enter the following and
then click OK:

Network Address/Netmask: 10.2.2.0/24

Gateway: (select)
Interface: tunnel.1
Gateway IP Address: 0.0.0.0
Metric: 1

Network > Routing > Routing Entries > trust-vr New: Enter the following and
then click OK:

Network Address/Netmask: 10.2.2.0/24

Gateway: (select)
Interface: ethernet4
Gateway IP Address: 1.2.2.5
Metric: 2

Network > Routing > Routing Entries > trust-vr New: Enter the following and
then click OK:

Network Address/Netmask: 10.2.2.0/24

Gateway: (select)
Interface: Null
Gateway IP Address: 0.0.0.0
Metric: 10

CLI (Device A)
set vrouter trust-vr route 0.0.0.0/0 interface ethernet3 gateway 1.1.1.250
set vrouter trust-vr route 10.2.2.0/24 interface tunnel.1
set vrouter trust-vr route 10.2.2.0/24 interface ethernet4 gateway 1.2.2.5 metric
2
set vrouter trust-vr route 10.2.2.0/24 interface null metric 10
save

Route-Based Virtual Private Network Security Considerations  85

 Concepts & Examples ScreenOS Reference Guide

You can verify that the new routes are present by executing the get route
command.

device-C-> get route

IPv4 Dest-Routes for <untrust-vr> (0 entries)

--------------------------------------------------------------------------------
H: Host C: Connected S: Static A: Auto-Exported
I: Imported R: RIP P: Permanent D: Auto-Discovered
iB: IBGP eB: EBGP O: OSPF E1: OSPF external type 1
E2: OSPF external type 2

IPv4 Dest-Routes for <trust-vr> (7 entries)

--------------------------------------------------------------------------------
ID IP-Prefix Interface Gateway P Pref Mtr Vsys
--------------------------------------------------------------------------------
* 8 0.0.0.0/0 eth1/1 10.100.37.1 S 20 1 Root
* 7 1.1.1.1/32 eth1/2 0.0.0.0 H 0 0 Root
* 3 192.168.1.1/32 mgt 0.0.0.0 H 0 0 Root
* 2 192.168.1.0/24 mgt 0.0.0.0 C 0 0 Root
* 4 10.100.37.0/24 eth1/1 0.0.0.0 C 0 0 Root
* 5 10.100.37.170/32 eth1/1 0.0.0.0 H 0 0 Root
* 6 1.1.1.0/24 eth1/2 0.0.0.0 C 0 0 Root

The route table entry with ID 5 directs traffic for 10.2.2.0/24 to tunnel.1 and then
through the VPN tunnel. It is the preferred route for traffic to reach the 10.2.2.0
network. If that tunnel fails, the next best route is route entry 6 over a leased line
through a gateway at 1.2.2.5. If the connection for route entry 6 fails, route entry 7
becomes the next best route, and the security device directs traffic for 10.2.2.0/24
to the null interface, which then drops it.

Decoy Tunnel Interface

Instead of failing over traffic from a VPN tunnel to a null interface (and then
dropping it), you can use a nonfunctioning tunnel interface to accomplish the same
objective.

NOTE: Releases prior to ScreenOS 5.1.0 do not support a null interface (see “Null Route”
on page 81). However, you can use a decoy tunnel interface to accomplish the
same objective.

To set up a decoy tunnel interface, do the following:

1. Create a second tunnel interface, but do not bind it to a VPN tunnel. Instead,
bind it to a tunnel zone that is in the same virtual routing domain as the first
tunnel interface.

NOTE: If a tunnel interface is bound to a tunnel zone, its status is always up.

86  Route-Based Virtual Private Network Security Considerations

 Chapter 3: Virtual Private Network Guidelines

2. Define a second route to the same destination using this second tunnel
interface, and assign it a higher metric (farther from zero) than the preferred
route.

If the state of the functioning tunnel interface changes from up to down and the
route table entry referencing that interface becomes inactive, all subsequent
route lookups find this second route to the nonfunctioning tunnel interface. The
security device forwards traffic to the second tunnel interface and because it is
not bound to a VPN tunnel, the device drops the traffic.

Virtual Router for Tunnel Interfaces

To avoid the case where the route through a VPN tunnel becomes deactivated and
then fails over traffic originally intended to pass through the tunnel to the default
route, you can create a special virtual routing domain exclusively for VPN traffic. To
set this up, take the following steps:

1. Create a separate virtual router to use for all routes pointing to tunnel interfaces
and name it, for example, “VR-VPN.”

2. Create a security zone—named, for example, “VPN zone”—and bind it to

VR-VPN.

3. Bind all tunnel interfaces to the VPN zone, and also put all addresses for remote
sites that you want to reach through VPN tunnels in this zone.

4. Configure static routes in all other virtual routers to VR-VPN for traffic that you
want encrypted and sent through the tunnels. If necessary, define static routes
for decrypted traffic from VR-VPN to the other virtual routers. Such routes are
necessary to allow inbound VPN traffic through the tunnel if it is initiated from
the remote site.

If the state of a tunnel interface changes from up to down, the security device
still forwards traffic to VR-VPN, where—because the state of the route to that
interface is now inactive and there are no other matching routes—the security
device drops the traffic.

Reroute to Another Tunnel

You can configure two or more VPN tunnels to the same remote peer. If one tunnel
goes down, the security device can then reroute traffic through another VPN tunnel.
For information and examples about configuring redundant VPN tunnels, see the
following:

 “Active-to-Backup Tunnel Failover” on page 11-56

 “Configuring Dual Active Tunnels” on page 11-76

 “Configuring Tunnel Failover Weights” on page 11-82

Route-Based Virtual Private Network Security Considerations  87

 Concepts & Examples ScreenOS Reference Guide

88  Route-Based Virtual Private Network Security Considerations

Chapter 4
Site-to-Site Virtual Private Networks

This chapter explains how to configure a site-to-site virtual private network (VPN)
tunnel between two Juniper Networks security devices. It examines route-based and
policy-based VPN tunnels, presents the various elements that you must consider
when setting up a tunnel, and offers several examples.

This chapter contains the following sections:

 “Site-to-Site VPN Configurations” on page 90

 “Route-Based Site-to-Site VPN, AutoKey IKE” on page 96

 “Policy-Based Site-to-Site VPN, AutoKey IKE” on page 105

 “Route-Based Site-to-Site VPN, Dynamic Peer” on page 111

 “Policy-Based Site-to-Site VPN, Dynamic Peer” on page 119

 “Route-Based Site-to-Site VPN, Manual Key” on page 128

 “Policy-Based Site-to-Site VPN, Manual Key” on page 134

 “Dynamic IKE Gateways Using FQDN” on page 139

 “Aliases” on page 140

 “Setting AutoKey IKE Peer with FQDN” on page 141

 “VPN Sites with Overlapping Addresses” on page 150

 “Transparent Mode VPN” on page 161

 89
 Concepts & Examples ScreenOS Reference Guide

Site-to-Site VPN Configurations

An IPSec VPN tunnel exists between two gateways, and each gateway needs an IP
address. When both gateways have static IP addresses, you can configure the
following kinds of tunnels:

 Site-to-Site VPN, AutoKey IKE tunnel (with a preshared key or certificates)

 Site-to-Site VPN, Manual Key tunnel

When one gateway has a static address and the other has a dynamically assigned
address, you can configure the following kind of tunnel:

 Dynamic Peer Site-to-Site VPN, AutoKey IKE tunnel (with a preshared key or
certificates)

As used here, a static site-to-site VPN involves an IPSec tunnel connecting two sites,
each with a security device operating as a secure gateway. The physical interface or
subinterface used as the outgoing interface on both devices has a fixed IP address,
and the internal hosts also have static IP addresses. If the security device is in
Transparent mode, it uses the VLAN1 address as the IP address for the outgoing
interface. With a static site-to-site VPN, hosts at either end of the tunnel can initiate
the VPN tunnel setup because the IP address of the remote gateway remains
constant and thus reachable.

If the outgoing interface of one of the security devices has a dynamically assigned
IP address, that device is termed a dynamic peer and the VPN is configured
differently. With a dynamic peer site-to-site VPN, only hosts behind the dynamic
peer can initiate the VPN tunnel setup because only their remote gateway has a
fixed IP address and is thus reachable from their local gateway. However, after a
tunnel is established between a dynamic peer and a static peer, hosts behind either
gateway can initiate VPN traffic if the destination hosts have fixed IP addresses.

NOTE: For background information about the available VPN options, see “Internet
Protocol Security” on page 1. For guidance when choosing among the various
options, see “Virtual Private Network Guidelines” on page 57.

The configuration of a site-to-site VPN tunnel requires the coordination of the tunnel
configuration with that of other settings—interfaces, addresses, routes, and policies.
The three example VPN configurations in this section are set in the following
context: an office in Tokyo wants to communicate securely with an office in Paris
through an IPSec VPN tunnel.

90  Site-to-Site VPN Configurations

 Chapter 4: Site-to-Site Virtual Private Networks

Figure 26: Site-to-Site VPN Tunnel Configuration

Tokyo Untrust Zone

Trust Zone
Office

tunnel.1, Unnumbered
ethernet1
10.1.1.1/24 ethernet3, 1.1.1.1/24
NAT
external router, 1.1.1.250
Tokyo
Security Device
LAN Internet LAN
10.1.1.0/24 10.2.2.0/24
Tunnel:vpn1 Paris
Security Device
external router, 2.2.2.250
ethernet1
ethernet3, 2.2.2.2/24 10.2.2.1/24

tunnel.1, Unnumbered

Untrust Zone Paris Trust Zone

Office

The administrators in both offices configure the following settings:

 Interfaces – Security Zones and Tunnel

 Addresses

 VPN (one of the following)

 AutoKey IKE

 Dynamic Peer

 Manual Key

 Routes

 Policies

Site-to-Site VPN Configurations  91

 Concepts & Examples ScreenOS Reference Guide

Figure 27: Site-to-Site Tunnel Configuration—Interfaces

Trust Zone Tokyo Untrust Zone

Office

tunnel.1, Unnumbered
ethernet1
10.1.1.1/24 Eth3, 1.1.1.1/24
NAT
Tokyo
Security Device
Internet
Paris
Security Device

ethernet1
Eth3, 2.2.2.2/24 10.2.2.1/24
NAT
tunnel.1, Unnumbered

Untrust Zone Paris Trust Zone

Office

1. Interfaces – Security Zones and Tunnel

The admin at the Tokyo office configures the security zone and tunnel interfaces
with the settings that appear in the upper half of Figure 27. The admin at the Paris
office does likewise with the settings that appear in the lower half of the figure.

Ethernet3 is going to be the outgoing interface for VPN traffic and the remote
gateway for VPN traffic sent from the other end of the tunnel.

Ethernet1 is in NAT mode so each admin can assign IP addresses to all the internal
hosts, yet when traffic passes from the Trust zone to the Untrust zone, the security
device translates the source IP address in the packet headers to the address of the
Untrust zone interface, ethernet3—1.1.1.1 for Tokyo, and 2.2.2.2 for Paris.

For a route-based VPN, each admin binds the tunnel interface tunnel.1 to the VPN
tunnel vpn1. By defining a route to the address space of the remote office LAN, the
security device can direct all traffic bound for that LAN to the tunnel.1 interface and
thus through the tunnel to which tunnel.1 is bound.

Because policy-based NAT services are not needed, a route-based VPN configuration
does not require tunnel.1 to have an IP address/netmask, and a policy-based VPN
configuration does not even require a tunnel interface.

92  Site-to-Site VPN Configurations

 Chapter 4: Site-to-Site Virtual Private Networks

Figure 28: Site-to-Site Tunnel Configuration—Addresses

Trust Zone Tokyo Untrust Zone

Office
tunnel.1, Unnumbered
ethernet1 ethernet3, 1.1.1.1/24
10.1.1.1/24
Trust_LAN Tokyo
Trust, 10.1.1.0/24 NAT
Security Device Paris
Tokyo Internet LAN Untrust, 10.2.2.0/24
LAN
Untrust 10.1.1.0/24 Paris Trust_LAN
Security Device Trust 10.2.2.0/24

ethernet3, 2.2.2.2/24 ethernet1

10.2.2.1/24
tunnel.1, Unnumbered NAT
Paris
Untrust Zone Office Trust Zone

2. Addresses
The admins define addresses for later use in inbound and outbound policies. The
admin at the Tokyo office defines the addresses that appear in the upper half of
Figure 28. The admin at the Paris office does likewise with the addresses that
appear in the lower half of the figure.

For policy-based VPNs, the security device derives proxy IDs from policies. Because
the proxy IDs used by the security devices at both ends of the VPN tunnel must
match perfectly, you cannot use the predefined address “ANY,” whose IP address is
0.0.0.0/0, at one end of the tunnel if you use a more specific address at the other
end. For example:

If the proxy ID in Tokyo is as follows:

From: 0.0.0.0/0
To: 10.2.2.0/24
Service: ANY

And if the proxy ID in Paris is as follows:

To: 10.1.1.0/24
From: 10.2.2.0/24
Service: ANY

Then the proxy IDs do not match, and IKE negotiations will fail.

NOTE: Beginning with ScreenOS 5.0.0, you can also define proxy IDs for VPN tunnels
referenced in policy-based VPN configurations.

For route-based VPNs, you can use “0.0.0.0/0–0.0.0.0/0–any” to define the local
and remote IP addresses and service type for a proxy ID. You can then use more
restrictive policies to filter the inbound and outbound VPN traffic by source address,
destination address, and service type.

Site-to-Site VPN Configurations  93

 Concepts & Examples ScreenOS Reference Guide

Figure 29: Site-to-Site Tunnel Configuration—VPN Tunnel

Trust Zone Tokyo Untrust Zone

Office
Tunnel.1, Unnumbered
ethernet1 ethernet3, 1.1.1.1/24
10.1.1.1/24
Trust_LAN NAT Tokyo Trust_LAN
Trust, 10.1.1.0/24 Security Device Internet Trust 10.2.2.0/24
LAN LAN
Tokyo Paris
Tunnel: vpn1 Paris Untrust, 10.2.2.0/24
Untrust 10.1.1.0/24
Security Device

ethernet3, 2.2.2.2/24 ethernet1

10.2.2.1/24
tunnel.1, Unnumbered NAT
Paris
Untrust Zone Trust Zone
Office

3. VPN
You can configure one of the following three VPNs:

 AutoKey IKE

The AutoKey IKE method uses a preshared key or a certificate to refresh—that

is, change—the encryption and authentication keys automatically at
user-defined intervals (known as key lifetimes). Essentially, frequently updating
these keys strengthens security, although excessively short lifetimes might
reduce overall performance.

 Dynamic Peer

A dynamic peer is a remote gateway that has a dynamically assigned IP

address. Because the IP address of the remote peer might be different each
time IKE negotiations begin, hosts behind the peer must initiate VPN traffic.
Also—if using a preshared key for authentication—the peer must send an IKE
ID during the first message of Phase 1 negotiations in aggressive mode to
identify itself.

 Manual Key

The Manual Key method requires you to set and update the encryption and
authentication keys manually. This method is a viable option for a small set of
VPN tunnels.

94  Site-to-Site VPN Configurations

 Chapter 4: Site-to-Site Virtual Private Networks

Figure 30: Site-to-Site Tunnel Configuration—Routes

trust-vr Tokyo
Dst 10.2.2.0/24 Trust Zone Untrust Zone
Use tunnel. 1 Office
tunnel.1, Unnumbered Trust_LAN
Dst 10.2.2.0/24 ethernet1 ethernet3, 1.1.1.1/24 Trust, 10.2.2.0/24
Use NULL 10.1.1.1/24 Paris
Metric: 50 Null Interface External router, 1.1.1.250 Untrust,
NAT
10.2.2.0/24
Dst 0.0.0.0/0 Internet trust-vr
LAN LAN
Use eth3 Tunnel:vpn1 Dst 10.1.1.0/24
gateway: 1.1.1.250 Use tunnel. 1

Trust_LAN external router, 2.2.2.250 Null Interface

Dst 10.1.1.0/24
Trust, 10.1.1.0/24 ethernet3, 2.2.2.2/24 ethernet1 Use NULL
10.2.2.1/24 Metric: 50
Tokyo tunnel.1, Unnumbered NAT
Untrust, 10.1.1.0/24 Paris Dst 0.0.0.0/0
Untrust Zone Office Trust Zone Use eth3
gateway:
2.2.2.250

4. Routes
The admins at each site must configure at least the following routes:

 A route for traffic to reach an address on the remote LAN to use tunnel.1

 A default route for all other traffic, including the outer VPN tunnel traffic, to
reach the internet through ethernet3 and then the external router beyond
it—1.1.1.250 for the Tokyo office and 2.2.2.250 for Paris. The external router is
the default gateway to which the security device forwards any traffic for which
it does not have a specific route in its routing table.

NOTE: If the security device at the Tokyo office receives its external IP address
dynamically from its ISP (that is, from the point of view of the Paris office, the
security device at the Tokyo office is its dynamic peer), then the ISP automatically
provides the Tokyo device with its default gateway IP address.

 A null route so that if the state of tunnel.1 ever changes to “down” and any
route referencing tunnel.1 becomes deactivated, the security device does not
use the default route to forward traffic destined to the remote LAN unencrypted
out ethernet3. A null route uses the remote LAN as the destination address, but
it points traffic to the Null interface, a logical interface that drops traffic sent to
it. You give the null route a higher metric (farther from zero) than the route to
the remote LAN using tunnel.1, making the null route less preferred than the
route referencing the tunnel.1 interface.

Site-to-Site VPN Configurations  95

 Concepts & Examples ScreenOS Reference Guide

Figure 31: Site-to-Site Tunnel Configuration—Policies

trust-vr trust-vr
Dst 10.2.2.0/24 Tokyo Dst 10.1.1.0/24
Use tunnel. 1 Trust Zone Untrust Zone
Office Use tunnel. 1

Dst 0.0.0.0/0 tunnel.1, Unnumbered Dst 0.0.0.0/0

Use eth1 ethernet1 ethernet3, 1.1.1.1/24 Use eth3
gateway: 10.1.1.1/24 Null Interface gateway:
1.1.1.250 NAT External router, 1.1.1.250 2.2.2.250
Internet Trust_LAN
Trust_LAN LAN LAN
Trust, 10.1.1.0/24 Trust, 10.2.2.0/24
Tunnel:vpn1

Tokyo Null Interface Paris

external router, 2.2.2.250 ethernet1 Untrust,
Untrust,
10.1.1.0/24 ethernet3, 2.2.2.2/24 10.2.2.1/24 10.2.2.0/24
tunnel.1, Unnumbered NAT
Trust-> Untrust
Trust-> Untrust Paris Trust_LAN ->Paris
Trust_LAN ->Paris Untrust Zone Office Trust Zone ANY, Permit
ANY, Permit
Untrust -> Trust
Untrust -> Trust Paris ->
Paris -> Trust_LAN Trust_LAN
ANY, Permit ANY, Permit

5. Policies
The admins at each site define policies to permit traffic between the two offices:

 A policy permitting any kind of traffic from “Trust_LAN” in the Trust zone to
“Paris” or “Tokyo” in the Untrust zone

 A policy permitting any kind of traffic from “Paris” or “Tokyo” in the Untrust
zone to “Trust_LAN” in the Trust zone

Because the preferred route to the remote site specifies tunnel.1, which is bound to
the VPN tunnel vpn1, the policy does not need to reference the VPN tunnel.

Route-Based Site-to-Site VPN, AutoKey IKE

In this example, an AutoKey IKE tunnel using either a preshared secret or a pair of
certificates (one at each end of the tunnel) provides the secure connection between
the Tokyo and Paris offices. For the Phase 1 and Phase 2 security levels, you specify
one Phase 1 proposal—either pre-g2-3des-sha for the preshared key method or
rsa-g2-3des-sha for certificates—and select the predefined “Compatible” set of
proposals for Phase 2. All zones are in the trust-vr.

96  Site-to-Site VPN Configurations

 Chapter 4: Site-to-Site Virtual Private Networks

Figure 32: Route-Based Site-to-Site VPN, AutoKey IKE

Topology of the zones Topology of the zones

configured on the security configured on the security
device in Tokyo device in Paris
Tokyo Paris Tokyo Paris

Trust Untrust Untrust Trust

Zone Zone Zone Zone

Outgoing Interface
Outgoing Interface
Untrust Zone
Untrust Zone
eth3, 1.1.1.1/24
Tokyo eth3, 2.2.2.2/24 Paris
Gateway 1.1.1.250
Trust Zone Gateway 2.2.2.250 Trust Zone
eth1, 10.1.1.1/24 eth1, 10.2.2.1/24
Internet

VPN Tunnel

Tunnel Interface Tunnel Interface

Tunnel.1 Tunnel.1

Setting up a route-based AutoKey IKE tunnel using either a preshared secret or

certificates, involves the following steps:

1. Assign IP addresses to the physical interfaces bound to the security zones and
to the tunnel interface.

2. Configure the VPN tunnel, designate its outgoing interface in the Untrust zone,
bind it to the tunnel interface, and configure its proxy-ID.

3. Enter the IP addresses for the local and remote endpoints in the address books
for the Trust and Untrust zones.

4. Enter a default route to the external router in the trust-vr, a route to the
destination through the tunnel interface, and a null route to the destination. You
assign a higher metric (farther from zero) to the null route so that it becomes
the next-choice route to the destination. Then, if the state of the tunnel
interface changes to “down” and the route referencing that interface becomes
inactive, the security device uses the null route, which essentially drops any
traffic sent to it, rather than the default route, which forwards unencrypted
traffic.

5. Set up policies for VPN traffic to pass between each site.

In the following examples, the preshared key is h1p8A24nG5. It is assumed that

both participants already have RSA certificates and are using Entrust as the
certificate authority (CA). (For information about obtaining and loading certificates,
see “Certificates and CRLs” on page 34.)

Site-to-Site VPN Configurations  97

 Concepts & Examples ScreenOS Reference Guide

WebUI (Tokyo)
1. Interfaces
Network > Interfaces > Edit (for ethernet1): Enter the following, then click
Apply:

Zone Name: Trust

Static IP: (select this option when present)
IP Address/Netmask: 10.1.1.1/24

Select the following, then click OK:

Interface Mode: NAT

Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:

Zone Name: Untrust

Static IP: (select this option when present)
IP Address/Netmask: 1.1.1.1/24

Network > Interfaces > New Tunnel IF: Enter the following, then click OK:

Tunnel Interface Name: tunnel.1

Zone (VR): Untrust (trust-vr)
Unnumbered: (select)
Interface: ethernet3 (trust-vr)
2. Addresses
Policy > Policy Elements> Addresses > List > New: Enter the following, then
click OK:

Address Name: Trust_LAN

IP Address/Domain Name:
IP/Netmask: (select), 10.1.1.0/24
Zone: Trust

Policy > Policy Elements> > Addresses > List > New: Enter the following,
then click OK:

Address Name: Paris_Office

IP Address/Domain Name:
IP/Netmask: (select), 10.2.2.0/24
Zone: Untrust
3. VPN
VPNs > AutoKey Advanced > Gateway > New: Enter the following, then click
OK:

Gateway Name: To_Paris

Security Level: Custom
Remote Gateway Type:
Static IP Address: (select), IP Address/Hostname: 2.2.2.2

98  Site-to-Site VPN Configurations

 Chapter 4: Site-to-Site Virtual Private Networks

Preshared Key
Preshared Key: h1p8A24nG5
Outgoing Interface: ethernet3

> Advanced: Enter the following advanced settings, then click Return to
return to the basic Gateway configuration page:

Security Level: Custom

Phase 1 Proposal (for Custom Security Level): pre-g2-3des-sha
Mode (Initiator): Main (ID Protection)

(or)

Certificates
Outgoing Interface: ethernet3

> Advanced: Enter the following advanced settings, then click Return to
return to the basic Gateway configuration page:

Security Level: Custom

Phase 1 Proposal (for Custom Security Level): rsa-g2-3des-sha
Preferred certificate (optional)
Peer CA: Entrust
Peer Type: X509-SIG

VPNs > AutoKey IKE > New: Enter the following, then click OK:

VPN Name: Tokyo_Paris

Security Level: Compatible
Remote Gateway:
Predefined: (select), To_Paris

> Advanced: Enter the following advanced settings, then click Return to
return to the basic AutoKey IKE configuration page:

Security Level: Compatible

Bind to: Tunnel Interface, tunnel.1
Proxy-ID: (select)
Local IP / Netmask: 10.1.1.0/24
Remote IP / Netmask: 10.2.2.0/24
Service: ANY
4. Routes
Network > Routing > Routing Entries > trust-vr New: Enter the following,
then click OK:

Network Address/Netmask: 0.0.0.0/0

Gateway: (select)
Interface: ethernet3
Gateway IP Address: 1.1.1.250

Network > Routing > Routing Entries > trust-vr New: Enter the following,
then click OK:

Network Address/Netmask: 10.2.2.0/24

Gateway: (select)
Interface: Tunnel.1
Gateway IP Address: 0.0.0.0

Site-to-Site VPN Configurations  99

 Concepts & Examples ScreenOS Reference Guide

Network > Routing > Routing Entries > trust-vr New: Enter the following,
then click OK:

Network Address/Netmask: 10.2.2.0/24

Gateway: (select)
Interface: Null
Gateway IP Address: 0.0.0.0
Metric: 10
5. Policies
Policies > (From: Trust, To: Untrust) New: Enter the following, then click OK:

Name: To Paris
Source Address: Trust_LAN
Destination Address: Paris_Office
Service: ANY
Action: Permit
Position at Top: (select)

Policies > (From: Untrust, To: Trust) > New: Enter the following, then click OK:

Name: From Paris

Source Address: Paris_Office
Destination Address: Trust_LAN
Service: ANY
Action: Permit
Position at Top: (select)

WebUI (Paris)
1. Interfaces
Network > Interfaces > Edit (for ethernet1): Enter the following, then click
Apply:

Zone Name: Trust

Static IP: (select this option when present)
IP Address/Netmask: 10.2.2.1/24

Select the following, then click OK:

Interface Mode: NAT

Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:

Zone Name: Untrust

Static IP: (select this option when present)
IP Address/Netmask: 2.2.2.2/24

Network > Interfaces > New Tunnel IF: Enter the following, then click OK:

Tunnel Interface Name: tunnel.1

Zone (VR): Untrust (trust-vr)
Unnumbered: (select)
Interface: ethernet3 (trust-vr)

100  Site-to-Site VPN Configurations

 Chapter 4: Site-to-Site Virtual Private Networks

2. Addresses
Policy > Policy Elements> > Addresses > List > New: Enter the following,
then click OK:

Address Name: Trust_LAN

IP Address/Domain Name:
IP/Netmask: (select), 10.2.2.0/24
Zone: Trust

Policy > Policy Elements> > Addresses > List > New: Enter the following,
then click OK:

Address Name: Tokyo_Office

IP Address/Domain Name:
IP/Netmask: (select), 10.1.1.0/24
Zone: Untrust
3. VPN
VPNs > AutoKey Advanced > Gateway > New: Enter the following, then click
OK:

Gateway Name: To_Tokyo

Security Level: Custom
Remote Gateway Type:
Static IP Address: (select), IP Address/Hostname: 1.1.1.1
Preshared Key
Preshared Key: h1p8A24nG5
Outgoing Interface: ethernet3

> Advanced: Enter the following advanced settings, then click Return to
return to the basic Gateway configuration page:

Security Level: Custom

Phase 1 Proposal (For Custom Security Level): pre-g2-3des-sha
Mode (Initiator): Main (ID Protection)

(or)

Certificates
Outgoing Interface: ethernet3

> Advanced: Enter the following advanced settings, then click Return to
return to the basic Gateway configuration page:

Security Level: Custom

Phase 1 Proposal (for Custom Security Level): rsa-g2-3des-sha
Preferred certificate (optional)
Peer CA: Entrust
Peer Type: X509-SIG

VPNs > AutoKey IKE > New: Enter the following, then click OK:

Name: Paris_Tokyo
Security Level: Compatible
Remote Gateway:
Predefined: (select), To_Tokyo

Site-to-Site VPN Configurations  101

 Concepts & Examples ScreenOS Reference Guide

> Advanced: Enter the following advanced settings, then click Return to
return to the basic AutoKey IKE configuration page:

Security Level: Compatible

Bind to: Tunnel Interface, tunnel.1
Proxy-ID: (select)
Local IP / Netmask: 10.2.2.0/24
Remote IP / Netmask: 10.1.1.0/24
Service: ANY
4. Routes
Network > Routing > Routing Entries > trust-vr New: Enter the following,
then click OK:

Network Address/Netmask: 0.0.0.0/0

Gateway: (select)
Interface: ethernet3
Gateway IP Address: 2.2.2.250

Network > Routing > Routing Entries > trust-vr New: Enter the following,
then click OK:

Network Address/Netmask: 10.1.1.0/24

Gateway: (select)
Interface: Tunnel.1
Gateway IP Address: 0.0.0.0

Network > Routing > Routing Entries > trust-vr New: Enter the following,
then click OK:

Network Address/Netmask: 10.1.1.0/24

Gateway: (select)
Interface: Null
Gateway IP Address: 0.0.0.0
Metric: 10
5. Policies
Policies > (From: Trust, To: Untrust) New: Enter the following, then click OK:

Name: To_Tokyo
Source Address:
Address Book Entry: (select), Trust_LAN
Destination Address:
Address Book Entry: (select), Tokyo_Office
Service: ANY
Action: Permit
Position at Top: (select)

Policies > (From: Untrust, To: Trust) New: Enter the following, then click OK:

Name: From_Tokyo
Source Address:
Address Book Entry: (select), Tokyo_Office
Destination Address:
Address Book Entry: (select), Trust_LAN
Service: ANY
Action: Permit
Position at Top: (select)

102  Site-to-Site VPN Configurations

 Chapter 4: Site-to-Site Virtual Private Networks

CLI (Tokyo)
1. Interfaces
set interface ethernet1 zone trust
set interface ethernet1 ip 10.1.1.1/24
set interface ethernet1 nat
set interface ethernet3 zone untrust
set interface ethernet3 ip 1.1.1.1/24
set interface tunnel.1 zone untrust
set interface tunnel.1 ip unnumbered interface ethernet3
2. Addresses
set address trust Trust_LAN 10.1.1.0/24
set address untrust Paris_Office 10.2.2.0/24
3. VPN
Preshared Key
set ike gateway To_Paris address 2.2.2.2 main outgoing-interface ethernet3
preshare h1p8A24nG5 proposal pre-g2-3des-sha
set vpn Tokyo_Paris gateway To_Paris sec-level compatible
set vpn Tokyo_Paris bind interface tunnel.1
set vpn Tokyo_Paris proxy-id local-ip 10.1.1.0/24 remote-ip 10.2.2.0/24 any

(or)

Certificate
set ike gateway To_Paris address 2.2.2.2 main outgoing-interface ethernet3
proposal rsa-g2-3des-sha
set ike gateway To_Paris cert peer-ca 1
set ike gateway To_Paris cert peer-cert-type x509-sig
set vpn Tokyo_Paris gateway To_Paris sec-level compatible
set vpn Tokyo_Paris bind interface tunnel.1
set vpn Tokyo_Paris proxy-id local-ip 10.1.1.0/24 remote-ip 10.2.2.0/24 any

NOTE: The number 1 is the CA ID number. To discover the CA’s ID number, use the
following command: get ike ca.

4. Routes
set vrouter trust-vr route 0.0.0.0/0 interface ethernet3 gateway 1.1.1.250
set vrouter trust-vr route 10.2.2.0/24 interface tunnel.1
set vrouter trust-vr route 10.2.2.0/24 interface null metric 10
5. Policies
set policy top name “To Paris” from trust to untrust Trust_LAN Paris_Office any
permit
set policy top name “From Paris” from untrust to trust Paris_Office Trust_LAN any
permit
save

Site-to-Site VPN Configurations  103

 Concepts & Examples ScreenOS Reference Guide

CLI (Paris)
1. Interfaces
set interface ethernet1 zone trust
set interface ethernet1 ip 10.2.2.1/24
set interface ethernet1 nat
set interface ethernet3 zone untrust
set interface ethernet3 ip 2.2.2.2/24
set interface tunnel.1 zone untrust
set interface tunnel.1 ip unnumbered interface ethernet3
2. Addresses
set address trust Trust_LAN 10.2.2.0/24
set address untrust Tokyo_Office 10.1.1.0/24
3. VPN
Preshared Key
set ike gateway To_Tokyo address 1.1.1.1 main outgoing-interface ethernet3
preshare h1p8A24nG5 proposal pre-g2-3des-sha
set vpn Paris_Tokyo gateway To_Tokyo sec-level compatible
set vpn Paris_Tokyo bind interface tunnel.1
set vpn Paris_Tokyo proxy-id local-ip 10.2.2.0/24 remote-ip 10.1.1.0/24 any

(or)

Certificate
set ike gateway To_Tokyo address 1.1.1.1 main outgoing-interface ethernet3
proposal rsa-g2-3des-sha
set ike gateway To_Tokyo cert peer-ca 1
set ike gateway To_Tokyo cert peer-cert-type x509-sig
set vpn Paris_Tokyo gateway To_Tokyo sec-level compatible
set vpn Paris_Tokyo bind interface tunnel.1
set vpn Paris_Tokyo proxy-id local-ip 10.2.2.0/24 remote-ip 10.1.1.0/24 any
4. Routes
set vrouter trust-vr route 0.0.0.0/0 interface ethernet3 gateway 2.2.2.250
set vrouter trust-vr route 10.1.1.0/24 interface tunnel.1
set vrouter trust-vr route 10.1.1.0/24 interface null metric 10
5. Policies
set policy top name “To Tokyo” from trust to untrust Trust_LAN Tokyo_Office any
permit
set policy top name “From Tokyo” from untrust to trust Tokyo_Office Trust_LAN any
permit
save

104  Site-to-Site VPN Configurations

 Chapter 4: Site-to-Site Virtual Private Networks

Policy-Based Site-to-Site VPN, AutoKey IKE

In this example, an AutoKey IKE tunnel using either a preshared secret or a pair of
certificates (one at each end of the tunnel) provides the secure connection between
the Tokyo and Paris offices. For the Phase 1 and Phase 2 security levels, you specify
one Phase 1 proposal—either pre-g2-3des-sha for the preshared key method or
rsa-g2-3des-sha for certificates—and select the predefined “Compatible” set of
proposals for Phase 2. All zones are in the trust-vr.

Figure 33: Policy-Based Site-to-Site VPN, AutoKey IKE

Topology of the zones Topology of the zones

configured on the security configured on the security
device in Tokyo device in Paris
Tokyo Paris Tokyo Paris

Trust Untrust-Tun Untrust Untrust Untrust-Tun Trust

Zone Zone Zone Zone Zone Zone

Outgoing Interface Outgoing Interface

Untrust Zone Untrust Zone
eth3, 1.1.1.1/24 eth3, 2.2.2.2/24
Tokyo Gateway 1.1.1.250 Gateway 2.2.2.250 Paris
Trust Zone Trust Zone
eth1, 10.1.1.1/24 eth1, 10.2.2.1/24
Internet

VPN Tunnel

Setting up the AutoKey IKE tunnel using AutoKey IKE, with either a preshared secret
or certificates, involves the following steps:

1. Define security zone interface IP addresses.

2. Make address book entries for the local and remote end entities.

3. Define the remote gateway and key exchange mode, and specify either a
preshared secret or a certificate.

4. Create the Autokey IKE VPN.

5. Set a default route to the external router.

6. Configure policies.

In the following examples, the preshared key is h1p8A24nG5. It is assumed that

both participants already have RSA certificates and are using Entrust as the
certificate authority (CA). (For information about obtaining and loading certificates,
see “Certificates and CRLs” on page 34.)

Site-to-Site VPN Configurations  105

 Concepts & Examples ScreenOS Reference Guide

WebUI (Tokyo)
1. Interfaces
Network > Interfaces > Edit (for ethernet1): Enter the following, then click
Apply:

Zone Name: Trust

Static IP: (select this option when present)
IP Address/Netmask: 10.1.1.1/24

Select the following, then click OK:

Interface Mode: NAT

Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:

Zone Name: Untrust

Static IP: (select this option when present)
IP Address/Netmask: 1.1.1.1/24
2. Addresses
Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: Trust_LAN

IP Address/Domain Name:
IP/Netmask: (select), 10.1.1.0/24
Zone: Trust

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: Paris_Office

IP Address/Domain Name:
IP/Netmask: (select), 10.2.2.0/24
Zone: Untrust
3. VPN
VPNs > AutoKey Advanced > Gateway > New: Enter the following, then click
OK:

Gateway Name: To_Paris

Security Level: Custom
Remote Gateway Type:
Static IP Address: (select), IP Address/Hostname: 2.2.2.2
Preshared Key
Preshared Key: h1p8A24nG5
Outgoing Interface: ethernet3

> Advanced: Enter the following advanced settings, then click OK to return
to the basic Gateway configuration page:

Security Level: Custom

Phase 1 Proposal (For Custom Security Level): pre-g2-3des-sha
Mode (Initiator): Main (ID Protection)

106  Site-to-Site VPN Configurations

 Chapter 4: Site-to-Site Virtual Private Networks

(or)

Certificates
Outgoing Interface: ethernet3

> Advanced: Enter the following advanced settings, then click OK to return
to the basic Gateway configuration page:

Security Level: Custom

Phase 1 Proposal (For Custom Security Level): rsa-g2-3des-sha
Mode (Initiator): Main (ID Protection)
Preferred certificate (optional)
Peer CA: Entrust
Peer Type: X509-SIG

VPNs > AutoKey IKE > New: Enter the following, then click OK:

VPN Name: Tokyo_Paris

Security Level: Compatible
Remote Gateway: Predefined: (select), To_Paris
4. Route
Network > Routing > Routing Entries > trust-vr New: Enter the following,
then click OK:

Network Address/Netmask: 0.0.0.0/0

Gateway: (select)
Interface: ethernet3
Gateway IP Address: 1.1.1.250
5. Policies
Policies > (From: Trust, To: Untrust) New: Enter the following, then click OK:

Name: To/From Paris

Source Address:
Address Book Entry: (select), Trust_LAN
Destination Address:
Address Book Entry: (select), Paris_Office
Service: ANY
Action: Tunnel
Tunnel VPN: Tokyo_Paris
Modify matching bidirectional VPN policy: (select)
Position at Top: (select)

WebUI (Paris)
1. Interfaces
Network > Interfaces > Edit (for ethernet1): Enter the following, then click
Apply:

Zone Name: Trust

Static IP: (select this option when present)
IP Address/Netmask: 10.2.2.1/24

Select the following, then click OK:

Interface Mode: NAT

Site-to-Site VPN Configurations  107

 Concepts & Examples ScreenOS Reference Guide

Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:

Zone Name: Untrust

Static IP: (select this option when present)
IP Address/Netmask: 2.2.2.2/24
2. Addresses
Policy > Policy Elements> Addresses > List > New: Enter the following, then
click OK:

Address Name: Trust_LAN

IP Address/Domain Name:
IP/Netmask: (select), 10.2.2.0/24
Zone: Trust

Policy > Policy Elements> Addresses > List > New: Enter the following, then
click OK:

Address Name: Tokyo_Office

IP Address/Domain Name:
IP/Netmask: (select), 10.1.1.0/24
Zone: Untrust
3. VPN
VPNs > AutoKey Advanced > Gateway > New: Enter the following, then click
OK:

Gateway Name: To_Tokyo

Security Level: Custom
Remote Gateway Type:
Static IP Address: (select), IP Address/Hostname: 1.1.1.1
Preshared Key
Preshared Key: h1p8A24nG5
Outgoing Interface: ethernet3

> Advanced: Enter the following advanced settings, then click Return to
return to the basic Gateway configuration page:

Security Level: Custom

Phase 1 Proposal (For Custom Security Level): pre-g2-3des-sha
Mode (Initiator): Main (ID Protection)

(or)

Certificates
Outgoing Interface: ethernet3

> Advanced: Enter the following advanced settings, then click Return to
return to the basic Gateway configuration page:

Security Level: Custom

Phase 1 Proposal (For Custom Security Level): rsa-g2-3des-sha
Mode (Initiator): Main (ID Protection)
Preferred certificate (optional)
Peer CA: Entrust
Peer Type: X509-SIG

108  Site-to-Site VPN Configurations

 Chapter 4: Site-to-Site Virtual Private Networks

VPNs > AutoKey IKE > New: Enter the following, then click OK:

VPN Name: Paris_Tokyo

Security Level: Compatible
Remote Gateway: Predefined: (select), To_Tokyo
4. Route
Network > Routing > Routing Entries > trust-vr New: Enter the following,
then click OK:

Network Address/Netmask: 0.0.0.0/0

Gateway: (select)
Interface: ethernet3
Gateway IP Address: 2.2.2.250
5. Policies
Policies > (From: Trust, To: Untrust) New: Enter the following, then click OK:

Name: To/From Tokyo

Source Address:
Address Book Entry: (select), Trust_LAN
Destination Address:
Address Book Entry: (select), Tokyo_Office
Service: ANY
Action: Tunnel
Tunnel VPN: Paris_Tokyo
Modify matching bidirectional VPN policy: (select)
Position at Top: (select)

CLI (Tokyo)
1. Interfaces
set interface ethernet1 zone trust
set interface ethernet1 ip 10.1.1.1/24
set interface ethernet1 nat
set interface ethernet3 zone untrust
set interface ethernet3 ip 1.1.1.1/24
2. Addresses
set address trust Trust_LAN 10.1.1.0/24
set address untrust paris_office 10.2.2.0/24
3. VPN
Preshared Key
set ike gateway to_paris address 2.2.2.2 main outgoing-interface ethernet3
preshare h1p8A24nG5 proposal pre-g2-3des-sha
set vpn tokyo_paris gateway to_paris sec-level compatible

(or)

Certificates
set ike gateway to_paris address 2.2.2.2 main outgoing-interface ethernet3
proposal rsa-g2-3des-sha
set ike gateway to_paris cert peer-ca 1
set ike gateway to_paris cert peer-cert-type x509-sig
set vpn tokyo_paris gateway to_paris sec-level compatible

Site-to-Site VPN Configurations  109

 Concepts & Examples ScreenOS Reference Guide

NOTE: The number 1 is the CA ID number. To discover the CA’s ID number, use the
following command: get ike ca.

4. Route
set vrouter trust-vr route 0.0.0.0/0 interface ethernet3 gateway 1.1.1.250
5. Policies
set policy top name “To/From Paris” from trust to untrust Trust_LAN paris_office
any tunnel vpn tokyo_paris
set policy top name “To/From Paris” from untrust to trust paris_office Trust_LAN
any tunnel vpn tokyo_paris
save

CLI (Paris)
1. Interfaces
set interface ethernet1 zone trust
set interface ethernet1 ip 10.2.2.1/24
set interface ethernet1 nat
set interface ethernet3 zone untrust
set interface ethernet3 ip 2.2.2.2/24
2. Addresses
set address trust Trust_LAN 10.2.2.0/24
set address untrust tokyo_office 10.1.1.0/24
3. VPN
Preshared Key
set ike gateway to_tokyo address 1.1.1.1 main outgoing-interface ethernet3
preshare h1p8A24nG5 proposal pre-g2-3des-sha
set vpn paris_tokyo gateway to_tokyo sec-level compatible

(or)

Certificates
set ike gateway to_tokyo address 1.1.1.1 main outgoing-interface ethernet3
proposal rsa-g2-3des-sha
set ike gateway to_tokyo cert peer-ca 1
set ike gateway to_tokyo cert peer-cert-type x509-sig
set vpn paris_tokyo gateway to_tokyo tunnel proposal nopfs-esp-3des-sha
4. Route
set vrouter trust-vr route 0.0.0.0/0 interface ethernet3 gateway 2.2.2.250
5. Policies
set policy top name “To/From Tokyo” from trust to untrust Trust_LAN tokyo_office
any tunnel vpn paris_tokyo
set policy top name “To/From Tokyo” from untrust to trust tokyo_office Trust_LAN
any tunnel vpn paris_tokyo
save

110  Site-to-Site VPN Configurations

 Chapter 4: Site-to-Site Virtual Private Networks

Route-Based Site-to-Site VPN, Dynamic Peer

In this example, an AutoKey IKE VPN tunnel using either a preshared key or a pair
of certificates (one at each end of the tunnel) provides a secure connection between
security devices protecting the Tokyo and Paris offices. The Untrust zone interface
for the Paris security device has a static IP address. The ISP serving the Tokyo office
assigns the IP address for the Untrust zone interface dynamically through DHCP.
Because only the Paris security device has a fixed address for its Untrust zone, VPN
traffic must originate from hosts in the Tokyo office. After a tunnel has been
established, traffic through the tunnel can originate from either end. All security
and tunnel zones are in the trust-vr.

Figure 34: Route-Based Site-to-Site VPN, Dynamic Peer

Topology of the zones Topology of the zones

configured on the security configured on the security
device in Tokyo device in Paris

Tokyo Paris Tokyo Paris

Untrust Trust
Trust Untrust Zone
Zone Zone
Zone

Outgoing Interface
Untrust Zone Outgoing Interface
Tokyo eth3 and gateway Untrust Zone Paris
Trust Zone dynamically assigned eth3, 2.2.2.2/24 Trust Zone
eth1, 10.1.1.1/24 by ISP Gateway 2.2.2.250 eth1, 10.2.2.1/24

Internet

VPN Tunnel

Tunnel Interface Tunnel Interface

Tunnel.1 Tunnel.1
DHCP Server
2.1.1.5

The preshared key is h1p8A24nG5. It is assumed that both participants already

have RSA certificates from the certificate authority (CA) Verisign and that the email
address [email protected] appears in the local certificate on Device A. (For
information about obtaining and loading certificates, see “Certificates and CRLs” on
page 34.) For the Phase 1 and Phase 2 security levels, you specify one Phase 1
proposal—either pre-g2-3des-sha for the preshared key method or rsa-g2-3des-sha
for certificates—and select the “Compatible” set of proposals for Phase 2.

You enter three routes on the security devices at each end of the VPN tunnel:

 A default route to the external router in the trust-vr

 A route to the destination through the tunnel interface

 A null route to the destination. You assign a higher metric (farther from zero) to
the null route so that it becomes the next-choice route to the destination. Then,
if the state of the tunnel interface changes to “down” and the route referencing
that interface becomes inactive, the security device uses the null route, which
essentially drops any traffic sent to it, rather than the default route, which
forwards unencrypted traffic.

Finally, you configure policies to permit bidirectional traffic between the two sites.

Site-to-Site VPN Configurations  111

 Concepts & Examples ScreenOS Reference Guide

WebUI (Tokyo)
1. Interfaces
Network > Interfaces > Edit (for ethernet1): Enter the following, then click
Apply:

Zone Name: Trust

Static IP: (select this option when present)
IP Address/Netmask: 10.1.1.1/24

Select the following, then click OK:

Interface Mode: NAT

Network > Interfaces > Edit (for ethernet3): Enter the following, then click
Apply:

Zone Name: Untrust

Enter the following, then click OK:

Obtain IP using DHCP: (select)

NOTE: You cannot specify the IP address of the DHCP server through the WebUI;
however, you can do so through the CLI.

Network > Interfaces > New Tunnel IF: Enter the following, then click OK:

Tunnel Interface Name: tunnel.1

Zone (VR): Untrust (trust-vr)
Unnumbered: (select)
Interface: ethernet3 (trust-vr)
2. Addresses
Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: Trust_LAN

IP Address/Domain Name:
IP/Netmask: (select), 10.1.1.0/24
Zone: Trust

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: Paris_Office

IP Address/Domain Name:
IP/Netmask: (select), 10.2.2.0/24
Zone: Untrust

112  Site-to-Site VPN Configurations

 Chapter 4: Site-to-Site Virtual Private Networks

3. VPN
VPNs > AutoKey Advanced > Gateway > New: Enter the following, then click
OK:

Gateway Name: To_Paris

Security Level: Custom
Remote Gateway Type:
Static IP Address: (select), IP Address/Hostname: 2.2.2.2
Preshared Key
Preshared Key: h1p8A24nG5
Local ID: [email protected]
Outgoing Interface: ethernet3

> Advanced: Enter the following advanced settings, then click Return to
return to the basic Gateway configuration page:

Security Level: Custom

Phase 1 Proposal (For Custom Security Level): pre-g2-3des-sha
Mode (Initiator): Aggressive

(or)

Certificates
Local ID: [email protected]
Outgoing Interface: ethernet3

NOTE: The U-FQDN “[email protected]” must appear in the SubjectAltName field in the
certificate.

> Advanced: Enter the following advanced settings, then click Return to
return to the basic Gateway configuration page:

Security Level: Custom

Phase 1 Proposal (For Custom Security Level): rsa-g2-3des-sha
Mode (Initiator): Aggressive
Preferred Certificate (optional):
Peer CA: Verisign
Peer Type: X509-SIG

VPNs > AutoKey IKE > New: Enter the following, then click OK:

VPN Name: Tokyo_Paris

Security Level: Compatible
Remote Gateway:
Predefined: (select), To_Paris

> Advanced: Enter the following advanced settings, then click Return to
return to the basic AutoKey IKE configuration page:

Bind to: Tunnel Interface: (select), tunnel.1

Proxy-ID: (select)
Local IP / Netmask: 10.1.1.0/24
Remote IP / Netmask: 10.2.2.0/24
Service: ANY

Site-to-Site VPN Configurations  113

 Concepts & Examples ScreenOS Reference Guide

4. Routes
Network > Routing > Routing Entries > trust-vr New: Enter the following,
then click OK:

Network Address/Netmask: 0.0.0.0/0

Gateway: (select)
Interface: ethernet3
Gateway IP Address: 0.0.0.0

NOTE: The ISP provides the gateway IP address dynamically through DHCP.

Network > Routing > Routing Entries > trust-vr New: Enter the following,
then click OK:

Network Address/Netmask: 10.2.2.0/24

Gateway: (select)
Interface: Tunnel.1
Gateway IP Address: 0.0.0.0

Network > Routing > Routing Entries > trust-vr New: Enter the following,
then click OK:

Network Address/Netmask: 10.2.2.0/24

Gateway: (select)
Interface: Null
Gateway IP Address: 0.0.0.0
Metric: 10
5. Policies
Policies > (From: Trust, To: Untrust) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), Trust_LAN
Destination Address:
Address Book Entry: (select), Paris_Office
Service: Any
Action: Permit
Position at Top: (select)

Policies > (From: Untrust, To: Trust) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), Paris_Office
Destination Address:
Address Book Entry: (select), Trust_LAN
Service: Any
Action: Permit
Position at Top: (select)

114  Site-to-Site VPN Configurations

 Chapter 4: Site-to-Site Virtual Private Networks

WebUI (Paris)
1. Interfaces
Network > Interfaces > Edit (for ethernet1): Enter the following, then click
Apply:

Zone Name: Trust

Static IP: (select this option when present)
IP Address/Netmask: 10.2.2.1/24

Select the following, then click OK:

Interface Mode: NAT

Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:

Zone Name: Untrust

Static IP: (select this option when present)
IP Address: 2.2.2.2/24

Network > Interfaces > New Tunnel IF: Enter the following, then click OK:

Tunnel Interface Name: tunnel.1

Zone (VR): Untrust (trust-vr)
Unnumbered: (select)
Interface: ethernet3 (trust-vr)
2. Addresses
Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: Trust_LAN

IP Address/Domain Name:
IP/Netmask: (select), 10.2.2.0/24
Zone: Trust

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: Tokyo_Office

IP Address/Domain Name:
IP/Netmask: (select), 10.1.1.0/24
Zone: Untrust
3. VPN
VPNs > AutoKey Advanced > Gateway > New: Enter the following, then click
OK:

Gateway Name: To_Tokyo

Security Level: Custom
Remote Gateway Type:
Dynamic IP Address: (select), Peer ID: [email protected]

Site-to-Site VPN Configurations  115

 Concepts & Examples ScreenOS Reference Guide

Preshared Key
Preshared Key: h1p8A24nG5
Outgoing Interface: ethernet3

> Advanced: Enter the following advanced settings, then click Return to
return to the basic Gateway configuration page:

Security Level: Custom

Phase 1 Proposal (For Custom Security Level): pre-g2-3des-sha
Mode (Initiator): Aggressive

(or)

Certificates
Outgoing Interface: ethernet3

> Advanced: Enter the following advanced settings, then click Return to
return to the basic Gateway configuration page:

Security Level: Custom

Phase 1 Proposal (For Custom Security Level): rsa-g2-3des-sha
Mode (Initiator): Aggressive
Preferred Certificate (optional):
Peer CA: Verisign
Peer Type: X509-SIG

VPNs > AutoKey IKE > New: Enter the following, then click OK:

VPN Name: Paris_Tokyo

Security Level: Compatible
Remote Gateway:
Predefined: (select), To_Tokyo

> Advanced: Enter the following advanced settings, then click Return to
return to the basic AutoKey IKE configuration page:

Bind to: Tunnel Interface: (select), tunnel.1

Proxy-ID: (select)
Local IP / Netmask: 10.2.2.0/24
Remote IP / Netmask: 10.1.1.0/24
Service: ANY
4. Routes
Network > Routing > Routing Entries > trust-vr New: Enter the following,
then click OK:

Network Address/Netmask: 0.0.0.0/0

Gateway: (select)
Interface: ethernet3
Gateway IP Address: (select), 2.2.2.250

Network > Routing > Routing Entries > trust-vr New: Enter the following,
then click OK:

Network Address/Netmask: 10.1.1.0/24

Gateway: (select)
Interface: Tunnel.1
Gateway IP Address: 0.0.0.0

116  Site-to-Site VPN Configurations

 Chapter 4: Site-to-Site Virtual Private Networks

Network > Routing > Routing Entries > trust-vr New: Enter the following,
then click OK:

Network Address/Netmask: 10.1.1.0/24

Gateway: (select)
Interface: Null
Gateway IP Address: 0.0.0.0
Metric: 10
5. Policies
Policies > (From: Trust, To: Untrust) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), Trust_LAN
Destination Address:
Address Book Entry: (select), Tokyo_Office
Service: Any
Action: Permit
Position at Top: (select)

Policies > (From: Untrust, To: Trust) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), Tokyo_Office
Destination Address:
Address Book Entry: (select), Trust_LAN
Service: Any
Action: Permit
Position at Top: (select)

CLI (Tokyo)
1. Interfaces
set interface ethernet1 zone trust
set interface ethernet1 ip 10.1.1.1/24
set interface ethernet1 nat
set interface ethernet3 zone untrust
set interface ethernet3 dhcp client
set interface ethernet3 dhcp client settings server 1.1.1.5
set interface tunnel.1 zone untrust
set interface tunnel.1 ip unnumbered interface ethernet3
2. Addresses
set address trust Trust_LAN 10.1.1.0/24
set address untrust Paris_Office 10.2.2.0/24
3. VPN
Preshared Key
set ike gateway To_Paris address 2.2.2.2 aggressive local-id [email protected]
outgoing-interface ethernet3 preshare h1p8A24nG5 proposal pre-g2-3des-sha
set vpn Tokyo_Paris gateway To_Paris tunnel sec-level compatible
set vpn Tokyo_Paris bind interface tunnel.1
set vpn Tokyo_Paris proxy-id local-ip 10.1.1.0/24 remote-ip 10.2.2.0/24 any

(or)

Site-to-Site VPN Configurations  117

 Concepts & Examples ScreenOS Reference Guide

Certificates
set ike gateway To_Paris address 2.2.2.2 aggressive local-id [email protected]
outgoing-interface ethernet3 proposal rsa-g2-3des-sha
set ike gateway To_Paris cert peer-ca 1
set ike gateway To_Paris cert peer-cert-type x509-sig
set vpn Tokyo_Paris gateway To_Paris tunnel sec-level compatible
set vpn Tokyo_Paris bind interface tunnel.1
set vpn Tokyo_Paris proxy-id local-ip 10.1.1.0/24 remote-ip 10.2.2.0/24 any

NOTE: The U-FQDN “[email protected]” must appear in the SubjectAltName field in the
certificate.

The number 1 is the CA ID number. To discover the CA’s ID number, use the
following command: get ike ca.

4. Routes
set vrouter trust-vr route 0.0.0.0/0 interface ethernet3
set vrouter trust-vr route 10.2.2.0/24 interface tunnel.1
set vrouter trust-vr route 10.2.2.0/24 interface null metric 10

NOTE: The ISP provides the gateway IP address dynamically through DHCP, so you
cannot specify it here.

5. Policies
set policy top from trust to untrust Trust_LAN Paris_Office any permit
set policy top from untrust to trust Paris_Office Trust_LAN any permit
save

CLI (Paris)
1. Interfaces
set interface ethernet1 zone trust
set interface ethernet1 ip 10.2.2.1/24
set interface ethernet1 nat
set interface ethernet3 zone untrust
set interface ethernet3 ip 2.2.2.2/24
set interface tunnel.1 zone untrust
set interface tunnel.1 ip unnumbered interface ethernet3
2. Addresses
set address trust Trust_LAN 10.2.2.0/24
set address untrust Tokyo_Office 10.1.1.0/24
3. VPN
Preshared Key
set ike gateway To_Tokyo dynamic [email protected] aggressive outgoing-interface
ethernet3 preshare h1p8A24nG5 proposal pre-g2-3des-sha
set vpn Paris_Tokyo gateway To_Tokyo tunnel sec-level compatible
set vpn Paris_Tokyo bind interface tunnel.1
set vpn Paris_Tokyo proxy-id local-ip 10.2.2.0/24 remote-ip 10.1.1.0/24 any

(or)

118  Site-to-Site VPN Configurations

 Chapter 4: Site-to-Site Virtual Private Networks

Certificates
set ike gateway To_Tokyo dynamic [email protected] aggressive outgoing-interface
ethernet3 proposal rsa-g2-3des-sha
set ike gateway To_Tokyo cert peer-ca 1
set ike gateway To_Tokyo cert peer-cert-type x509-sig
set vpn Paris_Tokyo gateway To_Tokyo tunnel sec-level compatible
set vpn Paris_Tokyo bind interface tunnel.1
set vpn Paris_Tokyo proxy-id local-ip 10.2.2.0/24 remote-ip 10.1.1.0/24 any

NOTE: The number 1 is the CA ID number. To discover the CA’s ID number, use the
following command: get ike ca.

4. Routes
set vrouter trust-vr route 0.0.0.0/0 interface ethernet3 gateway 2.2.2.250
set vrouter trust-vr route 10.1.1.0/24 interface tunnel.1
set vrouter trust-vr route 10.1.1.0/24 interface null metric 10
5. Policies
set policy top from trust to untrust Trust_LAN Tokyo_Office any permit
set policy top from untrust to trust Tokyo_Office Trust_LAN any permit
save

Policy-Based Site-to-Site VPN, Dynamic Peer

In this example, a VPN tunnel securely connects the users in the Trust zone behind
Device A to the mail server in the corporate DMZ zone, protected by Device B. The
Untrust zone interface for Device B has a static IP address. The ISP serving Device A
assigns the IP address for its Untrust zone interface dynamically through DHCP.
Because only Device B has a fixed address for its Untrust zone, VPN traffic must
originate from hosts behind Device A. After Device A has established the tunnel,
traffic through the tunnel can originate from either end. All zones are in the trust-vr
routing domain.

Site-to-Site VPN Configurations  119

 Concepts & Examples ScreenOS Reference Guide

Figure 35: Policy-Based Site-to-Site VPN, Dynamic Peer

Topology of the zones Topology of the zones

configured on Device A at the configured on Device B at the
branch office. corporate site.

A B A B

Trust Untrust Untrust DMZ

Zone Zone Zone Zone

Outgoing Interface Outgoing Interface

Untrust Zone Untrust Zone
Branch Office eth3 and gateway eth3, 2.2.2.2/24 Corporate Office
Trust Zone dynamically assigned Gateway 2.2.2.250 DMZ Zone
eth1, 10.1.1.1/24 by ISP eth2, 3.3.3.3/24
Mail Server
Internet 3.3.3.5

Device A VPN Tunnel Device B IDENT

SMTP or POP3 Request
Request DHCP Server
2.1.1.5
ID Authentication
User
User Name: pmason
Password: Nd4syst4
Note: Before making an SMTP or a POP3 connection to the
corporate mail server, Phil must first initiate an HTTP, an
Phil FTP, or a Telnet connection so that Device A can
authenticate him.

In this example, the local auth user Phil (login name: pmason; password: Nd4syst4)
wants to get his email from the mail server at the corporate site. When he attempts
to do so, he is authenticated twice: first, Device A authenticates him locally before
allowing traffic from him through the tunnel; second, the mail server program
authenticates him, sending the IDENT request through the tunnel.

NOTE: Because Phil is an authentication user, before he can make an SMTP of POP3
request, he must first initiate an HTTP, FTP, or Telnet connection so that Device A
can respond with a firewall user/login prompt to authenticate him. After Device A
authenticates him, he has permission to contact the corporate mail server through
the VPN tunnel.

The mail server can send the IDENT request through the tunnel only if the
Device A and B administrators add a custom service for it (TCP, port 113) and set
up policies allowing that traffic through the tunnel to the 10.10.10.0/24 subnet.

The preshared key is h1p8A24nG5. It is assumed that both participants already

have RSA certificates from the certificate authority (CA) Verisign and that the email
address [email protected] appears in the local certificate on Device A. (For
information about obtaining and loading certificates, see “Certificates and CRLs” on
page 34.) For the Phase 1 and Phase 2 security levels, you specify one Phase 1
proposal—either pre-g2-3des-sha for the preshared key method or rsa-g2-3des-sha
for certificates—and select the predefined “Compatible” set of proposals for
Phase 2.

120  Site-to-Site VPN Configurations

 Chapter 4: Site-to-Site Virtual Private Networks

WebUI (Device A)
1. Interfaces
Network > Interfaces > Edit (for ethernet1): Enter the following, then click
Apply:

Zone Name: Trust

Static IP: (select this option when present)
IP Address/Netmask: 10.1.1.1/24

Select the following, then click OK:

Interface Mode: NAT

Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:

Zone Name: Untrust

Obtain IP using DHCP: (select)

NOTE: You cannot specify the IP address of the DHCP server through the WebUI;
however, you can do so through the CLI.

2. User
Objects > Users > Local > New: Enter the following, then click OK:

User Name: pmason

Status: Enable
Authentication User: (select)
User Password: Nd4syst4
Confirm Password: Nd4syst4
3. Addresses
Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: Trusted_network

IP Address/Domain Name:
IP/Netmask: (select), 10.1.1.0/24
Zone: Trust

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: Mail_Server

IP Address/Domain Name:
IP/Netmask: (select), 3.3.3.5/32
Zone: Untrust

Site-to-Site VPN Configurations  121

 Concepts & Examples ScreenOS Reference Guide

4. Services
Policy > Policy Elements > Services > Custom > New: Enter the following,
then click OK:

Service Name: Ident

Service Timeout:
Use protocol default: (select)
Transport Protocol: TCP (select)
Source Port: Low 0, High 65535
Destination Port: Low 113, High 113

Policy > Policy Elements > Services > Group > New: Enter the following,
move the following services, then click OK:

Group Name: Remote_Mail

Group Members << Available Members:
HTTP
FTP
Telnet
Ident
MAIL
POP3
5. VPN
VPNs > AutoKey Advanced > Gateway > New: Enter the following, then click
OK:

Gateway Name: To_Mail

Security Level: Custom
Remote Gateway Type:
Static IP Address: (select), IP Address/Hostname: 2.2.2.2
Preshared Key
Preshared Key: h1p8A24nG5
Local ID: [email protected]
Outgoing Interface: ethernet3

> Advanced: Enter the following advanced settings, then click Return to
return to the basic Gateway configuration page:

Security Level: Custom

Phase 1 Proposal (For Custom Security Level): pre-g2-3des-sha
Mode (Initiator): Aggressive

(or)

122  Site-to-Site VPN Configurations

 Chapter 4: Site-to-Site Virtual Private Networks

Certificates
Local ID: [email protected]
Outgoing Interface: ethernet3

> Advanced: Enter the following advanced settings, then click Return to
return to the basic Gateway configuration page:

Security Level: Custom

Phase 1 Proposal (For Custom Security Level): rsa-g2-3des-sha
Mode (Initiator): Aggressive
Preferred Certificate (optional):
Peer CA: Verisign
Peer Type: X509-SIG

VPNs > AutoKey IKE > New: Enter the following, then click OK:

Name: branch_corp
Security Level: Compatible
Remote Gateway Tunnel: To_Mail
6. Route
Network > Routing > Routing Entries > trust-vr New: Enter the following,
then click OK:

Network Address/Netmask: 0.0.0.0/0

Gateway: (select)
Interface: ethernet3
Gateway IP Address: 0.0.0.0

NOTE: The ISP provides the gateway IP address dynamically through DHCP.

7. Policies
Policies > (From: Trust, To: Untrust) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), Trusted_network
Destination Address:
Address Book Entry: (select), Mail_Server
Service: Remote_Mail
Action: Tunnel
VPN Tunnel: branch_corp
Modify matching bidirectional VPN policy: (select)
Position at Top: (select)

> Advanced: Enter the following advanced settings, then click Return to
return to the basic Policy configuration page:

Authentication: (select)
Auth Server: Local
User: (select), Local Auth User - pmason

Site-to-Site VPN Configurations  123

 Concepts & Examples ScreenOS Reference Guide

WebUI (Device B)
1. Interfaces
Network > Interfaces > Edit (for ethernet2): Enter the following, then click
OK:

Zone Name: DMZ

Static IP: (select this option when present)
IP Address/Netmask: 3.3.3.3/24

Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:

Zone Name: Untrust

Static IP: (select this option when present)
IP Address/Netmask: 2.2.2.2/24
2. Addresses
Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: Mail Server

IP Address/Domain Name:
IP/Netmask: (select), 3.3.3.5/32
Zone: DMZ

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: branch office

IP Address/Domain Name:
IP/Netmask: (select), 10.1.1.0/24
Zone: Untrust
3. Services
Policy > Policy Elements > Services > Custom > New: Enter the following,
then click OK:

Service Name: Ident

Service Timeout:
Use protocol default: (select)
Transport Protocol: TCP (select)
Source Port: Low 0, High 65535
Destination Port: Low 113, High 113

Policy > Policy Elements > Services > Groups > New: Enter the following,
move the following services, then click OK:

Group Name: Remote_Mail

Group Members << Available Members:
Ident
MAIL
POP3

124  Site-to-Site VPN Configurations

 Chapter 4: Site-to-Site Virtual Private Networks

4. VPN
VPNs > AutoKey Advanced > Gateway > New: Enter the following, then click
OK:

Gateway Name: To_branch

Security Level: Custom
Remote Gateway Type:
Dynamic IP Address: (select), Peer ID: [email protected]
Preshared Key
Preshared Key: h1p8A24nG5
Outgoing Interface: ethernet3

> Advanced: Enter the following advanced settings, then click Return to
return to the basic Gateway configuration page:

Security Level: Custom

Phase 1 Proposal (For Custom Security Level): pre-g2-3des-sha
Mode (Initiator): Aggressive

(or)

Certificates
Outgoing Interface: ethernet3

> Advanced: Enter the following advanced settings, then click Return to
return to the basic Gateway configuration page:

Security Level: Custom

Phase 1 Proposal (For Custom Security Level): rsa-g2-3des-sha
Mode (Initiator): Aggressive
Preferred Certificate (optional):
Peer CA: Verisign
Peer Type: X509-SIG

VPNs > AutoKey IKE > New: Enter the following, then click OK:

VPN Name: corp_branch

Security Level: Compatible
Remote Gateway:
Predefined: (select), To_branch
5. Route
Network > Routing > Routing Entries > trust-vr New: Enter the following,
then click OK:

Network Address/Netmask: 0.0.0.0/0

Gateway: (select)
Interface: ethernet3
Gateway IP Address: 2.2.2.250

Site-to-Site VPN Configurations  125

 Concepts & Examples ScreenOS Reference Guide

6. Policies
Policies > (From: DMZ, To: Untrust) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), Mail_Server
Destination Address:
Address Book Entry: (select), branch_office
Service: Remote_Mail
Action: Tunnel
VPN Tunnel: corp_branch
Modify matching bidirectional VPN policy: (select)
Position at Top: (select)

CLI (Device A)
1. Interfaces
set interface ethernet1 zone trust
set interface ethernet1 ip 10.1.1.1/24
set interface ethernet1 nat
set interface ethernet3 zone untrust
set interface ethernet3 dhcp client
set interface ethernet3 dhcp client settings server 1.1.1.5
2. User
set user pmason password Nd4syst4
3. Addresses
set address trust “trusted network” 10.1.1.0/24
set address untrust “mail server” 3.3.3.5/32
4. Services
set service ident protocol tcp src-port 0-65535 dst-port 113-113
set group service remote_mail
set group service remote_mail add http
set group service remote_mail add ftp
set group service remote_mail add telnet
set group service remote_mail add ident
set group service remote_mail add mail
set group service remote_mail add pop3
5. VPN
Preshared Key
set ike gateway to_mail address 2.2.2.2 aggressive local-id [email protected]
outgoing-interface ethernet3 preshare h1p8A24nG5 proposal pre-g2-3des-sha
set vpn branch_corp gateway to_mail sec-level compatible

(or)

Certificates
set ike gateway to_mail address 2.2.2.2 aggressive local-id [email protected]
outgoing-interface ethernet3 proposal rsa-g2-3des-sha
set ike gateway to_mail cert peer-ca 1
set ike gateway to_mail cert peer-cert-type x509-sig
set vpn branch_corp gateway to_mail sec-level compatible

126  Site-to-Site VPN Configurations

 Chapter 4: Site-to-Site Virtual Private Networks

NOTE: The U-FQDN “[email protected]” must appear in the SubjectAltName field in the
certificate.

The number 1 is the CA ID number. To discover the CA’s ID number, use the
following command: get ike ca.

6. Route
set vrouter trust-vr route 0.0.0.0/0 interface ethernet3

NOTE: The ISP provides the gateway IP address dynamically through DHCP.

7. Policies
set policy top from trust to untrust “trusted network” “mail server” remote_mail
tunnel vpn branch_corp auth server Local user pmason
set policy top from untrust to trust “mail server” “trusted network” remote_mail
tunnel vpn branch_corp
save

CLI (Device B)
1. Interfaces
set interface ethernet2 zone dmz
set interface ethernet2 ip 3.3.3.3/24
set interface ethernet3 zone untrust
set interface ethernet3 ip 2.2.2.2/24
2. Addresses
set address dmz “mail server” 3.3.3.5/32
set address untrust “branch office” 10.1.1.0/24
3. Services
set service ident protocol tcp src-port 0-65535 dst-port 113-113
set group service remote_mail
set group service remote_mail add ident
set group service remote_mail add mail
set group service remote_mail add pop3
4. VPN
Preshared Key
set ike gateway to_branch dynamic [email protected] aggressive
outgoing-interface ethernet3 preshare h1p8A24nG5 proposal pre-g2-3des-sha
set vpn corp_branch gateway to_branch tunnel sec-level compatible

(or)

Certificates
set ike gateway to_branch dynamic [email protected] aggressive
outgoing-interface ethernet3 proposal rsa-g2-3des-sha
set ike gateway to_branch cert peer-ca 1
set ike gateway to_branch cert peer-cert-type x509-sig
set vpn corp_branch gateway to_branch sec-level compatible

NOTE: The number 1 is the CA ID number. To discover the CA’s ID number, use the
following command: get ike ca.

Site-to-Site VPN Configurations  127

 Concepts & Examples ScreenOS Reference Guide

5. Route
set vrouter trust-vr route 0.0.0.0/0 interface ethernet3 gateway 2.2.2.250
6. Policies
set policy top from dmz to untrust “mail server” “branch office” remote_mail
tunnel vpn corp_branch
set policy top from untrust to dmz “branch office” “mail server” remote_mail
tunnel vpn corp_branch
save

Route-Based Site-to-Site VPN, Manual Key

In this example, a Manual Key tunnel provides a secure communication channel
between offices in Tokyo and Paris. The Trust zones at each site are in NAT mode.
The addresses are as follows:

 Tokyo:

 Trust zone interface (ethernet1): 10.1.1.1/24

 Untrust zone interface (ethernet3): 1.1.1.1/24

 Paris:

 Trust zone interface (ethernet1): 10.2.2.1/24

 Untrust zone interface (ethernet3): 2.2.2.2/24

The Trust and Untrust security zones are all in the trust-vr routing domain. The
Untrust zone interface (ethernet3) serves as the outgoing interface for the VPN
tunnel.

Figure 36: Route-Based Site-to-Site VPN, Manual Key

Topology of the zones Topology of the zones

configured on the security configured on the security
device in Tokyo. device in Paris.

Tokyo Paris Tokyo Paris

Trust Untrust Untrust Trust

Zone Zone Zone Zone

Outgoing Interface Outgoing Interface

Untrust Zone Untrust Zone
eth3, 1.1.1.1/24 eth3, 2.2.2.2/24
Tokyo Gateway 1.1.1.250 Gateway 2.2.2.250 Paris
Trust Zone Trust Zone
eth1, 10.1.1.1/24 eth1, 10.2.2.1/24
Internet
VPN Tunnel

Tunnel Interface Tunnel Interface

Tunnel.1 Tunnel.1

128  Site-to-Site VPN Configurations

 Chapter 4: Site-to-Site Virtual Private Networks

To set up the tunnel, perform the following steps on the security devices at both
ends of the tunnel:

1. Assign IP addresses to the physical interfaces bound to the security zones and
to the tunnel interface.

2. Configure the VPN tunnel, designate its outgoing interface in the Untrust zone,
and bind it to the tunnel interface.

3. Enter the IP addresses for the local and remote endpoints in the address books
for the Trust and Untrust zones.

4. Enter a default route to the external router in the trust-vr, a route to the
destination through the tunnel interface, and a null route to the destination. You
assign a higher metric (farther from zero) to the null route so that it becomes
the next-choice route to the destination. Then, if the state of the tunnel
interface changes to “down” and the route referencing that interface becomes
inactive, the security device uses the null route, which essentially drops any
traffic sent to it, rather than the default route, which forwards unencrypted
traffic.

5. Set up policies for VPN traffic to pass between each site.

WebUI (Tokyo)
1. Interfaces
Network > Interfaces > Edit (for ethernet1): Enter the following, then click
Apply:

Zone Name: Trust

Static IP: (select this option when present)
IP Address/Netmask: 10.1.1.1/24

Select the following, then click OK:

Interface Mode: NAT

Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:

Zone Name: Untrust

Static IP: (select this option when present)
IP Address/Netmask: 1.1.1.1/24

Network > Interfaces > New Tunnel IF: Enter the following, then click OK:

Tunnel Interface Name: tunnel.1

Zone (VR): Untrust (trust-vr)
Unnumbered: (select)
Interface: ethernet3 (trust-vr)

Site-to-Site VPN Configurations  129

 Concepts & Examples ScreenOS Reference Guide

2. Addresses
Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: Trust_LAN

IP Address/Domain Name:
IP/Netmask: (select), 10.1.1.0/24
Zone: Trust

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: Paris_Office

IP Address/Domain Name:
IP/Netmask: (select), 10.2.2.0/24
Zone: Untrust
3. VPN
VPNs > Manual Key > New: Enter the following, then click OK:

VPN Tunnel Name: Tokyo_Paris

Gateway IP: 2.2.2.2
Security Index: 3020 (Local), 3030 (Remote)
Outgoing Interface: ethernet3
ESP-CBC: (select)
Encryption Algorithm: 3DES-CBC
Generate Key by Password: asdlk24234
Authentication Algorithm: SHA-1
Generate Key by Password: PNas134a

> Advanced: Enter the following advanced settings, then click Return to return
to the basic Manual Key tunnel configuration page:

Bind to: Tunnel Interface, tunnel.1

4. Routes
Network > Routing > Routing Entries > trust-vr New: Enter the following,
then click OK:

Network Address/Netmask: 0.0.0.0/0

Gateway: (select)
Interface: ethernet3
Gateway IP Address: 1.1.1.250

Network > Routing > Routing Entries > trust-vr New: Enter the following,
then click OK:

Network Address/Netmask: 10.2.2.0/24

Gateway: (select)
Interface: tunnel.1
Gateway IP Address: 0.0.0.0

130  Site-to-Site VPN Configurations

 Chapter 4: Site-to-Site Virtual Private Networks

Network > Routing > Routing Entries > trust-vr New: Enter the following,
then click OK:

Network Address/Netmask: 10.2.2.0/24

Gateway: (select)
Interface: Null
Gateway IP Address: 0.0.0.0
Metric: 10
5. Policies
Policies > (From: Trust, To: Untrust) New: Enter the following, then click OK:

Name: To Paris
Source Address:
Address Book Entry: (select), Trust_LAN
Destination Address:
Address Book Entry: (select), Paris_Office
Service: ANY
Action: Permit
Position at Top: (select)

Policies > (From: Untrust, To: Trust) New: Enter the following, then click OK:

Name: From Paris

Source Address:
Address Book Entry: (select), Paris_Office
Destination Address:
Address Book Entry: (select), Trust_LAN
Service: ANY
Action: Permit
Position at Top: (select)

WebUI (Paris)
1. Interfaces
Network > Interfaces > Edit (for ethernet1): Enter the following, then click
Apply:

Zone Name: Trust

Static IP: (select this option when present)
IP Address/Netmask: 10.2.2.1/24

Select the following, then click OK:

Interface Mode: NAT

Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:

Zone Name: Untrust

Static IP: (select this option when present)
IP Address/Netmask: 2.2.2.2/24

Site-to-Site VPN Configurations  131

 Concepts & Examples ScreenOS Reference Guide

Network > Interfaces > New Tunnel IF: Enter the following, then click OK:

Tunnel Interface Name: tunnel.1

Zone (VR): Untrust (trust-vr)
Unnumbered: (select)
Interface: ethernet3 (trust-vr)
2. Addresses
Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: Trust_LAN

IP Address/Domain Name:
IP/Netmask: (select), 10.2.2.0/24
Zone: Trust

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: Tokyo_Office

IP Address/Domain Name:
IP/Netmask: (select), 10.1.1.0/24
Zone: Untrust
3. VPN
VPNs > Manual Key > New: Enter the following, then click OK:

VPN Tunnel Name: Paris_Tokyo

Gateway IP: 1.1.1.1
Security Index: 3030 (Local), 3020 (Remote)
Outgoing Interface: ethernet3
ESP-CBC: (select)
Encryption Algorithm: 3DES-CBC
Generate Key by Password: asdlk24234
Authentication Algorithm: SHA-1
Generate Key by Password: PNas134a

> Advanced: Enter the following advanced settings, then click Return to
return to the basic Manual Key tunnel configuration page:

Bind to: Tunnel Interface, tunnel.1

4. Routes
Network > Routing > Routing Entries > trust-vr New: Enter the following,
then click OK:

Network Address/Netmask: 0.0.0.0/0

Gateway: (select)
Interface: ethernet3
Gateway IP Address: 2.2.2.250

Network > Routing > Routing Entries > trust-vr New: Enter the following,
then click OK:

Network Address/Netmask: 10.1.1.0/24

Gateway: (select)
Interface: tunnel.1
Gateway IP Address: 0.0.0.0

132  Site-to-Site VPN Configurations

 Chapter 4: Site-to-Site Virtual Private Networks

Network > Routing > Routing Entries > trust-vr New: Enter the following,
then click OK:

Network Address/Netmask: 10.1.1.0/24

Gateway: (select)
Interface: Null
Gateway IP Address: 0.0.0.0
Metric: 10
5. Policies
Policies > (From: Trust, To: Untrust) New: Enter the following, then click OK:

Name: To_Tokyo
Source Address:
Address Book Entry: (select), Trust_LAN
Destination Address:
Address Book Entry: (select), Tokyo_Office
Service: ANY
Action: Permit
Position at Top: (select)

Policies > (From: Untrust, To: Trust) New: Enter the following, then click OK:

Name: From_Tokyo
Source Address:
Address Book Entry: (select), Tokyo_Office
Destination Address:
Address Book Entry: (select), Trust_LAN
Service: ANY
Action: Permit
Position at Top: (select)

CLI (Tokyo)
1. Interfaces
set interface ethernet1 zone trust
set interface ethernet1 ip 10.1.1.1/24
set interface ethernet1 nat
set interface ethernet3 zone untrust
set interface ethernet3 ip 1.1.1.1/24
set interface tunnel.1 zone untrust
set interface tunnel.1 ip unnumbered interface ethernet3
2. Addresses
set address trust Trust_LAN 10.1.1.0/24
set address untrust Paris_Office 10.2.2.0/24
3. VPN
set vpn Tokyo_Paris manual 3020 3030 gateway 2.2.2.2 outgoing-interface
ethernet3 esp 3des password asdlk24234 auth sha-1 password PNas134a
set vpn Tokyo_Paris bind interface tunnel.1
4. Routes
set vrouter trust-vr route 0.0.0.0/0 interface ethernet3 gateway 1.1.1.250
set vrouter trust-vr route 10.2.2.0/24 interface tunnel.1
set vrouter trust-vr route 10.2.2.0/24 interface null metric 10

Site-to-Site VPN Configurations  133

 Concepts & Examples ScreenOS Reference Guide

5. Policies
set policy top name “To Paris” from trust to untrust Trust_LAN Paris_Office any
permit
set policy top name “From Paris” from untrust to trust Paris_Office Trust_LAN any
permit
save

CLI (Paris)
1. Interfaces
set interface ethernet1 zone trust
set interface ethernet1 ip 10.2.2.1/24
set interface ethernet1 nat
set interface ethernet3 zone untrust
set interface ethernet3 ip 2.2.2.2/24
set interface tunnel.1 zone untrust
set interface tunnel.1 ip unnumbered interface ethernet3
2. Addresses
set address trust Trust_LAN 10.2.2.0/24
set address untrust Tokyo_Office 10.1.1.0/24
3. VPN
set vpn Paris_Tokyo manual 3030 3020 gateway 1.1.1.1 outgoing-interface
ethernet3 esp 3des password asdlk24234 auth sha-1 password PNas134a
set vpn Paris_Tokyo bind interface tunnel.1
4. Routes
set vrouter trust-vr route 0.0.0.0/0 interface ethernet3 gateway 2.2.2.250
set vrouter trust-vr route 10.1.1.0/24 interface tunnel.1
set vrouter trust-vr route 10.1.1.0/24 interface null metric 10
5. Policies
set policy top name “To Tokyo” from trust to untrust Trust_LAN Tokyo_Office any
permit
set policy top name “From Tokyo” from untrust to trust Tokyo_Office Trust_LAN any
permit
save

Policy-Based Site-to-Site VPN, Manual Key

In this example, a Manual Key tunnel provides a secure communication channel
between offices in Tokyo and Paris, using ESP with 3DES encryption and SHA-1
authentication. The Trust zones at each site are in NAT mode. The addresses are as
follows:

 Tokyo:

 Trust interface (ethernet1): 10.1.1.1/24

 Untrust interface (ethernet3): 1.1.1.1/24

 Paris:

 Trust interface (ethernet1): 10.2.2.1/24

 Untrust interface (ethernet3): 2.2.2.2/24

134  Site-to-Site VPN Configurations

 Chapter 4: Site-to-Site Virtual Private Networks

The Trust and Untrust security zones and the Untrust-Tun tunnel zone are in the
trust-vr routing domain. The Untrust zone interface (ethernet3) serves as the
outgoing interface for the VPN tunnel.

Figure 37: Policy-Based Site-to-Site VPN, Manual Key

Topology of the zones Topology of the zones

configured on the security configured on the security
device in Tokyo. device in Paris.
Tokyo Paris Tokyo Paris

Trust Untrust-Tun Untrust Untrust Untrust-Tun Trust

Zone Zone Zone Zone Zone Zone

Outgoing Interface Outgoing Interface

Untrust Zone Untrust Zone
ethernet3, 1.1.1.1/24 ethernet3, 2.2.2.2/24
Tokyo Paris
Gateway 1.1.1.250 Gateway 2.2.2.250
Trust Zone Trust Zone
ethernet1, 10.1.1.1/24 ethernet1, 10.2.2.1/24
Internet

VPN Tunnel

To set up the tunnel, perform the following five steps on the security devices at both
ends of the tunnel:

1. Assign IP addresses to the physical interfaces bound to the security zones.

2. Configure the VPN tunnel, and designate its outgoing interface in the Untrust
zone.

3. Enter the IP addresses for the local and remote endpoints in the Trust and
Untrust address books.

4. Enter a default route to the external router.

5. Set up policies for VPN traffic to pass bidirectionally through the tunnel.

WebUI (Tokyo)
1. Interfaces
Network > Interfaces > Edit (for ethernet1): Enter the following, then click
Apply:

Zone Name: Trust

Static IP: (select this option when present)
IP Address/Netmask: 10.1.1.1/24

Select the following, then click OK:

Interface Mode: NAT

Site-to-Site VPN Configurations  135

 Concepts & Examples ScreenOS Reference Guide

Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:

Zone Name: Untrust

Static IP: (select this option when present)
IP Address/Netmask: 1.1.1.1/24
2. Addresses
Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: Trust_LAN

IP Address/Domain Name:
IP/Netmask: (select), 10.1.1.0/24
Zone: Trust

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: Paris_Office

IP Address/Domain Name:
IP/Netmask: (select), 10.2.2.0/24
Zone: Untrust
3. VPN
VPNs > Manual Key > New: Enter the following, then click OK:

VPN Tunnel Name: Tokyo_Paris

Gateway IP: 2.2.2.2
Security Index: 3020 (Local), 3030 (Remote)
Outgoing Interface: ethernet3
ESP-CBC: (select)
Encryption Algorithm: 3DES-CBC
Generate Key by Password: asdlk24234
Authentication Algorithm: SHA-1
Generate Key by Password: PNas134a

> Advanced: Enter the following advanced settings, then click Return to
return to the basic Manual Key tunnel configuration page:

Bind to: Tunnel Zone, Untrust-Tun

4. Route
Network > Routing > Routing Entries > trust-vr New: Enter the following,
then click OK:

Network Address/Netmask: 0.0.0.0/0

Gateway: (select)
Interface: ethernet3
Gateway IP Address: 1.1.1.250

136  Site-to-Site VPN Configurations

 Chapter 4: Site-to-Site Virtual Private Networks

5. Policies
Policies > (From: Trust, To: Untrust) New: Enter the following, then click OK:

Name: To/From Paris

Source Address:
Address Book Entry: (select), Trust_LAN
Destination Address:
Address Book Entry: (select), Paris_Office
Service: ANY
Action: Tunnel
Tunnel VPN: Tokyo_Paris
Modify matching bidirectional VPN policy: (select)
Position at Top: (select)

WebUI (Paris)
1. Interfaces
Network > Interfaces > Edit (for ethernet1): Enter the following, then click
Apply:

Zone Name: Trust

Static IP: (select this option when present)
IP Address/Netmask: 10.2.2.1/24

Select the following, then click OK:

Interface Mode: NAT

Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:
Zone Name: Untrust
Static IP: (select this option when present)
IP Address/Netmask: 2.2.2.2/24
2. Addresses
Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: Trust_LAN

IP Address/Domain Name:
IP/Netmask: (select), 10.2.2.0/24
Zone: Trust

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: Tokyo_Office

IP Address/Domain Name:
IP/Netmask: (select), 10.1.1.0/24
Zone: Untrust
3. VPN
VPNs > Manual Key > New: Enter the following, then click OK:

VPN Tunnel Name: Paris_Tokyo

Gateway IP: 1.1.1.1
Security Index (HEX Number): 3030 (Local), 3020 (Remote)
Outgoing Interface: ethernet3

Site-to-Site VPN Configurations  137

 Concepts & Examples ScreenOS Reference Guide

ESP-CBC: (select)
Encryption Algorithm: 3DES-CBC
Generate Key by Password: asdlk24234
Authentication Algorithm: SHA-1
Generate Key by Password: PNas134a

> Advanced: Enter the following advanced settings, then click Return to
return to the basic Manual Key tunnel configuration page:

Bind to: Tunnel Zone, Untrust-Tun

4. Route
Network > Routing > Routing Entries > trust-vr New: Enter the following,
then click OK:

Network Address/Netmask: 0.0.0.0/0

Gateway: (select)
Interface: ethernet3
Gateway IP Address: 2.2.2.250
5. Policies
Policies > (From: Trust, To: Untrust) New: Enter the following, then click OK:

Name: To/From Tokyo

Source Address:
Address Book Entry: (select), Trust_LAN
Destination Address:
Address Book Entry: (select), Tokyo_Office
Service: ANY
Action: Tunnel
Tunnel VPN: Paris_Tokyo
Modify matching bidirectional VPN policy: (select)
Position at Top: (select)

CLI (Tokyo)
1. Interfaces
set interface ethernet1 zone trust
set interface ethernet1 ip 10.1.1.1/24
set interface ethernet1 nat
set interface ethernet3 zone untrust
set interface ethernet3 ip 1.1.1.1/24
2. Addresses
set address trust Trust_LAN 10.1.1.0/24
set address untrust paris_office 10.2.2.0/24
3. VPN
set vpn tokyo_paris manual 3020 3030 gateway 2.2.2.2 outgoing-interface
ethernet3 esp 3des password asdlk24234 auth sha-1 password PNas134a
set vpn tokyo_paris bind zone untrust-tun
4. Route
set vrouter trust-vr route 0.0.0.0/0 interface ethernet3 gateway 1.1.1.250

138  Site-to-Site VPN Configurations

 Chapter 4: Site-to-Site Virtual Private Networks

5. Policies
set policy top name “To/From Paris” from trust to untrust Trust_LAN paris_office
any tunnel vpn tokyo_paris
set policy top name “To/From Paris” from untrust to trust paris_office Trust_LAN
any tunnel vpn tokyo_paris
save

CLI (Paris)
1. Interfaces
set interface ethernet1 zone trust
set interface ethernet1 ip 10.2.2.1/24
set interface ethernet1 nat
set interface ethernet3 zone untrust
set interface ethernet3 ip 2.2.2.2/24
2. Addresses
set address trust Trust_LAN 10.2.2.0/24
set address untrust tokyo_office 10.1.1.0/24
3. VPN
set vpn paris_tokyo manual 3030 3020 gateway 1.1.1.1 outgoing-interface
ethernet3 esp 3des password asdlk24234 auth sha-1 password PNas134a
set vpn paris_tokyo bind zone untrust-tun
4. Route
set vrouter trust-vr route 0.0.0.0/0 interface ethernet3 gateway 2.2.2.250
5. Policies
set policy top name “To/From Tokyo” from trust to untrust Trust_LAN tokyo_office
any tunnel vpn paris_tokyo
set policy top name “To/From Tokyo” from untrust to trust tokyo_office Trust_LAN
any tunnel vpn paris_tokyo
save

Dynamic IKE Gateways Using FQDN

For an IKE peer that obtains its IP address dynamically, you can specify its fully
qualified domain name (FQDN) in the local configuration for the remote gateway.
For example, an Internet service provider (ISP) might assign IP addresses through
DHCP to its customers. The ISP draws addresses from a large pool of addresses and
assigns them when its customers come online. Although the IKE peer has an
unchanging FQDN, it has an unpredictably changing IP address. The IKE peer has
three methods available for maintaining a Domain Name System (DNS) mapping of
its FQDN to its dynamically assigned IP address (a process known as dynamic
DNS).

 If the remote IKE peer is a security device, the admin can manually notify the
DNS server to update its FQDN-to-IP address mapping each time the security
device receives a new IP address from its ISP.

 If the remote IKE peer is another kind of VPN termination device that has
dynamic DNS software running on it, that software can automatically notify the
DNS server of its address changes so the server can update its FQDN-to-IP
address mapping table.

Dynamic IKE Gateways Using FQDN  139

 Concepts & Examples ScreenOS Reference Guide

 If the remote IKE peer is a security device or any other kind of VPN termination
device, a host behind it can run an FQDN-to-IP address automatic update
program that alerts the DNS server of address changes.

Figure 38: IKE Peer with a Dynamic IP Address

Local Security Device IKE Peer

Internet

www.jnpr.net
VPN Tunnel
1.1.1.202 = www.jnpr.net

1. The DHCP server draws 1.1.1.202 from its pool of IP addresses IP Pool
and assigns that address to the IKE peer.

2. The IKE peer notifies the DNS server of the new address in order
for the server to update its FQDN-to-IP address mapping table.
1.1.1.10 – DHCP Server DNS Server
1.1.7.9

Without needing to know the current IP address of a remote IKE peer, you can now
configure an AutoKey IKE VPN tunnel to that peer using its FQDN instead of an IP
address.

Aliases
You can also use an alias for the FQDN of the remote IKE peer if the DNS server that
the local security device queries returns only one IP address. If the DNS server
returns several IP addresses, the local device uses the first one it receives. Because
there is no guarantee for the order of the addresses in the response from the DNS
server, the local security device might use the wrong IP address, and IKE
negotiations might fail.

140  Dynamic IKE Gateways Using FQDN

 Chapter 4: Site-to-Site Virtual Private Networks

Figure 39: Multiple DNS Replies Leading to IKE Negotiation Success or Failure

Local Security Device The local security device wants to Remote IKE Peer
establish an IKE VPN tunnel with its
remote peer. It uses www.jnpr.net as the
remote gateway address.

DNS Query: www.jnpr.net = IP ?

Local Security Device DNS Server

DNS Reply:
The device uses this IP
address. www.jnpr.net = 1.1.1.202
www.jnpr.net = 1.1.1.114
www.jnpr.net = 1.1.1.20

Local Security Device If the remote IKE peer is at 1.1.1.202, IKE Remote IKE Peer
negotiations succeed.

If the remote IKE peer

Local Security Device is at 1.1.1.114 Remote IKE Peer
or
1.1.1.20, IKE
negotiations fail.

Setting AutoKey IKE Peer with FQDN

In this example, an AutoKey IKE VPN tunnel using either a preshared secret or a
pair of certificates (one at each end of the tunnel) provides a secure connection
between two offices in Tokyo and Paris. The Paris office has a dynamically assigned
IP address, so the Tokyo office uses the remote peer’s FQDN (www.nspar.com) as
the address of the remote gateway in its VPN tunnel configuration.

The configuration shown in Figure 40 is for a route-based VPN tunnel. For the
Phase 1 and Phase 2 security levels, you specify one Phase 1 proposal—either
pre-g2-3des-sha for the preshared key method or rsa-g2-3des-sha for
certificates—and select the predefined “Compatible” set of proposals for Phase 2.
All zones are in the trust-vr.

Dynamic IKE Gateways Using FQDN  141

 Concepts & Examples ScreenOS Reference Guide

Figure 40: AutoKey IKE Peer with FQDN

Topology of the zones Topology of the zones

configured on the security configured on the security
device in Tokyo device in Paris
Tokyo Paris Tokyo Paris

Trust Untrust Untrust Trust

Zone Zone Zone Zone

Outgoing Interface
Outgoing Interface Untrust Zone
Untrust Zone ethernet3, IP and gateway
ethernet3, 1.1.1.1/24 via DHCP
Tokyo www.nspar.com Paris
Trust Zone Gateway 1.1.1.250 Trust Zone
ethernet1, 10.1.1.1/24 ethernet1, 10.2.2.1/24
Internet
VPN Tunnel

Tunnel Interface: tunnel.1 Tunnel Interface: tunnel.1

Remote Gateway: www.nspar.com Remote Gateway: 1.1.1.1

Setting up a route-based AutoKey IKE tunnel using either a preshared secret or

certificates involves the following steps:

1. Assign IP addresses to the physical interfaces bound to the security zones and
to the tunnel interface.

2. Define the remote gateway and key exchange mode, and specify either a
preshared secret or a certificate.

3. Configure the VPN tunnel, designate its outgoing interface in the Untrust zone,
bind it to the tunnel interface, and configure its proxy-ID.

4. Enter the IP addresses for the local and remote endpoints in the Trust and
Untrust address books.

5. Enter a default route to the external router in the trust-vr, a route to the
destination through the tunnel interface, and a null route to the destination. You
assign a higher metric (farther from zero) to the null route so that it becomes
the next-choice route to the destination. Then, if the state of the tunnel
interface changes to “down” and the route referencing that interface becomes
inactive, the security device uses the null route, which essentially drops any
traffic sent to it, rather than the default route, which forwards unencrypted
traffic.

6. Set up policies for traffic to pass between each site.

In the following examples, the preshared key is h1p8A24nG5. It is assumed that

both participants already have RSA certificates and are using Entrust as the
certificate authority (CA). (For information about obtaining and loading certificates,
see “Public Key Cryptography” on page 29.)

142  Dynamic IKE Gateways Using FQDN

 Chapter 4: Site-to-Site Virtual Private Networks

WebUI (Tokyo)
1. Interfaces
Network > Interfaces > Edit (for ethernet1): Enter the following, then click
Apply:

Zone Name: Trust

Static IP: (select this option when present)
IP Address/Netmask: 10.1.1.1/24

Select the following, then click OK:

Interface Mode: NAT

Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:

Zone Name: Untrust

Static IP: (select this option when present)
IP Address/Netmask: 1.1.1.1

Network > Interfaces > New Tunnel IF: Enter the following, then click OK:

Tunnel Interface Name: tunnel.1

Zone (VR): Untrust (trust-vr)
Unnumbered: (select)
Interface: ethernet3 (trust-vr)
2. Addresses
Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: Trust_LAN

IP Address/Domain Name:
IP/Netmask: (select), 10.1.1.0/24
Zone: Trust

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: Paris_Office

IP Address/Domain Name:
IP/Netmask: (select), 10.2.2.0/24
Zone: Untrust
3. VPN
VPNs > AutoKey Advanced > Gateway > New: Enter the following, then click
OK:

Gateway Name: To_Paris

Security Level: Custom
Remote Gateway Type:
Static IP Address: (select), IP Address/Hostname: www.nspar.com

Dynamic IKE Gateways Using FQDN  143

 Concepts & Examples ScreenOS Reference Guide

Preshared Key
Preshared Key: h1p8A24nG5
Outgoing Interface: ethernet3

> Advanced: Enter the following advanced settings, then click Return to
return to the basic Gateway configuration page:

Security Level: Custom

Phase 1 Proposal (for Custom Security Level): pre-g2-3des-sha
Mode (Initiator): Main (ID Protection)

(or)

Certificates
Outgoing Interface: ethernet3

> Advanced: Enter the following advanced settings, then click Return to
return to the basic Gateway configuration page:

Security Level: Custom

Phase 1 Proposal (for Custom Security Level): rsa-g2-3des-sha
Preferred certificate (optional)
Peer CA: Entrust
Peer Type: X509-SIG

VPNs > AutoKey IKE > New: Enter the following, then click OK:

VPN Name: Tokyo_Paris

Security Level: Compatible
Remote Gateway:
Predefined: (select), To_Paris

> Advanced: Enter the following advanced settings, then click Return to
return to the basic AutoKey IKE configuration page:

Security Level: Compatible

Bind to: Tunnel Interface, tunnel.1
Proxy-ID: (select)
Local IP / Netmask: 10.1.1.0/24
Remote IP / Netmask: 10.2.2.0/24
Service: ANY
4. Routes
Network > Routing > Routing Entries > trust-vr New: Enter the following,
then click OK:

Network Address/Netmask: 0.0.0.0/0

Gateway: (select)
Interface: ethernet3
Gateway IP Address: 0.0.0.0

NOTE: The ISP provides the gateway IP address dynamically through DHCP.

144  Dynamic IKE Gateways Using FQDN

 Chapter 4: Site-to-Site Virtual Private Networks

Network > Routing > Routing Entries > trust-vr New: Enter the following,
then click OK:

Network Address/Netmask: 10.2.2.0/24

Gateway: (select)
Interface: tunnel.1
Gateway IP Address: 0.0.0.0

Network > Routing > Routing Entries > trust-vr New: Enter the following,
then click OK:

Network Address/Netmask: 10.2.2.0/24

Gateway: (select)
Interface: Null
Gateway IP Address: 0.0.0.0
Metric: 10
5. Policies
Policies > (From: Trust, To: Untrust) New: Enter the following, then click OK:

Name: To Paris
Source Address: Trust_LAN
Destination Address: Paris_Office
Service: ANY
Action: Permit
Position at Top: (select)

Policies > Policy (From: Untrust, To: Trust) > New Policy: Enter the following,
then click OK:

Name: From Paris

Source Address: Paris_Office
Destination Address: Trust_LAN
Service: ANY
Action: Permit
Position at Top: (select)

WebUI (Paris)
1. Host Name and Domain Name
Network > DNS: Enter the following, then click Apply:

Host Name: www

Domain Name: nspar.com
2. Interfaces
Network > Interfaces > Edit (for ethernet1): Enter the following, then click
Apply:

Zone Name: Trust

Static IP: (select this option when present)
IP Address/Netmask: 10.2.2.1/24

Select the following, then click OK:

Interface Mode: NAT

Dynamic IKE Gateways Using FQDN  145

 Concepts & Examples ScreenOS Reference Guide

Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:

Zone Name: Untrust

Obtain IP using DHCP: (select)

Network > Interfaces > New Tunnel IF: Enter the following, then click OK:

Tunnel Interface Name: tunnel.1

Zone (VR): Untrust (trust-vr)
Unnumbered: (select)
Interface: ethernet3 (trust-vr)
3. Addresses
Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: Trust_LAN

IP Address/Domain Name:
IP/Netmask: (select), 10.2.2.0/24
Zone: Trust

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: Tokyo_Office

IP Address/Domain Name:
IP/Netmask: (select), 10.1.1.0/24
Zone: Untrust
4. VPN
VPNs > AutoKey Advanced > Gateway > New: Enter the following, then click
OK:

Gateway Name: To_Tokyo

Security Level: Custom
Remote Gateway Type:
Static IP Address: (select), IP Address/Hostname: 1.1.1.1
Preshared Key
Preshared Key: h1p8A24nG5
Outgoing Interface: ethernet3

> Advanced: Enter the following advanced settings, then click Return to
return to the basic Gateway configuration page:

Security Level: Custom

Phase 1 Proposal (For Custom Security Level): pre-g2-3des-sha
Mode (Initiator): Main (ID Protection)

(or)

146  Dynamic IKE Gateways Using FQDN

 Chapter 4: Site-to-Site Virtual Private Networks

Certificates
Outgoing Interface: ethernet3

> Advanced: Enter the following advanced settings, then click Return to
return to the basic Gateway configuration page:

Security Level: Custom

Phase 1 Proposal (for Custom Security Level): rsa-g2-3des-sha
Preferred certificate (optional)
Peer CA: Entrust
Peer Type: X509-SIG

VPNs > AutoKey IKE > New: Enter the following, then click OK:

Name: Paris_Tokyo
Security Level: Custom
Remote Gateway:
Predefined: (select), To_Tokyo

> Advanced: Enter the following advanced settings, then click Return to
return to the basic AutoKey IKE configuration page:

Security Level: Compatible

Bind to: Tunnel Interface, tunnel.1
Proxy-ID: (select)
Local IP / Netmask: 10.2.2.0/24
Remote IP / Netmask: 10.1.1.0/24
Service: ANY
5. Routes
Network > Routing > Routing Entries > trust-vr New: Enter the following,
then click OK:

Network Address/Netmask: 0.0.0.0/0

Gateway: (select)
Interface: ethernet3
Gateway IP Address: 2.2.2.250

Network > Routing > Routing Entries > trust-vr New: Enter the following,
then click OK:

Network Address/Netmask: 10.1.1.0/24

Gateway: (select)
Interface: tunnel.1
Gateway IP Address: 0.0.0.0

Network > Routing > Routing Entries > trust-vr New: Enter the following,
then click OK:

Network Address/Netmask: 10.1.1.0/24

Gateway: (select)
Interface: Null
Gateway IP Address: 0.0.0.0
Metric: 10

Dynamic IKE Gateways Using FQDN  147

 Concepts & Examples ScreenOS Reference Guide

6. Policies
Policies > (From: Trust, To: Untrust) New: Enter the following, then click OK:

Name: To Tokyo
Source Address: Trust_LAN
Destination Address: Tokyo_Office
Service: ANY
Action: Permit
Position at Top: (select)

Policies > (From: Untrust, To: Trust) New: Enter the following, then click OK:

Name: From Tokyo

Source Address: Tokyo_Office
Destination Address: Trust_LAN
Service: ANY
Action: Permit
Position at Top: (select)

CLI (Tokyo)
1. Interfaces
set interface ethernet1 zone trust
set interface ethernet1 ip 10.1.1.1/24
set interface ethernet1 nat
set interface ethernet3 zone untrust
set interface ethernet3 ip 1.1.1.1/24
set interface tunnel.1 zone untrust
set interface tunnel.1 ip unnumbered interface ethernet3
2. Addresses
set address trust Trust_LAN 10.1.1.0/24
set address untrust paris_office 10.2.2.0/24
3. VPN
Preshared Key
set ike gateway to_paris address www.nspar.com main outgoing-interface
ethernet3 preshare h1p8A24nG5 proposal pre-g2-3des-sha
set vpn tokyo_paris gateway to_paris sec-level compatible
set vpn tokyo_paris bind interface tunnel.1
set vpn tokyo_paris proxy-id local-ip 10.1.1.0/24 remote-ip 10.2.2.0/24 any

(or)

Certificate
set ike gateway to_paris address www.nspar.com main outgoing-interface
ethernet3 proposal rsa-g2-3des-sha
set ike gateway to_paris cert peer-ca 1
set ike gateway to_paris cert peer-cert-type x509-sig
set vpn tokyo_paris gateway to_paris sec-level compatible
set vpn tokyo_paris bind interface tunnel.1
set vpn tokyo_paris proxy-id local-ip 10.1.1.0/24 remote-ip 10.2.2.0/24 any

NOTE: The number 1 is the CA ID number. To discover the CA’s ID number, use the
following command: get ike ca.

148  Dynamic IKE Gateways Using FQDN

 Chapter 4: Site-to-Site Virtual Private Networks

4. Routes
set vrouter trust-vr route 0.0.0.0/0 interface ethernet3 gateway 1.1.1.250
set vrouter trust-vr route 10.2.2.0/24 interface tunnel.1
set vrouter trust-vr route 10.2.2.0/24 interface null metric 10
5. Policies
set policy top name “To Paris” from trust to untrust Trust_LAN paris_office any
permit
set policy top name “From Paris” from untrust to trust paris_office Trust_LAN any
permit
save

CLI (Paris)
1. Host Name and Domain Name
set hostname www
set domain nspar.com
2. Interfaces
set interface ethernet1 zone trust
set interface ethernet1 ip 10.2.2.1/24
set interface ethernet1 nat
set interface ethernet3 zone untrust
set interface ethernet3 ip dhcp-client enable
set interface tunnel.1 zone untrust
set interface tunnel.1 ip unnumbered interface ethernet3
3. Addresses
set address trust Trust_LAN 10.2.2.0/24
set address untrust tokyo_office 10.1.1.0/24
4. VPN
Preshared Key
set ike gateway to_tokyo address 1.1.1.1 main outgoing-interface ethernet3
preshare h1p8A24nG5 proposal pre-g2-3des-sha
set vpn paris_tokyo gateway to_tokyo sec-level compatible
set vpn paris_tokyo bind interface tunnel.1
set vpn paris_tokyo proxy-id local-ip 10.2.2.0/24 remote-ip 10.1.1.0/24 any
(or)

Certificate
set ike gateway to_tokyo address 1.1.1.1 main outgoing-interface ethernet3
proposal rsa-g2-3des-sha
set ike gateway to_tokyo cert peer-ca 1
set ike gateway to_tokyo cert peer-cert-type x509-sig
set vpn paris_tokyo gateway to_tokyo sec-level compatible
set vpn paris_tokyo bind interface tunnel.1
set vpn paris_tokyo proxy-id local-ip 10.2.2.0/24 remote-ip 10.1.1.0/24 any
5. Routes
set vrouter trust-vr route 0.0.0.0/0 interface ethernet3 gateway 2.2.2.250
set vrouter trust-vr route 10.1.1.0/24 interface tunnel.1
set vrouter trust-vr route 10.1.1.0/24 interface null metric 10

Dynamic IKE Gateways Using FQDN  149

 Concepts & Examples ScreenOS Reference Guide

6. Policies
set policy top name “To Tokyo” from trust to untrust Trust_LAN tokyo_office any
permit
set policy top name “From Tokyo” from untrust to trust tokyo_office Trust_LAN any
permit
save

VPN Sites with Overlapping Addresses

Because the range of private IP addresses is relatively small, there is a good chance
that the addresses of protected networks of two VPN peers overlap. For
bidirectional VPN traffic between two end entities with overlapping addresses, the
security devices at both ends of the tunnel must apply Source Network Address
Translation (NAT-src) and Destination Network Address Translation (NAT-dst) to the
VPN traffic passing between them.

NOTE: An overlapping address space is when the IP address range in two networks are
partially or completely the same.

For NAT-src, the interfaces at both ends of the tunnel must have IP addresses in
mutually unique subnets, with a dynamic IP (DIP) pool in each of those subnets.
The policies regulating outbound VPN traffic can then apply NAT-src using DIP pool
addresses to translate original source addresses to those in a neutral address space.

NOTE: The range of addresses in a DIP pool must be in the same subnet as the tunnel
interface, but the pool must not include the interface IP address or any MIP or VIP
addresses that might also be in that subnet. For security zone interfaces, you can
also define an extended IP address and an accompanying DIP pool in a different
subnet from that of the interface IP address. For more information, see “Using DIP
in a Different Subnet” on page 2-145.

To provide NAT-dst on inbound VPN traffic, there are two options:

 Policy-based NAT-dst: A policy can apply NAT-dst to translate inbound VPN

traffic to an address that is either in the same subnet as the tunnel
interface—but not in the same range as the local DIP pool used for outbound
VPN traffic—or to an address in another subnet to which the security device
has an entry in its route table. (For information about routing considerations
when configuring NAT-dst, see “Routing for NAT-Dst” on page 8-32.)

 Mapped IP (MIP): A policy can reference a MIP as the destination address. The
MIP uses an address in the same subnet as the tunnel interface—but not in the
same range as the local DIP pool used for outbound VPN traffic. (For
information about MIPs, see “Mapped IP Addresses” on page 8-63.)

VPN traffic between sites with overlapping addresses requires address translation in
both directions. Because the source address on outbound traffic cannot be the same
as the destination address on inbound traffic—the NAT-dst address or MIP cannot
be in the DIP pool—the addresses referenced in the inbound and outbound policies
cannot be symmetrical.

150  VPN Sites with Overlapping Addresses

 Chapter 4: Site-to-Site Virtual Private Networks

When you want the security device to perform source and destination address
translation on bidirectional VPN traffic through the same tunnel, you have two
choices:

 You can define a proxy ID for a policy-based VPN configuration. When you
specifically reference a VPN tunnel in a policy, the security device derives a
proxy ID from the components in the policy that references that tunnel. The
security device derives the proxy ID when you first create the policy, and each
time the device reboots thereafter. However, if you manually define a proxy ID
for a VPN tunnel that is referenced in a policy, the security device applies the
user-defined proxy ID, not the proxy ID derived from the policy.

NOTE: A proxy ID is a kind of agreement between IKE peers to permit traffic through a
tunnel if the traffic matches a specified tuple of local address, remote address, and
service.

 You can use a route-based VPN tunnel configuration, which must have a
user-defined proxy ID. With a route-based VPN tunnel configuration, you do not
specifically reference a VPN tunnel in a policy. Instead, the policy controls
access (permit or deny) to a particular destination. The route to that destination
points to a tunnel interface that in turn is bound to a VPN tunnel. Because the
VPN tunnel is not directly associated with a policy from which it can derive a
proxy ID from the source address, destination address, and service, you must
manually define a proxy ID for it. (Note that a route-based VPN configuration
also allows you to create multiple policies that make use of a single VPN tunnel;
that is, a single Phase 2 SA.)

Consider the addresses in Figure 41, which illustrates a VPN tunnel between two
sites with overlapping address spaces.

Figure 41: Overlapping Addresses at Peer Sites

Device A VPN Tunnel Device B

Internal Address Internal Address
Space Space
10.1.1.0/24 tunnel.1 tunnel.2 10.1.1.0/24
10.10.1.1/24 10.20.2.1/24

Addresses in Policies

10.10.1.2 – 10.10.1.2 DIP MIP 10.20.2.5 (to 10.1.1.5)

10.10.1.5 (to 10.1.1.5) MIP DIP 10.20.2.2 – 10.20.2.2

If the security devices in Figure 41 derive proxy IDs from the policies, as they do in
policy-based VPN configurations, then the inbound and outbound policies produce
the following proxy IDs:

Device A Device B
Local Remote Service Local Remote Service
Outbound 10.10.1.2/32 10.20.2.5/32 Any Inbound 10.20.2.5/32 10.10.1.2/32 Any
Inbound 10.10.1.5/32 10.20.2.2/32 Any Outbound 10.20.2.2/32 10.10.1.5/32 Any

VPN Sites with Overlapping Addresses  151

 Concepts & Examples ScreenOS Reference Guide

As shown in the table, there are two proxy IDs: one for outbound VPN traffic and
another for inbound. When Device A first sends traffic from 10.10.1.2/32 to
10.20.2.5/32, the two peers perform IKE negotiations and produce Phase 1 and
Phase 2 security associations (SAs). The Phase 2 SA results in the above outbound
proxy ID for Device A, and the inbound proxy ID for Device B.

If Device B then sends traffic to Device A, the policy lookup for traffic from
10.20.2.2/32 to 10.10.1.5/32 indicates that there is no active Phase 2 SA for such a
proxy ID. Therefore, the two peers use the existing Phase 1 SA (assuming that its
lifetime has not yet expired) to negotiate a different Phase 2 SA. The resulting proxy
IDs are shown above as the inbound proxy ID for Device A and the outbound proxy
ID for Device B. There are two Phase 2 SAs—two VPN tunnels—because the
addresses are asymmetrical and require different proxy IDs.

To create just one tunnel for bidirectional VPN traffic, you can define the following
proxy IDs with addresses whose scope includes both the translated source and
destination addresses at each end of the tunnel:

Device A Device B
Local Remote Service Local Remote Service
10.10.1.0/24 10.20.2.0/24 Any 10.20.2.0/24 10.10.1.0/24 Any
or
0.0.0.0/0 0.0.0.0/0 Any 0.0.0.0/0 0.0.0.0/0 Any

The above proxy IDs encompass addresses appearing in both inbound and
outbound VPN traffic between the two sites. The address 10.10.1.0/24 includes both
the DIP pool 10.10.1.2 – 10.10.1.2 and the MIP 10.10.1.5. Likewise, the address
10.20.2.0/24 includes both the DIP pool 10.20.2.2 – 10.20.2.2 and the MIP
10.20.2.5. The above proxy IDs are symmetrical; that is, the local address for
Device A is the remote address for Device B, and vice versa. If Device A sends
traffic to Device B, the Phase 2 SA and proxy ID also apply to traffic sent from
Device B to Device A. Thus, a single Phase 2 SA—that is, a single VPN tunnel—is all
that is required for bidirectional traffic between the two sites.

NOTE: The address 0.0.0.0/0 includes all IP addresses, and thus the addresses of the DIP
pool and MIP.

To create one VPN tunnel for bidirectional traffic between sites with overlapping
address spaces when the addresses for NAT-src and NAT-dst configured on the same
device are in different subnets from each other, the proxy ID for the tunnel must be
(local IP) 0.0.0.0/0 – (remote IP) 0.0.0.0/0 – service type. If you want to use more
restrictive addresses in the proxy ID, then the addresses for NAT-src and NAT-dst
must be in the same subnet.

In this example, you configure a VPN tunnel between Device A at a corporate site
and Device B at a branch office. The address space for the VPN end entities
overlaps; they both use addresses in the 10.1.1.0/24 subnet. To overcome this
conflict, you use NAT-src to translate the source address on outbound VPN traffic

152  VPN Sites with Overlapping Addresses

 Chapter 4: Site-to-Site Virtual Private Networks

and NAT-dst to translate the destination address on inbound VPN traffic. The
policies permit all addresses in the corporate LAN to reach an FTP server at the
branch site, and for all addresses at the branch office site to reach an FTP server at
the corporate site.

NOTE: For more information about Source Network Address Translation (NAT-src) and
Destination Network Address Translation (NAT-dst), see Volume 8: Address
Translation.

The tunnel configurations at both ends of the tunnel use the following parameters:
AutoKey IKE, preshared key (“netscreen1”), and the security level predefined as
“Compatible” for both Phase 1 and Phase 2 proposals. (For details about these
proposals, see “Tunnel Negotiation” on page 8.)

The outgoing interface on Device A at the corporate site is ethernet3, which has IP
address 1.1.1.1/24 and is bound to the Untrust zone. Device B at the branch office
uses this address as its remote IKE gateway.

The outgoing interface on Device B at the branch office is ethernet3, which has IP
address 2.2.2.2/24 and is bound to the Untrust zone. Device A at the corporate site
uses this address as its remote IKE gateway.

The Trust zone interface on both security devices is ethernet1 and has IP address
10.1.1.1/24. All zones on both security devices are in the trust-vr routing domain.

Figure 42: Tunnel Interface with NAT-Src and NAT-Dst

Topology of the zones Topology of the zones

configured on Device A at the configured on Device B at
branch office. the branch1 office.

A B B A

Trust Zone Untrust Zone Untrust Zone Trust Zone

serverB
Gateway Gateway 10.1.1.5
1.1.1.250 2.2.2.250
network A Internet network B
10.1.1.0/24 Device A 10.1.1.0/24
Device B
serverA
Tunnel.1 10.10.1.1/24 Tunnel.1 10.20.1.1/24
10.1.1.5

DIP 5 10.10.1.2 – 10.10.1.2 DIP 6 10.20.1.2 – 10.20.1.2

NAT-Dst 10.10.1.5 –> 10.1.1.5 NAT-Dst 10.20.1.5 –> 10.1.1.5

Users at network A can access server B. Users at network B can access server A.
All traffic flows through the VPN tunnel between the two sites.

network A Device A Device B serverB

server A VPN Tunnel network B

“vpn1”

VPN Sites with Overlapping Addresses  153

 Concepts & Examples ScreenOS Reference Guide

WebUI (Device A)
1. Interfaces
Network > Interfaces > Edit (for ethernet1): Enter the following, then click
Apply:

Zone Name: Trust

Static IP: (select this option when present)
IP Address/Netmask: 10.1.1.1/24

Select the following, then click OK:

Interface Mode: NAT

Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:

Zone Name: Untrust

Static IP: (select this option when present)
IP Address/Netmask: 1.1.1.1/24

Network > Interfaces > New Tunnel IF: Enter the following, then click OK:

Tunnel Interface Name: tunnel.1

Zone (VR): Untrust (trust-vr)
Fixed IP: (select)
IP Address / Netmask: 10.10.1.1/24
2. DIP
Network > Interfaces > Edit (for tunnel.1) > DIP > New: Enter the following,
then click OK:

ID: 5
IP Address Range: (select), 10.10.1.2 ~ 10.10.1.2
Port Translation: (select)
In the same subnet as the interface IP or its secondary IPs: (select)
3. Addresses
Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: corp

IP Address/Domain Name:
IP/Netmask: (select), 10.1.1.0/24
Zone: Trust

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: virtualA

IP Address/Domain Name:
IP/Netmask: (select), 10.10.1.5/32
Zone: Trust

154  VPN Sites with Overlapping Addresses

 Chapter 4: Site-to-Site Virtual Private Networks

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: branch1

IP Address/Domain Name:
IP/Netmask: (select), 10.20.1.2/32
Zone: Untrust

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: serverB

IP Address/Domain Name:
IP/Netmask: (select), 10.20.1.5/32
Zone: Untrust
4. VPN
VPNs > AutoKey IKE > New: Enter the following, then click OK:

VPN Name: vpn1

Security Level: Compatible
Remote Gateway: Create a Simple Gateway: (select)
Gateway Name: branch1
Type: Static IP: (select), Address/Hostname: 2.2.2.2
Preshared Key: netscreen1
Security Level: Compatible
Outgoing Interface: ethernet3

NOTE: The outgoing interface does not have to be in the same zone to which the tunnel
interface is bound, although in this case they are in the same zone.

> Advanced: Enter the following advanced settings, then click Return to
return to the basic AutoKey IKE configuration page:

Bind to: Tunnel Interface, tunnel.1

Proxy-ID: (select)
Local IP / Netmask: 10.10.1.0/24
Remote IP / Netmask: 10.20.1.0/24
Service: ANY
5. Routes
Network > Routing > Routing Entries > trust-vr New: Enter the following,
then click OK:

Network Address/Netmask: 0.0.0.0/0

Gateway: (select)
Interface: ethernet3
Gateway IP Address: 1.1.1.250

Network > Routing > Routing Entries > trust-vr New: Enter the following,
then click OK:

Network Address/Netmask: 10.20.1.0/24

Gateway: (select)
Interface: tunnel.1
Gateway IP Address: 0.0.0.0

VPN Sites with Overlapping Addresses  155

 Concepts & Examples ScreenOS Reference Guide

Network > Routing > Routing Entries > trust-vr New: Enter the following,
then click OK:

Network Address/Netmask: 10.20.1.0/24

Gateway: (select)
Interface: Null
Gateway IP Address: 0.0.0.0
Metric: 10
6. Policies
Policies > (From: Trust, To: Untrust) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), corp
Destination Address:
Address Book Entry: (select), serverB
Service: FTP
Action: Permit
Position at Top: (select)

> Advanced: Enter the following advanced settings, then click Return to
return to the basic Policy configuration page:

NAT:
Source Translation: (select)
DIP On: 5 (10.10.1.2–10.10.1.2)/X-late

Policies > (From: Untrust, To: Trust) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), branch1
Destination Address:
Address Book Entry: (select), virtualA
Service: FTP
Action: Permit
Position at Top: (select)

> Advanced: Enter the following advanced settings, then click Return to
return to the basic Policy configuration page:

NAT:
Destination Translation: (select)
Translate to IP: (select), 10.1.1.5
Map to Port: (clear)

WebUI (Device B)
1. Interfaces
Network > Interfaces > Edit (for ethernet1): Enter the following, then click
Apply:

Zone Name: Trust

Static IP: (select this option when present)
IP Address/Netmask: 10.1.1.1/24

Select the following, then click OK:

Interface Mode: NAT

156  VPN Sites with Overlapping Addresses

 Chapter 4: Site-to-Site Virtual Private Networks

Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:

Zone Name: Untrust

Static IP: (select this option when present)
IP Address/Netmask: 2.2.2.2/24

Network > Interfaces > New Tunnel IF: Enter the following, then click OK:

Tunnel Interface Name: tunnel.1

Zone (VR): Untrust (trust-vr)
Fixed IP: (select)
IP Address / Netmask: 10.20.1.1/24
2. DIP
Network > Interfaces > Edit (for tunnel.1) > DIP > New: Enter the following,
then click OK:

ID: 6
IP Address Range: (select), 10.20.1.2 ~ 10.20.1.2
Port Translation: (select)
In the same subnet as the interface IP or its secondary IPs: (select)
3. Addresses
Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: branch1

IP Address/Domain Name:
IP/Netmask: (select), 10.1.1.0/24
Zone: Trust

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: virtualB

IP Address/Domain Name:
IP/Netmask: (select), 10.20.1.5/32
Zone: Trust

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: corp

IP Address/Domain Name:
IP/Netmask: (select), 10.10.1.2/32
Zone: Untrust

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: serverA

IP Address/Domain Name:
IP/Netmask: (select), 10.10.1.5/32
Zone: Untrust

VPN Sites with Overlapping Addresses  157

 Concepts & Examples ScreenOS Reference Guide

4. VPN
VPNs > AutoKey IKE > New: Enter the following, then click OK:

VPN Name: vpn1

Security Level: Compatible
Remote Gateway: Create a Simple Gateway: (select)
Gateway Name: corp
Type: Static IP: (select), Address/Hostname: 1.1.1.1
Preshared Key: netscreen1
Security Level: Compatible
Outgoing Interface: ethernet3

> Advanced: Enter the following advanced settings, then click Return to
return to the basic AutoKey IKE configuration page:

Bind to: Tunnel Interface, tunnel.1

Proxy-ID: (select)
Local IP / Netmask: 10.20.1.0/24
Remote IP / Netmask: 10.10.1.0/24
Service: ANY

NOTE: The outgoing interface does not have to be in the same zone to which the tunnel
interface is bound, although in this case they are in the same zone.

5. Routes
Network > Routing > Routing Entries > trust-vr New: Enter the following,
then click OK:

Network Address/Netmask: 0.0.0.0/0

Gateway: (select)
Interface: ethernet3
Gateway IP Address: 2.2.2.250

Network > Routing > Routing Entries > trust-vr New: Enter the following,
then click OK:

Network Address/Netmask: 10.10.1.0/24

Gateway: (select)
Interface: tunnel.1
Gateway IP Address: 0.0.0.0

Network > Routing > Routing Entries > trust-vr New: Enter the following,
then click OK:

Network Address/Netmask: 10.10.1.0/24

Gateway: (select)
Interface: Null
Gateway IP Address: 0.0.0.0
Metric: 10

158  VPN Sites with Overlapping Addresses

 Chapter 4: Site-to-Site Virtual Private Networks

6. Policies
Policies > (From: Trust, To: Untrust) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), corp
Destination Address:
Address Book Entry: (select), serverA
Service: FTP
Action: Permit
Position at Top: (select)

> Advanced: Enter the following advanced settings, then click Return to
return to the basic Policy configuration page:

NAT:
Source Translation: (select)
DIP on: 6 (10.20.1.2–10.20.1.2)/X-late

Policies > (From: Untrust, To: Trust) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), corp
Destination Address:
Address Book Entry: (select), virtualB
Service: FTP
Action: Permit
Position at Top: (select)

> Advanced: Enter the following advanced settings, then click Return to
return to the basic Policy configuration page:

NAT:
Destination Translation: (select)
Translate to IP: 10.1.1.5
Map to Port: (clear)

CLI (Device A)
1. Interfaces
set interface ethernet1 zone trust
set interface ethernet1 ip 10.1.1.1/24
set interface ethernet1 nat
set interface ethernet3 zone untrust
set interface ethernet3 ip 1.1.1.1/24
set interface tunnel.1 zone untrust
set interface tunnel.1 ip 10.10.1.1/24
2. DIP
set interface tunnel.1 dip 5 10.10.1.2 10.10.1.2
3. Addresses
set address trust corp 10.1.1.0/24
set address trust virtualA 10.10.1.5/32
set address untrust branch1 10.20.1.2/32
set address untrust serverB 10.20.1.5/32

VPN Sites with Overlapping Addresses  159

 Concepts & Examples ScreenOS Reference Guide

4. VPN
set ike gateway branch1 address 2.2.2.2 outgoing-interface ethernet3 preshare
netscreen1 sec-level compatible
set vpn vpn1 gateway branch1 sec-level compatible
set vpn vpn1 bind interface tunnel.1
set vpn vpn1 proxy-id local-ip 10.10.1.0/24 remote-ip 10.20.1.0/24 any

NOTE: The outgoing interface does not have to be in the same zone to which the tunnel
interface is bound, although in this case they are in the same zone.

5. Routes
set vrouter trust-vr route 0.0.0.0/0 interface ethernet3 gateway 1.1.1.250
set vrouter trust-vr route 10.20.1.0/24 interface tunnel.1
set vrouter trust-vr route 10.20.1.0/24 interface null metric 10
6. Policies
set policy top from trust to untrust corp serverB ftp nat src dip-id 5 permit
set policy top from untrust to trust branch1 virtualA ftp nat dst ip 10.1.1.5 permit
save

CLI (Device B)
1. Interfaces
set interface ethernet1 zone trust
set interface ethernet1 ip 10.1.1.1/24
set interface ethernet1 nat
set interface ethernet3 zone untrust
set interface ethernet3 ip 2.2.2.2/24
set interface tunnel.1 zone untrust
set interface tunnel.1 ip 10.20.1.1/24
2. DIP
set interface tunnel.1 dip 6 10.20.1.2 10.20.1.2
3. Addresses
set address trust branch1 10.1.1.0/24
set address trust virtualB 10.20.1.5/32
set address untrust corp 10.10.1.2/32
set address untrust serverA 10.10.1.5/32
4. VPN
set ike gateway corp address 1.1.1.1 outgoing-interface ethernet3 preshare
netscreen1 sec-level compatible
set vpn vpn1 gateway corp sec-level compatible
set vpn vpn1 bind interface tunnel.1
set vpn vpn1 proxy-id local-ip 10.20.1.0/24 remote-ip 10.10.1.0/24 any

NOTE: The outgoing interface does not have to be in the same zone to which the tunnel
interface is bound, although in this case they are in the same zone.

5. Routes
set vrouter trust-vr route 0.0.0.0/0 interface ethernet3 gateway 2.2.2.250
set vrouter trust-vr route 10.10.1.0/24 interface tunnel.1
set vrouter trust-vr route 10.10.1.0/24 interface null metric 10

160  VPN Sites with Overlapping Addresses

 Chapter 4: Site-to-Site Virtual Private Networks

6. Policies
set policy top from trust to untrust branch1 serverA ftp nat src dip-id 6 permit
set policy top from untrust to trust corp virtualB ftp nat dst ip 10.1.1.5 permit
save

Transparent Mode VPN

When the security device interfaces are in Transparent mode (that is, they have no
IP addresses and are operating at Layer 2 in the OSI Model), you can use the VLAN1
IP address as a VPN termination point. In place of an outgoing interface, as used
when the interfaces are in Route or NAT mode (that is, they have IP addresses and
are operating at Layer 3), a VPN tunnel references an outgoing zone. By default, a
tunnel uses the V1-Untrust zone as its outgoing zone. If you have multiple interfaces
bound to the same outgoing zone, the VPN tunnel can use any one of them.

NOTE: The OSI Model is a networking industry standard model of network protocol
architecture. The OSI Model consists of seven layers, in which Layer 2 is the
Data-Link Layer and Layer 3 is the Network Layer.

At the time of this release, a security device whose interfaces are in Transparent
mode supports only policy-based VPNs. For more information about Transparent
mode, see “Transparent Mode” on page 2-80.

It is not necessary that the interfaces of both security devices be in Transparent

mode. The interfaces of the device at one end of the tunnel can be in Transparent
mode and those of the other device can be in Route or NAT mode.

In this example, you set up a policy-based AutoKey IKE VPN tunnel between two
security devices with interfaces operating in Transparent mode.

NOTE: It is not necessary that the interfaces of both security devices be in Transparent
mode. The interfaces of the device at one end of the tunnel can be in Transparent
mode and those of the other device can be in Route or NAT mode.

The key elements of the configuration for the security devices at both ends of the
tunnel are as follows:

Configuration Elements Device A Device B

V1-Trust Zone Interface: ethernet1, 0.0.0.0/0 Interface: ethernet1, 0.0.0.0/0
(enable management for the local admin) (enable management for the local admin)
V1-Untrust Zone Interface: ethernet3, 0.0.0.0/0 Interface: ethernet3, 0.0.0.0/0
VLAN1 Interface IP Address: 1.1.1.1/24 IP Address: 2.2.2.2/24
Manage IP: 1.1.1.21 Manage IP: 2.2.2.3
Addresses local_lan: 1.1.1.0/24 in V1-Trust local_lan: 2.2.2.0/24 in V1-Trust
peer_lan: 2.2.2.0/24 in V1-Untrust peer_lan: 1.1.1.0/24 in V1-Untrust
IKE gateway gw1, 2.2.2.2, preshared key h1p8A24nG5, gw1, 1.1.1.1, preshared key h1p8A24nG5,
security: compatible security: compatible
VPN tunnel security: compatible security: compatible

Transparent Mode VPN  161

 Concepts & Examples ScreenOS Reference Guide

Configuration Elements Device A Device B

Policies local_lan -> peer_lan, any service, vpn1 local_lan -> peer_lan, any service, vpn1
peer_lan -> local_lan, any service, vpn1 peer_lan -> local_lan, any service, vpn1
External Router IP Address: 1.1.1.250 IP Address: 2.2.2.250
Route 0.0.0.0/0, use VLAN1 interface 0.0.0.0/0, use VLAN1 interface
to gateway 1.1.1.250 to gateway 2.2.2.250

1.You can separate administrative from VPN traffic by using the manage IP address to receive administrative traffic
and the VLAN1 address to terminate VPN traffic.

Configuring a policy-based AutoKey IKE tunnel for a security device whose

interfaces are in Transparent mode involves the following steps:

1. Remove any IP addresses from the physical interfaces, and bind them to the
Layer 2 security zones.

2. Assign an IP address and manage IP address to the VLAN1 interface.

3. Enter the IP addresses for the local and remote endpoints in the address books
for the V1-Trust and V1-Untrust zones.

4. Configure the VPN tunnel and designate its outgoing zone as the V1-Untrust
zone.

5. Enter a default route to the external router in the trust-vr.

6. Set up policies for VPN traffic to pass between each site.

WebUI (Device A)
1. Interfaces

NOTE: Moving the VLAN1 IP address to a different subnet causes the security device to
delete any routes involving the previous VLAN1 interface. When configuring a
security device through the WebUI, your workstation must reach the first VLAN1
address and then be in the same subnet as the new address. After changing the
VLAN1 address, you must then change the IP address of your workstation so that
it is in the same subnet as the new VLAN1 address. You might also have to relocate
your workstation to a subnet physically adjacent to the security device.

Network > Interfaces > Edit (for the VLAN1 interface): Enter the following,
then click OK:

IP Address/Netmask: 1.1.1.1/24
Manage IP: 1.1.1.2
Management Services: WebUI, Telnet, Ping

NOTE: You enable the management options for WebUI, Telnet, and Ping on both the
V1-Trust zone and the VLAN1 interface so that a local admin in the V1-Trust zone
can reach the VLAN1 manage IP address. If management through the WebUI is
not already enabled on VLAN1 and the V1-Trust zone interfaces, you cannot reach
the security device through the WebUI to make these settings. Instead, you must
first set WebUI manageability on these interfaces through a console connection.

162  Transparent Mode VPN

 Chapter 4: Site-to-Site Virtual Private Networks

Network > Interfaces > Edit (for ethernet1): Enter the following, then click
Apply:

Management Services: WebUI, Telnet

Other Services: Ping

Select the following, then click OK:

Zone Name: V1-Trust

IP Address/Netmask: 0.0.0.0/0

Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:

Zone Name: V1-Untrust

IP Address/Netmask: 0.0.0.0/0
2. Addresses
Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: local_lan

IP Address/Domain Name:
IP/Netmask: (select), 1.1.1.0/24
Zone: V1-Trust

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: peer_lan

IP Address/Domain Name:
IP/Netmask: (select), 2.2.2.0/24
Zone: V1-Untrust
3. VPN
VPNs > AutoKey Advanced > Gateway > New: Enter the following, then click
OK:

Gateway Name: gw1

Security Level: Compatible
Remote Gateway Type:
Static IP Address: (select), IP Address/Hostname: 2.2.2.2
Preshared Key: h1p8A24nG5
Outgoing Zone: V1-Untrust

Transparent Mode VPN  163

 Concepts & Examples ScreenOS Reference Guide

VPNs > AutoKey IKE > New: Enter the following, then click OK:

VPN Name: vpn1

Security Level: Compatible
Remote Gateway:
Predefined: (select), gw1
4. Route
Network > Routing > Routing Entries > trust-vr New: Enter the following,
then click OK:

Network Address/Netmask: 0.0.0.0/0

Gateway: (select)
Interface: VLAN1 (VLAN)
Gateway IP Address: 1.1.1.250
5. Policies
Policies > (From: Trust, To: Untrust) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), local_lan
Destination Address:
Address Book Entry: (select), peer_lan
Service: ANY
Action: Tunnel
Tunnel VPN: vpn1
Modify matching bidirectional VPN policy: (select)
Position at Top: (select)

WebUI (Device B)
1. Interfaces

NOTE: Moving the VLAN1 IP address to a different subnet causes the security device to
delete any routes involving the previous VLAN1 interface. When configuring a
security device through the WebUI, your workstation must reach the first VLAN1
address and then be in the same subnet as the new address. After changing the
VLAN1 address, you must then change the IP address of your workstation so that
it is in the same subnet as the new VLAN1 address. You might also have to relocate
your workstation to a subnet physically adjacent to the security device.

Network > Interfaces > Edit (for the VLAN1 interface): Enter the following,
then click OK:

IP Address/Netmask: 2.2.2.2/24
Manage IP: 2.2.2.3
Management Services: WebUI, Telnet, Ping

NOTE: If management through the WebUI is not already enabled on VLAN1 and the
V1-Trust zone interfaces, you cannot reach the security device through the WebUI
to make these settings. Instead, you must first set WebUI manageability on these
interfaces through a console connection.

164  Transparent Mode VPN

 Chapter 4: Site-to-Site Virtual Private Networks

Network > Interfaces > Edit (for ethernet1): Enter the following, then click
Apply:

Management Services: WebUI, Telnet

Other Services: Ping

Select the following, then click OK:

Zone Name: V1-Trust

IP Address/Netmask: 0.0.0.0/0

Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:

Zone Name: V1-Untrust

IP Address/Netmask: 0.0.0.0/0
2. Addresses
Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: local_lan

IP Address/Domain Name:
IP/Netmask: (select), 2.2.2.0/24
Zone: V1-Trust

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: peer_lan

IP Address/Domain Name:
IP/Netmask: (select), 1.1.1.0/24
Zone: V1-Untrust
3. VPN
VPNs > AutoKey Advanced > Gateway > New: Enter the following, then click
OK:

Gateway Name: gw1

Security Level: Compatible
Remote Gateway Type:
Static IP Address: (select), IP Address/Hostname: 1.1.1.1
Preshared Key: h1p8A24nG5
Outgoing Zone: V1-Untrust

VPNs > AutoKey IKE > New: Enter the following, then click OK:

VPN Name: vpn1

Security Level: Compatible
Remote Gateway:
Predefined: (select), gw1

Transparent Mode VPN  165

 Concepts & Examples ScreenOS Reference Guide

4. Route
Network > Routing > Routing Entries > trust-vr New: Enter the following,
then click OK:

Network Address/Netmask: 0.0.0.0/0

Gateway: (select)
Interface: VLAN1 (VLAN)
Gateway IP Address: 2.2.2.250
5. Policies
Policies > (From: Trust, To: Untrust) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), local_lan
Destination Address:
Address Book Entry: (select), peer_lan
Service: ANY
Action: Tunnel
Tunnel VPN: vpn1
Modify matching bidirectional VPN policy: (select)
Position at Top: (select)

CLI (Device A)
1. Interfaces and Zones
unset interface ethernet1 ip
unset interface ethernet1 zone
set interface ethernet1 zone v1-trust
set zone v1-trust manage web
set zone v1-trust manage telnet
set zone v1-trust manage ping
unset interface ethernet3 ip
unset interface ethernet3 zone
set interface ethernet3 zone v1-untrust
set interface vlan1 ip 1.1.1.1/24
set interface vlan1 manage-ip 1.1.1.2
set interface vlan1 manage web
set interface vlan1 manage telnet
set interface vlan1 manage ping

NOTE: You enable the management options for WebUI, Telnet, and Ping on both the
V1-Trust zone and the VLAN1 interface so that a local admin in the V1-Trust zone
can reach the VLAN1 manage IP address.

2. Addresses
set address v1-trust local_lan 1.1.1.0/24
set address v1-untrust peer_lan 2.2.2.0/24
3. VPN
set ike gateway gw1 address 2.2.2.2 main outgoing-interface v1-untrust preshare
h1p8A24nG5 sec-level compatible
set vpn vpn1 gateway gw1 sec-level compatible

166  Transparent Mode VPN

 Chapter 4: Site-to-Site Virtual Private Networks

4. Routes
set vrouter trust-vr route 0.0.0.0/0 interface vlan1 gateway 1.1.1.250
5. Policies
set policy top from v1-trust to v1-untrust local_lan peer_lan any tunnel vpn vpn1
set policy top from v1-untrust to v1-trust peer_lan local_lan any tunnel vpn vpn1
save

CLI (Device B)
1. Interfaces and Zones
unset interface ethernet1 ip
unset interface ethernet1 zone
set interface ethernet1 zone v1-trust
set zone v1-trust manage
unset interface ethernet3 ip
unset interface ethernet3 zone
set interface ethernet3 zone v1-untrust
set interface vlan1 ip 2.2.2.2/24
set interface vlan1 manage-ip 2.2.2.3
set interface vlan1 manage
2. Addresses
set address v1-trust local_lan 2.2.2.0/24
set address v1-untrust peer_lan 1.1.1.0/24
3. VPN
set ike gateway gw1 address 1.1.1.1 main outgoing-interface v1-untrust preshare
h1p8A24nG5 sec-level compatible
set vpn vpn1 gateway gw1 sec-level compatible
4. Routes
set vrouter trust-vr route 0.0.0.0/0 interface vlan1 gateway 2.2.2.250
5. Policies
set policy top from v1-trust to v1-untrust local_lan peer_lan any tunnel vpn vpn1
set policy top from v1-untrust to v1-trust peer_lan local_lan any tunnel vpn vpn1
save

Transparent Mode VPN  167

 Concepts & Examples ScreenOS Reference Guide

168  Transparent Mode VPN

Chapter 5
Dialup Virtual Private Networks

Juniper Networks security devices can support dialup virtual private network (VPN)
connections. You can configure a security device that has a static IP address to
secure an IPSec tunnel with a NetScreen-Remote client or with another security
device with a dynamic IP address.

This chapter contains the following sections:

 “Dialup” on page 170

 “Policy-Based Dialup VPN, AutoKey IKE” on page 170

 “Route-Based Dialup VPN, Dynamic Peer” on page 176

 “Policy-Based Dialup VPN, Dynamic Peer” on page 183

 “Bidirectional Policies for Dialup VPN Users” on page 188

 “Group IKE ID” on page 193

 “Group IKE ID with Certificates” on page 193

 “Wildcard and Container ASN1-DN IKE ID Types” on page 195

 “Creating a Group IKE ID (Certificates)” on page 197

 “Setting a Group IKE ID with Preshared Keys” on page 202

 “Shared IKE ID” on page 208

 169
 Concepts & Examples ScreenOS Reference Guide

Dialup
You can configure tunnels for VPN dialup users individually, or you can form users
into a VPN dialup group for which you need only configure one tunnel. You can also
create a group IKE ID user that allows you to define one user whose IKE ID is used
as part of the IKE IDs of dialup IKE users. This approach is particularly timesaving
when there are large groups of dialup users because you do not have to configure
each IKE user individually.

NOTE: For more information about creating IKE user groups, see “IKE Users and User
Groups” on page 9-67. For more information about the Group IKE ID feature, see
“Group IKE ID” on page 193.

If the dialup client can support a virtual internal IP address, which the
NetScreen-Remote does, you can also create a dynamic peer dialup VPN, AutoKey
IKE tunnel (with a preshared key or certificates). You can configure a Juniper
Networks security gateway with a static IP address to secure an IPSec tunnel with a
NetScreen-Remote client or with another security device with a dynamic IP address.

NOTE: For background information about the available VPN options, see “Internet
Protocol Security” on page 1. For guidance when choosing among the various
options, see “Virtual Private Network Guidelines” on page 57.

You can configure policy-based VPN tunnels for VPN dialup users. For a dialup
dynamic peer client, you can configure either a policy-based or route-based VPN.
Because a dialup dynamic peer client can support a virtual internal IP address,
which the NetScreen-Remote does, you can configure a routing table entry to that
virtual internal address through a designated tunnel interface. Doing so allows you
to configure a route-based VPN tunnel between the security device and that peer.

NOTE: A dialup dynamic peer client is a dialup client that supports a virtual internal IP
address.

The dialup dynamic peer is nearly identical to the Site-to-Site dynamic peer except
that the internal IP address for the dialup client is a virtual address.

Policy-Based Dialup VPN, AutoKey IKE

In this example, an AutoKey IKE tunnel using either a preshared key or a pair of
certificates (one at each end of the tunnel) provides the secure communication
channel between the IKE user Wendy and the UNIX server. The tunnel again uses
ESP with 3DES encryption and SHA-1 authentication.

NOTE: The preshared key is h1p8A24nG5. It is assumed that both participants already
have certificates. For more information about certificates, see “Certificates and
CRLs” on page 34.

170  Dialup
 Chapter 5: Dialup Virtual Private Networks

Setting up the AutoKey IKE tunnel using AutoKey IKE with either a preshared key or
certificates requires the following configuration at the corporate site:

1. Configure interfaces for the Trust and Untrust zones, both of which are in the
trust-vr routing domain.

2. Enter the address of the UNIX server in the Trust zone address book.

3. Define Wendy as an IKE user.

4. Configure the remote gateway and AutoKey IKE VPN.

5. Set up a default route.

6. Create a policy from the Untrust zone to the Trust zone permitting access to the
UNIX from the dialup user.

Figure 43: Policy-Based Dialup VPN, AutoKey IKE

Outgoing Interface Corporate Office
Remote User: Wendy Untrust Zone Trust Zone
NetScreen-Remote ethernet3, 1.1.1.1/24 ethernet1, 10.1.1.1/24
Gateway 1.1.1.250

Untrust Zone UNIX Server

10.1.1.5
Internet
LAN
VPN Tunnel

Untrust Trust
Zone Zone

The preshared key is h1p8A24nG5. This example assumes that both participants
already have RSA certificates issued by Verisign and that the local certificate on the
NetScreen-Remote contains the U-FQDN [email protected]. (For information
about obtaining and loading certificates, see “Certificates and CRLs” on page 34.)
For the Phase 1 and 2 security levels, you specify one Phase 1 proposal—either
pre-g2-3des-sha for the preshared key method or rsa-g2-3des-sha for
certificates—and select the predefined “Compatible” set of proposals for Phase 2.

WebUI
1. Interfaces
Network > Interfaces > Edit (for ethernet1): Enter the following, then click
Apply:

Zone Name: Trust

Static IP: (select this option when present)
IP Address/Netmask: 10.1.1.1/24
Select the following, then click OK:
Interface Mode: NAT

Dialup  171
 Concepts & Examples ScreenOS Reference Guide

Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:

Zone Name: Untrust

Static IP: (select this option when present)
IP Address/Netmask: 1.1.1.1/24
2. Address
Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: UNIX

IP Address/Domain Name:
IP/Netmask: (select), 10.1.1.5/32
Zone: Trust
3. User
Objects > Users > Local > New: Enter the following, then click OK:

User Name: Wendy

Status: Enable (select)
IKE User: (select)
Simple Identity: (select)
IKE Identity: [email protected]
4. VPN
VPNs > AutoKey Advanced > Gateway > New: Enter the following, then click
OK:

Gateway Name: Wendy_NSR

Security Level: Custom
Remote Gateway Type:
Dialup User: (select), User: Wendy
Certificates
Outgoing Interface: ethernet3

> Advanced: Enter the following advanced settings, then click Return to
return to the basic Gateway configuration page:

Security Level: Custom

Phase 1 Proposal (For Custom Security Level): rsa-g2-3des-sha
Mode (Initiator): Aggressive
Preferred Certificate (optional):
Peer CA: Verisign
Peer Type: X509-SIG

172  Dialup
 Chapter 5: Dialup Virtual Private Networks

VPNs > AutoKey IKE > New: Enter the following, then click OK:

VPN Name: Wendy_UNIX

Security Level: Compatible
Remote Gateway:
Predefined: (select), Wendy_NSR

(or)

Preshared Key

CAUTION: Aggressive mode is insecure. Due to protocol limitations, Main mode

IKE in combination with preshared key (PSK) is not possible for dialup VPN users.
In addition, it is never advisable to use Aggressive mode because this mode has
inherent security problems. Consequently, it is strongly advisable to configure
dialup VPN users with PKI certificates and Main mode.

Preshared Key: h1p8A24nG5

Outgoing Interface: ethernet3

> Advanced: Enter the following advanced settings, then click Return to
return to the basic Gateway configuration page:

Security Level: Custom

Phase 1 Proposal (For Custom Security Level): pre-g2-3des-sha
Mode (Initiator): Aggressive
5. Route
Network > Routing > Routing Entries > trust-vr New: Enter the following,
then click OK:

Network Address/Netmask: 0.0.0.0/0

Gateway: (select)
Interface: ethernet3
Gateway IP Address: 1.1.1.250
6. Policy
Policies > (From: Untrust, To: Trust) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), Dial-Up VPN
Destination Address:
Address Book Entry: (select), UNIX
Service: ANY
Action: Tunnel
Tunnel VPN: Wendy_UNIX
Modify matching bidirectional VPN policy: (clear)
Position at Top: (select)

CLI
1. Interfaces
set interface ethernet1 zone trust
set interface ethernet1 ip 10.1.1.1/24
set interface ethernet1 nat
set interface ethernet3 zone untrust
set interface ethernet3 ip 1.1.1.1/24

Dialup  173
 Concepts & Examples ScreenOS Reference Guide

2. Address
set address trust unix 10.1.1.5/32
3. User
set user wendy ike-id u-fqdn [email protected]
4. VPN
Certificates
set ike gateway wendy_nsr dialup wendy aggressive outgoing-interface ethernet3
proposal rsa-g2-3des-sha
set ike gateway wendy_nsr cert peer-ca 1
set ike gateway wendy_nsr cert peer-cert-type x509-sig
set vpn wendy_unix gateway wendy_nsr sec-level compatible

NOTE: The number 1 is the CA ID number. To discover the CA’s ID number, use the
following command: get pki x509 list ca-cert.

(or)

Preshared Key

CAUTION: Aggressive mode is insecure. Due to protocol limitations, Main mode

IKE in combination with preshared key (PSK) is not possible for dialup VPN users.
In addition, it is never advisable to use Aggressive mode because this mode has
inherent insecurity problems. Consequently, it is strongly advisable to configure
dialup VPN users with PKI certificates and Main mode.

set ike gateway wendy_nsr dialup wendy aggressive outgoing-interface ethernet3

preshare h1p8A24nG5 proposal pre-g2-3des-sha
set vpn wendy_unix gateway wendy_nsr sec-level compatible
5. Route
set vrouter trust-vr route 0.0.0.0/0 interface ethernet3 gateway 1.1.1.250
6. Policy
set policy top from untrust to trust “Dial-Up VPN” unix any tunnel vpn wendy_unix
save

NetScreen-Remote Security Policy Editor

1. Click Options > Secure > Specified Connections.

2. Click Add a new connection, and type UNIX next to the new connection icon
that appears.

3. Configure the connection options:

Connection Security: Secure

Remote Party Identity and Addressing:
ID Type: IP Address, 10.1.1.5
Protocol: All
Connect using Secure Gateway Tunnel: (select)
ID Type: IP Address, 1.1.1.1

4. Click the PLUS symbol, located to the left of the UNIX icon, to expand the
connection policy.

174  Dialup
 Chapter 5: Dialup Virtual Private Networks

5. Click My Identity: Do either of the following:

Click Pre-shared Key > Enter Key: Type h1p8A24nG5, then click OK.

ID Type: (select E-mail Address), and type [email protected].

(or)

Select a certificate from the Select Certificate drop-down list.

ID Type: (select E-mail Address)

NOTE: The email address from the certificate automatically appears in the identifier field.

6. Click the Security Policy icon, then select Aggressive Mode and clear Enable
Perfect Forward Secrecy (PFS).

7. Click the PLUS symbol, located to the left of the Security Policy icon, and then
the PLUS symbol to the left of Authentication (Phase 1) and Key Exchange
(Phase 2) to expand the policy further.

8. Click Authentication (Phase 1) > Proposal 1: Select the following

Authentication Method and Algorithms:

Authentication Method: Pre-Shared Key

(or)

Authentication Method: RSA Signatures

Encrypt Alg: Triple DES
Hash Alg: SHA-1
Key Group: Diffie-Hellman Group 2

9. Click Key Exchange (Phase 2) > Proposal 1: Select the following IPSec
Protocols:

Encapsulation Protocol (ESP): (select)

Encrypt Alg: Triple DES
Hash Alg: SHA-1
Encapsulation: Tunnel

10. Click Key Exchange (Phase 2) > Create New Proposal: Select the following
IPSec Protocols:

Encapsulation Protocol (ESP): (select)

Encrypt Alg: Triple DES
Hash Alg: MD5
Encapsulation: Tunnel

Dialup  175
 Concepts & Examples ScreenOS Reference Guide

11. Click Key Exchange (Phase 2) > Create New Proposal: Select the following
IPSec Protocols:

Encapsulation Protocol (ESP): (select)

Encrypt Alg: DES
Hash Alg: SHA-1
Encapsulation: Tunnel

12. Click Key Exchange (Phase 2) > Create New Proposal: Select the following
IPSec Protocols:

Encapsulation Protocol (ESP): (select)

Encrypt Alg: DES
Hash Alg: MD5
Encapsulation: Tunnel

13. Click File > Save Changes.

Route-Based Dialup VPN, Dynamic Peer

In this example, a VPN tunnel securely connects the user behind the
NetScreen-Remote to the Untrust zone interface of the security device protecting
the mail server in the DMZ zone. The Untrust zone interface has a static IP address.
The NetScreen-Remote client has a dynamically assigned external IP address and a
static (virtual) internal IP address. The administrator of the security device must
know the peer’s internal IP address for the following two purposes:

 The admin can use it in policies.

 The admin can create a route linking the address with a tunnel interface bound
to an appropriate tunnel.

After the NetScreen-Remote client establishes the tunnel, traffic through the tunnel
can then originate from either end. All zones on the security device are in the
trust-vr routing domain.

Figure 44: Route-Based Dialup VPN, Dynamic Peer

Remote User: Phil Outgoing Interface Corporate Office

NetScreen-Remote ethernet3 ethernet2
1.1.1.1/24 1.2.2.1/24
DMZ Zone Mail Server
Untrust Zone Gateway
SMTP 1.2.2.5
Request 1.1.1.250
Internet

VPN Tunnel IDENT

Request

External IP Address Tunnel Interface

Internal IP Address
Dynamic Tunnel.1
10.10.10.1

In this example, Phil wants to get his email from the mail server at the company
site. When he attempts to do so, he is authenticated by the mail server program,
which sends him an IDENT request through the tunnel.

176  Dialup
 Chapter 5: Dialup Virtual Private Networks

NOTE: The mail server can send the IDENT request through the tunnel only if the security
administrator adds a custom service for it (TCP, port 113) and sets up an outgoing
policy allowing that traffic through the tunnel to 10.10.10.1.

The preshared key is h1p8A24nG5. It is assumed that both participants already

have RSA certificates issued by Verisign and that the local certificate on the
NetScreen-Remote contains the U-FQDN [email protected]. (For information about
obtaining and loading certificates, see “Certificates and CRLs” on page 34.) For the
Phase 1 and Phase 2 security levels, you specify one Phase 1 proposal—either
pre-g2-3des-sha for the preshared key method or rsa-g2-3des-sha for
certificates—and select the predefined “Compatible” set of proposals for Phase 2.

You enter the following three routes on the security device:

 A default route to the external router in the trust-vr

 A route to the destination through the tunnel interface

 A null route to the destination. You assign a higher metric (farther from zero) to
the null route so that it becomes the next-choice route to the destination. Then,
if the state of the tunnel interface changes to “down” and the route referencing
that interface becomes inactive, the security device uses the null route, which
essentially drops any traffic sent to it, rather than the default route, which
forwards unencrypted traffic.

Finally, you create policies allowing traffic to flow in both directions between Phil
and the mail server.

WebUI
1. Interfaces
Network > Interfaces > Edit (for ethernet2): Enter the following, then click
OK:

Zone Name: DMZ

Static IP: (select this option when present)
IP Address/Netmask: 1.2.2.1/24

Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:

Zone Name: Untrust

Static IP: (select this option when present)
IP Address/Netmask: 1.1.1.1/24

Network > Interfaces > New Tunnel IF: Enter the following, then click OK:

Tunnel Interface Name: tunnel.1

Zone (VR): Untrust (trust-vr)
Unnumbered: (select)
Interface: ethernet3 (trust-vr)

Dialup  177
 Concepts & Examples ScreenOS Reference Guide

2. Addresses
Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: Mail Server

IP Address/Domain Name:
IP/Netmask: (select), 1.2.2.5/32
Zone: DMZ

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: Phil

IP Address/Domain Name:
IP/Netmask: (select), 10.10.10.1/32
Zone: Untrust
3. Services
Policy > Policy Elements > Services > Custom > New: Enter the following,
then click OK:

Service Name: Ident

Service Timeout:
Use protocol default: (select)
Transport Protocol: TCP (select)
Source Port: Low 1, High 65535
Destination Port: Low 113, High 113

Policy > Policy Elements > Services > Group > New: Enter the following,
move the following services, then click OK:

Group Name: Remote_Mail

Group Members << Available Members:
Ident
MAIL
POP3
4. VPN
VPNs > AutoKey Advanced > Gateway > New: Enter the following, then click
OK:

Gateway Name: To_Phil

Security Level: Custom
Remote Gateway Type:
Dynamic IP Address: (select), Peer ID: [email protected]
Preshared Key
Preshared Key: h1p8A24nG5
Outgoing Interface: ethernet3

> Advanced: Enter the following advanced settings, then click Return to
return to the basic Gateway configuration page:

Security Level: Custom

Phase 1 Proposal (For Custom Security Level): pre-g2-3des-sha
Mode (Initiator): Aggressive

(or)

178  Dialup
 Chapter 5: Dialup Virtual Private Networks

Certificates
Outgoing Interface: ethernet3

> Advanced: Enter the following advanced settings, then click Return to
return to the basic Gateway configuration page:

Security Level: Custom

Phase 1 Proposal (For Custom Security Level): rsa-g2-3des-sha
Mode (Initiator): Aggressive
Preferred Certificate (optional):
Peer CA: Verisign
Peer Type: X509-SIG

VPNs > AutoKey IKE > New: Enter the following, then click OK:

VPN Name: corp_Phil

Security Level: Compatible
Remote Gateway:
Predefined: (select), To_Phil

> Advanced: Enter the following advanced settings, then click Return to
return to the basic AutoKey IKE configuration page:

Bind to: Tunnel Interface: (select), tunnel.1

Proxy-ID: (select)
Local IP / Netmask: 1.2.2.5/32
Remote IP / Netmask: 10.10.10.1/32
Service: Any
5. Routes
Network > Routing > Routing Entries > trust-vr New: Enter the following,
then click OK:

Network Address/Netmask: 0.0.0.0/0

Gateway: (select)
Interface: ethernet3
Gateway IP Address: 1.1.1.250

Network > Routing > Routing Entries > trust-vr New: Enter the following,
then click OK:

Network Address/Netmask: 10.10.10.1/32

Gateway: (select)
Interface: tunnel.1
Gateway IP Address: 0.0.0.0

Network > Routing > Routing Entries > trust-vr New: Enter the following,
then click OK:

Network Address/Netmask: 10.10.10.1/32

Gateway: (select)
Interface: Null
Gateway IP Address: 0.0.0.0
Metric: 10

Dialup  179
 Concepts & Examples ScreenOS Reference Guide

6. Policies
Policies > (From: Untrust, To: DMZ) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), Phil
Destination Address:
Address Book Entry: (select), Mail Server
Service: Remote_Mail
Action: Permit
Position at Top: (select)

Policies > (From: DMZ, To: Untrust) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), Mail Server
Destination Address:
Address Book Entry: (select), Phil
Service: Remote_Mail
Action: Permit
Position at Top: (select)

CLI
1. Interfaces
set interface ethernet2 zone dmz
set interface ethernet2 ip 1.2.2.1/24
set interface ethernet3 zone untrust
set interface ethernet3 ip 1.1.1.1/24
set interface tunnel.1 zone untrust
set interface tunnel.1 ip unnumbered interface ethernet3
2. Addresses
set address dmz “Mail Server” 1.2.2.5/32
set address untrust phil 10.10.10.1/32
3. Services
set service ident protocol tcp src-port 1-65535 dst-port 113-113
set group service remote_mail
set group service remote_mail add ident
set group service remote_mail add mail
set group service remote_mail add pop3
4. VPN
Preshared Key
set ike gateway to_phil dynamic [email protected] aggressive outgoing-interface
ethernet3 preshare h1p8A24nG5 proposal pre-g2-3des-sha
set vpn corp_phil gateway to_phil sec-level compatible
set vpn corp_phil bind interface tunnel.1
set vpn corp_phil proxy-id local-ip 1.2.2.5/32 remote-ip 10.10.10.1/32 any

(or)

180  Dialup
 Chapter 5: Dialup Virtual Private Networks

Certificates
set ike gateway to_phil dynamic [email protected] aggressive outgoing-interface
ethernet3 proposal rsa-g2-3des-sha
set ike gateway to_phil cert peer-ca 1
set ike gateway to_phil cert peer-cert-type x509-sig
set vpn corp_phil gateway to_phil sec-level compatible
set vpn corp_phil bind interface tunnel.1
set vpn corp_phil proxy-id local-ip 1.2.2.5/32 remote-ip 10.10.10.1/32 any

NOTE: The number 1 is the CA ID number. To discover the CA’s ID number, use the
following command: get pki x509 list ca-cert.

5. Routes
set vrouter trust-vr route 0.0.0.0/0 interface ethernet3 gateway 1.1.1.250
set vrouter trust-vr route 10.10.10.1/32 interface tunnel.1
set vrouter trust-vr route 10.10.10.1/32 interface null metric 10
6. Policies
set policy top from dmz to untrust “Mail Server” phil remote_mail permit
set policy top from untrust to dmz phil “Mail Server” remote_mail permit
save

NetScreen-Remote
1. Click Options > Global Policy Settings, and select the Allow to Specify Internal
Network Address check box.

2. Options > Secure > Specified Connections.

3. Click the Add a new connection button, and type Mail next to the new
connection icon that appears.

4. Configure the connection options:

Connection Security: Secure

Remote Party Identity and Addressing:
ID Type: IP Address, 1.2.2.5
Protocol: All
Connect using Secure Gateway Tunnel: (select)
ID Type: IP Address, 1.1.1.1

5. Click the PLUS symbol, located to the left of the UNIX icon, to expand the
connection policy.

6. Click the Security Policy icon, then select Aggressive Mode and clear Enable
Perfect Forward Secrecy (PFS).

7. Click My Identity and do either of the following:

Click Pre-shared Key > Enter Key: Type h1p8A24nG5, then click OK.

ID Type: E-mail Address; [email protected]

Internal Network IP Address: 10.10.10.1

(or)

Dialup  181
 Concepts & Examples ScreenOS Reference Guide

Select the certificate that contains the email address “[email protected]” from
the Select Certificate drop-down list.

ID Type: E-mail Address; [email protected]

Internal Network IP Address: 10.10.10.1

8. Click the PLUS symbol, located to the left of the Security Policy icon, and then
the PLUS symbol to the left of Authentication (Phase 1) and Key Exchange
(Phase 2) to expand the policy further.

9. Click Authentication (Phase 1) > Proposal 1: Select the following

Authentication Method and Algorithms:

Authentication Method: Pre-Shared Key

(or)

Authentication Method: RSA Signatures

Encrypt Alg: Triple DES
Hash Alg: SHA-1
Key Group: Diffie-Hellman Group 2

10. Click Key Exchange (Phase 2) > Proposal 1: Select the following IPSec
Protocols:

Encapsulation Protocol (ESP): (select)

Encrypt Alg: Triple DES
Hash Alg: SHA-1
Encapsulation: Tunnel

11. Click Key Exchange (Phase 2) > Create New Proposal: Select the following
IPSec Protocols:

Encapsulation Protocol (ESP): (select)

Encrypt Alg: Triple DES
Hash Alg: MD5
Encapsulation: Tunnel

12. Click Key Exchange (Phase 2) > Create New Proposal: Select the following
IPSec Protocols:

Encapsulation Protocol (ESP): (select)

Encrypt Alg: DES
Hash Alg: SHA-1
Encapsulation: Tunnel

13. Click Key Exchange (Phase 2) > Create New Proposal: Select the following
IPSec Protocols:

Encapsulation Protocol (ESP): (select)

Encrypt Alg: DES
Hash Alg: MD5
Encapsulation: Tunnel

14. Click File > Save Changes.

182  Dialup
 Chapter 5: Dialup Virtual Private Networks

Policy-Based Dialup VPN, Dynamic Peer

In this example, a VPN tunnel securely connects the user behind the
NetScreen-Remote to the Untrust zone interface of the security device protecting
the mail server in the DMZ zone. The Untrust zone interface has a static IP address.
The NetScreen-Remote client has a dynamically assigned external IP address and a
static (virtual) internal IP address. The administrator of the security device must
know the client’s internal IP address so that he can add it to the Untrust address
book for use in policies to tunnel traffic from that source. After the
NetScreen-Remote client establishes the tunnel, traffic through the tunnel can
originate from either end.

Figure 45: Policy-Based Dialup VPN, Dynamic Peer

Remote User: Phil Outgoing Interface Corporate Office
NetScreen-Remote Untrust Zone DMZ Zone
ethernet3, 1.1.1.1/24 ethernet2, 1.2.2.1/24
Gateway 1.1.1.250
SMTP Mail Server
Request 1.2.2.5
Internet
IDENT
VPN Tunnel Request

Internal IP Address External IP Address Untrust Zone DMZ Zone

10.10.10.1 Dynamic

In this example, Phil wants to get his email from the mail server at the company
site. When he attempts to do so, he is authenticated by the mail server program,
which sends him an IDENT request through the tunnel.

NOTE: The mail server can send the IDENT request through the tunnel only if the security
administrator adds a custom service for it (TCP, port 113) and sets up an outgoing
policy allowing that traffic through the tunnel to 10.10.10.1.

The preshared key is h1p8A24nG5. This example assumes that both participants
have RSA certificates issued by Verisign and that the local certificate on the
NetScreen-Remote contains the U-FQDN [email protected]. (For more information
about obtaining and loading certificates, see “Certificates and CRLs” on page 34.)
For the Phase 1 and Phase 2 security levels, you specify one Phase 1
proposal—either pre-g2-3des-sha for the preshared key method or rsa-g2-3des-sha
for certificates—and select the predefined “Compatible” set of proposals for
Phase 2.

WebUI
1. Interfaces
Network > Interfaces > Edit (for ethernet2): Enter the following, then click
OK:

Zone Name: DMZ

Static IP: (select this option when present)
IP Address/Netmask: 1.2.2.1/24

Dialup  183
 Concepts & Examples ScreenOS Reference Guide

Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:

Zone Name: Untrust

Static IP: (select this option when present)
IP Address/Netmask: 1.1.1.1/24
2. Addresses
Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: Mail Server

IP Address/Domain Name:
IP/Netmask: (select), 1.2.2.5/32
Zone: DMZ

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: Phil

IP Address/Domain Name:
IP/Netmask: (select), 10.10.10.1/32
Zone: Untrust
3. Services
Policy > Policy Elements > Services > Custom > New: Enter the following,
then click OK:

Service Name: Ident

Service Timeout:
Use protocol default: (select)
Transport Protocol: TCP (select)
Source Port: Low 1, High 65535
Destination Port: Low 113, High 113

Policy > Policy Elements > Services > Group > New: Enter the following,
move the following services, then click OK:

Group Name: Remote_Mail

Group Members << Available Members:
Ident
MAIL
POP3
4. VPN
VPNs > AutoKey Advanced > Gateway > New: Enter the following, then click
OK:

Gateway Name: To_Phil

Security Level: Custom
Remote Gateway Type:
Dynamic IP Address: (select), Peer ID: [email protected]

184  Dialup
 Chapter 5: Dialup Virtual Private Networks

Preshared Key
Preshared Key: h1p8A24nG5
Outgoing Interface: ethernet3

> Advanced: Enter the following advanced settings, then click Return to
return to the basic Gateway configuration page:

Security Level: Custom

Phase 1 Proposal (For Custom Security Level): pre-g2-3des-sha
Mode (Initiator): Aggressive

(or)

Certificates
Outgoing Interface: ethernet3

> Advanced: Enter the following advanced settings, then click Return to
return to the basic Gateway configuration page:

Security Level: Custom

Phase 1 Proposal (For Custom Security Level): rsa-g2-3des-sha
Mode (Initiator): Aggressive
Preferred Certificate (optional):
Peer CA: Verisign
Peer Type: X509-SIG

VPNs > AutoKey IKE > New: Enter the following, then click OK:

VPN Name: corp_Phil

Security Level: Compatible
Remote Gateway:
Predefined: (select), To_Phil
5. Route
Network > Routing > Routing Entries > trust-vr New: Enter the following,
then click OK:

Network Address/Netmask: 0.0.0.0/0

Gateway: (select)
Interface: ethernet3
Gateway IP Address: 1.1.1.250
6. Policies
Policies > (From: Untrust, To: DMZ) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), Phil
Destination Address:
Address Book Entry: (select), Mail Server
Service: Remote_Mail
Action: Tunnel
VPN Tunnel: corp_Phil
Modify matching bidirectional VPN policy: (select)
Position at Top: (select)

Dialup  185
 Concepts & Examples ScreenOS Reference Guide

CLI
1. Interfaces
set interface ethernet2 zone dmz
set interface ethernet2 ip 1.2.2.1/24
set interface ethernet3 zone untrust
set interface ethernet3 ip 1.1.1.1/24
2. Addresses
set address dmz “mail server” 1.2.2.5/32
set address untrust phil 10.10.10.1/32
3. Services
set service ident protocol tcp src-port 1-65535 dst-port 113-113
set group service remote_mail
set group service remote_mail add ident
set group service remote_mail add mail
set group service remote_mail add pop3
4. VPN
Preshared Key
set ike gateway to_phil dynamic [email protected] aggressive outgoing-interface
ethernet3 preshare h1p8A24nG5 proposal pre-g2-3des-sha
set vpn corp_phil gateway to_phil sec-level compatible

(or)

Certificates
set ike gateway to_phil dynamic [email protected] aggressive outgoing-interface
ethernet3 proposal rsa-g2-3des-sha
set ike gateway to_phil cert peer-ca 1
set ike gateway to_phil cert peer-cert-type x509-sig
set vpn corp_phil gateway to_phil sec-level compatible

NOTE: The number 1 is the CA ID number. To discover the CA’s ID number, use the
following command: get pki x509 list ca-cert.

5. Route
set vrouter trust-vr route 0.0.0.0/0 interface ethernet3 gateway 1.1.1.250
6. Policies
set policy top from untrust to dmz phil “mail server” remote_mail tunnel vpn
corp_phil
set policy top from dmz to untrust “mail server” phil remote_mail tunnel vpn
corp_phil
save

NetScreen-Remote
1. Click Options > Global Policy Settings, and select Allow to Specify Internal
Network Address.

2. Options > Secure > Specified Connections.

3. Click Add a new connection, and type Mail next to the new connection icon
that appears.

186  Dialup
 Chapter 5: Dialup Virtual Private Networks

4. Configure the connection options:

Connection Security: Secure

Remote Party Identity and Addressing:
ID Type: IP Address, 1.2.2.5
Protocol: All
Connect using Secure Gateway Tunnel: (select)
ID Type: IP Address, 1.1.1.1

5. Click the PLUS symbol, located to the left of the UNIX icon, to expand the
connection policy.

6. Click the Security Policy icon, then select Aggressive Mode and clear Enable
Perfect Forward Secrecy (PFS).

7. Click My Identity and do either of the following:

Click Pre-shared Key > Enter Key: Type h1p8A24nG5, then click OK.

Internal Network IP Address: 10.10.10.1

ID Type: E-mail Address; [email protected]

(or)

Select the certificate that contains the email address “[email protected]”

from the Select Certificate drop-down list.

Internal Network IP Address: 10.10.10.1

ID Type: E-mail Address; [email protected]

8. Click the PLUS symbol, located to the left of the Security Policy icon, and then
the PLUS symbol to the left of Authentication (Phase 1) and Key Exchange
(Phase 2) to expand the policy further.

9. Click Authentication (Phase 1) > Proposal 1: Select the following

Authentication Method and Algorithms:

Authentication Method: Pre-Shared Key

(or)

Authentication Method: RSA Signatures

Encrypt Alg: Triple DES
Hash Alg: SHA-1
Key Group: Diffie-Hellman Group 2

10. Click Key Exchange (Phase 2) > Proposal 1: Select the following IPSec
Protocols:

Encapsulation Protocol (ESP): (select)

Encrypt Alg: Triple DES
Hash Alg: SHA-1
Encapsulation: Tunnel

Dialup  187
 Concepts & Examples ScreenOS Reference Guide

11. Click Key Exchange (Phase 2) > Create New Proposal: Select the following
IPSec Protocols:

Encapsulation Protocol (ESP): (select)

Encrypt Alg: Triple DES
Hash Alg: MD5
Encapsulation: Tunnel

12. Click Key Exchange (Phase 2) > Create New Proposal: Select the following
IPSec Protocols:

Encapsulation Protocol (ESP): (select)

Encrypt Alg: DES
Hash Alg: SHA-1
Encapsulation: Tunnel

13. Click Key Exchange (Phase 2) > Create New Proposal: Select the following
IPSec Protocols:

Encapsulation Protocol (ESP): (select)

Encrypt Alg: DES
Hash Alg: MD5
Encapsulation: Tunnel

14. Click File > Save Changes.

Bidirectional Policies for Dialup VPN Users

You can create bidirectional policies for dialup VPNs. This configuration provides
similar functionality as a dynamic peer VPN configuration. However, with a
dynamic peer VPN configuration, the security device admin must know the internal
IP address space of the dialup user, so that the admin can use it as the destination
address when configuring an outgoing policy (see “Policy-Based Dialup VPN,
Dynamic Peer” on page 183). With a dialup VPN user configuration, the admin at
the LAN site does not need to know the internal address space of the dialup user.
The security device protecting the LAN uses the predefined address “Dial-Up VPN”
as the source address in the incoming policy and the destination in the outgoing
policy.

The ability to create bidirectional policies for a dialup VPN tunnel allows traffic to
originate from the LAN end of the VPN connection after the connection has been
established. (The remote end must first initiate the tunnel creation.) Note that
unlike a dialup dynamic peer VPN tunnel, this feature requires that the services on
the incoming and outgoing policies be identical.

NOTE: ScreenOS does not support service groups and address groups in bidirectional
policies that reference a dialup VPN configuration.

The internal address space of two or more concurrently connected dialup VPN
users might overlap. For example, dialup users A and B might both have an internal
IP address space of 10.2.2.0/24. If that happens, the security device sends all
outbound VPN traffic to both user A and user B through the VPN referenced in the
first policy it finds in the policy list. For example, if the outbound policy referencing
the VPN to user A appears first in the policy list, then the security device sends all
outbound VPN traffic intended for users A and B to user A.

188  Dialup
 Chapter 5: Dialup Virtual Private Networks

Similarly, the internal address of a dialup user might happen to overlap an address
in any other policy—whether or not that other policy references a VPN tunnel. If
that occurs, the security device applies the first policy that matches the basic traffic
attributes of source address, destination address, source port number, destination
port number, service. To avoid a bidirectional dialup VPN policy with a dynamically
derived address superseding another policy with a static address, Juniper Networks
recommends positioning the bidirectional dialup VPN policy lower in the policy list.

In this example, you configure bidirectional policies for a dialup AutoKey IKE VPN
tunnel named VPN_dial for IKE user dialup-j with IKE ID [email protected]. For Phase 1
negotiations, you use the proposal pre-g2-3des-sha, with the preshared key
Jf11d7uU. You select the predefined “Compatible” set of proposals for Phase 2
negotiations.

The IKE user initiates a VPN connection to the security device from the Untrust
zone to reach corporate servers in the Trust zone. After the IKE user establishes the
VPN connection, traffic can initiate from either end of the tunnel.

The Trust zone interface is ethernet1, has IP address 10.1.1.1/24, and is in NAT
mode. The Untrust zone interface is ethernet3 and has IP address 1.1.1.1/24. The
default route points to the external router at 1.1.1.250.

WebUI
1. Interfaces
Network > Interfaces > Edit (for ethernet1): Enter the following, then click
Apply:

Zone Name: Trust

Static IP: (select this option when present)
IP Address/Netmask: 10.1.1.1/24

Select the following, then click OK:

Interface Mode: NAT

Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:

Zone Name: Untrust

Static IP: (select this option when present)
IP Address/Netmask: 1.1.1.1/24
2. Objects
Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: trust_net

IP Address/Domain Name:
IP/Netmask: (select), 10.1.1.0/24
Zone: Trust

Dialup  189
 Concepts & Examples ScreenOS Reference Guide

Policy > Policy Elements > Users > Local > New: Enter the following, then
click OK:

User Name: dialup-j

Status: Enable
IKE User: (select)
Simple Identity: (select); [email protected]
3. VPN
VPNs > AutoKey Advanced > Gateway > New: Enter the following, then click
OK:

Gateway Name: dialup1

Security Level: Custom
Remote Gateway Type:
Dialup User: (select); dialup-j
Preshared Key: Jf11d7uU

> Advanced: Enter the following advanced settings, then click Return to
return to the basic Gateway configuration page:

Security Level: Custom

Phase 1 Proposal (For Custom Security Level): pre-g2-3des-sha
Mode (Initiator): Aggressive

VPNs > AutoKey IKE > New: Enter the following, then click OK:

VPN Name: VPN_dial

Security Level: Compatible
Remote Gateway:
Create a Simple Gateway: (select)
Gateway Name: dialup1
Type:
Dialup User: (select); dialup-j
Preshared Key: Jf11d7uU
Security Level: Compatible
Outgoing Interface: ethernet3
4. Route
Network > Routing > Routing Entries > trust-vr New: Enter the following,
then click OK:

Network Address/Netmask: 0.0.0.0/0

Gateway: (select)
Interface: ethernet1
Gateway IP Address: 1.1.1.250
5. Policies
Policies > (From: Untrust, To: Trust) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), Dial-Up VPN
Destination Address:
Address Book Entry: (select), trust_net
Service: ANY
Action: Tunnel
VPN Tunnel: VPN_dial
Modify matching bidirectional VPN policy: (select)

190  Dialup
 Chapter 5: Dialup Virtual Private Networks

CLI
1. Interfaces
set interface ethernet1 zone trust
set interface ethernet1 ip 10.1.1.1/24
set interface ethernet1 nat
set interface ethernet3 zone untrust
set interface ethernet3 ip 1.1.1.1/24
2. Objects
set address trust trust_net 10.1.1.0/24
set user dialup-j ike-id u-fqdn [email protected]
3. VPN
set ike gateway dialup1 dialup dialup-j aggressive outgoing-interface ethernet3
preshare Jf11d7uU proposal pre-g2-3des-sha
set vpn VPN_dial gateway dialup1 sec-level compatible
4. Route
set vrouter trust-vr route 0.0.0.0/0 interface ethernet3 gateway 1.1.1.250
5. Policies
set policy from untrust to trust “Dial-Up VPN” trust_net any tunnel vpn VPN_dial
set policy from trust to untrust trust_net “Dial-Up VPN” any tunnel vpn VPN_dial
save

NetScreen-Remote Security Policy Editor

1. Click Options > Secure > Specified Connections.

2. Click Add a new connection, and type Corp next to the new connection icon
that appears.

3. Configure the connection options:

Connection Security: Secure

Remote Party Identity and Addressing
ID Type: IP Subnet
Subnet: 10.1.1.0
Mask: 255.255.255.0
Protocol: All
Connect using Secure Gateway Tunnel: (select)
ID Type: IP Address, 1.1.1.1

4. Click the PLUS symbol, located to the left of the UNIX icon, to expand the
connection policy.

5. Click My Identity: Do either of the following:

Click Pre-shared Key > Enter Key: Type Jf11d7uU, then click OK.

ID Type: (select E-mail Address), and type [email protected].

6. Click the Security Policy icon, then select Aggressive Mode and clear Enable
Perfect Forward Secrecy (PFS).

Dialup  191
 Concepts & Examples ScreenOS Reference Guide

7. Click the PLUS symbol, located to the left of the Security Policy icon, and then
the PLUS symbol to the left of Authentication (Phase 1) and Key Exchange
(Phase 2) to expand the policy further.

8. Click Authentication (Phase 1) > Proposal 1: Select the following

Authentication Method and Algorithms:

Authentication Method: Pre-Shared Key

(or)

Authentication Method: RSA Signatures

Encrypt Alg: Triple DES
Hash Alg: SHA-1
Key Group: Diffie-Hellman Group 2

9. Click Key Exchange (Phase 2) > Proposal 1: Select the following IPSec
Protocols:

Encapsulation Protocol (ESP): (select)

Encrypt Alg: Triple DES
Hash Alg: SHA-1
Encapsulation: Tunnel

10. Click Key Exchange (Phase 2) > Create New Proposal: Select the following
IPSec Protocols:

Encapsulation Protocol (ESP): (select)

Encrypt Alg: Triple DES
Hash Alg: MD5
Encapsulation: Tunnel

11. Click Key Exchange (Phase 2) > Create New Proposal: Select the following
IPSec Protocols:

Encapsulation Protocol (ESP): (select)

Encrypt Alg: DES
Hash Alg: SHA-1
Encapsulation: Tunnel

12. Click Key Exchange (Phase 2) > Create New Proposal: Select the following
IPSec Protocols:

Encapsulation Protocol (ESP): (select)

Encrypt Alg: DES
Hash Alg: MD5
Encapsulation: Tunnel

13. Click File > Save Changes.

192  Dialup
 Chapter 5: Dialup Virtual Private Networks

Group IKE ID
Some organizations have many dialup VPN users. For example, a sales department
might have hundreds of users, many of whom require secure dialup communication
when off site. With so many users, it is impractical to create a separate user
definition, dialup VPN configuration, and policy for each one.

To avoid this difficulty, the Group IKE ID method makes one user definition
available for multiple users. The group IKE ID user definition applies to all users
having certificates with specified values in the distinguished name (dn) or to all
users whose full IKE ID and preshared key on their VPN client match a partial IKE
ID and preshared key on the security device.

NOTE: When a dialup IKE user connects to the security device, the security device first
extracts and uses the full IKE ID to search its peer gateway records in case the user
does not belong to a group IKE ID user group. If the full IKE ID search produces no
matching entry, the security device then checks for a partial IKE ID match
between the incoming embedded IKE ID and a configured group IKE ID user.

You add a single group IKE ID user to an IKE dialup VPN user group and specify the
maximum number of concurrent connections that the group supports. The
maximum number of concurrent sessions cannot exceed the maximum number of
allowed Phase 1 SAs or the maximum number of VPN tunnels allowed on the
platform.

Group IKE ID with Certificates

Group IKE ID with certificates is a technique for performing IKE authentication for a
group of dialup IKE users without configuring a separate user profile for each one.
Instead, the security device uses a single group IKE ID user profile that contains a
partial IKE ID. A dialup IKE user can successfully build a VPN tunnel to a security
device if the VPN configuration on his VPN client specifies a certificate that contains
distinguished name elements that match those configured as the partial IKE ID
definition in the group IKE ID user profile on the security device.

Group IKE ID  193

 Concepts & Examples ScreenOS Reference Guide

Figure 46: Group IKE ID with Certificates

Dialup User Group

Full IKE ID
Dialup IKE Users (distinguished name)

Certificate
DN:
cn=alice
ou=eng Group IKE ID User
---------- ASN1-DN IKE ID Type
---------- Partial IKE ID: ou=eng

Certificate
DN:
cn=bob To authenticate the user, the device compares a
ou=eng specific element of the distinguished name (dn)
---------- associated with the dialup user group with the
---------- corresponding element in the certificate and the
dn used for the IKE ID payload accompanying
Certificate the initial Phase 1 packet.
DN:
cn=carol
ou=sales
----------
---------- Note: Because the dn in Carol’s certificate
does not include ou=eng, the device rejects
the connection request.

You can set up group IKE ID with certificates as follows:

On the Security Device:

1. Create a new group IKE ID user with a partial IKE identity (such as
ou=sales,o=netscreen), and specify how many dialup users can use the group
IKE ID profile to log on.

2. Assign the new group IKE ID user to a dialup user group, and name the group.

NOTE: You can put only one group IKE ID user in an IKE user group.

3. In the dialup AutoKey IKE VPN configuration, specify the name of the dialup
user group, that the Phase 1 negotiations be in Aggressive mode and that
certificates (RSA or DSA, depending on the type of certificate loaded on the
dialup VPN clients) be used for authentication.

4. Create a policy permitting inbound traffic through the specified dialup VPN.

On the VPN Client:

1. Obtain and load a certificate whose distinguished name contains the same
information as defined in the partial IKE ID on the security device.

2. Configure a VPN tunnel to the security device using Aggressive mode for
Phase 1 negotiations, specify the certificate that you have previously loaded,
and select Distinguished Name for the local IKE ID type.

Thereafter, each individual dialup IKE user with a certificate with distinguished
name elements that match the partial IKE ID defined in the group IKE ID user
profile can successfully build a VPN tunnel to the security device. For example, if the
group IKE ID user has IKE ID OU=sales,O=netscreen, the security device accepts

194  Group IKE ID

 Chapter 5: Dialup Virtual Private Networks

Phase 1 negotiations from any user with a certificate containing those elements in
its distinguished name. The maximum number of such dialup IKE users that can
connect to the security device depends upon the maximum number of concurrent
sessions that you specify in the group IKE ID user profile.

Wildcard and Container ASN1-DN IKE ID Types

When you define the IKE ID for a group IKE user, you must use the Abstract Syntax
Notation, version 1, distinguished name (ASN1-DN) as the IKE ID type of identity
configuration. This notation is a string of values, which is frequently although not
always ordered from general to specific. See Figure 47 for an example.

Figure 47: ASN1 Distinguished Name

ASN1-DN: C=us,ST=ca,L=sunnyvale,O=juniper,OU=sales,CN=jozef

C=us Legend:
General
C = Country
ST=ca
ST = State
L=sunnyvale L = Locality
O = Organization
O=juniper OU = Organizational Unit
CN = Common Name
OU=sales

CN=jozef

Specific

When configuring the group IKE ID user, you must specify the peer’s ASN1-DN ID
as one of two types:

 Wildcard: ScreenOS authenticates a dialup IKE user’s ID if the values in the

dialup IKE user’s ASN1-DN identity fields match those in the group IKE user’s
ASN1-DN identity fields. The wildcard ID type supports only one value per
identity field (for example, “ou=eng” or “ou=sw” but not “ou=eng,ou=sw”).
The ordering of the identity fields in the two ASN1-DN strings is
inconsequential.

 Container: ScreenOS authenticates a dialup IKE user’s ID if the values in the

dialup IKE user’s ASN1-DN identity fields exactly match the values in the group
IKE user’s ASN1-DN identity fields. The container ID type supports multiple
entries for each identity field (for example, “ou=eng,ou=sw,ou=screenos”).
The ordering of the values in the identity fields of the two ASN1-DN strings
must be identical.

When configuring an ASN1-DN ID for a remote IKE user, specify the type as either
“wildcard” or “container” and define the ASN1-DN ID that you expect to receive in
the peer’s certificate (for example, “c=us,st=ca,cn=kgreen”). When configuring
an ASN1-DN ID for a local IKE ID, use the following keyword: [DistinguishedName].
Include the brackets and spell it exactly as shown.

Group IKE ID  195

 Concepts & Examples ScreenOS Reference Guide

Wildcard ASN1-DN IKE ID

A wildcard ASN1-DN requires values in the remote peer’s distinguished name IKE
ID to match values in the group IKE user’s partial ASN1-DN IKE ID. The sequencing
of these values in the ASN1-DN string is inconsequential. For example, if the dialup
IKE user’s ID and the group IKE user’s ID are as follows:

 Dialup IKE user’s full ASN1-DN IKE ID:

CN=kristine,OU=finance,O=juniper,ST=ca,C=us

 Group IKE user’s partial ASN1-DN IKE ID: C=us,O=juniper

then a wildcard ASN1-DN IKE ID successfully matches the two IKE IDs, even though
the order of values in the two IDs is different.

Figure 48: Successful Wildcard ASN1-DN Authentication

Dialup IKE User’s Group IKE User’s Wildcard
ASN1-DN IKE ID ASN1-DN IKE ID
The dialup IKE user’s ASN1-DN contains the
values specified in the group IKE user’s ASN1-DN. E= E=
The order of values does not matter.

CN=kristine C=us
Authentication
Success
OU=finance ST=

O=juniper L=

L= O=juniper

ST=ca OU=

C=us CN=

Container ASN1-DN IKE ID

A container ASN1-DN ID allows the group IKE user’s ID to have multiple entries in
each identity field. ScreenOS authenticates a dialup IKE user if the dialup user’s ID
contains values that exactly match the values in the group IKE user’s ID. Unlike the
wildcard type, the order of the ASN1-DN fields must be identical in both the dialup
IKE user’s and group IKE user’s IDs and the order of multiple values in those fields
must be identical.

196  Group IKE ID

 Chapter 5: Dialup Virtual Private Networks

Figure 49: Authentication Success and Failure Using Container ASN1-DN IDs
Dialup IKE User’s Group IKE User’s container
ASN1-DN IKE ID ASN1-DN IKE ID

E= E=
The first dialup IKE
user’s ASN1-DN
contains exact matches
of the group IKE user’s C=us C=us
ASN1-DN. The order of
the multiple entries in Authentication
the OU ID field is also ST=ca ST=
identical. Success

L= sf L=

O=juniper O=juniper

OU=mkt,OU=dom,OU=west OU=mkt,OU=dom,OU=west

CN=rick CN=

Dialup IKE User’s Group IKE User’s container

ASN1-DN IKE ID ASN1-DN IKE ID

E= E=

The second dialup IKE

user’s ASN1-DN C=us C=us
contains exact matches
of the group IKE user’s Authentication
ASN1-DN. However, ST=ca ST=
the order of the multiple Failure
entries in the OU ID
field is not identical. L= la L=

O=juniper O=juniper

OU=mkt,OU=west,OU=dom OU=mkt,OU=dom,OU=west

CN=tony CN=

Creating a Group IKE ID (Certificates)

In this example, you create a new group IKE ID user definition named User1. You
configure it to accept up to 10 Phase 1 negotiations concurrently from VPN clients
with RSA certificates containing O=netscreen and OU=marketing. The certificate
authority (CA) is Verisign. You name the dialup IKE user group office_1.

Group IKE ID  197

 Concepts & Examples ScreenOS Reference Guide

Figure 50: Group IKE ID

Outgoing Interface Trust Zone
Untrust Zone ethernet1, 10.1.1.1/24
ethernet3, 1.1.1.1/24 NAT Mode

Untrust Zone Trust Zone

Dialup User with
IKE ID: Internet LAN web1
o=juniper VPN Tunnel 10.1.1.5
ou=marketing Group IKE ID User Profile
User Name: User1
User Group: office_1
gateway 1.1.1.250 Distinguished Name:
o=juniper
ou=marketing

The dialup IKE users send a distinguished name as their IKE ID. The distinguished
name (dn) in a certificate for a dialup IKE user in this group might appear as the
following concatenated string:

C=us,ST=ca,L=sunnyvale,O=netscreen,OU=marketing,CN=carrie
nowocin,CN=a2010002,CN=ns500,
CN=4085557800,CN=rsa-key,CN=10.10.5.44

Because the values O=netscreen and OU=marketing appear in the peer’s certificate
and the user uses the distinguished name as its IKE ID type, the security device
authenticates the user.

For the Phase 1 and Phase 2 security levels, you specify one Phase 1 proposal —
rsa-g2-3des-sha for certificates—and select the predefined “Compatible” set of
proposals for Phase 2.

You configure a dialup VPN and a policy permitting HTTP traffic through the VPN
tunnel to reach the webserver Web1. The configuration of the remote VPN client
(using NetScreen-Remote) is also included.

WebUI
1. Interfaces
Network > Interfaces > Edit (for ethernet1): Enter the following, then click
OK:

Zone Name: Trust

Static IP: (select this option when present)
IP Address/Netmask: 10.1.1.1/24
Select the following, then click OK:
Interface Mode: NAT

Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:

Zone Name: Untrust

Static IP: (select this option when present)
IP Address/Netmask: 1.1.1.1/24

198  Group IKE ID

 Chapter 5: Dialup Virtual Private Networks

2. Address
Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: web1

IP Address/Domain Name:
IP/Netmask: (select), 10.1.1.5/32
Zone: Trust
3. Users
Policy > Policy Elements > Users > Local > New: Enter the following, then
click OK:

User Name: User1

Status Enable: (select)
IKE User: (select)
Number of Multiple Logins with same ID: 10
Use Distinguished Name For ID: (select)
OU: marketing
Organization: juniper

Objects > User Groups > Local > New: Type office_1 in the Group Name field,
do the following, then click OK:

Select User1 and use the << button to move her from the Available Members
column to the Group Members column.
4. VPN
VPNs > AutoKey Advanced > Gateway > New: Enter the following, then click
OK:

Gateway Name: Corp_GW

Security Level: Custom
Remote Gateway Type: Dialup User Group: (select), Group: office_1
Outgoing Interface: ethernet3

> Advanced: Enter the following advanced settings, then click Return to
return to the basic Gateway configuration page:

Security Level: Custom

Phase 1 Proposal (For Custom Security Level): rsa-g2-3des-sha
Mode (Initiator): Aggressive
Preferred Certificate (optional):
Peer CA: Verisign
Peer Type: X509-SIG

VPNs > AutoKey IKE > New: Enter the following, then click OK:

VPN Name: Corp_VPN

Security Level: Compatible
Remote Gateway: Predefined: (select), Corp_GW

Group IKE ID  199

 Concepts & Examples ScreenOS Reference Guide

5. Route
Network > Routing > Routing Entries > trust-vr New: Enter the following,
then click OK:

Network Address/Netmask: 0.0.0.0/0

Gateway: (select)
Interface: ethernet3
Gateway IP Address: 1.1.1.250
6. Policy
Policies > (From: Untrust, To: Trust) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), Dial-Up VPN
Destination Address:
Address Book Entry: (select), web1
Service: HTTP
Action: Tunnel
Tunnel VPN: Corp_VPN
Modify matching bidirectional VPN policy: (clear)
Position at Top: (select)

CLI
1. Interfaces
set interface ethernet1 zone trust
set interface ethernet1 ip 10.1.1.1/24
set interface ethernet1 nat
set interface ethernet3 zone untrust
set interface ethernet3 ip 1.1.1.1/24
2. Address
set address trust web1 10.1.1.5/32
3. Users
set user User1 ike-id asn1-dn wildcard o=juniper,ou=marketing share-limit 10
set user-group office_1 user User1
4. VPN
set ike gateway Corp_GW dialup office_1 aggressive outgoing-interface ethernet3
proposal rsa-g2-3des-sha
set ike gateway Corp_GW cert peer-ca 1
set ike gateway Corp_GW cert peer-cert-type x509-sig
set vpn Corp_VPN gateway Corp_GW sec-level compatible

NOTE: The number 1 is the CA ID number. To discover the CA’s ID number, use the
following command: get pki x509 list ca-cert.

5. Route
set vrouter trust-vr route 0.0.0.0/0 interface ethernet3 gateway 1.1.1.250
6. Policy
set policy top from untrust to trust “Dial-Up VPN” web1 http tunnel vpn Corp_VPN
save

200  Group IKE ID

 Chapter 5: Dialup Virtual Private Networks

NetScreen-Remote Security Policy Editor

1. Click Options > Secure > Specified Connections.

2. Click Add a new connection, and type web1 next to the new connection icon
that appears.

3. Configure the connection options:

Connection Security: Secure

Remote Party Identity and Addressing
ID Type: IP Address, 10.1.1.5
Protocol: Highlight All, type HTTP, press the Tab key, and type 80.
Connect using Secure Gateway Tunnel: (select)
ID Type: IP Address, 1.1.1.1

4. Click the PLUS symbol, located to the left of the web1 icon, to expand the
connection policy.

5. Click My Identity: Select the certificate that has o=netscreen,ou=marketing as

elements in its distinguished name from the Select Certificate drop-down list.

ID Type: Select Distinguished Name from the drop-down list.

NOTE: This example assumes that you have already loaded a suitable certificate on the
NetScreen-Remote client. For information about loading certificates on the
NetScreen-Remote, refer to the NetScreen-Remote documentation.

6. Click the Security Policy icon, then select Aggressive Mode and clear Enable
Perfect Forward Secrecy (PFS).

7. Click the PLUS symbol, located to the left of the Security Policy icon, and then
the PLUS symbol to the left of Authentication (Phase 1) and Key Exchange
(Phase 2) to expand the policy further.

8. Click Authentication (Phase 1) > Proposal 1: Select the following Encryption

and Data Integrity Algorithms:

Authentication Method: RSA Signatures

Encrypt Alg: Triple DES
Hash Alg: SHA-1
Key Group: Diffie-Hellman Group 2

9. Click Key Exchange (Phase 2) > Proposal 1: Select the following IPSec
Protocols:

Encapsulation Protocol (ESP): (select)

Encrypt Alg: Triple DES
Hash Alg: SHA-1
Encapsulation: Tunnel

Group IKE ID  201

 Concepts & Examples ScreenOS Reference Guide

10. Click Key Exchange (Phase 2) > Create New Proposal: Select the following
IPSec Protocols:

Encapsulation Protocol (ESP): (select)

Encrypt Alg: Triple DES
Hash Alg: MD5
Encapsulation: Tunnel

11. Click Key Exchange (Phase 2) > Create New Proposal: Select the following
IPSec Protocols:

Encapsulation Protocol (ESP): (select)

Encrypt Alg: DES
Hash Alg: SHA-1
Encapsulation: Tunnel

12. Click Key Exchange (Phase 2) > Create New Proposal: Select the following
IPSec Protocols:

Encapsulation Protocol (ESP): (select)

Encrypt Alg: DES
Hash Alg: MD5
Encapsulation: Tunnel

13. Click File > Save Changes.

Setting a Group IKE ID with Preshared Keys

Group IKE ID with preshared keys is a technique for performing IKE authentication
for a group of dialup IKE users without configuring a separate user profile for each
one. Instead, the security device uses a single group IKE ID user profile, which
contains a partial IKE ID. A dialup IKE user can successfully build a VPN tunnel to a
security device if the VPN configuration on his VPN client has the correct preshared
key and if the rightmost part of the user’s full IKE ID matches the group IKE ID user
profile’s partial IKE ID.

Figure 51: Group IKE ID with Preshared Keys

Full IKE ID
Dialup IKE Users +
Preshared Key Dialup User Group
alice.eng.jnpr.net
+
011fg3322eda837c

bob.eng.jnpr.net Group IKE ID User

+ Partial IKE ID: eng.jnpr.net
bba7e22561c5da82 Preshared Key Seed Value: N11wWd2

The security device generates a preshared key

on the fly when an IKE user sends his full IKE ID.

carol.jnpr.net (The preshared key for each IKE user =

+ preshared key seed value x full IKE ID.)
834a2bbd32adc4e9
Note: Because the IKE ID for Carol is not The security device compares its generated key
carol.eng.jnpr.net, the security device with the preshared key accompanying the initial
rejects the connection request. Phase 1 packet to authenticate the user.

202  Group IKE ID

 Chapter 5: Dialup Virtual Private Networks

The IKE ID type that you can use for the Group IKE ID with Preshared Key feature
can be either an email address or a fully qualified domain name (FQDN).

You can set up group IKE ID with preshared keys as follows:

On the Security Device:

1. Create a new group IKE ID user with a partial IKE identity (such as juniper.net),
and specify the number of dialup users that can use the group IKE ID profile to
log on.

2. Assign the new group IKE ID user to a dialup user group.

3. In the dialup AutoKey IKE VPN configuration, assign a name for the remote
gateway (such as road1), specify the dialup user group, and enter a preshared
key seed value.

4. Use the following CLI command to generate an individual dialup user’s

preshared key using the preshared key seed value and the full user IKE ID (such
as [email protected])

exec ike preshare-gen name_str usr_name_str

(for example) exec ike preshare-gen road1 [email protected]

5. Record the preshared key for use when configuring the remote VPN client.

On the VPN Client:

Configure a VPN tunnel to the security device using Aggressive mode for
Phase 1 negotiations, and enter the preshared key that you previously
generated on the security device.

Thereafter, the security device can successfully authenticate each individual user
whose full IKE ID contains a section that matches the partial group IKE ID user
profile. For example, if the group IKE ID user has IKE identity juniper.net, any user
with that domain name in his IKE ID can initiate Phase 1 IKE negotiations in
Aggressive mode with the security device. For example: [email protected],
[email protected], and [email protected]. How many such users can log on
depends upon a maximum number of concurrent sessions specified in the group
IKE ID user profile.

In this example, you create a new group IKE ID user named User2. You configure it
to accept up to 10 Phase 1 negotiations concurrently from VPN clients with
preshared keys containing an IKE ID ending with the string juniper.net. The seed
value for the preshared key is jk930k. You name the dialup IKE user group office_2.

Group IKE ID  203

 Concepts & Examples ScreenOS Reference Guide

Figure 52: Group IKE ID (Preshared Keys)

Outgoing Interface Trust Zone
Untrust Zone ethernet1, 10.1.1.1/24
ethernet3, 1.1.1.1/24 NAT Mode
Untrust Zone
Trust Zone
Dialup User with
Internet LAN web1
IKE ID:
[email protected] 10.1.1.5
VPN Tunnel
Group IKE ID User Profile
User Name: User2
gateway 1.1.1.250 User Group: office_2
Simple ID: juniper.net

For both the Phase 1 and Phase 2 negotiations, you select the security level
predefined as “Compatible.” All the security zones are in the trust-vr routing
domain.

WebUI
1. Interfaces
Network > Interfaces > Edit (for ethernet1): Enter the following, then click
OK:

Zone Name: Trust

Static IP: (select this option when present)
IP Address/Netmask: 10.1.1.1/24
Select the following, then click OK:
Interface Mode: NAT

Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:

Zone Name: Untrust

Static IP: (select this option when present)
IP Address/Netmask: 1.1.1.1/24
2. Address
Policy > Policy Elements > Addresses > List > New : Enter the following,
then click OK:

Address Name: web1

IP Address/Domain Name:
IP/Netmask: (select), 10.1.1.5/32
Zone: Trust
3. Users
Policy > Policy Elements > Users > Local > New: Enter the following, then
click OK:

User Name: User2

Status: Enable
IKE User: (select)
Number of Multiple Logins with same ID: 10
Simple Identity: (select)
IKE Identity: juniper.net

204  Group IKE ID

 Chapter 5: Dialup Virtual Private Networks

Policy > Policy Elements > User Groups > Local > New: Type office_2 in the
Group Name field, do the following, then click OK:

Select User2 and use the << button to move him from the Available Members
column to the Group Members column.
4. VPN

NOTE: The WebUI allows you to enter only a value for a preshared key, not a seed value
from which the security device derives a preshared key. To enter a preshared key
seed value when configuring an IKE gateway, you must use the CLI.

VPNs > AutoKey IKE > New: Enter the following, then click OK:

VPN Name: Corp_VPN

Security Level: Compatible
Remote Gateway: Predefined: (select), Corp_GW
5. Route
Network > Routing > Routing Entries > trust-vr New: Enter the following,
then click OK:

Network Address/Netmask: 0.0.0.0/0

Gateway: (select)
Interface: ethernet3
Gateway IP Address: 1.1.1.250
6. Policy
Policies > (From: Untrust, To: Trust) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), Dial-Up VPN
Destination Address:
Address Book Entry: (select), web1
Service: HTTP
Action: Tunnel
Tunnel VPN: Corp_VPN
Modify matching bidirectional VPN policy: (clear)
Position at Top: (select)

CLI
1. Interfaces
set interface ethernet1 zone trust
set interface ethernet1 ip 10.1.1.1/24
set interface ethernet1 nat
set interface ethernet3 zone untrust
set interface ethernet3 ip 1.1.1.1/24
2. Address
set address trust web1 10.1.1.5/32
3. Users
set user User2 ike-id u-fqdn juniper.net share-limit 10
set user-group office_2 user User2

Group IKE ID  205

 Concepts & Examples ScreenOS Reference Guide

4. VPN
set ike gateway Corp_GW dialup office_2 aggressive seed-preshare jk930k
sec-level compatible
set vpn Corp_VPN gateway Corp_GW sec-level compatible
5. Route
set vrouter trust-vr route 0.0.0.0/0 interface ethernet3 gateway 1.1.1.250
6. Policy
set policy top from untrust to trust “Dial-Up VPN” web1 http tunnel vpn Corp_VPN
save

Obtaining the Preshared Key

You can only obtain the preshared key by using the following CLI command:

exec ike preshare-gen name_str usr_name_str

The preshared key, based on the preshared key seed value jk930k (as specified
in the configuration for the remote gateway named Corp_GW), and the full
identity of individual user [email protected] is
11ccce1d396f8f29ffa93d11257f691af96916f2.

NetScreen-Remote Security Policy Editor

1. Click Options > Secure > Specified Connections.

2. Click Add a new connection, and type web1 next to the new connection icon
that appears.

3. Configure the connection options:

Connection Security: Secure

Remote Party Identity and Addressing
ID Type: IP Address, 10.1.1.5
Protocol: Highlight All, type HTTP, press the Tab key, and type 80.
Connect using Secure Gateway Tunnel: (select)
ID Type: IP Address, 1.1.1.1

4. Click the PLUS symbol, located to the left of the web1 icon, to expand the
connection policy.

5. Click the Security Policy icon, then select Aggressive Mode and clear Enable
Perfect Forward Secrecy (PFS).

6. Click My Identity: Click Pre-shared Key > Enter Key: Type

11ccce1d396f8f29ffa93d11257f691af96916f2, then click OK.

ID Type: (select E-mail Address), and type [email protected].

7. Click the PLUS symbol, located to the left of the Security Policy icon, then click
the PLUS symbol to the left of Authentication (Phase 1) and Key Exchange
(Phase 2) to expand the policy further.

206  Group IKE ID

 Chapter 5: Dialup Virtual Private Networks

8. Click Authentication (Phase 1) > Proposal 1: Select the following Encryption

and Data Integrity Algorithms:

Authentication Method: Pre-Shared Key

Encrypt Alg: Triple DES
Hash Alg: SHA-1
Key Group: Diffie-Hellman Group 2

9. Click Authentication (Phase 1) > Create New Proposal: Select the following
IPSec Protocols:

Authentication Method: Pre-Shared Key

Encrypt Alg: Triple DES
Hash Alg: MD5
Key Group: Diffie-Hellman Group 2

10. Click Authentication (Phase 1) > Create New Proposal: Select the following
IPSec Protocols:

Authentication Method: Pre-Shared Key

Encrypt Alg: DES
Hash Alg: SHA-1
Key Group: Diffie-Hellman Group 2

11. Click Authentication (Phase 1) > Create New Proposal: Select the following
IPSec Protocols:

Authentication Method: Pre-Shared Key

Encrypt Alg: DES
Hash Alg: MD5
Key Group: Diffie-Hellman Group 2

12. Click Key Exchange (Phase 2) > Proposal 1: Select the following IPSec
Protocols:

Encapsulation Protocol (ESP): (select)

Encrypt Alg: Triple DES
Hash Alg: SHA-1
Encapsulation: Tunnel

13. Click Key Exchange (Phase 2) > Create New Proposal: Select the following
IPSec Protocols:

Encapsulation Protocol (ESP): (select)

Encrypt Alg: Triple DES
Hash Alg: MD5
Encapsulation: Tunnel

14. Click Key Exchange (Phase 2) > Create New Proposal: Select the following
IPSec Protocols:

Encapsulation Protocol (ESP): (select)

Encrypt Alg: DES
Hash Alg: SHA-1
Encapsulation: Tunnel

Group IKE ID  207

 Concepts & Examples ScreenOS Reference Guide

15. Click Key Exchange (Phase 2) > Create New Proposal: Select the following
IPSec Protocols:

Encapsulation Protocol (ESP): (select)

Encrypt Alg: DES
Hash Alg: MD5
Encapsulation: Tunnel

16. Click File > Save Changes.

Shared IKE ID
The shared IKE ID feature facilitates the deployment of a large number of dialup
users. With this feature, the security device authenticates multiple dialup VPN users
using a single group IKE ID and preshared key. Thus, it provides IPSec protection for
large remote user groups through a common VPN configuration.

This feature is similar to the Group IKE ID with pre-shared keys feature, with the
following differences:

 With the group IKE ID feature, the IKE ID can be an email address or an FQDN
(fully qualified domain name). For this feature, the IKE ID must be an email
address.

 Instead of using the preshared key seed value and the full user IKE ID to
generate a preshared key for each user, you specify a single preshared key for
all users in the group.

 You must use XAuth to authenticate the individual users.

To set up a shared IKE ID and preshared key on the security device:

1. Create a new group IKE ID user, and specify how many dialup users can use the
group IKE ID to log on. For this feature, use an email address as the IKE ID.

2. Assign the new group IKE ID to a dialup user group.

3. In the dialup-to-LAN AutoKey IKE VPN configuration, create a shared IKE ID

gateway.

4. Define the XAuth users and enable XAuth on the remote IKE gateway.

On the VPN Client:

Configure a VPN tunnel to the security device using Aggressive mode for Phase 1
negotiations, and enter the preshared key that you previously defined on the
security device.Thereafter, the security device authenticates each remote user as
follows:

208  Shared IKE ID

 Chapter 5: Dialup Virtual Private Networks

During Phase 1 negotiations, the security device first authenticates the VPN client
by matching the IKE ID and preshared key that the client sends with the IKE ID and
preshared key on the security device. If there is a match, then the security device
uses XAuth to authenticate the individual user. It sends a login prompt to the user at
the remote site between Phase 1 and Phase 2 IKE negotiations. If the remote user
successfully logs on with the correct username and password, Phase 2 negotiations
begin.

In this example, you create a new group IKE ID user named Remote_Sales. It
accepts up to 250 Phase 1 negotiations concurrently from VPN clients with the
same preshared key (abcd1234). You name the dialup IKE user group R_S. In
addition, you configure two XAuth users, Joe and Mike.

For both the Phase 1 and Phase 2 negotiations, you select the security level
predefined as Compatible. All the security zones are in the trust-vr routing domain.

Figure 53: Shared IKE ID (Preshared Keys)

Dialup User with
IKE ID: [email protected]
XAuth password: 1234 Outgoing Interface ethernet1, 10.1.1.1/24
ethernet3, 1.1.1.1/24 NAT Mode
Untrust Zone
Trust Zone

VPN Tunnels LAN web1

10.1.1.5
Shared IKE ID User Profile
User Name: Remote_Sales
Dialup User with User Group: R_S
IKE ID: [email protected] Simple ID: [email protected]
XAuth password: 5678

WebUI
1. Interfaces
Network > Interfaces > Edit (for ethernet1): Enter the following, then click
Apply:

Zone Name: Trust

Static IP: (select this option when present)
IP Address/Netmask: 10.1.1.1/24
Select the following, then click OK:
Interface Mode: NAT

Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:

Zone Name: Untrust

Static IP: (select this option when present)
IP Address/Netmask: 1.1.1.1/24

Shared IKE ID  209

 Concepts & Examples ScreenOS Reference Guide

2. Address
Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: web1

IP Address/Domain Name:
IP/Netmask: (select), 10.1.1.5/32
Zone: Trust
3. Users
Policy > Policy Elements > Users > Local > New: Enter the following, then
click OK:

User Name: Remote_Sales

Status: Enable
IKE User: (select)
Number of Multiple Logins with same ID: 250
Simple Identity: (select)
IKE Identity: [email protected]

Policy > Policy Elements > User Groups > Local > New: Type R_S in the
Group Name field, do the following, then click OK:

Select Remote_sales and use the << button to move him from the Available
Members column to the Group Members column.

Policy > Policy Elements > Users > Local > New: Enter the following, then
click OK:

User Name: Joe

Status: Enable
XAuth User: (select)
Password: 1234
Confirm Password: 1234

Policy > Policy Elements > Users > Local > New: Enter the following, then
click OK:

User Name: Mike

Status: Enable
XAuth User: (select)
Password: 5678
Confirm Password: 5678
4. VPN
VPNs > AutoKey Advanced > Gateway > New: Enter the following, then click
OK:

Gateway Name: sales_gateway

Security Level: Compatible (select)
Remote Gateway Type: Dialup Group (select), R_S
Preshared Key: abcd1234
Outgoing Interface: ethernet3

210  Shared IKE ID

 Chapter 5: Dialup Virtual Private Networks

> Advanced: Enter the following, then click Return to return to the base
Gateway configuration page:

Enable XAuth: (select)

Local Authentication: (select)
Allow Any: (select)

VPNs > AutoKey IKE > New: Enter the following, then click OK:

VPN Name: Sales_VPN

Security Level: Compatible
Remote Gateway: Predefined: (select) sales_gateway

> Advanced: Enter the following advanced settings, then click Return to
return to the basic AutoKey IKE configuration page:

Bind to: Tunnel Zone, Untrust-Tun

5. Route
Network > Routing > Routing Entries > trust-vr New: Enter the following,
then click OK:

Network Address / Netmask: 0.0.0.0/0

Gateway: (select)
Interface: ethernet3
Gateway IP Address: 1.1.1.250
6. Policy
Policies > (From: Untrust, To: Trust) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), Dial-Up VPN
Destination Address:
Address Book Entry: (select), web1
Service: HTTP
Action: Tunnel
Tunnel VPN: Sales_VPN
Modify matching bidirectional VPN policy: (clear)
Position at Top: (select)

CLI
1. Interfaces
set interface ethernet1 zone trust
set interface ethernet1 ip 10.1.1.1/24
set interface ethernet1 nat
set interface ethernet3 zone untrust
set interface ethernet3 ip 1.1.1.1/24
2. Address
set address trust web1 10.1.1.5/32

Shared IKE ID  211

 Concepts & Examples ScreenOS Reference Guide

3. Users
set user Remote_Sales ike-id [email protected] share-limit 250
set user-group R_S user Remote_Sales
set user Joe password 1234
set user Joe type xauth
set user Mike password 5678
set user Mike type xauth
4. VPN
set ike gateway sales_gateway dialup R_S aggressive outgoing-interface ethernet3
preshare abcd1234 sec-level compatible
set ike gateway sales_gateway xauth
set vpn sales_vpn gateway sales_gateway sec-level compatible
set vpn sales_vpn bind zone untrust-tun
5. Route
set route 0.0.0.0/0 interface ethernet3 gateway 1.1.1.250
6. Policy
set policy top from untrust to trust “Dial-Up VPN” web1 http tunnel vpn sales_vpn
save

NetScreen-Remote Security Policy Editor

This example shows the configuration for the user named Joe.

1. Click Options > Secure > Specified Connections.

2. Click Add a new connection, and type web1 next to the new connection icon
that appears.

3. Configure the connection options:

Connection Security: Secure

Remote Party ID Type: IP Address
IP Address: 10.1.1.5
Connect using Secure Gateway Tunnel: (select)
ID Type: IP Address; 1.1.1.1

4. Click the PLUS symbol, located to the left of the web1 icon, to expand the
connection policy.

5. Click the Security Policy icon, then select Aggressive Mode and clear Enable
Perfect Forward Secrecy (PFS).

6. Click My Identity: Click Pre-shared Key > Enter Key: Type abcd1234, then
click OK.

ID Type: (select E-mail Address), and type [email protected].

7. Click the PLUS symbol, located to the left of the Security Policy icon, then click
the PLUS symbol to the left of Authentication (Phase 1) and Key Exchange
(Phase 2) to expand the policy further.

212  Shared IKE ID

 Chapter 5: Dialup Virtual Private Networks

8. Click Authentication (Phase 1) > Proposal 1: Select the following Encryption

and Data Integrity Algorithms:

Authentication Method: Pre-Shared Key; Extended Authentication

Encrypt Alg: Triple DES
Hash Alg: SHA-1
Key Group: Diffie-Hellman Group 2

9. Click Authentication (Phase 1) > Create New Proposal: Select the following
IPSec Protocols:

Authentication Method: Pre-Shared Key; Extended Authentication

Encrypt Alg: Triple DES
Hash Alg: MD5
Key Group: Diffie-Hellman Group 2

10. Click Authentication (Phase 1) > Create New Proposal: Select the following
IPSec Protocols:

Authentication Method: Pre-Shared Key; Extended Authentication

Encrypt Alg: DES
Hash Alg: SHA-1
Key Group: Diffie-Hellman Group 2

11. Click Authentication (Phase 1) > Create New Proposal: Select the following
IPSec Protocols:

Authentication Method: Pre-Shared Key; Extended Authentication

Encrypt Alg: DES
Hash Alg: MD5
Key Group: Diffie-Hellman Group 2

12. Click Key Exchange (Phase 2) > Proposal 1: Select the following IPSec
Protocols:

Encapsulation Protocol (ESP): (select)

Encrypt Alg: Triple DES
Hash Alg: SHA-1
Encapsulation: Tunnel

13. Click Key Exchange (Phase 2) > Create New Proposal: Select the following
IPSec Protocols:

Encapsulation Protocol (ESP): (select)

Encrypt Alg: Triple DES
Hash Alg: MD5
Encapsulation: Tunnel

14. Click Key Exchange (Phase 2) > Create New Proposal: Select the following
IPSec Protocols:

Encapsulation Protocol (ESP): (select)

Encrypt Alg: DES
Hash Alg: SHA-1
Encapsulation: Tunnel

Shared IKE ID  213

 Concepts & Examples ScreenOS Reference Guide

15. Click Key Exchange (Phase 2) > Create New Proposal: Select the following
IPSec Protocols:

Encapsulation Protocol (ESP): (select)

Encrypt Alg: DES
Hash Alg: MD5
Encapsulation: Tunnel

16. Click File > Save Changes.

214  Shared IKE ID

Chapter 6
Layer 2 Tunneling Protocol

This chapter provides an introduction to Layer 2 Tunneling Protocol (L2TP), its use
alone and with IPSec support, and some configuration examples for L2TP and
L2TP-over-IPSec. It contains the following sections:

 “Introduction to L2TP” on page 215

 “Packet Encapsulation and Decapsulation” on page 218

 “Encapsulation” on page 218

 “Decapsulation” on page 219

 “Setting L2TP Parameters” on page 221

 “L2TP and L2TP-over-IPSec” on page 223

 “Configuring L2TP” on page 223

 “Configuring L2TP-over-IPSec” on page 228

 “Bidirectional L2TP-over-IPSec” on page 235

Introduction to L2TP
Layer 2 Tunneling Protocol (L2TP) provides a way for a dialup user to make a virtual
Point-to-Point Protocol (PPP) connection to an L2TP network server (LNS), which
can be a security device. L2TP sends PPP frames through a tunnel between an L2TP
access concentrator (LAC) and the LNS.

Originally, L2TP was designed so that a LAC residing at an ISP site tunneled to an
LNS at either another ISP or corporate site. The L2TP tunnel did not extend
completely to the dialup user’s computer, but only to the LAC at the dialup user’s
local ISP. (This is sometimes referred to as a compulsory L2TP configuration.)

A NetScreen-Remote client on Windows 2000 or Windows NT, or a Windows 2000

client by itself, can act as a LAC. The L2TP tunnel can extend directly to the dialup
user’s computer, thus providing end-to-end tunneling. (This approach is sometimes
referred to as a voluntary L2TP configuration.)

Introduction to L2TP  215

 Concepts & Examples ScreenOS Reference Guide

Figure 54: L2TP Tunnel Between VPN Client (LAC) and Security Device (LNS)
NetScreen-Remote
or Windows 2000 Security device
(LAC) Internet (LNS)
ISP
Corporate
LAN

L2TP Tunnel
(forwarding PPP sessions
from LAC to LNS)

Because the PPP link extends from the dialup user across the Internet to the
security device (LNS), it is the security device, not the ISP, that assigns the client its
IP address, DNS and WINS servers addresses, and authenticates the user, either
from the local database or from an external auth server (RADIUS, SecurID, or
LDAP).

In fact, the client receives two IP addresses—one for its physical connection to the
ISP, and a logical one from the LNS. When the client contacts its ISP, perhaps using
PPP, the ISP makes IP and DNS assignments, and authenticates the client. This
allows users to connect to the Internet with a public IP address, which becomes the
outer IP address of the L2TP tunnel.

Figure 55: IP and DNS Assignments from ISP

First, the ISP assigns the ISP

client a public IP address
and DNS server addresses.

IP Address: 5.5.5.5
DNS: 6.6.6.6, 7.7.7.7

Then, when the L2TP tunnel forwards the encapsulated PPP frames to the security
device, the security device assigns the client an IP address, and DNS and WINS
settings. The IP address can be from the set of private addresses not used on the
Internet. This address becomes the inner IP address of the L2TP tunnel.

216  Introduction to L2TP

 Chapter 6: Layer 2 Tunneling Protocol

Figure 56: IP and DNS Assignments from LNS

Second, the security device—acting as an
LNS—assigns the client a private (logical) IP
address, and DNS and WINS server addresses.

Security device
Internet (LNS)
CorporateLAN
10.1.1.0/24

IP Address: 10.10.1.161
DNS: 10.1.1.10, 1.2.2.10 IP Address Pool
WINS: 10.1.1.48, 10.1.1.49 10.10.1.1 – 10.10.1.254

NOTE: The IP addresses assigned to the L2TP client must be in a different subnet from
the IP addresses in the corporate LAN.

The current version of ScreenOS provides the following L2TP support:

 L2TP tunnels originating from a host running Windows 2000

NOTE: By default, Windows 2000 performs L2TP-over-IPSec. To force it to use L2TP only,
you must navigate to the ProhibitIPSec key in the registry and change 0
(L2TP-over-IPSec) to 1 (L2TP only). (Before performing this, Juniper Networks
recommends that you back up your registry.) Click Start > Run: Type regedit.
Double-click HKEY_LOCAL_MACHINE > System > CurrentControlSet >
Services > RasMan > Parameters. Double-click ProhibitIPSec: Type 1 in the
Value data field, select Hexadecimal as the base value, then click OK. Reboot. (If
you do not find such an entry in the registry, see Microsoft WIndows
documentation for information about how to create one.)

Introduction to L2TP  217

 Concepts & Examples ScreenOS Reference Guide

 Combination of L2TP and IPSec in Transport mode (L2TP-over-IPSec)

 For NetScreen-Remote: L2TP-over-IPSec with Main mode negotiations

using certificates, and Aggressive mode using either a preshared key or
certificates

 For Windows 2000: L2TP-over-IPSec with Main mode negotiations using

certificates

 Outgoing dialup policy for L2TP and L2TP-over-IPSec tunnels (An outgoing
dialup policy can be paired with an incoming policy to provide a bidirectional
tunnel.)

 User authentication using either the Password Authentication Protocol (PAP)

and Challenge Handshake Authentication Protocol (CHAP) from the local
database or an external auth server (RADIUS, SecurID, or LDAP)

NOTE: The local database and RADIUS servers support both PAP and CHAP. SecurID and
LDAP servers support PAP only.

 The assignment of dialup users’ IP address, Domain Name System (DNS)

servers, and Windows Internet Naming Service (WINS) servers from either the
local database or a RADIUS server

 L2TP tunnels and L2TP-over-IPSec tunnels for the root system and virtual
systems

NOTE: To use L2TP, the security device must be operating at Layer 3, with security zone
interfaces in NAT or Route mode. When the security device is operating at Layer 2,
with security zone interfaces in Transparent mode, no L2TP-related material
appears in the WebUI, and L2TP-related CLI commands elicit error messages.

Packet Encapsulation and Decapsulation

L2TP employs encapsulation of packets as the means for transporting PPP frames
from the LAC to the LNS. Before looking at specific examples for setting up L2TP
and L2TP-over-IPSec, an overview of the encapsulation and decapsulation involved
in the L2TP process is presented.

Encapsulation
When a dialup user on an IP network sends data over an L2TP tunnel, the LAC
encapsulates the IP packet within a series of Layer 2 frames, Layer 3 packets, and
Layer 4 segments. Assuming that the dialup user connects to the local ISP over a
PPP link, the encapsulation proceeds as shown in Figure 57 on page 219.

218  Packet Encapsulation and Decapsulation

 Chapter 6: Layer 2 Tunneling Protocol

Figure 57: L2TP Packet Encapsulation

DATA

IP PAYLOAD

PPP PAYLOAD

L2TP PAYLOAD

UDP PAYLOAD

IP PAYLOAD

PPP PAYLOAD

1. The data is placed in an IP payload.

2. The IP packet is encapsulated in a PPP frame.

3. The PPP frame is encapsulated in an L2TP frame.

4. The L2TP frame is encapsulated in a UDP segment.

5. The UDP segment is encapsulated in an IP packet.

6. The IP packet is encapsulated in a PPP frame to make the physical connection

between the dialup user and the ISP.

Decapsulation
When the LAC initiates the PPP link to the ISP, the decapsulation and forwarding of
the nested contents proceed as shown in Figure 58 on page 220.

Packet Encapsulation and Decapsulation  219

 Concepts & Examples ScreenOS Reference Guide

Figure 58: L2TP Packet Decapsulation

ISP PPP PAYLOAD

IP PAYLOAD

UDP PAYLOAD

L2TP PAYLOAD

LNS
PPP PAYLOAD

IP PAYLOAD

DATA

1. The ISP completes the PPP link and assigns the user’s computer an IP address.

Inside the PPP payload is an IP packet.

2. The ISP removes the PPP header and forwards the IP packet to the LNS.

3. The LNS removes the IP header.

Inside the IP payload is a UDP segment specifying port 1701, the port number
reserved for L2TP.

4. The LNS removes the UDP header.

Inside the UDP payload is an L2TP frame.

5. The LNS processes the L2TP frame, using the tunnel ID and call ID in the L2TP
header to identify the specific L2TP tunnel. The LNS then removes the L2TP
header.

Inside the L2TP payload is a PPP frame.

6. The LNS processes the PPP frame, assigning the user’s computer a logical IP
address.

Inside the PPP payload is an IP packet.

7. The LNS routes the IP packet to its ultimate destination, where the IP header is
removed and the data in the IP packet is extracted.

220  Packet Encapsulation and Decapsulation

 Chapter 6: Layer 2 Tunneling Protocol

Setting L2TP Parameters

The LNS uses L2TP to provide the PPP settings for a dialup user, which typically
come from an ISP. These settings are as follows:

 IP address – The security device selects an address from a pool of IP addresses

and assigns it to the dialup user’s computer. The selection process operates
cyclically through the IP address pool; that is, in a pool from 10.10.1.1 to
10.10.1.3, the addresses are selected in the following cycle: 10.10.1.1 –
10.10.1.2 – 10.10.1.3 – 10.10.1.1 – 10.10.1.2 …

 DNS primary and secondary server IP addresses – The security device provides
these addresses to the dialup user’s computer.

 WINS primary and secondary server IP addresses – The security device also
provides these addresses to the dialup user’s computer.

The LNS also authenticates the user through a username and password. You can
enter the user in the local database or in an external auth server (RADIUS, SecurID,
or LDAP).

NOTE: The RADIUS or SecurID server that you use for authenticating L2TP users can be
the same server you use for network users, or it can be a different server.

In addition, you can specify one of the following schemes for the PPP
authentication:

 Challenge Handshake Authentication Protocol (CHAP), in which the security

device sends a challenge (encryption key) to the dialup user after he or she
makes a PPP link request, and the user encrypts his or her login name and
password with the key. The local database and RADIUS servers support CHAP.

 Password Authentication Protocol (PAP), which sends the dialup user’s

password in the clear along with the PPP link request. The local database and
RADIUS, SecurID, and LDAP servers support PAP.

 “ANY”, meaning that the security device negotiates CHAP, and then if that fails,
PAP.

You can apply to dialup users and dialup user groups the default L2TP parameters
that you configure on the L2TP Default Configuration page (VPNs > L2TP >
Default Settings) or with the set l2tp default command. You can also apply L2TP
parameters that you configure specifically for L2TP users on the User Configuration
page (Users > Users > Local > New) or with the set user name_str
remote-settings command. The user-specific L2TP settings supersede the default
L2TP settings.

As shown in Figure 59 on page 222, you define an IP address pool with addresses
ranging from 10.1.3.40 to 10.1.3.100. You specify DNS server IP addresses 1.1.1.2
(primary) and 1.1.1.3 (secondary). The security device performs PPP authentication
using CHAP.

Setting L2TP Parameters  221

 Concepts & Examples ScreenOS Reference Guide

NOTE: You specify the auth server on a per-L2TP tunnel basis.

Figure 59: IP Pool and L2TP Default Settings

RADIUS
10.1.1.245
Trust Zone Untrust Zone DNS 1
1.1.1.2
Note: The L2TP pool addresses Internet DNS 2
must be in a different subnet from 1.1.1.3
those in the Trust zone.

ethernet1, L2TP IP Pool ethernet3,

10.1.1.1/24 10.1.3.40 – 10.1.3.100 1.1.1.1/24

WebUI
1. IP Pool
Objects > IP Pools > New: Enter the following, then click OK:

IP Pool Name: Sutro

Start IP: 10.1.3.40
End IP: 10.1.3.100
2. Default L2TP Settings
VPNs > L2TP > Default Settings: Enter the following, then click Apply:

IP Pool Name: Sutro

PPP Authentication: CHAP
DNS Primary Server IP: 1.1.1.2
DNS Secondary Server IP: 1.1.1.3
WINS Primary Server IP: 0.0.0.0
WINS Secondary Server IP: 0.0.0.0

CLI
1. IP Pool
set ippool sutro 10.1.3.40 10.1.3.100
2. Default L2TP Settings
set l2tp default ippool sutro
set l2tp default ppp-auth chap
set l2tp default dns1 1.1.1.2
set l2tp default dns2 1.1.1.3
save

222  Setting L2TP Parameters

 Chapter 6: Layer 2 Tunneling Protocol

L2TP and L2TP-over-IPSec

Although the dialup user can be authenticated using CHAP or PAP, an L2TP tunnel is
not encrypted, and therefore is not a true VPN tunnel. The purpose of L2TP is
simply to permit the administrator of the local security device to assign IP
addresses to remote dialup users. These addresses can then be referenced in
policies.

To encrypt an L2TP tunnel, you need to apply an encryption scheme to the L2TP
tunnel. Because L2TP assumes that the network between the LAC and the LNS is IP,
you can employ IPSec to provide encryption. This combination is called
L2TP-over-IPSec. L2TP-over-IPSec requires setting up both an L2TP tunnel and an
IPSec tunnel with the same endpoints, and then linking them together in a policy.
L2TP-over-IPSec requires that the IPSec tunnel be in Transport mode so that the
tunnel endpoint addresses remain in the clear. (For information about Transport
and Tunnel mode, see “Modes” on page 4.)

You can create an L2TP tunnel between a security device and a host running
Windows 2000 if you change the Windows 2000 registry settings. (For instructions
on how to change the registry, see the note on page 217.)

You can create an L2TP-over-IPSec tunnel between a security device and either of
the following VPN clients:

 A host running NetScreen-Remote on a Windows 2000 or Windows NT

operating system

 A host running Windows 2000 (without NetScreen-Remote)

NOTE: To provide authentication when using WIndows 2000 without NetScreen-Remote,

you must use certificates.

Configuring L2TP
In this example, as illustrated in Figure 60 on page 224, you create a dialup user
group called “fs” (for “field-sales”) and configure an L2TP tunnel called
“sales_corp,” using ethernet3 (Untrust zone) as the outgoing interface for the L2TP
tunnel. The security device applies the following default L2TP tunnel settings to the
dialup user group:

 The L2TP users are authenticated through the local database.

 PPP authentication uses CHAP.

 The range of addresses in the IP pool (named “global”) is from 10.10.2.100 to

10.10.2.180.

 The DNS servers are 1.1.1.2 (primary) and 1.1.1.3 (secondary).

L2TP and L2TP-over-IPSec  223

 Concepts & Examples ScreenOS Reference Guide

NOTE: An L2TP-only configuration is not secure. It is recommended only for debugging

purposes.

The addresses in the L2TP IP pool must be in a different subnet than the
addresses in the corporate network.

Figure 60: Configuring L2TP

Auth/L2TP Dialup Users
Group: fs

Dialup IP Pool: global

Zone DNS1: 1.1.1.2 10.10.2.100 –
Adam 10.10.2.180 Corporate
DNS2: 1.1.1.3 Network

Trust Zone
Betty

Internet

Carol
L2TP Tunnel:
sales_corp Outgoing Interface ethernet1,
ethernet3, 1.1.1.1/24 10.1.1.1/24
NetScreen-
Remote Clients

The remote L2TP clients are on Windows 2000 operating systems. For information
about how to configure L2TP on the remote clients, refer to your Windows 2000
documentation. Only the configuration for the security device end of the L2TP
tunnel is provided below.

WebUI
1. Interfaces
Network > Interfaces > Edit (for ethernet1): Enter the following, then click
Apply:

Zone Name: Trust

Static IP: (select this option when present)
IP Address/Netmask: 10.1.1.1/24

Select the following, then click OK:

Interface Mode: NAT

Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:

Zone Name: Untrust

Static IP: (select this option when present)
IP Address/Netmask: 1.1.1.1/24

224  L2TP and L2TP-over-IPSec

 Chapter 6: Layer 2 Tunneling Protocol

2. L2TP Users
Objects > Users > Local > New: Enter the following, then click OK:

User Name: Adam

Status: Enable
L2TP User: (select)
User Password: AJbioJ15
Confirm Password: AJbioJ15

Objects > Users > Local > New: Enter the following, then click OK:

User Name: Betty

Status: Enable
L2TP User: (select)
User Password: BviPsoJ1
Confirm Password: BviPsoJ1

Objects > Users > Local > New: Enter the following, then click OK:

User Name: Carol

Status: Enable
L2TP User: (select)
User Password: Cs10kdD3
Confirm Password: Cs10kdD3
3. L2TP User Group
Objects > User > Local Groups> New: Type fs in the Group Name field, do the
following, then click OK:

Select Adam and use the << button to move him from the Available
Members column to the Group Members column.

Select Betty and use the << button to move her from the Available
Members column to the Group Members column.

Select Carol and use the << button to move her from the Available
Members column to the Group Members column.

4. Default L2TP Settings

Objects > IP Pools > New: Enter the following, then click OK:

IP Pool Name: global

Start IP: 10.10.2.100
End IP: 10.10.2.180

VPNs > L2TP > Default Settings: Enter the following, then click OK:

IP Pool Name: global

PPP Authentication: CHAP
DNS Primary Server IP: 1.1.1.2
DNS Secondary Server IP: 1.1.1.3
WINS Primary Server IP: 0.0.0.0
WINS Secondary Server IP: 0.0.0.0

L2TP and L2TP-over-IPSec  225

 Concepts & Examples ScreenOS Reference Guide

5. L2TP Tunnel
VPNs > L2TP > Tunnel > New: Enter the following, then click OK:

Name: sales_corp
Use Custom Settings: (select)
Authentication Server: Local
Dialup Group: Local Dialup Group - fs
Outgoing Interface: ethernet3
Peer IP: 0.0.0.0
Host Name (optional): Enter the name of the computer acting as the LAC.
Secret (optional): Enter a secret shared between the LAC and the LNS.
Keep Alive: 60

Peer IP: Because the peer’s ISP dynamically assigns it an IP address, you would
enter 0.0.0.0 in the above example.

LAC: To find the name of a computer running Windows 2000, do the following:
Click Start > Settings > Control Panel > System. The System Properties dialog
box appears. Click the Network Identification tab, and see entry following Full
computer name.

To add a secret to the LAC for authenticating the L2TP tunnel, you must modify the
Windows 2000 registry as follows:

1. Click Start > Run, and then type regedit. The Registry Editor opens.

2. Click HKEY_LOCAL_MACHINE.

3. Right-click SYSTEM, and then select Find from the pop-up menu that appears.

4. Type ms_l2tpminiport, then click Find Next.

5. In the Edit menu, highlight New, and then select String Value.

6. Type Password.

7. Double-click Password. The Edit String dialog box appears.

8. Type the password in the Value data field. This must be the same as the word in
the L2TP Tunnel Configuration Secret field on the security device.

9. Reboot the computer running Windows 2000.

When using L2TP-over-IPSec, which is the Windows 2000 default, tunnel

authentication is unnecessary; all L2TP messages are encrypted and
authenticated inside IPSec.

Keep-Alive: The Keep Alive value is the number of seconds of inactivity before the
security device sends an L2TP hello signal to the LAC.

226  L2TP and L2TP-over-IPSec

 Chapter 6: Layer 2 Tunneling Protocol

6. Route
Network > Routing > Routing Entries > New: Enter the following, then click
OK:

Network Address/Netmask: 0.0.0.0/0

Gateway: (select)
Interface: ethernet3
Gateway IP Address: 1.1.1.250
7. Policy
Policies > (From: Untrust, To: Trust) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), Dial-Up VPN
Destination Address:
Address Book Entry: (select), Any
NAT: Off
Service: ANY
Action: Tunnel
Tunnel L2TP: sales_corp
Position at Top: (select)

CLI
1. Dialup Users
set user adam type l2tp
set user adam password AJbioJ15
unset user adam type auth
set user betty type l2tp
set user betty password BviPsoJ1
unset user betty type auth
set user carol type l2tp
set user carol password Cs10kdD3
unset user carol type auth

NOTE: Defining a password for a user automatically classifies the user as an auth user.
Therefore, to define the user type strictly as L2TP, you must unset the auth user
type.

2. L2TP User Group

set user-group fs location local
set user-group fs user adam
set user-group fs user betty
set user-group fs user carol
3. Default L2TP Settings
set ippool global 10.10.2.100 10.10.2.180
set l2tp default ippool global
set l2tp default auth server Local
set l2tp default ppp-auth chap
set l2tp default dns1 1.1.1.2
set l2tp default dns2 1.1.1.3
4. L2TP Tunnel
set l2tp sales_corp outgoing-interface ethernet3
set l2tp sales_corp auth server Local user-group fs

L2TP and L2TP-over-IPSec  227

 Concepts & Examples ScreenOS Reference Guide

5. Route
set vrouter trust-vr route 0.0.0.0/0 interface ethernet3 gateway 1.1.1.250
6. Policy
set policy top from untrust to trust “Dial-Up VPN” any any tunnel l2tp sales_corp
save

Configuring L2TP-over-IPSec
This example uses the same L2TP tunnel created in the previous example
(“Configuring L2TP” on page 223). Additionally, you overlay an IPSec tunnel onto
the L2TP tunnel to provide encryption. The IPSec tunnel negotiates Phase 1 in
Aggressive Mode using a previously loaded RSA certificate, 3DES encryption and
SHA-1 authentication. The certificate authority (CA) is Verisign. (For information
about obtaining and loading certificates, see “Public Key Cryptography” on
page 29.) The Phase 2 negotiation uses the security level predefined as
“Compatible” for Phase 2 proposals. The IPSec tunnel is in Transport mode.

The predefined Trust zone and the user-defined Dialup zone are in the trust-vr
routing domain. The interfaces for the Dialup and Trust zones are ethernet2
(1.3.3.1/24) and ethernet1 (10.1.1.1/24), respectively. The Trust zone is in NAT
mode.

The dialup users Adam, Betty, and Carol use NetScreen-Remote clients on a
Windows 2000 operating system. The NetScreen-Remote configuration for dialup
user Adam is also included below. (The NetScreen-Remote configuration for the
other two dialup users is the same as that for Adam.)

NOTE: To configure an L2TP-over-IPSec tunnel for Windows 2000 (without

NetScreen-Remote), the Phase 1 negotiations must be in Main mode and the IKE
ID type must be ASN1-DN.

Figure 61: Configuring L2TP-over-IPSec

IKE-L2TP
Dialup User Group: fs
Dialup IP Pool: global
Zone DNS1: 1.1.1.2 10.10.2.100 –
Adam 10.10.2.180 Corporate
DNS2: 1.1.1.3 Network

Trust Zone
Betty

Internet

Carol
L2TP Tunnel: sales_corp
VPN Tunnel: from_sales Outgoing Interface ethernet1,
ethernet2, 1.3.3.1/24 10.1.1.1/24
NetScreen-
Remote Clients

228  L2TP and L2TP-over-IPSec

 Chapter 6: Layer 2 Tunneling Protocol

WebUI
1. User-Defined Zone
Network > Zones > New: Enter the following, then click OK:

Zone Name: Dialup

Virtual Router Name: trust-vr
Zone Type: Layer 3 (select)
Block Intra-Zone Traffic: (select)
TCP/IP Reassembly for ALG: (clear)

NOTE: The Trust zone is preconfigured. You do not need to create it.

2. Interfaces
Network > Interfaces > Edit (for ethernet1): Enter the following, then click
Apply:

Zone Name: Trust

Static IP: (select this option when present)
IP Address/Netmask: 10.1.1.1/24
Select the following, then click OK:
Interface Mode: NAT

Network > Interfaces > Edit (for ethernet2): Enter the following, then click
OK:

Zone Name: Dialup

Static IP: (select this option when present)
IP Address/Netmask: 1.3.3.1/24
3. IKE/L2TP Users
Objects > Users > Local > New: Enter the following, then click OK:

User Name: Adam

Status: Enable
IKE User: (select)
Simple Identity: (select)
IKE Identity: [email protected]
L2TP User: (select)
User Password: AJbioJ15
Confirm Password: AJbioJ15

NOTE: The IKE ID that you enter must be the same as the one that the NetScreen-Remote
client sends, which is the email address that appears in the certificate that the
client uses for authentication.

Objects > Users > Local > New: Enter the following, then click OK:

User Name: Betty

Status: Enable
IKE User: (select)
Simple Identity: (select)
IKE Identity: [email protected]
L2TP User: (select)
User Password: BviPsoJ1
Confirm Password: BviPsoJ1

L2TP and L2TP-over-IPSec  229

 Concepts & Examples ScreenOS Reference Guide

Objects > Users > Local > New: Enter the following, then click OK:

User Name: Carol

Status: Enable
IKE User: (select)
Simple Identity: (select)
IKE Identity: [email protected]
L2TP User: (select)
User Password: Cs10kdD3
Confirm Password: Cs10kdD3
4. IKE/L2TP User Group
Objects > Users > Local Groups > New: Type fs in the Group Name field, do
the following, then click OK:

Select Adam and use the << button to move him from the Available
Members column to the Group Members column.

Select Betty and use the << button to move her from the Available
Members column to the Group Members column.

Select Carol and use the << button to move her from the Available
Members column to the Group Members column.

5. IP Pool
Objects > IP Pools > New: Enter the following, then click OK:

IP Pool Name: global

Start IP: 10.10.2.100
End IP: 10.10.2.180
6. Default L2TP Settings
VPNs > L2TP > Default Settings: Enter the following, then click Apply:

IP Pool Name: global

PPP Authentication: CHAP
DNS Primary Server IP: 1.1.1.2
DNS Secondary Server IP: 1.1.1.3
WINS Primary Server IP: 0.0.0.0
WINS Secondary Server IP: 0.0.0.0
7. L2TP Tunnel
VPNs > L2TP > Tunnel > New: Enter the following, then click OK:

Name: sales_corp
Dialup Group: (select), Local Dialup Group - fs
Authentication Server: Local
Outgoing Interface: ethernet2
Peer IP: 0.0.0.0

Host Name (optional): If you want to restrict the L2TP tunnel to a specific
host, enter the name of the computer acting as the LAC.

Secret (optional): Enter a secret shared between the LAC and the LNS.

Keep Alive: 60

230  L2TP and L2TP-over-IPSec

 Chapter 6: Layer 2 Tunneling Protocol

LAC: To find the name of a computer running Windows 2000, do the following:
Click Start > Settings > Control Panel > System. The System Properties dialog
box appears. Click the Network Identification tab, and see entry following Full
computer name.

Secret: To add a secret to the LAC for authenticating the L2TP tunnel, you must
modify the Windows 2000 registry as follows:

1. Click Start > Run, and then type regedit. The Registry Editor opens.

2. Click HKEY_LOCAL_MACHINE.

3. Right-click SYSTEM, and then select Find from the pop-up menu that appears.

4. Type ms_l2tpminiport, then click Find Next.

5. In the Edit menu, highlight New, and then select String Value.

6. Type Password.

7. Double-click Password. The Edit String dialog box appears.

8. Type the password in the Value data field. This must be the same as the word in
the L2TP Tunnel Configuration Secret field on the security device.

9. Reboot the computer running Windows 2000.

When using L2TP-over-IPSec, which is the Windows 2000 default, tunnel

authentication is unnecessary; all L2TP messages are encrypted and
authenticated inside IPSec.

Keep-Alive: The Keep Alive value is the number of seconds of inactivity before the
security device sends an L2TP hello signal to the LAC.

NOTE: The hostname and secret settings can usually be ignored. Only advanced users are
recommended to use these settings.

8. VPN Tunnel
VPNs > AutoKey Advanced > Gateway > New: Enter the following, then click
OK:

Gateway Name: field

Security Level: Custom
Remote Gateway Type:
Dialup User Group: (select), Group: fs
Outgoing Interface: ethernet2

L2TP and L2TP-over-IPSec  231

 Concepts & Examples ScreenOS Reference Guide

> Advanced: Enter the following advanced settings, then click Return to
return to the basic Gateway configuration page:

Security Level: User Defined: Custom

Phase 1 Proposal: rsa-g2-3des-sha
Mode (Initiator): Aggressive
Preferred Certificate (Optional):
Peer CA: Verisign
Peer Type: X509-SIG

NOTE: Windows 2000 (without NetScreen-Remote) supports Main mode negotiations

only.

VPNs > AutoKey IKE > New: Enter the following, then click OK:

Name: from_sales
Security Level: Compatible
Remote Gateway: Predefined: field

> Advanced: Enter the following advanced settings, then click Return to
return to the basic AutoKey IKE configuration page:

Security Level: Compatible

Transport Mode: (select)
9. Policy
Policies > (From: Dialup, To: Trust) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), Dial-Up VPN
Destination Address:
Address Book Entry: (select), Any
Service: ANY
Action: Tunnel
Tunnel VPN: from_sales
Modify matching bidirectional VPN policy: (clear)
L2TP: sales_corp
Position at Top: (select)

CLI
1. User-Defined Zone
set zone name dialup
set zone dialup vrouter trust-vr
set zone dialup block
2. Interfaces
set interface ethernet1 zone trust
set interface ethernet1 ip 10.1.1.1/24
set interface ethernet1 nat
set interface ethernet2 zone dialup
set interface ethernet2 ip 1.3.3.1/24

232  L2TP and L2TP-over-IPSec

 Chapter 6: Layer 2 Tunneling Protocol

3. L2TP/IKE Users
set user adam type ike l2tp
set user adam password AJbioJ15
unset user adam type auth
set user adam ike-id u-fqdn [email protected]
set user betty type ike l2tp
set user betty password BviPsoJ1
unset user betty type auth
set user betty ike-id u-fqdn [email protected]
set user carol type ike l2tp
set user carol password Cs10kdD3
unset user carol type auth
set user carol ike-id u-fqdn [email protected]
4. IKE/L2TP User Group
set user-group fs location Local
set user-group fs user adam
set user-group fs user betty
set user-group fs user carol
5. IP Pool
set ippool global 10.10.2.100 10.10.2.180
6. Default L2TP Settings
set l2tp default ippool global
set l2tp default ppp-auth chap
set l2tp default dns1 1.1.1.2
set l2tp default dns2 1.1.1.3
7. L2TP Tunnel
set l2tp sales_corp outgoing-interface ethernet2
set l2tp sales_corp auth server Local user-group fs
8. VPN Tunnel
set ike gateway field dialup fs aggressive outgoing-interface ethernet2 proposal
rsa-g2-3des-sha
set ike gateway field cert peer-ca1
set ike gateway field cert peer-cert-type x509-sig
set vpn from_sales gateway field transport sec-level compatible

NOTE: Windows 2000 (without NetScreen-Remote) supports Main mode negotiations

only.

The number 1 is the CA ID number. To discover the CA’s ID number, use the
following command: get pki x509 list ca-cert.

9. Policy
set policy top from dialup to trust “Dial-Up VPN” any any tunnel vpn from_sales
l2tp sales_corp
save

L2TP and L2TP-over-IPSec  233

 Concepts & Examples ScreenOS Reference Guide

NetScreen-Remote Security Policy Editor (Adam)

To configure L2TP-over-IPSec tunnels for Betty and Carol’s NetScreen-Remote
clients, follow the same procedure as that provided here for Adam.

1. Click Options > Secure > Specified Connections.

2. Click Add a new connection, and type AJ next to the new connection icon that
appears.

3. Configure the connection options:

Connection Security: Secure

Remote Party ID Type: IP Address
IP Address: 1.3.3.1
Protocol: UDP
Port: L2TP
Connect using Secure Gateway Tunnel: (clear)

4. Click the PLUS symbol, located to the left of the AJ icon, to expand the
connection policy.

5. Click My Identity, and configure the following:

Select the certificate with the email address specified as the user’s IKE ID on
the security device from the Select Certificate drop-down list:

ID Type: E-mail Address

Port: L2TP

NOTE: The email address from the certificate appears in the identifier field automatically.

6. Click the Security Policy icon, and select Aggressive Mode.

7. Click the PLUS symbol, located to the left of the Security Policy icon, and then
the PLUS symbol to the left of Authentication (Phase 1) and Key Exchange
(Phase 2) to expand the policy further.

8. Click Authentication (Phase 1) > Proposal 1: Select the following

Authentication Method and Algorithms:

Authentication Method: Pre-Shared Key

(or)
Authentication Method: RSA Signatures
Hash Alg: SHA-1
Key Group: Diffie-Hellman Group 2

9. Click Key Exchange (Phase 2) > Proposal 1: Select the following IPSec
Protocols:

Encapsulation Protocol (ESP): (select)

Encrypt Alg: Triple DES
Hash Alg: SHA-1
Encapsulation: Transport

234  L2TP and L2TP-over-IPSec

 Chapter 6: Layer 2 Tunneling Protocol

10. Click Key Exchange (Phase 2) > Create New Proposal: Select the following
IPSec Protocols:

Encapsulation Protocol (ESP): (select)

Encrypt Alg: Triple DES
Hash Alg: MD5
Encapsulation: Transport

11. Click Key Exchange (Phase 2) > Create New Proposal: Select the following
IPSec Protocols:

Encapsulation Protocol (ESP): (select)

Encrypt Alg: DES
Hash Alg: SHA-1
Encapsulation: Transport

12. Click Key Exchange (Phase 2) > Create New Proposal: Select the following
IPSec Protocols:

Encapsulation Protocol (ESP): (select)

Encrypt Alg: DES
Hash Alg: MD5
Encapsulation: Transport

13. Click File > Save Changes.

14. You also need to set up the network connection for your Windows 2000
operating system using the Network Connection Wizard.

NOTE: When configuring the Network Connection Wizard, you must enter a destination
hostname or IP address. Enter 1.3.3.1. Later, when initiating a connection and are
prompted for a username and password, enter adam, AJbioJ15. For more
information, consult Microsoft Windows 2000 documentation.

Bidirectional L2TP-over-IPSec
In this example, ethernet1 (10.1.1.1/24) is the Trust zone interface and is in NAT
mode, and ethernet3 (1.1.1.1/24) is the Untrust zone interface. You create
L2TP-over-IPSec tunnels between a NetScreen-Remote dialup user and a corporate
LAN. The remote user is running an X-Windows application, which requires
bidirectional policies.

You configure incoming and outgoing policies for the dialup AutoKey IKE VPN
tunnel named VPN_dial for IKE user dialup-j with IKE ID [email protected]., and the L2TP
tunnel named tun1. The IKE user initiates a IPSec connection to the security device
from the Untrust zone to reach corporate servers in the Trust zone. At this point,
only L2TP communication is allowed. After L2TP/PPP negotiation, the L2TP tunnel
is established. With bidirectional policies configured, traffic can initiate from either
end of the tunnel.

The dialup user dialup-j uses a NetScreen-Remote client on a Windows 2000

operating system. The NetScreen-Remote configuration for dialup user dialup-j is
included after Figure 62 on page 236.

L2TP and L2TP-over-IPSec  235

 Concepts & Examples ScreenOS Reference Guide

Figure 62: Bidirectional L2TP-over-IPSec

ethernet3 ethernet3
1.1.1.1/24 10.1.1.1/24
Dialup Zone
Trust Zone
Internet
LAN

NetScreen-Remote Client L2TP-over-IPSec External Router UNIX Server

Running X-Windows Server Tunnel 1.1.1.250

NOTE: To configure an L2TP-over-IPSec tunnel for Windows 2000 (without

NetScreen-Remote), the Phase 1 negotiations must be in Main mode and the IKE
ID type must be ASN1-DN.

WebUI
1. Interfaces
Network > Interfaces > Edit (for ethernet1): Enter the following, then click
Apply:

Zone Name: Trust

Static IP: (select this option when present)
IP Address/Netmask: 10.1.1.1/24

Select the following, then click OK:

Interface Mode: NAT

Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:

Zone Name: Untrust

Static IP: (select this option when present)
IP Address/Netmask: 1.1.1.1/24
2. Address
Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: trust_net

IP Address/Domain Name:
IP/Netmask: (select), 10.1.1.0/24
Zone: Trust

236  L2TP and L2TP-over-IPSec

 Chapter 6: Layer 2 Tunneling Protocol

3. L2TP/IKE User
Objects > Users > Local > New: Enter the following, then click OK:

User Name: dialup-j

Status: Enable
IKE User: (select)
Simple Identity: (select)
IKE Identity: [email protected]
Authentication User: (select)
L2TP User: (select)
User Password: abc123
Confirm Password: abc123

NOTE: The IKE ID that you enter must be the same as the one that the NetScreen-Remote
client sends, which is the email address that appears in the certificate that the
client uses for authentication.

4. L2TP
VPNs > L2TP > Tunnel > New: Enter the following, then click OK:

Name: tun1
Use Default Settings: (select)
Secret: netscreen
Keepalive: 60
5. VPN
VPNs > AutoKey Advanced > Gateway > New: Enter the following, then click
OK:

Gateway Name: dialup1

Security Level: (select), Standard
Remote Gateway Type: Dialup User; (select), dialup-j
Preshared Key: n3TsCr33N
Outgoing Interface: (select), ethernet3

> Advanced: Enter the following, and then click Return to return to the
basic AutoKey IKE Gateway configuration page:

Mode (Initiator): Aggressive

Enable NAT-Traversal: (select)
UDP Checksum: (select)
Keepalive Frequency: 5

VPNs > AutoKey IKE > New: Enter the following, then click OK:

VPN Name: VPN_dial

Remote Gateway: Predefined: (select), dialup1

> Advanced: Enter the following, and then click Return to return to the
basic AutoKey IKE configuration page:

Security Level: Standard (select)

Transport Mode (For L2TP-over-IPSec only): (select)

L2TP and L2TP-over-IPSec  237

 Concepts & Examples ScreenOS Reference Guide

6. Route
Network > Routing > Routing Entries > New: Enter the following, then click
OK:

Network Address/Netmask: 0.0.0.0/0

Gateway: (select)
Interface: ethernet3
Gateway IP Address: 1.1.1.250
7. Policies
Policies > (From: Untrust, To: Trust) > New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), Dial-Up VPN
Destination Address:
Address Book Entry: (select), trust_net
Service: ANY
Action: Tunnel
Tunnel VPN: VPN_dial
Modify matching bidirectional VPN policy: (select)
L2tp: (select) tun1

Policies > (From: Trust, To: Untrust) > New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), trust_net
Destination Address:
Address Book Entry: (select), Dial-Up VPN
Service: ANY
Action: Tunnel
Tunnel VPN: VPN_dial
Modify matching bidirectional VPN policy: (select)
L2TP: tun1

CLI
1. Interfaces
set interface ethernet1 zone trust
set interface ethernet1 ip 10.1.1.1/24
set interface ethernet1 nat
set interface ethernet3 zone untrust
set interface ethernet3 ip 1.1.1.1/24
2. Address
set address trust trust_net 10.1.1.0/24
3. L2TP/IKE User
set user dialup-j ike-id u-fqdn [email protected]
set user dialup-j type auth ike l2tp
set user dialup-j password abc123
4. L2TP
set L2TP tun1 outgoing-interface ethernet3 secret "netscreen" keepalive 60

238  L2TP and L2TP-over-IPSec

 Chapter 6: Layer 2 Tunneling Protocol

5. VPN
set ike gateway dialup1 dialup "dialup-j" aggressive outgoing-interface ethernet3
preshare n3TsCr33N sec-level standard
set ike gateway dialup1 nat-traversal udp-checksum
set ike gateway dialup1 nat-traversal keepalive-frequency 5
set vpn VPN_dial gateway dialup1 no-replay transport idletime 0 sec-level standard
6. Route
set vrouter trust-vr route 0.0.0.0/0 interface ethernet3 gateway 1.1.1.250
7. Policies
set policy from untrust to trust “Dial-Up VPN” “trust_net” any tunnel vpn VPN_dial
tun1
set policy from trust to untrust trust_net “Dial-Up VPN” any tunnel vpn VPN_dial
l2tp tun1
save

NetScreen-Remote Security Policy Editor (for User “dialup-j”)

1. Click Options > Secure > Specified Connections.

2. Click Add a new connection, and type dialup-j next to the new connection
icon that appears.

3. Configure the connection options:

Connection Security: Secure

Remote Party ID Type: IP Address
IP Address: 1.1.1.1
Protocol: UDP
Port: L2TP
Connect using Secure Gateway Tunnel: (clear)

4. Click the PLUS symbol, located to the left of the dialup-j icon, to expand the
connection policy.

5. Click My Identity, and configure the following:

Select the certificate with the email address specified as the user’s IKE ID on
the security device from the Select Certificate drop-down list

ID Type: E-mail Address

Port: L2TP

NOTE: The email address from the certificate appears in the identifier field automatically.

6. Click the Security Policy icon, and select Aggressive Mode.

7. Click the PLUS symbol, located to the left of the Security Policy icon, and then
the PLUS symbol to the left of Authentication (Phase 1) and Key Exchange
(Phase 2) to expand the policy further.

L2TP and L2TP-over-IPSec  239

 Concepts & Examples ScreenOS Reference Guide

8. Click Authentication (Phase 1) > Proposal 1: Select the following

Authentication Method and Algorithms:

Authentication Method: Pre-Shared Key

(or)
Authentication Method: RSA Signatures
Hash Alg: SHA-1
Key Group: Diffie-Hellman Group 2

NOTE: When Perfect Forwarding Secrecy (PFS) is enabled on the security device (DF
Group 1,2 or 5), it must also be enabled for the VPN client in NetScreen-Remote.

9. Click Key Exchange (Phase 2) > Proposal 1: Select the following IPSec
Protocols:

Encapsulation Protocol (ESP): (select)

Encrypt Alg: Triple DES
Hash Alg: SHA-1
Encapsulation: Transport

10. Click Key Exchange (Phase 2) > Create New Proposal: Select the following
IPSec Protocols:

Encapsulation Protocol (ESP): (select)

Encrypt Alg: Triple DES
Hash Alg: MD5
Encapsulation: Transport

11. Click Key Exchange (Phase 2) > Create New Proposal: Select the following
IPSec Protocols:

Encapsulation Protocol (ESP): (select)

Encrypt Alg: DES
Hash Alg: SHA-1
Encapsulation: Transport

12. Click Key Exchange (Phase 2) > Create New Proposal: Select the following
IPSec Protocols:

Encapsulation Protocol (ESP): (select)

Encrypt Alg: DES
Hash Alg: MD5
Encapsulation: Transport

13. Click File > Save Changes.

You also need to set up the network connection for your Windows 2000 operating
system using the Network Connection Wizard.

NOTE: When you configure the Network Connection Wizard, you must enter a
destination hostname or IP address. Enter 1.1.1.1. Later, when you initiate a
connection and are prompted for a username and password, enter dialup-j,
abc123. For more information, consult your Microsoft Windows 2000
documentation.

240  L2TP and L2TP-over-IPSec

Chapter 7
Advanced Virtual Private Network
Features

This chapter covers the following uses of virtual private network (VPN) technology:

 “NAT-Traversal” on page 242

 “Probing for NAT” on page 243

 “Traversing a NAT Device” on page 245

 “UDP Checksum” on page 247

 “Keepalive Packets” on page 247

 “Initiator/Responder Symmetry” on page 247

 “Enabling NAT-Traversal” on page 249

 “Using IKE IDs with NAT-Traversal” on page 250

 “VPN Monitoring” on page 252

 “Rekey and Optimization Options” on page 253

 “Source Interface and Destination Address” on page 254

 “Policy Considerations” on page 255

 “Configuring the VPN Monitoring Feature” on page 255

 “SNMP VPN Monitoring Objects and Traps” on page 263

 “Multiple Tunnels per Tunnel Interface” on page 265

 “Route-to-Tunnel Mapping” on page 265

 “Remote Peers’ Addresses” on page 267

 “Manual and Automatic Table Entries” on page 268

 241
 Concepts & Examples ScreenOS Reference Guide

 “Redundant VPN Gateways” on page 301

 “VPN Groups” on page 302

 “Monitoring Mechanisms” on page 303

 “TCP SYN-Flag Checking” on page 307

 “Creating Back-to-Back VPNs” on page 314

 “Creating Hub-and-Spoke VPNs” on page 321

NAT-Traversal
Network Address Translation (NAT) and Network Address Port Translation (NAPT)
are Internet standards that allow a local-area network (LAN) to use one set of IP
addresses for internal traffic and a second set of addresses for external traffic. NAT
devices generate these external addresses from predetermined pools of IP
addresses.

When setting up an IPSec tunnel, the presence of a NAT device along the data path
has no effect on Phase 1 and Phase 2 IKE negotiations, which always encapsulate
IKE packets within User Datagram Protocol (UDP) segments. However, after the
Phase 2 negotiations complete, performing NAT on the IPSec packets causes the
tunnel to fail. Of the many reasons why NAT causes disruption to IPSec, one reason
is that, for the Encapsulating Security Protocol (ESP), NAT devices cannot discern
the location of the Layer 4 header for port translation (because it is encrypted). For
the Authentication Header (AH) protocol, NAT devices can modify the port number,
but the authentication check, which includes the entire IPSec packet, fails.

NOTE: For a list of IPSec/NAT incompatibilities, refer to draft-ietf-ipsec-nat-regts-00.txt by

Bernard Aboba.

To solve these problems, security devices and the NetScreen-Remote client (version
6.0 or later) can apply a NAT-Traversal (NAT-T) feature. NAT-T adds a layer of UDP
encapsulation to IPSec packets after detecting one or more NAT devices along the
data path during Phase 1 exchanges, as prescribed in the IETF drafts
draft-ietf-ipsec-nat-t-ike-00.txt and draft-ietf-ipsec-udp-encaps-00.txt, as well as in
later versions of these drafts.

NOTE: NetScreen-Remote 6 and NetScreen-Remote 7 support NAT-T as described in

draft-ietf-ipsec-nat-t-ike-00.txt and draft-ietf-ipsec-udp-encaps-00.txt.
NetScreen-Remote 8.2 supports draft 02.

NAT devices can create another problem if they are also IKE/IPSec-aware and
attempt to process packets with the IKE port number of 500 or the IPSec protocol
numbers 50 (for ESP) and 51 (for AH). To avoid such intermediary processing of IKE
packets, version 2 of the previously mentioned IETF drafts proposes the shifting (or
“floating”) of UDP port numbers for IKE from 500 to 4500. To avoid intermediary
processing of IPSec packets, both drafts 0 and 2 insert a UDP header between the
outer IP header and the ESP or AH header, thereby changing the value in the

242  NAT-Traversal
 Chapter 7: Advanced Virtual Private Network Features

Protocol field from 50 or 51 (for ESP or AH, respectively) to 17 (for UDP). In

addition, the inserted UDP header also uses port 4500. The current version of
ScreenOS supports NAT-T based on draft-ietf-ipsec-nat-t-ike-02.txt and
draft-ietf-ipsec-udp-encaps-02.txt, as well as version 0 of these drafts.

NOTE: ScreenOS does not support NAT-T for Manual Key tunnels nor for IPSec traffic
using AH. ScreenOS only supports NAT-T for AutoKey IKE tunnels using ESP.

Probing for NAT

To check that both ends of the VPN tunnel support NAT-T, ScreenOS sends two
MD-5 hashes in the vendor ID payload in the first two exchanges of Phase 1
negotiations—one hash for the title of draft 0 and one of the title for draft 2:

 “4485152d 18b6bbcd 0be8a846 9579ddcc”—which is an MD-5 hash of

“draft-ietf-ipsec-nat-t-ike-00”

 “90cb8091 3ebb696e 086381b5 ec427b1f”—which is an MD-5 hash of

“draft-ietf-ipsec-nat-t-ike-02”

Both peers must send and receive at least one of these values in the vendor payload
ID for the NAT-T probe to continue. If they send hashes for both drafts, ScreenOS
uses the NAT-T implementation for draft 2.

If the devices at each endpoint support NAT-T, they send each other NAT discovery
(NAT-D) payloads in the third and fourth Phase 1 exchanges (Main mode) or in the
second and third exchanges (Aggressive mode). The NAT discovery (NAT-D) payload
is a IKE payload type for NAT-T. The NAT-D payload type number is 0130. For a list
of other IKE payload types, see “IKE Packets” on page 12.

NOTE: ScreenOS can handle multiple NAT-Discovery (NAT-D) payloads in an IKE

negotiation.

The NAT-D payloads contain a negotiated hash of the following information:

 Destination NAT-D hash:

 Initiator’s cookie (CKY-I)

 Responder’s cookie (CKY-R)

 Remote (destination) IKE peer’s IP address

 Destination port number

NAT-Traversal  243
 Concepts & Examples ScreenOS Reference Guide

 Source NAT-D hash (one or more):

 Initiator’s cookie (CKY-I)

 Responder’s cookie (CKY-R)

 Local (source) IKE peer’s IP address

 Source port number

NOTE: NAT-T supports multiple source NAT-D hashes for devices with multiple interfaces
and implementations that do not specify an outgoing interface.

When each peer compares the hashes it receives with the ones it sends, it can tell if
address translation has occurred between them. Distinguishing which packet has
been modified also indicates the location of the NAT device:

If Matches Then
the local peer’s destination at least one of the remote no address translation has
hash peer’s source hashes occurred.
at least one of the local peer’s the remote peer’s destination no address translation has
source hashes hash occurred.

If Does not match Then

the local peer’s destination at least one of the remote no address translation has
hash peer’s source hashes occurred.
at least one of the local peer’s the remote peer’s destination no address translation has
source hashes hash occurred.

Knowing the location of the NAT device is important because IKE keepalives must
initiate from the peer behind the NAT device. See “Keepalive Packets” on page 247.

If both peers support IETF draft 2, then they also float the IKE port number from
500 to 4500 as soon as they detect a NAT device between themselves during Phase
1 negotiations. In Main mode, the port numbers float to 4500 in the fifth and sixth
exchanges of Phase 1, and then for all Phase 2 exchanges. In Aggressive mode, the
port number floats to 4500 in the third—and final—exchange of Phase 1, and then
for all Phase 2 exchanges. The peers also use 4500 for the UDP port number for all
subsequent IPSec traffic.

244  NAT-Traversal
 Chapter 7: Advanced Virtual Private Network Features

Traversing a NAT Device

In Figure 63, a NAT device at the perimeter of a hotel LAN receives a packet from a
VPN dialup client with IP address 2.1.1.5, assigned by the hotel. For all outbound
traffic, the NAT device replaces the original source IP address in the outer header
with a new address 2.2.2.2. During Phase 1 negotiations, the VPN client and the
security device detect that both VPN participants support NAT-T, that a NAT device is
present along the data path, and that it is located in front of the VPN client.

Figure 63: NAT-Traversal

Corporate
Hotel

NAT device
Security device
Internet

VPN Tunnel
VPN Dialup Client

Src IP 200.1.1.1 -> 210.2.2.2

Encapsulating the IPSec packets within UDP packets—which both the VPN client
and the security device do—solves the problem of the authentication check failure.
The NAT device processes them as UDP packets, changing the source port in the
UDP header and leaving the SPI in the AH or ESP header unmodified. The VPN
participants strip off the UDP layer and process the IPSec packets, which pass the
authentication check because none of the authenticated content has been changed.

Another problem can arise if the NAT device is IKE/IPSec-aware. An IKE/IPSec-aware

NAT device might attempt to process IKE/IPSec traffic instead of forwarding it. To
prevent such intermediary processing, NAT-T (v2) changes the source and
destination UDP port numbers for IKE from 500 to 4500. NAT-T also inserts a
non-ESP marker in the UDP header just before the payload. For IPSec traffic, NAT-T
(v0 and v2) inserts a UDP header between the outer IP header and the ESP header.
The UDP packet also uses 4500 for both the source and destination port numbers.

As mentioned, NAT-T (v2) adds a non-ESP marker between the header and payload
of the UDP segment encapsulating the ISAKMP packet. The non-ESP marker is 4
bytes of zero (0000), and is added to the UDP segment to distinguish an
encapsulated ISAKMP packet from an encapsulated ESP packet, which does not
have such a marker. Without the non-ESP marker, the recipient would be unsure if
the encapsulated packet was an ISAKMP packet or an ESP packet because the UDP
header uses 4500 for both types. Using this marker indicates the correct type of
packet that is encapsulated so that the recipient can correctly demultiplex it.

As shown in Figure 64 on page 246, after detecting a NAT device in the data path,
the source and destination port numbers in the UDP header of an IKE packet
change from 500 to 4500. Also, the VPN tunnel endpoints insert a non-ESP marker
between the UDP header and payload to distinguish the encapsulated ISAKMP
packet from an ESP packet. The recipient can use this marker to distinguish the
encapsulated ISAKMP packet from an ESP packet and demultiplex it correctly.

NAT-Traversal  245
 Concepts & Examples ScreenOS Reference Guide

Figure 64: IKE Packet (for Phases 1 and 2)

IP Header UDP Header ISAKMP Header Payload

Note: ISAKMP is the packet format that IKE uses.

UDP Segment

Source Port (500 for IKE) Destination Port (500 for IKE)

Length Checksum

Payload

UDP Segment after detecting a NAT device

Source Port (4500 for IKE) Destination Port (4500 for IKE)

Length Checksum

Non-ESP Marker (0000)

Payload

Figure 65 shows how, after detecting a NAT device in the data path, the VPN tunnel
endpoints insert an additional UDP header between the outer IP header and the
ESP header of an IPSec packet. Because there is no non-ESP marker, the recipient
can distinguish the encapsulated ESP packet from an ISAKMP packet and
demultiplex the ESP packet correctly.

Figure 65: IPSec ESP Packet Before and After NAT Detection
IPSec ESP Packet before detecting a NAT device
IPSec Packet
Original Packet
Sent by IKE Gateway Sent by Initiating Host
IP2 ESP IP1 TCP
Payload
Header Header Header Header

The local gateway adds these

headers to the packet.

IPSec ESP Packet after detecting a NAT device

IPSec Packet Callouts
Original Packet
Sent by IKE Gateway
Sent by Initiating Host
IP2 UDP ESP IP1 TCP
Payload
Header Header Header Header Header

The local gateway adds these

headers to the packet.

UDP Header

Source Port (4500 for IKE) Destination Port (4500 for IKE)
Length Checksum

Payload

246  NAT-Traversal
 Chapter 7: Advanced Virtual Private Network Features

UDP Checksum
All UDP packets contain a UDP checksum, a calculated value that ensures UDP
packets are free of transmission errors. A security device does not require use of the
UDP checksum for NAT-T, so the WebUI and CLI present the checksum as an
optional setting. Even so, some NAT devices require a checksum, so you might have
to enable or disable this setting. By default, the UDP checksum is included when
you enable NAT-T.

WebUI
VPNs > AutoKey Advanced > Gateway > New:

Enter the necessary parameters for the new tunnel gateway as described in
“Site-to-Site Virtual Private Networks” on page 89 or “Dialup Virtual Private
Networks” on page 169; enter the following, then click OK:

> Advanced: Enter the following advanced settings, then click Return to
return to the basic Gateway configuration page:

Enable NAT-Traversal: (select)

UDP Checksum: Enable

CLI
set ike gateway name nat-traversal udp-checksum
unset ike gateway name nat-traversal udp-checksum

Keepalive Packets
When a NAT device assigns an IP address to a host, the NAT device determines how
long the new address remains valid when no traffic occurs. For example, a NAT
device might invalidate any generated IP address that remains unused for 20
seconds. Therefore, it is usually necessary for the IPSec participants to send
periodic keepalive packets—empty UDP packets—through the NAT device, so that
the NAT mapping does not change until the Phase 1 and Phase 2 SAs expire.

NOTE: NAT devices have different session timeout intervals, depending on the
manufacturer and model. It is important to determine what the interval is for the
NAT device and to set the keepalive frequency value below that.

Initiator/Responder Symmetry
When two security devices establish a tunnel in the absence of a NAT device, either
device can serve as initiator or responder. However, if either host resides behind a
NAT device, such initiator/responder symmetry might be impossible. This happens
whenever the NAT device generates IP addresses dynamically.

NAT-Traversal  247
 Concepts & Examples ScreenOS Reference Guide

Figure 66: Security Device with a Dynamically Assigned IP Address Behind a NAT Device
Note: Security zones depicted are from the
perspective of Device B. Untrust Zone Trust Zone

NAT
device
Device A Internet Device B
Host A Host B
Tunnel 10.1.1.5

1.2.1.1 1.1.1.250

The NAT device translates the source IP address in

IP Address Pool packets it receives from Device B using addresses
1.2.1.2 - 1.2.1.50 drawn from its IP address pool.

In Figure 66, Device B resides in a subnet located behind a NAT device. If the NAT
device generates new source IP addresses for packets it receives from
Device B—drawing them dynamically from a pool of IP addresses—Device A
cannot unambiguously identify Device B. Therefore, Device A cannot successfully
initiate a tunnel with Device B. Device A must be the responder, Device B the
initiator, and they must perform Phase 1 negotiations in Aggressive mode.

However, if the NAT device generates the new IP address using a mapped IP (MIP)
address, or some other one-to-one addressing method, Device A can
unambiguously identify Device B. Consequently, either Device A or Device B can be
the initiator, and both can use Main mode or Aggressive mode for Phase 1.
Device B, which is not behind the NAT device, configures this new IP address as the
IKE gateway address. At this time, the local ID or ID (peer ID) needs to be set.

NOTE: If you enable NAT-T on a security device acting as the responder and configure it to
perform IKE negotiations in Main mode, that device and all its peers of the
following types that are configured on the same outgoing interface must use the
same Phase 1 proposals presented in the same order as each other:

Dynamic peer (peers with dynamically assigned IP addresses)

Dialup VPN users
Peers with static IP addresses behind a NAT device

Because it is not possible to know the identity of a peer when negotiating Phase 1
in Main mode until the last two messages, the Phase 1 proposals must all be the
same so that IKE negotiations can proceed.

The security device automatically checks that all Phase 1 proposals are the same
and in the same order when you configure IKE in Main mode to one of the above
peer types on the same outgoing interface. If the proposals are different, the
security device generates an error message.

248  NAT-Traversal
 Chapter 7: Advanced Virtual Private Network Features

In the example shown in Figure 67, two devices, Device A and Device B, are
connected by a VPN tunnel. Device A is behind a NAT and has a private IP
31.0.0.14. The NAT generates a new public IP using MIP for Device A. You use the
MIP address as the gateway address while configuring IKEv2 gateway on Device B.
For more information about MIPs, see “Mapped IP Addresses” on page 8-63.

Figure 67: Security Device with a Mapped IP Address Behind a NAT Device
NAT device
31.0.0.14 VPN tunnel 33.0.0.15
Internet

Device A Device B
MIP 31.0.0.14 to 33.0.0.14

Device A Configuration
set ike gateway ikev2 "dev-b" address 33.0.0.15 id "dev-b.net" local-id "dev-a.net"
outgoing-interface "ethernet0/1" preshare
"KghBa3TbNruG2Es6e2C5zkr83SnLzIy1MQ==" proposal "pre-g2-3des-md5"
set ike gateway ikev2 "dev-b" nat-traversal
set ike gateway ikev2 "dev-b" nat-traversal udp-checksum
set ike gateway ikev2 "dev-b" nat-traversal keepalive-frequency 5
set vpn "dev-b" gateway "dev-b" no-replay tunnel idletime 0 proposal
"g2-esp-3des-md5"
set vpn "dev-b" id 0x1 bind interface tunnel.1
Device B Configuration
set ike gateway ikev2 "dev-a" address 33.0.0.14 id "dev-a.net" local-id "dev-b.net"
outgoing-interface "ethernet2/3" preshare
"5LXhnzFYNz8EO6srN9CgzDdrpKnEep28Uw==" proposal "pre-g2-3des-md5"
set ike gateway ikev2 "dev-a" nat-traversal
set ike gateway ikev2 "dev-a" nat-traversal udp-checksum
set ike gateway ikev2 "dev-a" nat-traversal keepalive-frequency 5
set vpn "dev-a" gateway "dev-a" no-replay tunnel idletime 0 proposal
"g2-esp-3des-md5"
set vpn "dev-a" id 0x1 bind interface tunnel.1

Enabling NAT-Traversal
In Figure 68, a NAT device at the perimeter of a hotel LAN assigns an address to the
VPN dialup client used by Jozef, a salesman attending a convention. For Jozef to
reach the corporate LAN through a dialup VPN tunnel, you must enable NAT-T for
the remote gateway “jozef,” configured on the security device, and for the remote
gateway configured on the VPN dialup client. You also enable the security device to
include a UDP checksum in its transmissions, and you set the keepalive frequency
to 8 seconds.

Figure 68: Enabling NAT-Traversal

Hotel Corporate

NAT device
Security device
Internet

VPN tunnel
VPN dialup client

NAT-Traversal  249
 Concepts & Examples ScreenOS Reference Guide

WebUI
VPNs > AutoKey Advanced > Gateway > New: Enter the necessary
parameters for the new tunnel gateway (described in “Site-to-Site Virtual
Private Networks ” on page 89 or “Dialup Virtual Private Networks ” on
page 169), enter the following, then click OK:

> Advanced: Enter the following advanced settings, then click Return to
return to the basic Gateway configuration page:

Enable NAT-Traversal: (select)

UDP Checksum: Enable
Keepalive Frequency: 8 Seconds (0~300 Sec)

NOTE: When you configure a dialup VPN through the CLI, the security device
automatically enables NAT-Traversal.

CLI
set ike gateway jozef nat-traversal
set ike gateway jozef nat-traversal udp-checksum
set ike gateway jozef nat-traversal keepalive-frequency 8
save

Using IKE IDs with NAT-Traversal

When two VPN gateways negotiate in main mode, they exchange IP addresses in
order to identify each other and activate the tunnel. When devices at either or both
ends of the tunnel have dynamically assigned IP addresses, however, you must
configure IKE IDs (local ID and peer ID) on the devices at both ends of the tunnel.
An IKE ID is a unique identifier that remains static. The IKE ID is set up during the
phase when you configure the IKE gateway.You configure IKE IDs instead of remote
IP address.

Without NAT-T, a VPN tunnel can be activated using only the local ID on the local
side and only the peer ID on the remote side. But when using NAT-Traversal with
dynamic VPN in main mode using certificates, you must set both the local ID and
peer ID on both sides of the VPN tunnel. The following example shows how you can
configure local IDs and peer IDs on firewall1 and firewall2 so they can identify each
other and activate a tunnel between them.

WebUI
On firewall1, enter the following:

VPNs > AutoKey IKE Advanced> Gateway > New: Enter the following,then
click Advanced:

Gateway Name: test_gw

Address/Hostname: 0.0.0.0
Peer-ID: firewall2

Click Advanced, then enter the following:

Security Level: Standard

Local-ID: firewall1
Outgoing Interface: ethernet0/0

250  NAT-Traversal
 Chapter 7: Advanced Virtual Private Network Features

Mode: Main
Security Level: Standard

On firewall2, enter the following:

VPNs > AutoKey IKE Advanced> Gateway > New: Enter the following, then
click Advanced:

Gateway Name: gw_bap15_p1

Address/Hostname: 1.1.1.1
Peer-ID: firewall1

Click Advanced, then enter the following:

Security Level: Standard

Local-ID: firewall2
Outgoing Interface: ethernet0/0
Mode: Main
Security Level: Standard

Cli
On firewall1, enter the following:

set ike gateway test-gw address 0.0.0.0 id firewall2 main local-id firewall1
outgoing-interface ethernet0/0 proposal standard

On firewall2, enter the following

set ike gateway gw_bap15_p1 address 1.1.1.1 id firewall1 main local-id firewall2
outgoing-interface ethernet0/0 proposal standard

The following table shows the CLI command for each of the IPsec NAT-T tasks:

To Use This CLI Command

Enable IPsec NAT-T per gateway set ike nat-t gateway name
Disable IPsec NAT-T per gateway unset ike nat-t gateway name
Set the IPsec NAT-T keepalive per gateway set ike nat-t keep-alive period seconds
Set the IPsec NAT-T keepalive count per gateway set ike nat-t keep-alive count count
Get the IPsec NAT-T status get ike nat-t gateway name

NAT-Traversal  251
 Concepts & Examples ScreenOS Reference Guide

VPN Monitoring
When you enable VPN monitoring for a specific tunnel, the security device sends
ICMP echo requests (or “pings”) through the tunnel at specified intervals
(configured in seconds) to monitor network connectivity through the tunnel.

NOTE: To change the ping interval, you can use the following CLI command: set
vpnmonitor interval number. The default is 10 seconds.

If the ping activity indicates that the VPN monitoring status has changed, the
security device triggers one of the following Simple Network Management Protocol
(SNMP) traps:

 Up to Down: This trap occurs when the state of VPN monitoring for the tunnel
is up, but a specified consecutive number of ICMP echo requests does not elicit
a reply and there is no other incoming VPN traffic. Then the state changes to
down.

 Down to Up: When the state of VPN monitoring for the tunnel is down, but the
ICMP echo request elicits a single response, then the state changes to up. The
down-to-up trap occurs only if you have disabled the rekey option and the
Phase 2 SA is still active when an ICMP echo request elicits a reply through the
tunnel.

NOTE: To change the threshold for the number of consecutive unsuccessful ICMP echo
requests, you can use the following CLI command: set vpnmonitor threshold
number. The default is 10 consecutive requests.

For more information about the SNMP data that VPN monitoring provides, see
“SNMP VPN Monitoring Objects and Traps” on page 263.

You apply VPN monitoring per VPN object, not necessarily per VPN tunnel. A VPN
object is what you define with the set vpn command or with its WebUI counterpart.
After you define one VPN object, you can then reference it in one or more policies
(creating policy-based VPNs). Because ScreenOS derives a policy-based VPN tunnel
from a VPN object plus the other policy parameters, a single VPN object can be an
element in numerous VPN tunnels. This distinction between VPN object and VPN
tunnel is important because Juniper Networks recommends that you apply VPN
monitoring to no more than 100 IPSec VPN tunnels—if you do not enable
optimization. If you do enable optimization, then there is no limitation to the
number of VPN tunnels to which you can apply VPN monitoring. To learn about the
optimization option, see “Rekey and Optimization Options” on page 253.

NOTE: VPN monitoring optimization operates on a per-object basis. You can enable it on
all VPN objects, on none, or only on some.

252  VPN Monitoring

 Chapter 7: Advanced Virtual Private Network Features

Rekey and Optimization Options

If you enable the rekey option, the security device starts sending ICMP echo
requests immediately upon completion of the tunnel configuration and continues to
send them indefinitely. The echo requests trigger an attempt to initiate IKE
negotiations to establish a VPN tunnel until the state of VPN monitoring for the
tunnel is up. The security device then uses the pings for VPN monitoring purposes.
If the state of VPN monitoring for the tunnel changes from up to down, the security
device deactivates its Phase 2 security association (SA) for that peer. The security
device continues to send echo requests to its peer at defined intervals, triggering
attempts to reinitiate IKE Phase 2 negotiations—and Phase 1 negotiations, if
necessary—until it succeeds. At that point, the security device reactivates the Phase
2 SA, generates a new key, and reestablishes the tunnel. A message appears in the
event log stating that a successful rekey operation has occurred.

NOTE: If a security device is a DHCP client, a DHCP update to a different address causes
IKE to rekey. However, a DHCP update to the same address does not provoke the
IKE rekey operation.

You can use the rekey option to ensure that an AutoKey IKE tunnel is always up,
perhaps to monitor devices at the remote site or to allow dynamic routing protocols
to learn routes at a remote site and transmit messages through the tunnel. Another
use to which you can apply VPN monitoring with the rekey option is for automatic
population of the next-hop tunnel binding table (NHTB table) and the route table
when multiple VPN tunnels are bound to a single tunnel interface. For an example
of this last use, see “Multiple Tunnels per Tunnel Interface” on page 265.

If you disable the rekey option, the security device performs VPN monitoring only
when the tunnel is active with user-generated traffic.

By default, VPN monitoring optimization is disabled. If you enable it (set vpn name
monitor optimized), the VPN monitoring behavior changes as follows:

 The security device considers incoming traffic through the VPN tunnel to be the
equivalent of ICMP echo replies. Accepting incoming traffic as a substitute for
ICMP echo replies can reduce false alarms that might occur when traffic
through the tunnel is heavy and the echo replies do not get through.

 If there is both incoming and outgoing traffic through the VPN tunnel, the
security device suppresses VPN monitoring pings altogether. Doing so can help
reduce network traffic.

Although VPN monitoring optimization offers some benefits, be aware that VPN
monitoring can no longer provide accurate SNMP statistics, such as VPN network
delay time, when the optimization option is active. Also, if you are using VPN
monitoring to track the availability of a particular destination IP address at the
remote end of a tunnel, the optimization feature can produce misleading results.

VPN Monitoring  253

 Concepts & Examples ScreenOS Reference Guide

Source Interface and Destination Address

By default, the VPN monitoring feature uses the IP address of the local outgoing
interface as the source address and the IP address of the remote gateway as the
destination address. If the remote peer is a VPN dialup client—such as the
NetScreen-Remote—that has an internal IP address, the security device
automatically detects its internal address and uses that as the destination. The VPN
client can be an XAuth user with an assigned internal IP address, or a dialup VPN
user or a member of a dialup VPN group with an internal IP address. You can also
specify the use of other source and destination IP addresses for VPN
monitoring—mainly to provide support for VPN monitoring when the other end of a
VPN tunnel is not a security device.

Because VPN monitoring operates independently at the local and remote sites, the
source address configured on the device at one end of a tunnel does not have to be
the destination address configured on the device at the other end. In fact, you can
enable VPN monitoring at both ends of a tunnel or at only one end.

Figure 69: Source and Destination Addresses for VPN Monitoring

Device A –> Device B
Source Address: Destination Address:
Device A pings from its outgoing
interface to the remote gateway; Outgoing Interface Remote Gateway
that is, from the Untrust zone
interface on Device A to the Device A
Untrust zone interface on VPN Tunnel Device B
Device B. LAN LAN

(Default Behavior) Trust Zone Untrust Zone

Device A –> NetScreen-Remote

Source Address: Destination Address:
Device A pings from its Trust
zone interface to the Trust Zone Interface NetScreen-Remote
NetScreen-Remote. The
NetScreen-Remote requires a
policy permitting inbound ICMP Device A VPN Tunnel
traffic from an address beyond LAN
the remote gateway; that is,
from beyond the Untrust zone Trust Zone Untrust Zone
interface of Device A.
Note: Device A requires a policy permitting ping traffic from the Trust to Untrust zones.
Device A –> Third-Party VPN Terminator
Source Address: Destination Address:
Device A pings from its FTP Server
Trust zone interface to a Trust Zone Interface
device beyond the remote Third-Party
gateway. This might be Device A
necessary if the remote VPN Tunnel VPN Terminator
peer does not respond to LAN
pings but can support
policies permitting inbound Trust Zone Untrust Zone
ping traffic.
Note: Device A requires a policy permitting ping traffic from the Trust to Untrust zones.

NOTE: If the other end of a tunnel is the NetScreen-Remote VPN client that receives its
address through XAuth, then the security device, by default, uses the
XAuth-assigned IP address as the destination for VPN monitoring. For information
about XAuth, see “XAuth Users and User Groups” on page 9-70.

254  VPN Monitoring

 Chapter 7: Advanced Virtual Private Network Features

Policy Considerations
You must create a policy on the sending device to permit pings from the zone
containing the source interface to pass through the VPN tunnel to the zone
containing the destination address if:

 The source interface is in a different zone from the destination address

 The source interface is in the same zone as the destination address, and
intrazone blocking is enabled

Likewise, you must create a policy on the receiving device to permit pings from the
zone containing the source address to pass through the VPN tunnel to the zone
containing the destination address if:

 The destination address is in a different zone from the source address

 The destination address is in the same zone as the source address, and
intrazone blocking is enabled

NOTE: If the receiving device is a third-party product that does not respond to the ICMP
echo requests, change the destination to an internal host in the remote peer’s LAN
that does respond. The remote peer’s firewall must have a policy permitting the
ICMP echo requests to pass through it.

Configuring the VPN Monitoring Feature

To enable VPN monitoring, do the following:

WebUI
VPNs > AutoKey IKE > New: Configure the VPN, click Advanced, enter the
following, click Return to go back to the basic VPN configuration page, then
click OK:

VPN Monitor: Select to enable VPN monitoring of this VPN tunnel.

Source Interface: Choose an interface from the drop-down list. If you

choose default, the security device uses the outgoing interface.

Destination IP: Enter a destination IP address. If you do not enter anything,

the security device uses the remote gateway IP address.

Rekey: Select this option if you want the security device to attempt IKE
Phase 2 negotiations—and IKE Phase 1 negotiations if necessary—if the
tunnel status changes from up to down. When you select this option, the
security device attempts IKE negotiations to set up the tunnel and begin
VPN monitoring immediately after you finish configuring the tunnel.

Clear this option if you do not want the security device to attempt IKE
negotiations if the tunnel status changes from up to down. When the
rekey option is disabled, VPN monitoring begins after user-generated
traffic has triggered IKE negotiations and stops when the tunnel status
changes from up to down.

VPN Monitoring  255

 Concepts & Examples ScreenOS Reference Guide

(Or)

VPNs > Manual Key > New: Configure the VPN, click Advanced, enter the
following, click Return to go back to the basic VPN configuration page, then
click OK:

VPN Monitor: Select to enable VPN monitoring of this VPN tunnel.

Source Interface: Choose an interface from the drop-down list. If you

choose default, the security device uses the outgoing interface.

Destination IP: Enter a destination IP address. If you do not enter anything,

the security device uses the remote gateway IP address.

CLI
set vpnmonitor frequency number
set vpnmonitor threshold number
set vpn name_str monitor [ source-interface interface [ destination-ip ip_addr ]
[optimized] [ rekey ]
save

NOTE: The VPN monitoring frequency is in seconds. The default setting is 10-second
intervals.

The VPN monitoring threshold number is the consecutive number of successful or

unsuccessful ICMP echo requests that determines whether the remote gateway is
reachable through the VPN tunnel or not. The default threshold is 10 consecutive
successful or 10 consecutive unsuccessful ICMP echo requests.

If you do not choose a source interface, the security device uses the outgoing
interface as the default.

If you do not choose a destination IP address, the security device uses the IP
address for the remote gateway.

The rekey option is not available for Manual Key VPN tunnels.

In this example, you configure an AutoKey IKE VPN tunnel between two security
devices (Device A and Device B). On Device A, you set up VPN monitoring from its
Trust zone interface (ethernet1) to the Trust zone interface (10.2.1.1/24) on
Device B. On the Device B, you set up VPN monitoring from its Trust zone interface
(ethernet1) to a corporate intranet server (10.1.1.5) behind Device A.

256  VPN Monitoring

 Chapter 7: Advanced Virtual Private Network Features

Device A Device B
Zones and Interfaces
 ethernet1  ethernet1
 Zone: Trust  Zone: Trust
 IP address: 10.1.1.1/24  IP address: 10.2.1.1/24
 Interface mode: NAT  Interface mode: NAT
 ethernet3  ethernet3
 Zone: Untrust  Zone: Untrust
 IP address: 1.1.1.1/24  IP address: 2.2.2.2/24

Route-Based AutoKey IKE Tunnel Parameters

 Phase 1  Phase 1
 Gateway name: gw1  Gateway name: gw1
 Gateway static IP address: 2.2.2.2  Gateway static IP address: 1.1.1.1
 Security level: Compatible1  Proposals: Compatible
 Preshared Key: Ti82g4aX  Preshared Key: Ti82g4aX
 Outgoing interface: ethernet3  Outgoing interface: ethernet3
 Mode: Main  Mode: Main
 Phase 2  Phase 2
 VPN tunnel name: vpn1  VPN tunnel name: vpn1
 Security level: Compatible2  Security level: Compatible
 VPN Monitoring: src = ethernet1; dst =  VPN Monitoring: src = ethernet1; dst =
10.2.1.1 10.1.1.5
 Bound to interface: tunnel.1  Bound to interface: tunnel.1

1.A Phase 1 security level of Compatible includes these proposals: pre-g2-3des-sha,

pre-g2-3des-md5, pre-g2-des-sha, and pre-g2-des-md5.
2.A Phase 2 security level of Compatible includes these proposals: nopfs-esp-3des-sha,
nopfs-esp-3des-md5, nopfs-esp-des-sha, and nopfs-esp-des-md5.

Device A Device B
Routes
To 0.0.0.0/0, use ethernet3, gateway To 0.0.0.0/0, use ethernet3, gateway 2.2.2.250
1.1.1.250 To 10.1.1.0/24, use tunnel.1, no gateway
To 10.2.1.0/24, use tunnel.1, no gateway (Null route–to drop traffic to 10.1.1.0/24 if
(Null route–to drop traffic to 10.2.1.0/24 if tunnel.1 goes down) To 10.1.1.0/24, use null
tunnel.1 goes down) To 10.2.1.0/24, use null interface, metric: 10
interface, metric: 10

Because both devices ping from an interface in their Trust zone to an address in
their Untrust zone, the admins at both ends of the VPN tunnel must define policies
permitting pings to pass from zone to zone.

NOTE: Because both VPN terminators are security devices in this example, you can use
the default source and destination addresses for VPN monitoring. The use of other
options is included purely to illustrate how you can configure a security device to
use them.

VPN Monitoring  257

 Concepts & Examples ScreenOS Reference Guide

WebUI (Device A)
1. Interfaces
Network > Interfaces > Edit (for ethernet1): Enter the following, then click
Apply:

Zone Name: Trust

Static IP: (select this option when present)
IP Address/Netmask: 10.1.1.1/24
Enter the following, then click OK:
Interface Mode: NAT

Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:

Zone Name: Untrust

Static IP: (select this option when present)
IP Address/Netmask: 1.1.1.1/24

Network > Interfaces > Tunnel IF New: Enter the following, then click OK:

Tunnel Interface Name: tunnel.1

Zone (VR): Trust (trust-vr)
Unnumbered: (select)
Interface: ethernet1(trust-vr)
2. Addresses
Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: Trust_LAN

IP Address/Domain Name:
IP/Netmask: (select), 10.1.1.0/24
Zone: Trust

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: Remote_LAN

IP Address/Domain Name:
IP/Netmask: (select), 10.2.1.0/24
Zone: Untrust
3. VPN
VPNs > AutoKey IKE > New: Enter the following, then click OK:

VPN Name: vpn1

Security Level: Compatible
Remote Gateway:
Create a Simple Gateway: (select)
Gateway Name: gw1
Type:
Static IP: (select), Address/Hostname: 2.2.2.2
Preshared Key: Ti82g4aX
Security Level: Compatible
Outgoing Interface: ethernet3

258  VPN Monitoring

 Chapter 7: Advanced Virtual Private Network Features

> Advanced: Enter the following advanced settings, then click Return to
return to the basic AutoKey IKE configuration page:

Bind to: Tunnel Interface, tunnel.1

Proxy-ID: (select)
Local IP / Netmask: 10.1.1.0/24
Remote IP / Netmask: 10.2.1.0/24
Service: ANY
VPN Monitor: (select)
Source Interface: ethernet1
Destination IP: 10.2.1.1
Rekey: (clear)
4. Routes
Network > Routing > Routing Entries > trust-vr New: Enter the following,
then click OK:

Network Address / Netmask: 0.0.0.0/0

Gateway: (select)
Interface: ethernet3
Gateway IP Address: 1.1.1.250

Network > Routing > Routing Entries > trust-vr New: Enter the following,
then click OK:

Network Address / Netmask: 10.2.1.0/24

Gateway: (select)
Interface: Tunnel.1
Gateway IP Address: 0.0.0.0

Network > Routing > Routing Entries > trust-vr New: Enter the following,
then click OK:

Network Address / Netmask: 10.2.1.0/24

Gateway: (select)
Interface: Null
Gateway IP Address: 0.0.0.0
Metric: 10
5. Policies
Policies > (From: Trust, To: Untrust) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), Trust_LAN
Destination Address:
Address Book Entry: (select), Remote_LAN
Service: ANY
Action: Permit
Position at Top: (select)

VPN Monitoring  259

 Concepts & Examples ScreenOS Reference Guide

Policies > (From: Untrust, To: Trust) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), Remote_LAN
Destination Address:
Address Book Entry: (select), Trust_LAN
Service: Any
Action: Permit
Position at Top: (select)

WebUI (Device B)
1. Interfaces
Network > Interfaces > Edit (for ethernet1): Enter the following, then click
Apply:

Zone Name: Trust

Static IP: (select this option when present)
IP Address/Netmask: 10.2.1.1/24
Enter the following, then click OK:
Interface Mode: NAT

Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:

Zone Name: Untrust

Static IP: (select this option when present)
IP Address/Netmask: 2.2.2.2/24

Network > Interfaces > Tunnel IF New: Enter the following, then click OK:

Tunnel Interface Name: tunnel.1

Zone (VR): Trust (trust-vr)
Unnumbered: (select)
Interface: ethernet1(trust-vr)
2. Addresses
Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: Trust_LAN

IP Address/Domain Name:
IP/Netmask: (select), 10.2.1.0/24
Zone: Trust

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: Remote_LAN

IP Address/Domain Name:
IP/Netmask: (select), 10.1.1.0/24
Zone: Untrust

260  VPN Monitoring

 Chapter 7: Advanced Virtual Private Network Features

3. VPN
VPNs > AutoKey IKE > New: Enter the following, then click OK:

VPN Name: vpn1

Security Level: Compatible
Remote Gateway:
Create a Simple Gateway: (select)
Gateway Name: gw1
Type:
Static IP: (select), Address/Hostname: 1.1.1.1
Preshared Key: Ti82g4aX
Security Level: Compatible
Outgoing Interface: ethernet3

> Advanced: Enter the following advanced settings, then click Return to
return to the basic AutoKey IKE configuration page:

Bind to: Tunnel Interface, tunnel.1

Proxy-ID: (select)
Local IP / Netmask: 10.2.1.0/24
Remote IP / Netmask: 10.1.1.0/24
Service: ANY
VPN Monitor: (select)
Source Interface: ethernet1
Destination IP: 10.1.1.5
Rekey: (clear)
4. Routes
Network > Routing > Routing Entries > trust-vr New: Enter the following,
then click OK:

Network Address / Netmask: 0.0.0.0/0

Gateway: (select)
Interface: ethernet3
Gateway IP Address: 2.2.2.250

Network > Routing > Routing Entries > trust-vr New: Enter the following,
then click OK:

Network Address / Netmask: 10.1.1.0/24

Gateway: (select)
Interface: Tunnel.1
Gateway IP Address: 0.0.0.0

Network > Routing > Routing Entries > trust-vr New: Enter the following,
then click OK:

Network Address / Netmask: 10.1.1.0/24

Gateway: (select)
Interface: Null
Gateway IP Address: 0.0.0.0
Metric: 10

VPN Monitoring  261

 Concepts & Examples ScreenOS Reference Guide

5. Policies
Policies > (From: Trust, To: Untrust) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), Trust_LAN
Destination Address:
Address Book Entry: (select), Remote_LAN
Service: ANY
Action: Permit
Position at Top: (select)

Policies > (From: Untrust, To: Trust) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), Remote_LAN
Destination Address:
Address Book Entry: (select), Trust_LAN
Service: Any
Action: Permit
Position at Top: (select)

CLI (Device A)
1. Interfaces
set interface ethernet1 zone trust
set interface ethernet1 ip 10.1.1.1/24
set interface ethernet1 nat
set interface ethernet3 zone untrust
set interface ethernet3 ip 1.1.1.1/24
set interface tunnel.1 zone trust
set interface tunnel.1 ip unnumbered interface ethernet1
2. Addresses
set address trust Trust_LAN 10.1.1.0/24
set address untrust Remote_LAN 10.2.1.0/24
3. VPN
set ike gateway gw1 address 2.2.2.2 main outgoing-interface ethernet3 preshare
Ti82g4aX sec-level compatible
set vpn vpn1 gateway gw1 sec-level compatible
set vpn vpn1 bind interface tunnel.1
set vpn vpn1 proxy-id local-ip 10.1.1.0/24 remote-ip 10.2.1.0/24 any
set vpn vpn1 monitor source-interface ethernet1 destination-ip 10.2.1.1
4. Routes
set vrouter trust-vr route 0.0.0.0/0 interface ethernet3 gateway 1.1.1.250
set vrouter trust-vr route 10.2.1.0/24 interface tunnel.1
set vrouter trust-vr route 10.2.1.0/24 interface null metric 10
5. Policies
set policy top from trust to untrust Trust_LAN Remote_LAN any permit
set policy top from untrust to trust Remote_LAN Trust_LAN any permit
save

262  VPN Monitoring

 Chapter 7: Advanced Virtual Private Network Features

CLI (Device B)
1. Interfaces
set interface ethernet1 zone trust
set interface ethernet1 ip 10.2.1.1/24
set interface ethernet1 nat
set interface ethernet3 zone untrust
set interface ethernet3 ip 2.2.2.2/24
set interface tunnel.1 zone trust
set interface tunnel.1 ip unnumbered interface ethernet1
2. Addresses
set address trust Trust_LAN 10.2.1.0/24
set address untrust Remote_LAN 10.1.1.0/24
3. VPN
set ike gateway gw1 address 1.1.1.1 main outgoing-interface ethernet3 preshare
Ti82g4aX sec-level compatible
set vpn vpn1 gateway gw1 sec-level compatible
set vpn vpn1 bind interface tunnel.1
set vpn vpn1 proxy-id local-ip 10.2.1.0/24 remote-ip 10.1.1.0/24 any
set vpn vpn1 monitor source-interface ethernet1 destination-ip 10.1.1.5
4. Routes
set vrouter trust-vr route 0.0.0.0/0 interface ethernet3 gateway 2.2.2.250
set vrouter trust-vr route 10.1.1.0/24 interface tunnel.1
set vrouter trust-vr route 10.1.1.0/24 interface null metric 10
5. Policies
set policy top from trust to untrust Trust_LAN Remote_LAN any permit
set policy top from untrust to trust Remote_LAN Trust_LAN any permit
save

SNMP VPN Monitoring Objects and Traps

ScreenOS provides the ability to determine the status and condition of active VPNs
through the use of Simple Network Management Protocol (SNMP) VPN monitoring
objects and traps. The VPN monitoring MIB notes whether each ICMP echo request
elicits a reply, a running average of successful replies, the latency of the reply, and
the average latency over the last 30 attempts.

NOTE: To enable your SNMP manager application to recognize the VPN monitoring MIBs,
you must import the ScreenOS-specific MIB extension files into the application.
You can find the MIB extension files on the documentation CD that shipped with
your security device.

VPN Monitoring  263

 Concepts & Examples ScreenOS Reference Guide

By enabling the VPN monitoring feature on an AutoKey IKE or Manual Key VPN
tunnel, the security device activates its SNMP VPN monitoring objects, which
include data on the following:

 The total number of active VPN sessions

 The time each session started

 The Security Association (SA) elements for each session:

 ESP encryption (DES or 3DES) and authentication algorithm (MD5 or

SHA-1) types

 AH algorithm type (MD5 or SHA-1)

 Key exchange protocol (AutoKey IKE or Manual Key)

 Phase 1 authentication method (Preshared Key or certificates)

 VPN type (dialup or peer-to-peer)

 Peer and local gateway IP addresses

 Peer and local gateway IDs

 Security Parameter Index (SPI) numbers

 Session status parameters

 VPN monitoring status (up or down)

 Tunnel status (up or down)

 Phase 1 and 2 status (inactive or active)

 Phase 1 and 2 lifetime (time in seconds before rekeying; Phase 2 lifetime is

also reported in remaining bytes before rekeying)

264  VPN Monitoring

 Chapter 7: Advanced Virtual Private Network Features

Multiple Tunnels per Tunnel Interface

You can bind multiple IPSec VPN tunnels to a single tunnel interface. To link a
specific destination to one of a number of VPN tunnels bound to the same tunnel
interface, the security device uses two tables: the route table and the next-hop
tunnel binding (NHTB) table. The security device maps the next-hop gateway IP
address specified in the route table entry to a particular VPN tunnel specified in the
NHTB table. With this technique, a single tunnel interface can support many VPN
tunnels. (See “Route-to-Tunnel Mapping” on page 265.)

Figure 70: One Tunnel Interface Bound to Multiple Tunnels

Route-based VPN tunnels to
multiple remote peers.

All tunnels share the

same tunnel interface.

Local security device

The security device can sort VPN traffic sent through a single tunnel interface to as many VPN
tunnels as the route table or VPN tunnel capacity—whichever is lower—can support.

The maximum number of VPN tunnels is not limited by the number of tunnel
interfaces that you can create, but by either route table capacity or the maximum
number of dedicated VPN tunnels allowed—whichever is lower. For instance, if your
security device supports 4000 routes and 1000 dedicated VPN tunnels, you can
create 1000 VPN tunnels and bind them to a single tunnel interface. If your security
device supports 8192 routes and 10,000 dedicated VPN tunnels, then you can
create over 8000 VPN tunnels and bind them to a single tunnel interface. To see the
maximum route and tunnel capacities for your security device, refer to the relevant
product datasheet.

NOTE: If route-table capacity is the limiting factor, you must subtract the routes
automatically generated by security zone interfaces and any other static
routes—such as the route to the default gateway—that you might need to define
from the total available for route-based VPN tunnels.

Route-to-Tunnel Mapping
To sort traffic among multiple VPN tunnels bound to the same tunnel interface, the
security device maps the next-hop gateway IP address specified in the route to a
particular VPN tunnel name. The mapping of entries in the route table to entries in
the NHTB table is shown below. In Figure 71, the local security device routes traffic
sent from 10.2.1.5 to 10.1.1.5 through the tunnel.1 interface and then through
vpn2.

Multiple Tunnels per Tunnel Interface  265

 Concepts & Examples ScreenOS Reference Guide

Figure 71: Route Table and Next-Hop Tunnel Binding (NHTB) Table
Local security device with Remote VPN peers—with dynamically assigned
multiple tunnels bound to external IP addresses and fixed tunnel interface
the tunnel.1 interface IP addresses—and their protected LANs

10.1.1.1

10.1.0.0/24
vpn1
10.2.1.5 tunnel.1 10.1.1.5
vpn2 10.1.2.1

10.1.1.0/24
10.2.0.0/16 vpn3
Trust Zone LAN 10.1.3.1

10.1.2.0/24

Route Table Next-Hop Tunnel Binding Table

ID IP-Prefix (Dst) Interface Gateway Next-Hop VPN Flag

1 10.1.0.0/24 tunnel.1 10.1.1.1 10.1.1.1 vpn1 static

2 10.1.1.0/24 tunnel.1 10.1.2.1 10.1.2.1 vpn2 static

3 10.1.2.0/24 tunnel.1 10.1.3.1 10.1.3.1 vpn3 static

You can employ a dynamic routing protocol such as Border Gateway During Phase 2 negotiations, the two IKE peers exchange tunnel
Protocol (BGP) to populate the route table automatically, or you can interface addresses and automatically enter these next-hop-
manually enter these routes. The IP address for the gateway is the to-tunnel bindings. Optionally, you can manually enter these. The
address of the tunnel interface at the remote peer’s site. next-hop IP address is the remote peer’s tunnel interface IP
address.
In the above entries, the IP address for the gateway in the route table (which is also the next-hop IP address in the NHTB table) is the tunnel
interface at the remote peer’s site. This IP address links the route—and consequently the tunnel interface specified in the route—to a particular
VPN tunnel for traffic destined to the specified IP prefix.

The security device uses the IP address of the remote peer’s tunnel interface as the
gateway and next-hop IP address. You can enter the route manually, or you can
allow a dynamic routing protocol to enter a route referencing the peer’s tunnel
interface IP address as the gateway in the route table automatically. The same IP
address must also be entered as the next hop, along with the appropriate VPN
tunnel name, in the NHTB table. Again, there are two options: you can either enter
it manually, or you can allow the security device to obtain it from the remote peer
during Phase 2 negotiations and enter it automatically.

The security device uses the gateway IP address in the route table entry and the
next-hop IP address in the NHTB table entry as the common element to link the
tunnel interface with the corresponding VPN tunnel. The security device can then
direct traffic destined for the IP-prefix specified in the route with the correct VPN
tunnel specified in the NHTB table.

266  Multiple Tunnels per Tunnel Interface

 Chapter 7: Advanced Virtual Private Network Features

Remote Peers’ Addresses

The internal addressing scheme for all remote peers reached through route-based
VPNs must be unique among each other. One way to accomplish this is for each
remote peer to perform Network Address Translation (NAT) for the source and
destination addresses. In addition, the tunnel interface IP addresses must also be
unique among all remote peers. If you intend to connect to large numbers of
remote sites, an address plan becomes imperative. The following is a possible
addressing plan for up to 1000 VPN tunnels:

Gateway/Next-Hop
Dst in Local Local Tunnel (Peer’s Tunnel
Route Table Interface Interface) VPN Tunnel
10.0.3.0/24 tunnel.1 10.0.2.1/24 vpn1
10.0.5.0/24 tunnel.1 10.0.4.1/24 vpn2
10.0.7.0/24 tunnel.1 10.0.6.1/24 vpn3
… … … …
10.0.251.0/24 tunnel.1 10.0.250.1/24 vpn125

10.1.3.0/24 tunnel.1 10.1.2.1/24 vpn126

10.1.5.0/24 tunnel.1 10.1.4.1/24 vpn127
10.1.7.0/24 tunnel.1 10.1.6.1/24 vpn128
… … … …
10.1.251.0/24 tunnel.1 10.1.250.1/24 vpn250

10.2.3.0/24 tunnel.1 10.2.2.1/24 vpn251

… … … …
10.2.251.0/24 tunnel.1 10.2.250.1/24 vpn375
… … … …
10.7.3.0/24 tunnel.1 10.7.2.1/24 vpn876
… … … …
10.7.251.0/24 tunnel.1 10.7.250.1/24 vpn1000

The tunnel interface on the local security device: is 10.0.0.1/24. On all remote
hosts, there is a tunnel interface with an IP address, which appears as the
gateway/next-hop IP address in the local route table and NHTB table.

For an example illustrating multiple tunnels bound to a single tunnel interface with
address translation, see “Setting VPNs on a Tunnel Interface to Overlapping
Subnets” on page 270.

Multiple Tunnels per Tunnel Interface  267

 Concepts & Examples ScreenOS Reference Guide

Figure 72: Multiple Tunnels Bound to a Single Tunnel Interface with Address Translation
The local security device and all its 10.0.4.1/24
NAT-dst 10.0.5.1 -> 10.0.6.1/24
peers perform NAT-dst with IP shifting NAT-dst 10.0.7.1 ->
on inbound VPN traffic and NAT-src internal IP addresses
internal IP addresses
from the egress tunnel interface IP
IF 10.0.2.1/24
address with port translation on NAT-dst 10.0.3.1 -> vpn2
outbound VPN traffic. internal IP addresses vpn3
vpn1 10.1.1.1/24
NAT-dst 10.1.2.1 ->
IF 10.0.2.1/24 internal IP addresses
NAT-dst 10.0.3.1 -> vpn251
internal IP addresses
10.6.2.1/24
NAT-dst 10.6.3.1->
Local security device internal IP addresses
10.0.0.1/24 vpn751
NAT-dst 10.0.1.1 ->
internal IP addresses
vpn1000
10.7.250.1/24
NAT-dst 10.7.251.1 ->
internal IP addresses

Manual and Automatic Table Entries

You can make entries in the NHTB and route tables manually. You can also
automate the populating of the NHTB and route tables. For a small number of
tunnels bound to a single tunnel interface, the manual method works well. For a
large number of tunnels, the automatic method reduces administrative setup and
maintenance as the routes dynamically self-adjust if tunnels or interfaces become
unavailable on the tunnel interface at the hub site.

Manual Table Entries

You can manually map a VPN tunnel to the IP address of a remote peer’s tunnel
interface in the next-hop tunnel binding (NHTB) table. First, you must contact the
remote admin and learn the IP address used for the tunnel interface at that end of a
tunnel. Then, you can associate that address with the VPN tunnel name in the
NHTB table with the following command:

set interface tunnel.1 nhtb peer’s_tunnel_interface_addr vpn name_str

After that, you can enter a static route in the route table that uses that tunnel
interface IP address as the gateway. You can enter the route either through the
WebUI or through the following CLI command:

set vrouter name_str route dst_addr interface tunnel.1 gateway

peer’s_tunnel_interface_addr

Automatic Table Entries

To make the population of both the NHTB and route tables automatic, the following
conditions must be met:

 The remote peers for all VPN tunnels bound to a single local tunnel interface
must be security devices running ScreenOS 5.0.0 or later.

 Each remote peer must bind its tunnel to a tunnel interface, and that interface
must have an IP address unique among all peer tunnel interface addresses.

268  Multiple Tunnels per Tunnel Interface

 Chapter 7: Advanced Virtual Private Network Features

 At both ends of each VPN tunnel, enable VPN monitoring with the rekey option,
or enable the IKE heartbeat reconnect option for each remote gateway.

 The local and remote peers must have an instance of a dynamic routing
protocol enabled on their connecting tunnel interfaces.

The use of VPN monitoring with the rekey option allows the security devices at both
ends of a tunnel to set up the tunnel without having to wait for user-originated VPN
traffic. After you enable VPN monitoring with the rekey option at both ends of a
VPN tunnel, the two security devices perform Phase 1 and Phase 2 IKE negotiations
to establish the tunnel. (For more information, see “VPN Monitoring” on page 252.)

NOTE: If you are running a dynamic routing protocol on the tunnel interfaces, traffic
generated by the protocol can trigger IKE negotiations even without enabling VPN
monitoring with the rekey option or enabling the IKE heartbeat reconnect option.
Still, we recommend that you not rely on dynamic routing traffic to trigger IKE
negotiations. Instead use VPN monitoring with the rekey option or the IKE
heartbeat reconnect option.

For Open Shortest Path First (OSPF), you must configure the tunnel interface on
the local peer as a point-to-multipoint interface before you enable the routing
protocol on the interface.

For remote peers with a dynamically assigned external IP address or with a fully
qualified domain name (FQDN) mapped to a dynamic IP address, the remote peer
must first initiate IKE negotiations. However, because the Phase 2 SA on the local
security device caches the remote peer’s dynamically assigned IP address, either
peer can reinitiate IKE negotiations to reestablish a tunnel whose VPN monitoring
state has changed from up to down.

During Phase 2 negotiations, the security devices exchange tunnel interface IP

addresses with each other. Each IKE module can then automatically enter the
tunnel interface IP address and its corresponding VPN tunnel name in the NHTB
table.

To enable the local security device to enter routes to remote destinations

automatically in its route table, you must enable an instance of BGP on the local and
remote tunnel interfaces. The basic steps are as follows:

1. Create a BGP routing instance on the virtual router that contains the tunnel
interface to which you have bound multiple VPN tunnels.

2. Enable the routing instance on the virtual router.

3. Enable the routing instance on the tunnel interface leading to the BPG peers.

The remote peers also perform these steps.

On the local (or hub) device, you must also define a default route and a static route
to each peer’s tunnel interface IP address. Static routes to the peers’ tunnel
interfaces are necessary for the hub device to reach its BGP neighbors initially
through the correct VPN tunnel.

Multiple Tunnels per Tunnel Interface  269

 Concepts & Examples ScreenOS Reference Guide

After establishing communications, the BGP neighbors exchange routing

information so that they can each automatically populate their route tables. After
the two peers establish a VPN tunnel between themselves, the remote peers can
send and receive routing information to and from the local device. When the
dynamic routing instance on the local security device learns a route to a peer
through a local tunnel interface, it includes the IP address of the remote peer’s
tunnel interface as the gateway in the route.

For an example illustrating the configuration of multiple tunnels bound to a single

tunnel interface where the “hub” device populates its NHTB and route tables
automatically, see “Binding Automatic Route and NHTB Table Entries” on page 288.

Setting VPNs on a Tunnel Interface to Overlapping Subnets

In this example, you bind three route-based AutoKey IKE VPN tunnels—vpn1, vpn2,
and vpn3—to a single tunnel interface—tunnel.1. The tunnels lead from Device A to
three remote peers—peer1, peer2, and peer3. You manually add both the route
table and NHTB table entries on Device A for all three peers. To see a configuration
that provides an automatic means of populating the route and NHTB tables, see
“Binding Automatic Route and NHTB Table Entries” on page 288.

Figure 73: Tunnel.1 interface Bound to Three VPN Tunnels

vpn1
IKE gateway: peer1, 2.2.2.2
Trust zone for Device A not shown. Untrust Zone remote peer’s tunnel interface: 10.0.2.1
peer1
LAN vpn2
vpn1
Device A IKE gateway: peer2, 3.3.3.3
vpn2 peer2
LAN remote peer’s
vpn3 tunnel interface: 10.0.4.1
peer3
LAN
Trust Zone tunnel.1 ethernet3 vpn3
ethernet1 10.0.0.1/30 1.1.1.1/24 IKE gateway: peer3, 4.4.4.4
10.1.1.1/24 DIP Pool 5: router
external router remote peer’s tunnel interface: 10.0.6.1
10.0.0.2 - 10.0.0.2 1.1.1.250

The VPN tunnel configurations at both ends of each tunnel use the following
parameters:

 AutoKey IKE

 Preshared key for each peer:

 peer1 uses “netscreen1”

 peer2 uses “netscreen2”

 peer3 uses “netscreen3”

 Security level predefined as “Compatible” for both Phase 1 and Phase 2

proposals. (For details about these proposals, see “Tunnel Negotiation” on
page 8.)

All security zones and interfaces on each device are in the trust-vr virtual routing
domain for that device.

270  Multiple Tunnels per Tunnel Interface

 Chapter 7: Advanced Virtual Private Network Features

This example uses the same address space—10.1.1.0/24—for every LAN to show
how you can use Source Network Address Translation (NAT-src) and Destination
Network Address Translation (NAT-dst) to overcome addressing conflicts among
IPSec peers. For more information about NAT-src and NAT-dst, see Volume 8: Address
Translation.

WebUI (Device A)
1. Interfaces
Network > Interfaces > Edit (for ethernet1): Enter the following, then click
Apply:

Zone Name: Trust

Static IP: (select this option when present)
IP Address/Netmask: 10.1.1.1/24
Enter the following, then click OK:
Interface Mode: NAT

Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:

Zone Name: Untrust

Static IP: (select this option when present)
IP Address/Netmask: 1.1.1.1/24

Network > Interfaces > New Tunnel IF: Enter the following, then click OK:

Tunnel Interface Name: tunnel.1

Zone (VR): Untrust (trust-vr)
Fixed IP: (select)
IP Address / Netmask: 10.0.0.1/30

Network > Interfaces > Edit (for tunnel.1) > DIP > New: Enter the following,
then click OK:

ID: 5
IP Address Range: (select), 10.0.0.2 ~ 10.0.0.2
Port Translation: (select)
In the same subnet as the interface IP or its secondary IPs: (select)
2. Addresses
Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: corp

IP Address/Domain Name:
IP/Netmask: (select), 10.1.1.0/24
Zone: Trust

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: oda1

IP Address/Domain Name:
IP/Netmask: (select), 10.0.1.0/24
Zone: Trust

Multiple Tunnels per Tunnel Interface  271

 Concepts & Examples ScreenOS Reference Guide

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: peers

IP Address/Domain Name:
IP/Netmask: (select), 10.0.0.0/16
Zone: Untrust
3. VPNs
VPNs > AutoKey IKE > New: Enter the following, then click OK:

VPN Name: vpn1

Security Level: Compatible
Remote Gateway: Create a Simple Gateway: (select)
Gateway Name: peer1
Type: Static IP: (select), Address/Hostname: 2.2.2.2
Preshared Key: netscreen1
Security Level: Compatible
Outgoing Interface: ethernet3

> Advanced: Enter the following advanced settings, then click Return to
return to the basic AutoKey IKE configuration page:

Bind to: Tunnel Interface, tunnel.1

Proxy-ID: (select)
Local IP / Netmask: 0.0.0.0/0
Remote IP / Netmask: 0.0.0.0/0
Service: ANY

VPNs > AutoKey IKE > New: Enter the following, then click OK:

VPN Name: vpn2

Security Level: Compatible
Remote Gateway: Create a Simple Gateway: (select)
Gateway Name: peer2
Type: Static IP: (select), Address/Hostname: 3.3.3.3
Preshared Key: netscreen2
Security Level: Compatible
Outgoing Interface: ethernet3

> Advanced: Enter the following advanced settings, then click Return to
return to the basic AutoKey IKE configuration page:

Bind to: Tunnel Interface, tunnel.1

Proxy-ID: (select)
Local IP / Netmask: 0.0.0.0/0
Remote IP / Netmask: 0.0.0.0/0
Service: ANY

VPNs > AutoKey IKE > New: Enter the following, then click OK:

VPN Name: vpn3

Security Level: Compatible
Remote Gateway: Create a Simple Gateway: (select)
Gateway Name: peer3
Type: Static IP: (select), Address/Hostname: 4.4.4.4
Preshared Key: netscreen3

272  Multiple Tunnels per Tunnel Interface

 Chapter 7: Advanced Virtual Private Network Features

Security Level: Compatible

Outgoing Interface: ethernet3

> Advanced: Enter the following advanced settings, then click Return to
return to the basic AutoKey IKE configuration page:

Bind to: Tunnel Interface, tunnel.1

Proxy-ID: (select)
Local IP / Netmask: 0.0.0.0/0
Remote IP / Netmask: 0.0.0.0/0
Service: ANY
4. Routes
Network > Routing > Routing Entries > (trust-vr) New: Enter the following,
then click OK:

Network Address / Netmask: 0.0.0.0/0

Gateway: (select)
Interface: ethernet3
Gateway IP Address: 1.1.1.250

Network > Routing > Routing Entries > (trust-vr) New: Enter the following,
then click OK:

Network Address / Netmask: 10.0.1.0/24

Gateway: (select)
Interface: ethernet1
Gateway IP Address: 0.0.0.0

Network > Routing > Routing Entries > (trust-vr) New: Enter the following,
then click OK:

Network Address / Netmask: 10.0.3.0/24

Gateway: (select)
Interface: tunnel.1
Gateway IP Address: 10.0.2.1

Network > Routing > Routing Entries > (trust-vr) New: Enter the following,
then click OK:

Network Address / Netmask: 10.0.2.2/32

Gateway: (select)
Interface: tunnel.1
Gateway IP Address: 10.0.2.1

Network > Routing > Routing Entries > (trust-vr) New: Enter the following,
then click OK:

Network Address / Netmask: 10.0.5.0/24

Gateway: (select)
Interface: tunnel.1
Gateway IP Address: 10.0.4.1

Network > Routing > Routing Entries > (trust-vr) New: Enter the following,
then click OK:

Network Address / Netmask: 10.0.4.2/32

Gateway: (select)

Multiple Tunnels per Tunnel Interface  273

 Concepts & Examples ScreenOS Reference Guide

Interface: tunnel.1
Gateway IP Address: 10.0.4.1

Network > Routing > Routing Entries > (trust-vr) New: Enter the following,
then click OK:

Network Address / Netmask: 10.0.7.0/24

Gateway: (select)
Interface: tunnel.1
Gateway IP Address: 10.0.6.1

Network > Routing > Routing Entries > (trust-vr) New: Enter the following,
then click OK:

Network Address / Netmask: 10.0.6.2/32

Gateway: (select)
Interface: tunnel.1
Gateway IP Address: 10.0.6.1

Network > Routing > Routing Entries > (trust-vr) New: Enter the following,
then click OK:

Network Address / Netmask: 10.0.0.0/16

Gateway: (select)
Interface: null
Gateway IP Address: 0.0.0.0
Metric: 10

Network > Interfaces > Edit (for tunnel.1) > NHTB > New: Enter the
following, then click Add:

New Next Hop Entry:

IP Address: 10.0.2.1
VPN: vpn1

Network > Interfaces > Edit (for tunnel.1) > NHTB: Enter the following, then
click Add:

New Next Hop Entry:

IP Address: 10.0.4.1
VPN: vpn2

Network > Interfaces > Edit (for tunnel.1) > NHTB: Enter the following, then
click Add:

New Next Hop Entry:

IP Address: 10.0.6.1
VPN: vpn3
5. Policies
Policies > (From: Trust, To: Untrust) New: Enter the following, then click OK:

Source Address:
Address Book: (select), corp
Destination Address:
Address Book: (select), peers
Service: Any

274  Multiple Tunnels per Tunnel Interface

 Chapter 7: Advanced Virtual Private Network Features

Action: Permit
Position at Top: (select)

> Advanced: Enter the following advanced settings, then click Return to
return to the basic Policy configuration page:

NAT:
Source Translation: (select)
DIP On: 5 (10.0.0.2–10.0.0.2)/X-late

Policies > (From: Untrust, To: Trust) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), peers
Destination Address:
Address Book Entry: (select), oda1
Service: Any
Action: Permit
Position at Top: (select)

> Advanced: Enter the following advanced settings, then click Return to
return to the basic Policy configuration page:

NAT:
Destination Translation: (select)
Translate to IP Range: (select), 10.1.1.0 - 10.1.1.254

CLI (Device A)
1. Interfaces
set interface ethernet1 zone trust
set interface ethernet1 ip 10.1.1.1/24
set interface ethernet3 zone untrust
set interface ethernet3 ip 1.1.1.1/24
set interface tunnel.1 zone untrust
set interface tunnel.1 ip 10.0.0.1/30
set interface tunnel.1 dip 5 10.0.0.2 10.0.0.2
2. Addresses
set address trust corp 10.1.1.0/24
set address trust oda1 10.0.1.0/24
set address untrust peers 10.0.0.0/16
3. VPNs
set ike gateway peer1 address 2.2.2.2 outgoing-interface ethernet3 preshare
netscreen1 sec-level compatible
set vpn vpn1 gateway peer1 sec-level compatible
set vpn vpn1 bind interface tunnel.1
set vpn vpn1 proxy-id local-ip 0.0.0.0/0 remote-ip 0.0.0.0/0 any
set ike gateway peer2 address 3.3.3.3 outgoing-interface ethernet3 preshare
netscreen2 sec-level compatible
set vpn vpn2 gateway peer2 sec-level compatible
set vpn vpn2 bind interface tunnel.1
set vpn vpn2 proxy-id local-ip 0.0.0.0/0 remote-ip 0.0.0.0/0 any
set ike gateway peer3 address 4.4.4.4 outgoing-interface ethernet3 preshare
netscreen3 sec-level compatible
set vpn vpn3 gateway peer3 sec-level compatible
set vpn vpn3 bind interface tunnel.1

Multiple Tunnels per Tunnel Interface  275

 Concepts & Examples ScreenOS Reference Guide

set vpn vpn3 proxy-id local-ip 0.0.0.0/0 remote-ip 0.0.0.0/0 any

4. Routes
set vrouter trust-vr route 0.0.0.0/0 interface ethernet3 gateway 1.1.1.250
set vrouter trust-vr route 10.0.1.0/24 interface ethernet1
set vrouter trust-vr route 10.0.3.0/24 interface tunnel.1 gateway 10.0.2.1
set vrouter trust-vr route 10.0.2.2/32 interface tunnel.1 gateway 10.0.2.1
set vrouter trust-vr route 10.0.5.0/24 interface tunnel.1 gateway 10.0.4.1
set vrouter trust-vr route 10.0.4.2/32 interface tunnel.1 gateway 10.0.4.1
set vrouter trust-vr route 10.0.7.0/24 interface tunnel.1 gateway 10.0.6.1
set vrouter trust-vr route 10.0.6.2/32 interface tunnel.1 gateway 10.0.6.1
set vrouter trust-vr route 10.0.0.0/16 interface null metric 10
set interface tunnel.1 nhtb 10.0.2.1 vpn vpn1
set interface tunnel.1 nhtb 10.0.4.1 vpn vpn2
set interface tunnel.1 nhtb 10.0.6.1 vpn vpn3
5. Policies
set policy from trust to untrust corp peers any nat src dip-id 5 permit
set policy from untrust to trust peers oda1 any nat dst ip 10.1.1.0 10.1.1.254
permit
save
Peer1
The following configuration, as illustrated in Figure 74, is what the remote admin
for the security device at the peer1 site must enter to create a VPN tunnel to
Device A at the corporate site. The remote admin configures the security device to
perform source and destination NAT (NAT-src and NAT-dst) because the internal
addresses are in the same address space as those in the corporate LAN: 10.1.1.0/24.
Peer1 performs NAT-src using DIP pool 6 to translate all internal source addresses to
10.0.2.2 when sending traffic through VPN1 to Device A. Peer1 performs NAT-dst
on VPN traffic sent from Device A, translating addresses from 10.0.3.0/24 to
10.1.1.0/24 with address shifting in effect.

Figure 74: Peer1 Performing NAT-Dst

ethernet3 tunnel.10
2.2.2.2/24 10.0.2.1/30 NAT-dst Range NAT-dst from
external router DIP Pool 6 10.0.2.2 - 10.0.3.0 – 10.0.3.255 10.0.3.0 – 10.0.3.255
2.2.2.250 10.0.2.2 to
ethernet1 10.1.1.0 – 10.1.1.255
10.1.1.1/24 with address shifting
Untrust Zone
Peer1
Trust Zone
vpn1 from
Device A
LAN
10.1.1.0/24

NOTE: For more information about NAT-src and NAT-dst, see Volume 8: Address
Translation.

276  Multiple Tunnels per Tunnel Interface

 Chapter 7: Advanced Virtual Private Network Features

WebUI (Peer1)
1. Interfaces
Network > Interfaces > Edit (for ethernet1): Enter the following, then click
Apply:

Zone Name: Trust

Static IP: (select this option when present)
IP Address/Netmask: 10.1.1.1/24
Enter the following, then click OK:
Interface Mode: NAT

Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:

Zone Name: Untrust

Static IP: (select this option when present)
IP Address/Netmask: 2.2.2.2/24

Network > Interfaces > New Tunnel IF: Enter the following, then click OK:

Tunnel Interface Name: tunnel.10

Zone (VR): Untrust (trust-vr)
Fixed IP: (select)
IP Address / Netmask: 10.0.2.1/30

Network > Interfaces > Edit (for tunnel.10) > DIP > New: Enter the
following, then click OK:

ID: 6
IP Address Range: (select), 10.0.2.2 ~ 10.0.2.2
Port Translation: (select)
In the same subnet as the interface IP or its secondary IPs: (select)
2. Addresses
Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: lan

IP Address/Domain Name:
IP/Netmask: (select), 10.1.1.0/24
Zone: Trust

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: oda2

IP Address/Domain Name:
IP/Netmask: (select), 10.0.3.0/24
Zone: Trust

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: to_corp

IP Address/Domain Name:
IP/Netmask: (select), 10.0.1.0/24
Zone: Untrust

Multiple Tunnels per Tunnel Interface  277

 Concepts & Examples ScreenOS Reference Guide

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: fr_corp

IP Address/Domain Name:
IP/Netmask: (select), 10.0.0.2/32
Zone: Untrust
3. VPN
VPNs > AutoKey IKE > New: Enter the following, then click OK:

VPN Name: vpn1

Security Level: Compatible
Remote Gateway: Create a Simple Gateway: (select)
Gateway Name: corp
Type: Static IP: (select), Address/Hostname: 1.1.1.1
Preshared Key: netscreen1
Security Level: Compatible
Outgoing Interface: ethernet3

> Advanced: Enter the following advanced settings, then click Return to
return to the basic AutoKey IKE configuration page:

Bind to: Tunnel Interface, tunnel.10

Proxy-ID: (select)
Local IP / Netmask: 0.0.0.0/0
Remote IP / Netmask: 0.0.0.0/0
Service: ANY
4. Routes
Network > Routing > Routing Entries > (trust-vr) New: Enter the following,
then click OK:

Network Address / Netmask: 0.0.0.0/0

Gateway: (select)
Interface: ethernet3
Gateway IP Address: 2.2.2.250
Metric: 1

Network > Routing > Routing Entries > (trust-vr) New: Enter the following,
then click OK:

Network Address / Netmask: 10.0.3.0/24

Gateway: (select)
Interface: ethernet1
Gateway IP Address: 0.0.0.0
Metric: 1

Network > Routing > Routing Entries > (trust-vr) New: Enter the following,
then click OK:

Network Address / Netmask: 10.0.0.0/8

Gateway: (select)
Interface: tunnel.10
Gateway IP Address: 0.0.0.0
Metric: 10

278  Multiple Tunnels per Tunnel Interface

 Chapter 7: Advanced Virtual Private Network Features

Network > Routing > Routing Entries > (trust-vr) New: Enter the following,
then click OK:

Network Address / Netmask: 10.0.0.0/8

Gateway: (select)
Interface: null
Gateway IP Address: 0.0.0.0
Metric: 12
5. Policies
Policies > (From: Untrust, To: Trust) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), fr_corp
Destination Address:
Address Book Entry: (select), oda2
Service: Any
Action: Permit
Position at Top: (select)

> Advanced: Enter the following advanced settings, then click Return to
return to the basic Policy configuration page:

NAT:
Destination Translation: (select)
Translate to IP Range: (select), 10.1.1.0 - 10.1.1.254

Policies > (From: Trust, To: Untrust) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), lan
Destination Address:
Address Book Entry: (select), to_corp
Service: Any
Action: Permit
Position at Top: (select)

> Advanced: Enter the following advanced settings, then click Return to
return to the basic Policy configuration page:

NAT:
Source Translation: (select)
DIP On: 6 (10.0.2.2–10.0.2.2)/X-late

CLI (Peer1)
1. Interfaces
set interface ethernet1 zone trust
set interface ethernet1 ip 10.1.1.1/24
set interface ethernet3 zone untrust
set interface ethernet3 ip 2.2.2.2/24
set interface tunnel.10 zone untrust
set interface tunnel.10 ip 10.0.2.1/30
set interface tunnel.10 dip 6 10.0.2.2 10.0.2.2

Multiple Tunnels per Tunnel Interface  279

 Concepts & Examples ScreenOS Reference Guide

2. Addresses
set address trust lan 10.1.1.0/24
set address trust oda2 10.0.3.0/24
set address untrust to_corp 10.0.1.0/24
set address untrust fr_corp 10.0.0.2/32
3. VPN
set ike gateway corp address 1.1.1.1 outgoing-interface ethernet3 preshare
netscreen1 sec-level compatible
set vpn vpn1 gateway corp sec-level compatible
set vpn vpn1 bind interface tunnel.10
set vpn vpn1 proxy-id local-ip 0.0.0.0/0 remote-ip 0.0.0.0/0 any
4. Routes
set vrouter trust-vr route 0.0.0.0/0 interface ethernet3 gateway 2.2.2.250
metric 1
set vrouter trust-vr route 10.0.3.0/24 interface ethernet1 metric 1
set vrouter trust-vr route 10.0.0.0/8 interface tunnel.10 metric 10
set vrouter trust-vr route 10.0.0.0/8 interface null metric 12
5. Policies
set policy from trust to untrust lan to_corp any nat src dip-id 6 permit
set policy from untrust to trust fr_corp oda2 any nat dst ip 10.1.1.0 10.1.1.254
permit
save
Peer2
The following configuration, as illustrated in Figure 75, is what the remote admin
for the security device at the peer2 site must enter to create a VPN tunnel to
Device A at the corporate site. The remote admin configures the security device to
perform source and destination NAT (NAT-src and NAT-dst) because the internal
addresses are in the same address space as those in the corporate LAN: 10.1.1.0/24.
Peer2 performs NAT-src using DIP pool 7 to translate all internal source addresses to
10.0.4.2 when sending traffic through VPN2 to Device A. Peer2 performs NAT-dst
on VPN traffic sent from Device A, translating addresses from 10.0.5.0/24 to
10.1.1.0/24 with address shifting in effect.

Figure 75: Peer2

ethernet3 tunnel.20
10.0.4.1/30 NAT-dst Range NAT-dst from
3.3.3.3/24 10.0.5.0 – 10.0.5.255
external router DIP Pool 7 10.0.4.2 - 10.0.5.0 – 10.0.5.255
3.3.3.250 10.0.4.2 ethernet1 to
10.1.1.1/24 10.1.1.0 – 10.1.1.255
with address shifting
Untrust Zone
Peer2
vpn2 Trust Zone
from
Device A
LAN
10.1.1.0/24

NOTE: For more information about NAT-src and NAT-dst, see Volume 8: Address
Translation.

280  Multiple Tunnels per Tunnel Interface

 Chapter 7: Advanced Virtual Private Network Features

WebUI (Peer2)
1. Interfaces
Network > Interfaces > Edit (for ethernet1): Enter the following, then click
Apply:

Zone Name: Trust

Static IP: (select this option when present)
IP Address/Netmask: 10.1.1.1/24
Enter the following, then click OK:
Interface Mode: NAT

Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:

Zone Name: Untrust

Static IP: (select this option when present)
IP Address/Netmask: 3.3.3.3/24

Network > Interfaces > New Tunnel IF: Enter the following, then click OK:

Tunnel Interface Name: tunnel.20

Zone (VR): Untrust (trust-vr)
Fixed IP: (select)
IP Address / Netmask: 10.0.4.1/30

Network > Interfaces > Edit (for tunnel.20) > DIP > New: Enter the
following, then click OK:

ID: 7
IP Address Range: (select), 10.0.4.2 ~ 10.0.4.2
Port Translation: (select)
In the same subnet as the interface IP or its secondary IPs: (select)
2. Addresses
Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: lan

IP Address/Domain Name:
IP/Netmask: (select), 10.1.1.0/24
Zone: Trust

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: oda3

IP Address/Domain Name:
IP/Netmask: (select), 10.0.5.0/24
Zone: Trust

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: to_corp

IP Address/Domain Name:
IP/Netmask: (select), 10.0.1.0/24
Zone: Untrust

Multiple Tunnels per Tunnel Interface  281

 Concepts & Examples ScreenOS Reference Guide

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: fr_corp

IP Address/Domain Name:
IP/Netmask: (select), 10.0.0.2/32
Zone: Untrust
3. VPN
VPNs > AutoKey IKE > New: Enter the following, then click OK:

VPN Name: vpn2

Security Level: Compatible
Remote Gateway: Create a Simple Gateway: (select)
Gateway Name: corp
Type: Static IP: (select), Address/Hostname: 1.1.1.1
Preshared Key: netscreen2
Security Level: Compatible
Outgoing Interface: ethernet3

> Advanced: Enter the following advanced settings, then click Return to
return to the basic AutoKey IKE configuration page:

Bind to: Tunnel Interface, tunnel.20

Proxy-ID: (select)
Local IP / Netmask: 0.0.0.0/0
Remote IP / Netmask: 0.0.0.0/0
Service: ANY
4. Routes
Network > Routing > Routing Entries > (trust-vr) New: Enter the following,
then click OK:

Network Address / Netmask: 0.0.0.0/0

Gateway: (select)
Interface: ethernet3
Gateway IP Address: 3.3.3.250
Metric: 1

Network > Routing > Routing Entries > (trust-vr) New: Enter the following,
then click OK:

Network Address / Netmask: 10.0.5.0/24

Gateway: (select)
Interface: ethernet1
Gateway IP Address: 0.0.0.0
Metric: 1

Network > Routing > Routing Entries > (trust-vr) New: Enter the following,
then click OK:

Network Address / Netmask: 10.0.1.0/24

Gateway: (select)
Interface: tunnel.20
Gateway IP Address: 0.0.0.0
Metric: 10

282  Multiple Tunnels per Tunnel Interface

 Chapter 7: Advanced Virtual Private Network Features

Network > Routing > Routing Entries > (trust-vr) New: Enter the following,
then click OK:

Network Address / Netmask: 10.0.1.0/24

Gateway: (select)
Interface: null
Gateway IP Address: 0.0.0.0
Metric: 12
5. Policies
Policies > (From: Trust, To: Untrust) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), lan
Destination Address:
Address Book Entry: (select), to_corp
Service: Any
Action: Permit
Position at Top: (select)

> Advanced: Enter the following advanced settings, then click Return to
return to the basic Policy configuration page:

NAT:
Source Translation: (select)
DIP On: 7 (10.0.4.2–10.0.4.2)/X-late

Policies > (From: Untrust, To: Trust) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), fr_corp
Destination Address:
Address Book Entry: (select), oda3
Service: Any
Action: Permit
Position at Top: (select)

> Advanced: Enter the following advanced settings, then click Return to
return to the basic Policy configuration page:

NAT:
Destination Translation: (select)
Translate to IP Range: (select), 10.1.1.0 - 10.1.1.254

CLI (Peer2)
1. Interfaces
set interface ethernet1 zone trust
set interface ethernet1 ip 10.1.1.1/24
set interface ethernet3 zone untrust
set interface ethernet3 ip 3.3.3.3/24
set interface tunnel.20 zone untrust
set interface tunnel.20 ip 10.0.4.1/30
set interface tunnel.20 dip 7 10.0.4.2 10.0.4.2

Multiple Tunnels per Tunnel Interface  283

 Concepts & Examples ScreenOS Reference Guide

2. Addresses
set address trust lan 10.1.1.0/24
set address trust oda3 10.0.5.0/24
set address untrust to_corp 10.0.1.0/24
set address untrust fr_corp 10.0.0.2/32
3. VPN
set ike gateway corp address 1.1.1.1 outgoing-interface ethernet3 preshare
netscreen2 sec-level compatible
set vpn vpn2 gateway corp sec-level compatible
set vpn vpn2 bind interface tunnel.20
set vpn vpn2 proxy-id local-ip 0.0.0.0/0 remote-ip 0.0.0.0/0 any
4. Routes
set vrouter trust-vr route 0.0.0.0/0 interface ethernet3 gateway 3.3.3.250
metric 1
set vrouter trust-vr route 10.0.5.0/24 interface ethernet1 metric 1
set vrouter trust-vr route 10.0.0.0/8 interface tunnel.20 metric 10
set vrouter trust-vr route 10.0.0.0/8 interface null metric 12
5. Policies
set policy from trust to untrust lan to_corp any nat src dip-id 7 permit
set policy from untrust to trust fr_corp oda3 any nat dst ip 10.1.1.0 10.1.1.254
permit
save
Peer3
The following configuration, as illustrated in Figure 76, is what the remote admin
for the security device at the peer3 site must enter to create a VPN tunnel to
Device A at the corporate site. The remote admin configures the security device to
perform source and destination NAT (NAT-src and NAT-dst) because the internal
addresses are in the same address space as those in the corporate LAN: 10.1.1.0/24.
Peer3 performs NAT-src using DIP pool 8 to translate all internal source addresses to
10.0.6.2 when sending traffic through VPN3 to Device A. Peer3 performs NAT-dst
on VPN traffic sent from Device A, translating addresses from 10.0.7.0/24 to
10.1.1.0/24 with address shifting in effect.

Figure 76: Peer3

ethernet3
4.4.4.4/24 tunnel.30 NAT-dst Range
external router 10.0.6.1/30 NAT-dst from
DIP Pool 8 10.0.7.0 – 10.0.7.255 10.0.7.0 – 10.0.7.255
4.4.4.250
vpn2 from 10.0.6.2 - 10.0.6.2 to
Device A Untrust Zone ethernet1 10.1.1.0 – 10.1.1.255
10.1.1.1/24 with address shifting
Peer3
Trust Zone

LAN
10.1.1.0/24

NOTE: For more information about NAT-dst, see Volume 8: Address Translation.

284  Multiple Tunnels per Tunnel Interface

 Chapter 7: Advanced Virtual Private Network Features

WebUI (Peer3)
1. Interfaces
Network > Interfaces > Edit (for ethernet1): Enter the following, then click
Apply:

Zone Name: Trust

Static IP: (select this option when present)
IP Address/Netmask: 10.1.1.1/24
Enter the following, then click OK:
Interface Mode: NAT

Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:

Zone Name: Untrust

Static IP: (select this option when present)
IP Address/Netmask: 4.4.4.4/24

Network > Interfaces > New Tunnel IF: Enter the following, then click OK:

Tunnel Interface Name: tunnel.30

Zone (VR): Untrust (trust-vr)
Fixed IP: (select)
IP Address / Netmask: 10.0.6.1/30

Network > Interfaces > Edit (for tunnel.320) > DIP > New: Enter the
following, then click OK:

ID: 7
IP Address Range: (select), 10.0.6.2 ~ 10.0.6.2
Port Translation: (select)
In the same subnet as the interface IP or its secondary IPs: (select)
2. Addresses
Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: lan

IP Address/Domain Name:
IP/Netmask: (select), 10.1.1.0/24
Zone: Trust

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: oda4

IP Address/Domain Name:
IP/Netmask: (select), 10.0.7.0/24
Zone: Trust

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: to_corp

IP Address/Domain Name:
IP/Netmask: (select), 10.0.1.0/24
Zone: Untrust

Multiple Tunnels per Tunnel Interface  285

 Concepts & Examples ScreenOS Reference Guide

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: fr_corp

IP Address/Domain Name:
IP/Netmask: (select), 10.0.0.2/32
Zone: Untrust
3. VPN
VPNs > AutoKey IKE > New: Enter the following, then click OK:

VPN Name: vpn3

Security Level: Compatible
Remote Gateway: Create a Simple Gateway: (select)
Gateway Name: corp
Type: Static IP: (select), Address/Hostname: 1.1.1.1
Preshared Key: netscreen3
Security Level: Compatible
Outgoing Interface: ethernet3

> Advanced: Enter the following advanced settings, then click Return to
return to the basic AutoKey IKE configuration page:

Bind to: Tunnel Interface, tunnel.30

Proxy-ID: (select)
Local IP / Netmask: 0.0.0.0/0
Remote IP / Netmask: 0.0.0.0/0
Service: ANY
4. Routes
Network > Routing > Routing Entries > (trust-vr) New: Enter the following,
then click OK:

Network Address / Netmask: 0.0.0.0/0

Gateway: (select)
Interface: ethernet3
Gateway IP Address: 4.4.4.250
Metric: 1

Network > Routing > Routing Entries > (trust-vr) New: Enter the following,
then click OK:

Network Address / Netmask: 10.0.7.0/24

Gateway: (select)
Interface: ethernet1
Gateway IP Address: 0.0.0.0
Metric: 1

Network > Routing > Routing Entries > (trust-vr) New: Enter the following,
then click OK:

Network Address / Netmask: 10.0.0.0/8

Gateway: (select)
Interface: tunnel.20
Gateway IP Address: 10.0.0.1
Metric: 10

286  Multiple Tunnels per Tunnel Interface

 Chapter 7: Advanced Virtual Private Network Features

Network > Routing > Routing Entries > (trust-vr) New: Enter the following,
then click OK:

Network Address / Netmask: 10.0.0.0/8

Gateway: (select)
Interface: null
Gateway IP Address: 10.0.0.1
Metric: 12
5. Policies
Policies > (From: Trust, To: Untrust) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), lan
Destination Address:
Address Book Entry: (select), to_corp
Service: Any
Action: Permit
Position at Top: (select)

> Advanced: Enter the following advanced settings, then click Return to
return to the basic Policy configuration page:

NAT:
Source Translation: (select)
DIP On: 8 (10.0.6.2–10.0.6.2)/X-late

Policies > (From: Untrust, To: Trust) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), fr_corp
Destination Address:
Address Book Entry: (select), oda4
Service: Any
Action: Permit
Position at Top: (select)

> Advanced: Enter the following advanced settings, then click Return to
return to the basic Policy configuration page:

NAT:
Destination Translation: (select)
Translate to IP Range: (select), 10.1.1.0 - 10.1.1.254

CLI (Peer3)
1. Interfaces
set interface ethernet1 zone trust
set interface ethernet1 ip 10.1.1.1/24
set interface ethernet3 zone untrust
set interface ethernet3 ip 4.4.4.4/24
set interface tunnel.30 zone untrust
set interface tunnel.30 ip 10.0.6.1/30
set interface tunnel.30 dip 8 10.0.6.2 10.0.6.2

Multiple Tunnels per Tunnel Interface  287

 Concepts & Examples ScreenOS Reference Guide

2. Addresses
set address trust lan 10.1.1.0/24
set address trust oda4 10.0.7.0/24
set address untrust to_corp 10.0.1.0/24
set address untrust fr_corp 10.0.0.2/32
3. VPN
set ike gateway corp address 1.1.1.1 outgoing-interface ethernet3 preshare
netscreen3 sec-level compatible
set vpn vpn3 gateway corp sec-level compatible
set vpn vpn3 bind interface tunnel.30
set vpn vpn3 proxy-id local-ip 0.0.0.0/0 remote-ip 0.0.0.0/0 any
4. Routes
set vrouter trust-vr route 0.0.0.0/0 interface ethernet3 gateway 3.3.3.250 metric
1
set vrouter trust-vr route 10.0.7.0/24 interface ethernet1 metric 1
set vrouter trust-vr route 10.0.0.0/8 interface tunnel.30 metric 10
set vrouter trust-vr route 10.0.0.0/8 interface null metric 12
5. Policies
set policy from trust to untrust lan to_corp any nat src dip-id 8 permit
set policy from untrust to trust fr_corp oda4 any nat dst ip 10.1.1.0 10.1.1.254
permit
save

Binding Automatic Route and NHTB Table Entries

In Figure 77 on page 289, you bind two route-based AutoKey IKE VPN
tunnels—vpn1, vpn2—to a single tunnel interface—tunnel.1 on Device A at the
corporate site. The network that each remote peer protects has multiple routes
behind the connected route. Using Border Gateway Protocol (BGP), the peers
communicate their routes to Device A. This example permits VPN traffic from the
corporate site behind Device A to the peer sites.

NOTE: You can also use Open Shortest Path First (OSPF) instead of BGP as the routing
protocol in this example. See “Using OSPF for Automatic Route Table Entries” on
page 300 for the OSPF configurations.

288  Multiple Tunnels per Tunnel Interface

 Chapter 7: Advanced Virtual Private Network Features

Figure 77: Automatic Route and NHTB Table Entries (Device A)

vpn1
The tunnel.1 interface on Device A is The routes behind each peer are
IKE gateway: peer1, 2.2.2.2
bound to two VPN tunnels. unknown to Device A until the
remote peer’s tunnel interface: 2.3.3.1
peers use BGP to send them.

Untrust Zone

peer1
vpn1
Device A

peer2
vpn2
Trust Zone tunnel.1 ethernet3
ethernet1 10.0.0.1/30 1.1.1.1/24
10.1.1.1/24 external router
1.1.1.250

vpn2
IKE gateway: peer2, 3.3.3.3
remote peer’s tunnel interface: 3.4.4.1

The VPN tunnel configurations at both ends of each tunnel use the following
parameters: AutoKey IKE, preshared key (peer1: “netscreen1”, peer2:
“netscreen2”), and the security level predefined as “Compatible” for both Phase 1
and Phase 2 proposals. (For details about these proposals, see “Tunnel Negotiation”
on page 8.)

By configuring the following two features, you can enable Device A to populate its
NHTB and route tables automatically:

 VPN monitoring with the rekey option (or the IKE heartbeats reconnect option)

 BGP dynamic routing on tunnel.1

NOTE: If you are running a dynamic routing protocol on the tunnel interfaces, traffic
generated by the protocol can trigger IKE negotiations even without enabling VPN
monitoring with the rekey option or enabling the IKE heartbeat reconnect option.
Still, Juniper Networks recommends that you not rely on dynamic routing traffic to
trigger IKE negotiations. Instead use VPN monitoring with the rekey option or the
IKE heartbeat reconnect option.

If you are running BGP on the tunnel interfaces, the BGP-generated traffic can
trigger IKE negotiations even without enabling VPN monitoring with the rekey
option or enabling the IKE heartbeat reconnect option. Still, Juniper Networks
recommends that you not rely on BGP traffic to trigger IKE negotiations. Instead,
use VPN monitoring with the rekey option or the IKE heartbeat reconnect option.

When you enable VPN monitoring with the rekey option for an AutoKey IKE VPN
tunnel, Device A establishes a VPN connection with its remote peer as soon as you
and the admin at the remote site finish configuring the tunnel. The devices do not
wait for user-generated VPN traffic to perform IKE negotiations. During Phase 2
negotiations, the security devices exchange their tunnel interface IP address, so that
Device A can automatically make a VPN-to-next-hop mapping in its NHTB table.

Multiple Tunnels per Tunnel Interface  289

 Concepts & Examples ScreenOS Reference Guide

The rekey option ensures that when the Phase 1 and Phase 2 key lifetimes expire,
the devices automatically negotiate the generation of new keys without the need for
human intervention. VPN monitoring with the rekey option enabled essentially
provides a means for keeping a VPN tunnel up continually, even when there is no
user-generated traffic. This is necessary so that the BGP dynamic routing instances
that you and the remote admins create and enable on the tunnel interfaces at both
ends of the tunnels can send routing information to Device A and automatically
populate its route table with the routes it needs to direct traffic through the VPN
tunnel before those routes are required for user-generated traffic. (The admins at
the peer sites still need to enter a single static route to the rest of the virtual private
network through the tunnel interface at each respective site.)

You enter a default route and static routes on Device A to reach its BGP neighbors
through the correct VPN tunnels. All security zones and interfaces on each device
are in the trust-vr virtual routing domain for that device.

WebUI (Device A)
1. Interfaces
Network > Interfaces > Edit (for ethernet1): Enter the following, then click
Apply:

Zone Name: Trust

Static IP: (select this option when present)
IP Address/Netmask: 10.1.1.1/24
Enter the following, then click OK:
Interface Mode: NAT

Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:

Zone Name: Untrust

Static IP: (select this option when present)
IP Address/Netmask: 1.1.1.1/24

Network > Interfaces > New Tunnel IF: Enter the following, then click OK:

Tunnel Interface Name: tunnel.1

Zone (VR): Untrust (trust-vr)
Fixed IP: (select)
IP Address / Netmask: 10.0.0.1/30

290  Multiple Tunnels per Tunnel Interface

 Chapter 7: Advanced Virtual Private Network Features

2. VPNs
VPNs > AutoKey IKE > New: Enter the following, then click OK:

VPN Name: vpn1

Security Level: Compatible
Remote Gateway: Create a Simple Gateway: (select)
Gateway Name: peer1
Type: Static IP: (select), Address/Hostname: 2.2.2.2
Preshared Key: netscreen1
Security Level: Compatible
Outgoing Interface: ethernet3

> Advanced: Enter the following advanced settings, then click Return to return
to the basic AutoKey IKE configuration page:

Bind to: Tunnel Interface, tunnel.1

Proxy-ID: (select)
Local IP / Netmask: 0.0.0.0/0
Remote IP / Netmask: 0.0.0.0/0
Service: ANY
VPN Monitor: (select)
Rekey: (select)

NOTE: Leave the Source Interface and Destination IP options at their default settings. For
information about these options, see “VPN Monitoring” on page 252.

VPNs > AutoKey IKE > New: Enter the following, then click OK:

VPN Name: vpn2

Security Level: Compatible
Remote Gateway: Create a Simple Gateway: (select)
Gateway Name: peer2
Type: Static IP: (select), Address/Hostname: 3.3.3.3
Preshared Key: netscreen2
Security Level: Compatible
Outgoing Interface: ethernet3

> Advanced: Enter the following advanced settings, then click Return to
return to the basic AutoKey IKE configuration page:

Bind to: Tunnel Interface, tunnel.1

Proxy-ID: (select)
Local IP / Netmask: 0.0.0.0/0
Remote IP / Netmask: 0.0.0.0/0
Service: ANY
VPN Monitor: (select)
Rekey: (select)

NOTE: Leave the Source Interface and Destination IP options at their default settings. For
information about these options, see “VPN Monitoring” on page 252.

Multiple Tunnels per Tunnel Interface  291

 Concepts & Examples ScreenOS Reference Guide

3. Static Route
Network > Routing > Routing Entries > (trust-vr) New: Enter the following,
then click OK:

Network Address / Netmask: 0.0.0.0/0

Gateway: (select)
Interface: ethernet3
Gateway IP Address: 1.1.1.250

Network > Routing > Routing Entries > (trust-vr) New: Enter the following,
then click OK:

Network Address / Netmask: 2.3.3.1/32

Gateway: (select)
Interface: tunnel.1
Gateway IP Address: 2.3.3.1

Network > Routing > Routing Entries > (trust-vr) New: Enter the following,
then click OK:

Network Address / Netmask: 3.4.4.1/32

Gateway: (select)
Interface: tunnel.1
Gateway IP Address: 3.4.4.1
4. Dynamic Routing
Network > Routing > Virtual Routers > Edit (for trust-vr) > Create BGP
Instance: Enter the following, then click OK:

AS Number (required): 99
BGP Enabled: (select)

Network > Interfaces > Edit (for tunnel.1) > BGP: Select the Protocol BGP
check box, then click OK.

Network > Routing > Virtual Routers > Edit (for trust-vr) > Edit BGP Instance
> Neighbors: Enter the following, then click Add:

AS Number: 99
Remote IP: 2.3.3.1
Outgoing Interface: tunnel.1

Network > Routing > Virtual Routers > Edit (for trust-vr) > Edit BGP Instance
> Neighbors: Enter the following, then click Add:

AS Number: 99
Remote IP: 3.4.4.1
Outgoing Interface: tunnel.1
5. Policy
Policies > (From: Trust, To: Untrust) New: Enter the following, then click OK:

Source Address:
Address Book: (select), Any
Destination Address:
Address Book: (select), Any
Service: ANY
Action: Permit

292  Multiple Tunnels per Tunnel Interface

 Chapter 7: Advanced Virtual Private Network Features

CLI (Device A)
1. Interfaces
set interface ethernet1 zone trust
set interface ethernet1 ip 10.1.1.1/24
set interface ethernet1 nat
set interface ethernet3 zone untrust
set interface ethernet3 ip 1.1.1.1/24
set interface tunnel.1 zone untrust
set interface tunnel.1 ip 10.0.0.1/30
2. VPNs
set ike gateway peer1 address 2.2.2.2 outgoing-interface ethernet3 preshare
netscreen1 sec-level compatible
set vpn vpn1 gateway peer1 sec-level compatible
set vpn vpn1 bind interface tunnel.1
set vpn vpn1 proxy-id local-ip 0.0.0.0/0 remote-ip 0.0.0.0/0 any
set vpn vpn1 monitor rekey
set ike gateway peer2 address 3.3.3.3 outgoing-interface ethernet3 preshare
netscreen2 sec-level compatible
set vpn vpn2 gateway peer2 sec-level compatible
set vpn vpn2 bind interface tunnel.1
set vpn vpn2 proxy-id local-ip 0.0.0.0/0 remote-ip 0.0.0.0/0 any
set vpn vpn2 monitor rekey
3. Static Routes
set vrouter trust-vr route 0.0.0.0/0 interface ethernet3 gateway 1.1.1.250
set vrouter trust-vr route 2.3.3.1/32 interface tunnel.1 gateway 2.3.3.1
set vrouter trust-vr route 2.4.4.1/32 interface tunnel.1 gateway 2.4.4.1
4. Dynamic Routing
device-> set vrouter trust-vr protocol bgp 99
device-> set vrouter trust-vr protocol bgp enable
device-> set interface tunnel.1 protocol bgp
device-> set vrouter trust-vr
device(trust-vr)-> set protocol bgp
device(trust-vr/bgp)-> set neighbor 2.3.3.1 remote-as 99 outgoing interface
tunnel.1
device(trust-vr/bgp)-> set neighbor 2.3.3.1 enable
device(trust-vr/bgp)-> set neighbor 3.4.4.1 remote-as 99 outgoing interface
tunnel.1
device(trust-vr/bgp)-> set neighbor 3.4.4.1 enable
device(trust-vr/bgp)-> exit
device(trust-vr)-> exit
5. Policy
set policy from trust to untrust any any any permit
save
Peer1
The following configuration, as illustrated in Figure 78 on page 294, is what the
remote admin for the security device at the peer1 site must enter to create a VPN
tunnel to Device A at the corporate site. The remote admin configures the security
device to permit inbound traffic from the corporate site and to communicate
internal routes to its BGP neighbor through vpn1.

Multiple Tunnels per Tunnel Interface  293

 Concepts & Examples ScreenOS Reference Guide

Figure 78: Peer1

ethernet3
2.2.2.2/24
external router tunnel.10 ethernet1 Trust Zone
2.2.2.250 2.3.3.1/30 2.3.4.1/24
Untrust Zone

2.3.
Peer1

2.3.4.0/24
vpn2 from
Device A
2.3.

WebUI (Peer1)
1. Interfaces
Network > Interfaces > Edit (for ethernet1): Enter the following, then click
OK:

Zone Name: Trust

Static IP: (select this option when present)
IP Address/Netmask: 2.3.4.1/24

Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:

Zone Name: Untrust

Static IP: (select this option when present)
IP Address/Netmask: 2.2.2.2/24

Network > Interfaces > New Tunnel IF: Enter the following, then click OK:

Tunnel Interface Name: tunnel.10

Zone (VR): Untrust (trust-vr)
Fixed IP: (select)
IP Address / Netmask: 2.3.3.1/30
2. Address
Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: corp

IP Address/Domain Name:
IP/Netmask: (select), 10.1.1.0/24
Zone: Untrust

294  Multiple Tunnels per Tunnel Interface

 Chapter 7: Advanced Virtual Private Network Features

3. VPN
VPNs > AutoKey IKE > New: Enter the following, then click OK:

VPN Name: vpn1

Security Level: Compatible
Remote Gateway: Create a Simple Gateway: (select)
Gateway Name: corp
Type: Static IP: (select), Address/Hostname: 1.1.1.1
Preshared Key: netscreen1
Security Level: Compatible
Outgoing Interface: ethernet3

> Advanced: Enter the following advanced settings, then click Return to
return to the basic AutoKey IKE configuration page:

Bind to: Tunnel Interface, tunnel.10

Proxy-ID: (select)
Local IP / Netmask: 0.0.0.0/0
Remote IP / Netmask: 0.0.0.0/0
Service: ANY
4. Static Routes
Network > Routing > Routing Entries > (trust-vr) New: Enter the following,
then click OK:

Network Address / Netmask: 0.0.0.0/0

Gateway: (select)
Interface: ethernet3
Gateway IP Address: 2.2.2.250
Metric: 1

Network > Routing > Routing Entries > (trust-vr) New: Enter the following,
then click OK:

Network Address / Netmask: 10.1.1.0/24

Gateway: (select)
Interface: tunnel.10
Gateway IP Address: 0.0.0.0
Metric: 1
5. Dynamic Routing
Network > Routing > Virtual Routers > Edit (for trust-vr) > Create BGP
Instance: Enter the following, then click OK:

AS Number (required): 99
BGP Enabled: (select)

Network > Interfaces > Edit (for tunnel.10) > BGP: Select the Protocol BGP
check box, then click OK.

Network > Routing > Virtual Routers > Edit (for trust-vr) > Edit BGP Instance
> Neighbors: Enter the following, then click Add:

AS Number: 99
Remote IP: 10.0.0.1
Outgoing Interface: tunnel.10

Multiple Tunnels per Tunnel Interface  295

 Concepts & Examples ScreenOS Reference Guide

6. Policy
Policies > (From: Untrust, To: Trust) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), corp
Destination Address:
Address Book Entry: (select), Any
Service: ANY
Action: Permit

CLI (Peer1)
1. Interfaces
set interface ethernet1 zone trust
set interface ethernet1 ip 2.3.4.1/24
set interface ethernet3 zone untrust
set interface ethernet3 ip 2.2.2.2/24
set interface tunnel.10 zone untrust
set interface tunnel.10 ip 2.3.3.1/30
2. Address
set address untrust corp 10.1.1.0/24
3. VPN
set ike gateway corp address 1.1.1.1 outgoing-interface ethernet3 preshare
netscreen1 sec-level compatible
set vpn vpn1 gateway corp sec-level compatible
set vpn vpn1 bind interface tunnel.10
set vpn vpn1 proxy-id local-ip 0.0.0.0/0 remote-ip 0.0.0.0/0 any
4. Static Routes
set vrouter trust-vr route 0.0.0.0/0 interface ethernet3 gateway 2.2.2.250
metric 1
set vrouter trust-vr route 10.1.1.0/24 interface tunnel.10 metric 1
5. Dynamic Routing
device-> set vrouter trust-vr protocol bgp 99
device-> set vrouter trust-vr protocol bgp enable
device-> set interface tunnel.10 protocol bgp
device-> set vrouter trust-vr
device(trust-vr)-> set protocol bgp
device(trust-vr/bgp)-> set neighbor 10.0.0.1 remote-as 99 outgoing interface
tunnel.10
device(trust-vr/bgp)-> set neighbor 10.0.0.1 enable
device(trust-vr/bgp)-> exit
device(trust-vr)-> exit
6. Policy
set policy from untrust to trust corp any any permit
save

296  Multiple Tunnels per Tunnel Interface

 Chapter 7: Advanced Virtual Private Network Features

Peer2
The following configuration, as illustrated in Figure 79, is what the remote admin
for the security device at the peer2 site must enter to create a VPN tunnel to
Device A at the corporate site. The remote admin configures the security device to
permit inbound traffic from the corporate site and communicate internal routes to
its BGP neighbor through vpn2.

Figure 79: Peer2

ethernet3
3.3.3.3/24
external router tunnel.20 ethernet1 Trust Zone
3.3.3.250 3.4.4.1/30 3.4.5.1/24

vpn2 from
Device A 3.4.
Peer2

3.4.5.0/24

Untrust Zone
3.4.

WebUI (Peer2)
1. Interfaces
Network > Interfaces > Edit (for ethernet1): Enter the following, then click
OK:

Zone Name: Trust

Static IP: (select this option when present)
IP Address/Netmask: 2.3.4.1/24

Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:

Zone Name: Untrust

Static IP: (select this option when present)
IP Address/Netmask: 3.3.3.3/24

Network > Interfaces > New Tunnel IF: Enter the following, then click OK:

Tunnel Interface Name: tunnel.20

Zone (VR): Untrust (trust-vr)
Fixed IP: (select)
IP Address / Netmask: 3.4.4.1/30
2. Address
Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: corp

IP Address/Domain Name:
IP/Netmask: (select), 10.1.1.0/24
Zone: Untrust

Multiple Tunnels per Tunnel Interface  297

 Concepts & Examples ScreenOS Reference Guide

3. VPN
VPNs > AutoKey IKE > New: Enter the following, then click OK:

VPN Name: vpn2

Security Level: Compatible
Remote Gateway: Create a Simple Gateway: (select)
Gateway Name: corp
Type: Static IP: (select), Address/Hostname: 1.1.1.1
Preshared Key: netscreen2
Security Level: Compatible
Outgoing Interface: ethernet3

> Advanced: Enter the following advanced settings, then click Return to
return to the basic AutoKey IKE configuration page:

Bind to: Tunnel Interface, tunnel.20

Proxy-ID: (select)
Local IP / Netmask: 0.0.0.0/0
Remote IP / Netmask: 0.0.0.0/0
Service: ANY
4. Static Routes
Network > Routing > Routing Entries > (trust-vr) New: Enter the following,
then click OK:

Network Address / Netmask: 0.0.0.0/0

Gateway: (select)
Interface: ethernet3
Gateway IP Address: 3.3.3.250
Metric: 1

Network > Routing > Routing Entries > (trust-vr) New: Enter the following,
then click OK:

Network Address / Netmask: 10.1.1.0/24

Gateway: (select)
Interface: tunnel.20
Gateway IP Address: 0.0.0.0
Metric: 1
5. Dynamic Routing
Network > Routing > Virtual Routers > Edit (for trust-vr) > Create BGP
Instance: Enter the following, then click OK:

AS Number (required): 99
BGP Enabled: (select)

Network > Interfaces > Edit (for tunnel.20) > BGP: Select the Protocol BGP
check box, then click OK.

Network > Routing > Virtual Routers > Edit (for trust-vr) > Edit BGP Instance
> Neighbors: Enter the following, then click Add:

AS Number: 99
Remote IP: 10.0.0.1
Outgoing Interface: tunnel.20

298  Multiple Tunnels per Tunnel Interface

 Chapter 7: Advanced Virtual Private Network Features

6. Policy
Policies > (From: Untrust, To: Trust) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), corp
Destination Address:
Address Book Entry: (select), Any
Service: ANY
Action: Permit

CLI (Peer2)
1. Interfaces
set interface ethernet1 zone trust
set interface ethernet1 ip 3.4.5.1/24
set interface ethernet3 zone untrust
set interface ethernet3 ip 3.3.3.3/24
set interface tunnel.20 zone untrust
set interface tunnel.20 ip 3.4.4.1/30
2. Address
set address untrust corp 10.1.1.0/24
3. VPN
set ike gateway corp address 1.1.1.1 outgoing-interface ethernet3 preshare
netscreen2 sec-level compatible
set vpn vpn1 gateway corp sec-level compatible
set vpn vpn1 bind interface tunnel.20
set vpn vpn1 proxy-id local-ip 0.0.0.0/0 remote-ip 0.0.0.0/0 any
4. Static Routes
set vrouter trust-vr route 0.0.0.0/0 interface ethernet3 gateway 3.3.3.250
metric 1
set vrouter trust-vr route 10.1.1.0/24 interface tunnel.20 metric 1
5. Dynamic Routing
device-> set vrouter trust-vr protocol bgp 99
device-> set vrouter trust-vr protocol bgp enable
device-> set interface tunnel.20 protocol bgp
device-> set vrouter trust-vr
device(trust-vr)-> set protocol bgp
device(trust-vr/bgp)-> set neighbor 10.0.0.1 remote-as 99 outgoing interface
tunnel.20
device(trust-vr/bgp)-> set neighbor 10.0.0.1 enable
device(trust-vr/bgp)-> exit
device(trust-vr)-> exit
6. Policy
set policy from untrust to trust corp any any permit
save

Multiple Tunnels per Tunnel Interface  299

 Concepts & Examples ScreenOS Reference Guide

Using OSPF for Automatic Route Table Entries

You can also configure OSPF instead of BGP dynamic routing for the peers to
communicate routes to Device A. To allow tunnel.1 on Device A to form OSPF
adjacencies with its peers, you must configure the tunnel interface as a
point-to-multipoint interface. The OSPF dynamic routing configuration for each
device is shown below.

WebUI (Device A)
Dynamic Routing (OSPF)
Network > Routing > Virtual Routers > Edit (for trust-vr) > Create OSPF
Instance: Select OSPF Enabled, then click Apply.

Area > Configure (for area 0.0.0.0): Click << Add to move the tunnel.1
interface from the Available Interface(s) list to the Selected Interface(s) list,
then click OK.

Network > Interfaces > Edit (for tunnel.1) > OSPF: Enter the following, then
click Apply:

Bind to Area: (select), Select 0.0.0.0 from the drop down list
Protocol OSPF: Enable
Link Type: Point-to-Multipoint (select)

CLI (Device A)
Dynamic Routing (OSPF)
device-> set vrouter trust-vr protocol ospf
device-> set vrouter trust-vr protocol ospf enable
device-> set interface tunnel.1 protocol ospf area 0
device-> set interface tunnel.1 protocol ospf link-type p2mp
device-> set interface tunnel.1 protocol ospf enable
device-> save

WebUI (Peer1)
Dynamic Routing (OSPF)
Network > Routing > Virtual Routers > Edit (for trust-vr) > Create OSPF
Instance: Select OSPF Enabled, then click Apply.

Area > Configure (for area 0.0.0.0): Click << Add to move the tunnel.1
interface from the Available Interface(s) list to the Selected Interface(s) list,
then click OK.

Network > Interfaces > Edit (for tunnel.1) > OSPF: Enter the following, then
click Apply:

Bind to Area: (select), Select 0.0.0.0 from the drop down list
Protocol OSPF: Enable

300  Multiple Tunnels per Tunnel Interface

 Chapter 7: Advanced Virtual Private Network Features

CLI (Peer1)
Dynamic Routing (OSPF)
device-> set vrouter trust-vr protocol ospf
device-> set vrouter trust-vr protocol ospf enable
device-> set interface tunnel.1 protocol ospf area 0
device-> set interface tunnel.1 protocol ospf enable
device-> save

WebUI (Peer2)
Dynamic Routing (OSPF)
Network > Routing > Virtual Routers > Edit (for trust-vr) > Create OSPF
Instance: Select OSPF Enabled, then click Apply.

Area > Configure (for area 0.0.0.0): Click << Add to move the tunnel.1
interface from the Available Interface(s) list to the Selected Interface(s) list,
then click OK.

Network > Interfaces > Edit (for tunnel.1) > OSPF: Enter the following, then
click Apply:

Bind to Area: (select), Select 0.0.0.0 from the drop down list
Protocol OSPF: Enable

CLI (Peer2)
Dynamic Routing (OSPF)
device-> set vrouter trust-vr protocol ospf
device-> set vrouter trust-vr protocol ospf enable
device-> set interface tunnel.1 protocol ospf area 0
device-> set interface tunnel.1 protocol ospf enable
device-> save

Redundant VPN Gateways

The redundant gateway feature provides a solution for continuous VPN connectivity
during and after a site-to-site failover. You can create a VPN group to provide a set of
up to four redundant gateways to which policy-based site-to-site or site-to-site
dynamic peer AutoKey IKE IPSec VPN tunnels can connect. When the security
device first receives traffic matching a policy referencing a VPN group, it performs
Phase 1 and Phase 2 IKE negotiations with all members in that group. The security
device sends data through the VPN tunnel to the gateway with the highest priority,
or weight, in the group. For all other gateways in the group, the security device
maintains the Phase 1 and 2 SAs and keeps the tunnels active by sending IKE
keepalive packets through them. If the active VPN tunnel fails, the tunnel can fail
over to the tunnel and gateway with the second highest priority in the group.

Redundant VPN Gateways  301

 Concepts & Examples ScreenOS Reference Guide

NOTE: VPN groups do not support L2TP, L2TP-over-IPSec, dialup, Manual Key, or
route-based VPN tunnel types. In a Site-to-Site Dynamic Peer arrangement, the
security device monitoring the VPN group must be the one whose untrust IP
address is dynamically assigned, while the untrust IP addresses of the VPN group
members must be static.

This scheme assumes that the sites behind the redundant gateways are connected
so that data is mirrored among hosts at all sites. Furthermore, each site—being
dedicated to high availability (HA)—has a redundant cluster of security devices
operating in HA mode. Therefore, the VPN failover threshold must be set higher
than the device failover threshold or VPN failovers might occur unnecessarily.

Figure 80: Redundant VPN Gateways for VPN Tunnel Failover

VPN Group, ID 1 VPN Group, ID 1

= Data (After a VPN failover)
= IKE Heartbeats

VPN Groups
A VPN group is a set of VPN tunnel configurations for up to four targeted remote
gateways. The Phase 1 and Phase 2 security association (SA) parameters for each
tunnel in a group can be different or identical (except for the IP address of the
remote gateway, which obviously must be different). The VPN group, shown in
Figure 81 on page 303, has a unique ID number, and each member in the group is
assigned a unique weight to indicate its place in rank of preference to be the active
tunnel. A value of 1 indicates the lowest, or least-preferred, ranking.

302  Redundant VPN Gateways

 Chapter 7: Advanced Virtual Private Network Features

Figure 81: Targeted Remote Gateways

VPN Group 1 Weight

T 4

A
R 3

Monitor
G
E 2

Note: In this illustration, the shading symbolizes the weight of each S 1

tunnel. The darker the tunnel, the higher its priority.

The security device communicating with VPN group members and the members
themselves have a monitor-to-target relationship. The monitoring device continually
monitors the connectivity and wellbeing of each targeted device. The tools that the
monitor uses to do this are as follows:

 IKE heartbeats

 IKE recovery attempts

Both tools are presented in the next section, “Monitoring Mechanisms ” on

page 303.

NOTE: The monitor-to-target relationship need not be one way. The monitoring device
might also be a member of a VPN group and thus be the target of another
monitoring device.

Monitoring Mechanisms
Two mechanisms monitor members of a VPN group to determine their ability to
terminate VPN traffic:

 IKE heartbeats

 IKE recovery attempts

Using these two tools, plus the TCP application failover option (see “TCP SYN-Flag
Checking” on page 307), security devices can detect when a VPN failover is
required and shift traffic to the new tunnel without disrupting VPN service.

Redundant VPN Gateways  303

 Concepts & Examples ScreenOS Reference Guide

IKE Heartbeats
IKE heartbeats are hello messages that IKE peers send to each other under the
protection of an established Phase 1 security association (SA) to confirm the
connectivity and wellbeing of the other. If, for example, device_m (the “monitor”)
does not receive a specified number of heartbeats (the default is 5) from device_t
(the “target”), device_m concludes that device_t is down. Device_m clears the
corresponding Phase 1 and Phase 2 security associations (SAs) from its SA cache
and begins the IKE recovery procedure. (See “IKE Recovery Procedure” on
page 305.) Device_t also clears its SAs.

NOTE: The IKE heartbeats feature must be enabled on the devices at both ends of a VPN
tunnel in a VPN group. If it is enabled on device_m but not on device_t, device_m
suppresses IKE heartbeat transmission and generates the following message in the
event log: “Heartbeats have been disabled because the peer is not sending them.”

Figure 82: IKE Heartbeats Flow in Both Directions

IKE heartbeats must flow both ways through the VPN tunnel.

To define the IKE heartbeat interval and threshold for a specified VPN tunnel (the
default is 5), do the following:

WebUI
VPNs > AutoKey Advanced > Gateway > Edit (for the gateway whose IKE
heartbeat threshold you want to modify) > Advanced: Enter the new
values in the Heartbeat Hello and Heartbeat Threshold fields, then click OK.

CLI
set ike gateway name_str heartbeat hello number
set ike gateway name_str heartbeat threshold number

Dead Peer Detection

DPD is a protocol used by network devices to verify the current existence and
availability of other peer devices.

You can use DPD as an alternative to the IKE heartbeat feature (described above).
However, you cannot use both features simultaneously. In addition, IKE heartbeat
can be a global setting, which affects all IKE gateways configured in the device. The
IKE heartbeat setting can also apply to an individual IKE gateway context, which
affects an individual gateway only. By contrast, you can configure DPD only in an
individual IKE gateway context, not as a global parameter.

A device performs DPD verification by sending encrypted IKE Phase 1 notification

payloads (R-U-THERE) to peers, and waiting for DPD acknowledgements
(R-U-THERE-ACK) from the peers. The device sends an R-U-THERE request if and
only if it has not received any traffic from the peer during a specified DPD interval.
If a DPD-enabled device receives traffic on a tunnel, it resets its R-U-THERE counter
for that tunnel, thus starting a new interval. If the device receives an
R-U-THERE-ACK from the peer during this interval, it considers the peer alive. If the
device does not receive an R-U-THERE-ACK response during the interval, it
considers the peer dead.

304  Redundant VPN Gateways

 Chapter 7: Advanced Virtual Private Network Features

When the device deems a peer device to be dead, the device removes the Phase 1
SA and all Phase 2 SAs for the peer.

You can configure the following DPD parameters, either through the CLI or the
WebUI:

 The interval parameter specifies the DPD interval. This interval is the amount
of time (expressed in seconds) the device allows to pass before considering a
peer to be dead.

 The always-send parameter instructs the device to send DPD requests

regardless of whether there is IPSec traffic with the peer.

 The retry parameter specifies the maximum number of times to send the
R-U-THERE request before considering the peer to be dead. As with an IKE
heartbeat configuration, the default number of transmissions is 5 times, with a
permissible range of 1-128 retries. A setting of zero disables DPD.

In the following example you create a gateway that uses a DPD interval of five
seconds.

WebUI
VPNs > AutoKey Advanced > Gateway > Edit: Create a gateway by entering
the following values, then clicking OK.

Gateway Name: our_gateway

Security Level: Standard
Remote Gateway Type: Static IP Address
IP Address/Hostname: 1.1.1.1
Preshared Key: jun9345

VPNs > AutoKey Advanced > Gateway > Edit (our_gateway): Enter the
following values, then click OK.

Predefined: Standard (select)

DPD:
Interval: 5

CLI
set ike gateway "our_gateway" address 1.1.1.1 main outgoing-interface "untrust"
preshare "jun9345" sec-level standard
set ike gateway "our_gateway" dpd interval 5

IKE Recovery Procedure

After the monitoring security device determines that a targeted device is down, the
monitor stops sending IKE heartbeats and clears the SAs for that peer from its SA
cache. After a defined interval, the monitor attempts to initiate Phase 1 negotiations
with the failed peer. If the first attempt is unsuccessful, the monitor continues to
attempt Phase 1 negotiations at regular intervals until negotiations are successful.

Redundant VPN Gateways  305

 Concepts & Examples ScreenOS Reference Guide

Figure 83: Repeated IKE Phase 1 Negotiation Attempts

IKE Phase 1
Negotiation Attempts
Monitor Every Five Minutes Target

Interval:
5 minutes
(300 seconds) Unsuccessful Attempt
.
.. .. ..
. .
Unsuccessful Attempt

.. . ..
. ..
.
Successful Attempt

To define the IKE recovery interval for a specified VPN tunnel (the minimum setting
is 60 seconds), do either of the following:

WebUI
VPNs > AutoKey Advanced > Gateway > Edit (for the gateway whose IKE
reconnect interval you want to modify) > Advanced: Enter the value in
seconds in the Heartbeat Reconnect field, then click OK.

CLI
set ike gateway name_str heartbeat reconnect number

When a VPN group member with the highest weight fails over the tunnel to another
group member and then reconnects with the monitoring device, the tunnel
automatically fails back to the first member. The weighting system always causes
the best ranking gateway in the group to handle the VPN data whenever it can do
so.

Figure 84 on page 307 presents the process that a member of a VPN group
undergoes when the missing heartbeats from a targeted gateway surpass the failure
threshold.

306  Redundant VPN Gateways

 Chapter 7: Advanced Virtual Private Network Features

Figure 84: Failover and Then Recovery

Monitor Target

IKE heartbeats flowing in both directions

Target stops sending IKE heartbeats.

Monitor fails over the VPN (if target was handling VPN data), clears the P1 and
P2 SAs, and attempts to reestablish the VPN tunnel at specified intervals.

Target responds to P1 initiation with IKE heartbeats enabled.

IKE P1 and P2 negotiations succeed, tunnel is back up, and VPN

fails back (if its weight preempts other VPN group members).

TCP SYN-Flag Checking

For a seamless VPN failover to occur, the handling of TCP sessions must be
addressed. If, after a failover, the new active gateway receives a packet in an
existing TCP session, the new gateway treats it as the first packet in a new TCP
session and checks if the SYN flag is set in the packet header. Because this packet is
really part of an existing session, it does not have the SYN flag set. Consequently,
the new gateway rejects the packet. With TCP SYN flag checking enabled, all TCP
applications have to reconnect after the failover occurs.

To resolve this, you can disable SYN-flag checking for TCP sessions in VPN tunnels,
as follows:

WebUI
You cannot disable SYN-flag checking through the WebUI.

CLI
unset flow tcp-syn-check-in-tunnel

Redundant VPN Gateways  307

 Concepts & Examples ScreenOS Reference Guide

NOTE: By default, SYN-flag checking is enabled.

Creating Redundant VPN Gateways

In this example, a corporate site has one VPN tunnel to a data center and a second
tunnel to a backup data center. All the data is mirrored through a leased line
connection between the two data center sites. The data centers are physically
separate to provide continuous service even in the event of a catastrophic failure
such as an all-day power outage or a natural disaster.

The device location and name, the physical interfaces and their IP addresses for the
Trust and Untrust zones, and the VPN group ID and weight for each security device
are as follows:

Physical Interface
Device and IP Address Physical Interface, IP Address, VPN Group
Device Location Name (Trust Zone) Default Gateway (Untrust Zone) ID and Weight
Corporate Monitor1 ethernet1, 10.10.1.1/24 ethernet3, 1.1.1.1/24, (GW) 1.1.1.2 ––
Data Center (Primary) Target1 ethernet1, 10.1.1.1/16 ethernet3, 2.2.2.1/24, (GW) 2.2.2.2 ID = 1, Weight = 2
Data Center (Backup) Target2 ethernet1, 10.1.1.1/16 ethernet3, 3.3.3.1/24, (GW) 3.3.3.2 ID = 1, Weight =1

NOTE: The internal address space at both data center sites must be identical.

All security zones are in the trust-vr routing domain. All the Site-to-Site AutoKey IKE
tunnels use the security level predefined as “Compatible” for both Phase 1 and
Phase 2 proposals. Preshared keys authenticate the participants.

Figure 85: Redundant VPN Gateways

Untrust, ethernet3 Trust, ethernet1
2.2.2.1/24 10.1.1.1/16
Target1
Data Center
10.1.0.0/16 Primary Site

Corporate Site Leased line to mirror

Monitor1 data from primary site
to backup site
10.10.1.0/24 Internet

Trust, ethernet1 Untrust, ethernet3

10.10.1.1/24 1.1.1.1/24 Target2
Data Center
10.1.0.0/16 Backup Site

Untrust, ethernet3 Trust, ethernet1

3.3.3.1/24 10.1.1.1/16

308  Redundant VPN Gateways

 Chapter 7: Advanced Virtual Private Network Features

WebUI (Monitor1)
1. Interfaces
Network > Interfaces > Edit (for ethernet1): Enter the following, then click
Apply:

Zone Name: Trust

Static IP: (select this option when present)
IP Address/Netmask: 10.10.1.1/24
Enter the following, then click OK:
Interface Mode: NAT

Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:

Zone Name: Untrust

Static IP: (select this option when present)
IP Address/Netmask: 1.1.1.1/24
2. Addresses
Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: in_trust

IP Address/Domain Name:
IP/Netmask: (select), 10.10.1.0/24
Zone: Trust

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: data_ctr

IP Address/Domain Name:
IP/Netmask: (select), 10.1.0.0/16
Zone: Untrust
3. VPNs
VPNs > AutoKey Advanced > VPN Group: Enter 1 in the VPN Group ID field,
then click Add.

VPNs > AutoKey Advanced > Gateway > New: Enter the following, then click
OK:

Gateway Name: target1

Security Level: Compatible
Remote Gateway Type: Static IP Address: (select), IP Address: 2.2.2.1
Preshared Key: SLi1yoo129
Outgoing Interface: ethernet3

> Advanced: Enter the following advanced settings, then click Return to
return to the basic Gateway configuration page:

Security Level: Compatible

Mode (Initiator): Main (ID Protection)
Heartbeat:
Hello: 3 Seconds
Reconnect: 60 seconds
Threshold: 5

Redundant VPN Gateways  309

 Concepts & Examples ScreenOS Reference Guide

VPNs > AutoKey IKE > New: Enter the following, then click OK:

VPN Name: to_target1

Security Level: Compatible
Remote Gateway: Predefined: (select), target1

> Advanced: Enter the following advanced settings, then click Return to
return to the basic AutoKey IKE configuration page:

VPN Group: VPN Group-1

Weight: 2

VPNs > AutoKey Advanced > Gateway > New: Enter the following, then click
OK:

Gateway Name: target2

Security Level: Compatible
Remote Gateway Type: Static IP Address: (select), IP Address: 3.3.3.1
Preshared Key: CMFwb7oN23
Outgoing Interface: ethernet3

> Advanced: Enter the following advanced settings, then click Return to
return to the basic Gateway configuration page:

Security Level: Compatible

Mode (Initiator): Main (ID Protection)
Heartbeat:
Hello: 3 Seconds
Reconnect: 60 seconds
Threshold: 5

VPNs > AutoKey IKE > New: Enter the following, then click OK:

VPN Name: to_target2

Security Level: Compatible
Remote Gateway: Predefined: (select), target2

> Advanced: Enter the following advanced settings, then click Return to
return to the basic AutoKey IKE configuration page:

VPN Group: VPN Group-1

Weight: 1
4. Route
Network > Routing > Routing Entries > trust-vr New: Enter the following,
then click OK:

Network Address / Netmask: 0.0.0.0/0

Gateway: (select)
Interface: ethernet3
Gateway IP Address: 1.1.1.2(untrust)

310  Redundant VPN Gateways

 Chapter 7: Advanced Virtual Private Network Features

5. Policies
Policies > (From: Trust, To: Untrust) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), in_trust
Destination Address:
Address Book Entry: (select), data_ctr
Service: ANY
Action: Tunnel
VPN: VPN Group-1
Modify matching bidirectional VPN policy: (select)
Position at Top: (select)

WebUI (Target1)
1. Interfaces
Network > Interfaces > Edit (for ethernet1): Enter the following, then click
Apply:

Zone Name: Trust

Static IP: (select this option when present)
IP Address/Netmask: 10.1.1.1/16
Enter the following, then click OK:
Interface Mode: NAT

Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:

Zone Name: Untrust

Static IP: (select this option when present)
IP Address/Netmask: 2.2.2.1/24
2. Addresses
Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: in_trust

IP Address/Domain Name:
IP/Netmask: (select), 10.1.0.0/16
Zone: Trust

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: corp

IP Address/Domain Name:
IP/Netmask: (select), 10.10.1.0/24
Zone: Untrust

Redundant VPN Gateways  311

 Concepts & Examples ScreenOS Reference Guide

3. VPN
VPNs > AutoKey Advanced > Gateway > New: Enter the following, then click
OK:

Gateway Name: monitor1

Security Level: Compatible
Remote Gateway Type:
Static IP Address: (select), IP Address/Hostname: 1.1.1.1
Preshared Key: SLi1yoo129
Outgoing Interface: ethernet3

> Advanced: Enter the following advanced settings, then click Return to
return to the basic Gateway configuration page:

Security Level: Compatible

Mode (Initiator): Main (ID Protection)
Heartbeat:
Hello: 3 Seconds
Reconnect: 0 seconds

VPNs > AutoKey IKE > New: Enter the following, then click OK:

Name: to_monitor1
Security Level: Compatible
Remote Gateway: Predefined: (select), monitor1
4. Route
Network > Routing > Routing Entries > trust-vr New: Enter the following,
then click OK:

Network Address / Netmask: 0.0.0.0/0

Gateway: (select)
Interface: ethernet3
Gateway IP Address: 2.2.2.2
5. Policies
Policies > ( From: Trust, To: Untrust) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), in_trust
Destination Address:
Address Book Entry: (select), corp
Service: ANY
Action: Tunnel
Tunnel VPN: monitor1
Modify matching bidirectional VPN policy: (select)
Position at Top: (select)

WebUI (Target2)

NOTE: Follow the Target1 configuration steps to configure Target2, but define the Untrust
zone interface IP address as 3.3.3.1/24, the default gateway IP address as 3.3.3.2,
and use CMFwb7oN23 to generate the preshared key.

312  Redundant VPN Gateways

 Chapter 7: Advanced Virtual Private Network Features

CLI (Monitor1)
1. Interfaces
set interface ethernet1 zone trust
set interface ethernet1 ip 10.10.1.1/24
set interface ethernet1 nat
set interface ethernet3 zone untrust
set interface ethernet3 ip 1.1.1.1/24
2. Addresses
set address trust in_trust 10.10.1.0/24
set address untrust data_ctr 10.1.0.0/16
3. VPNs
set ike gateway target1 address 2.2.2.1 main outgoing-interface ethernet3
preshare SLi1yoo129 sec-level compatible
set ike gateway target1 heartbeat hello 3
set ike gateway target1 heartbeat reconnect 60
set ike gateway target1 heartbeat threshold 5
set vpn to_target1 gateway target1 sec-level compatible
set ike gateway target2 address 3.3.3.1 main outgoing-interface ethernet3
preshare CMFwb7oN23 sec-level compatible
set ike gateway target2 heartbeat hello 3
set ike gateway target2 heartbeat reconnect 60
set ike gateway target2 heartbeat threshold 5
set vpn to_target2 gateway target2 sec-level compatible
set vpn-group id 1 vpn to_target1 weight 2
set vpn-group id 1 vpn to_target2 weight 1
unset flow tcp-syn-check-in-tunnel
4. Route
set vrouter trust-vr route 0.0.0.0/0 interface ethernet3 gateway 1.1.1.2
5. Policies
set policy top from trust to untrust in_trust data_ctr any tunnel “vpn-group 1”
set policy top from untrust to trust data_ctr in_trust any tunnel “vpn-group 1”
save

CLI (Target1)
1. Interfaces
set interface ethernet1 zone trust
set interface ethernet1 ip 10.1.1.1/16
set interface ethernet1 nat
set interface ethernet3 zone untrust
set interface ethernet3 ip 2.2.2.1/24
2. Addresses
set address trust in_trust 10.1.0.0/16
set address untrust corp 10.10.1.0/24
3. VPN
set ike gateway monitor1 address 1.1.1.1 main outgoing-interface ethernet3
preshare SLi1yoo129 sec-level compatible
set ike gateway monitor1 heartbeat hello 3
set ike gateway monitor1 heartbeat threshold 5
set vpn to_monitor1 gateway monitor1 sec-level compatible

Redundant VPN Gateways  313

 Concepts & Examples ScreenOS Reference Guide

4. Route
set vrouter trust-vr route 0.0.0.0/0 interface ethernet3 gateway 2.2.2.2
5. Policies
set policy top from trust to untrust in_trust corp any tunnel vpn to_monitor
set policy top from untrust to trust corp in_trust any tunnel vpn to_monitor
save

CLI (Target2)

NOTE: Follow the Target1 configuration steps to configure Target2, but define the Untrust
zone interface IP address as 3.3.3.1/24, the default gateway IP address as 3.3.3.2,
and use CMFwb7oN23 to generate the preshared key.

Creating Back-to-Back VPNs

You can enforce interzone policies at the hub site for traffic passing from one VPN
tunnel to another by putting the spoke sites in different zones. Because they are in
different zones, the security device at the hub must do a policy lookup before
routing the traffic from one tunnel to another. You can control the traffic flowing
through the VPN tunnels between the spoke sites. This arrangement is called
back-to-back VPNs.

NOTE: Optionally, you can enable intrazone blocking and define an intrazone policy to
control traffic between the two tunnel interfaces within the same zone.

Figure 86: Back-to-Back VPNs

X1
Zone X2
Zone
Spoke A Spoke B

VPN1 VPN2

Policy
Lookup

Hub

Following are a few benefits of back-to-back VPNs:

 You can conserve the number of VPNs you need to create. For example,
perimeter site A can link to the hub and to perimeter sites B, C, D…, but A only
has to set up one VPN tunnel. Especially for NetScreen-5XP users, who can use
a maximum of ten VPN tunnels concurrently, applying the hub-and-spoke
method dramatically increases their VPN options and capabilities.

314  Creating Back-to-Back VPNs

 Chapter 7: Advanced Virtual Private Network Features

 The administrator (admin) at the hub device can completely control VPN traffic
between perimeter sites. For example,

 The admin might permit only HTTP traffic to flow from sites A to B, but
allow any kind of traffic to flow from B to A.

 The admin can allow traffic originating from A to reach C, but deny traffic
originating from C to reach A.

 The admin can allow a specific host at A to reach the entire D network,
while allowing only a specific host at D to reach a different host at A.

 The administrator at the hub device can completely control outbound traffic
from all perimeter networks. At each perimeter site, there must first be a policy
that tunnels all outbound traffic through the spoke VPNs to the hub; for
example: set policy top from trust to untrust any any any tunnel vpn
name_str (where name_str defines the specific VPN tunnel from each perimeter
site to the hub). At the hub, the administrator can control Internet access,
allowing certain kinds of traffic (such as HTTP only), performing URL blocking
on undesirable websites, and so on.

 Regional hubs can be used and interconnected through spoke tunnels, allowing
spoke sites in one region to reach spoke sites in another.

The following example is similar to “Creating Hub-and-Spoke VPNs” on page 321

except that the security device at the hub site in New York performs policy checking
on the traffic it routes between the two tunnels to the branch offices in Tokyo and
Paris. By putting each remote site in a different zone, you control the VPN traffic at
the hub.

The Tokyo LAN address is in the user-defined X1 zone, and the Paris LAN address is
in the user-defined X2 zone. Both zones are in the Trust-VR routing domain.

NOTE: To create user-defined zones, you might first need to obtain and load a zone
software key on the security device.

You bind the VPN1 tunnel to the tunnel.1 interface and the VPN2 tunnel to the
tunnel.2 interface. Although you do not assign IP addresses to the X1 and X2 zone
interfaces, you do give addresses to both tunnel interfaces. Routes for these
interfaces automatically appear in the Trust-VR routing table. By putting the IP
address for a tunnel interface in the same subnet as that of the destination, traffic
destined for that subnet is routed to the tunnel interface.

The outgoing interface is ethernet3, which is bound to the Untrust zone. As you can
see in Figure 87, both tunnels terminate in the Untrust zone; however, the
endpoints for the traffic that makes use of the tunnels are in the X1 and X2 zones.
The tunnels use AutoKey IKE, with preshared keys. You select the security level
predefined as “Compatible” for both Phase 1 and Phase 2 proposals. You bind the
Untrust zone to the untrust-vr. Because the tunnels are route-based (that is, the
correct tunnel is determined by routing, not by a tunnel name specified in a policy),
proxy IDs are included in the configuration of each tunnel.

Creating Back-to-Back VPNs  315

 Concepts & Examples ScreenOS Reference Guide

Figure 87: Back-to-Back VPNs with Two Routing Domains and Multiple Security Zones
Default Tokyo (Spoke)
Gateway 110.1.1.1
IP 123.1.1.2 Paris (Spoke)
New York 220.2.2.2
Outgoing Interface
Untrust Zone Untrust-VR
ethernet3, IP 123.1.1.1/24 VPN1 Routing Domain
Trust-VR Interface:
Routing Domain VPN2
tunnel.1
10.10.1.2/24
New York
Corporate Site Tokyo LAN
(Hub) X1 Zone
10.10.1.0/24

Trust Zone Policy

Lookup
Paris LAN
X2 Zone 10.20.1.0/24
Interface:
ethernet1 tunnel.2
10.1.1.1/24 10.20.1.2/24

WebUI
1. Security Zones and Virtual Routers
Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:

IP Address/Netmask: 0.0.0.0/0
Manage IP: 0.0.0.0

Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:

Zone Name: Null

Network > Zones > Edit (for Untrust): Enter the following, then click OK:

Virtual Router Name: untrust-vr

Block Intra-Zone Traffic: (select)

Network > Zones > New: Enter the following, then click OK:

Zone Name: X1
Virtual Router Name: trust-vr
Block Intra-Zone Traffic: (select)

Network > Zones > New: Enter the following, then click OK:

Name: X2
Virtual Router Name: trust-vr
Block Intra-Zone Traffic: (select)

316  Creating Back-to-Back VPNs

 Chapter 7: Advanced Virtual Private Network Features

2. Interfaces
Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:

Zone Name: Untrust

Static IP: (select this option when present)
IP Address/Netmask: 123.1.1.1/24

Network > Interfaces > New Tunnel IF: Enter the following, then click OK:

Tunnel Interface Name: tunnel.1

Zone (VR): X1 (trust-vr)
Fixed IP: (select)
IP Address / Netmask: 10.10.1.2/24

Network > Interfaces > New Tunnel IF: Enter the following, then click OK:

Tunnel Interface Name: tunnel.2

Zone (VR): X2 (trust-vr)
Fixed IP: (select)
IP Address / Netmask: 10.20.1.2/24
3. VPN for Tokyo Office
VPNs > AutoKey IKE > New: Enter the following, then click OK:

VPN Name: VPN1

Security Level: Compatible
Remote Gateway: Create a Simple Gateway: (select)
Gateway Name: Tokyo
Type: Static IP: (select), Address/Hostname: 110.1.1.1
Preshared Key: netscreen1
Outgoing Interface: ethernet3

> Advanced: Enter the following advanced settings, then click Return to
return to the basic AutoKey IKE configuration page:

Proxy-ID: (select)
Local IP / Netmask: 10.20.1.0/24
Remote IP / Netmask: 10.10.1.0/24
Service: ANY

NOTE: When configuring the VPN tunnel on the security device protecting the Tokyo and
Paris offices, do either of the following:

(Route-based VPN) Select the Enable Proxy-ID check box, and enter 10.10.1.0/24
(Tokyo) and 10.20.1.0/24 (Paris) for the Local IP and Netmask and 10.20.1.0/24
(Tokyo) and 10.10.1.0/24 (Paris) for the Remote IP and Netmask.

(Policy-based VPN) Make an entry in the Trust zone address book for 10.10.1.0/24
(Tokyo) and 10.20.1.0/24 (Paris) and another in the Untrust zone address book for
10.20.1.0/24 (Tokyo) and 10.10.1.0/24 (Paris). Use those as the source and
destination addresses in the policy referencing the VPN tunnel to the hub site.

Creating Back-to-Back VPNs  317

 Concepts & Examples ScreenOS Reference Guide

4. VPN for Paris Office

VPNs > AutoKey IKE > New: Enter the following, then click OK:

VPN Name: VPN2

Security Level: Compatible
Remote Gateway: Create a Simple Gateway: (select)
Gateway Name: Paris
Type: Static IP: (select), Address/Hostname: 220.2.2.2
Preshared Key: netscreen2
Outgoing Interface: ethernet3

> Advanced: Enter the following advanced settings, then click Return to
return to the basic AutoKey IKE configuration page:

Proxy-ID: (select)
Local IP / Netmask: 10.10.1.0/24
Remote IP / Netmask: 10.20.1.0/24
Service: ANY
5. Routes
Network > Routing > Routing Entries > trust-vr New: Enter the following,
then click OK:

Network Address / Netmask: 0.0.0.0/0

Next Hop Virtual Router Name: (select), untrust-vr

Network > Routing > Routing Entries > untrust-vr New: Enter the following,
then click OK:

Network Address / Netmask: 0.0.0.0/0

Gateway: (select)
Interface: ethernet3
Gateway IP Address: 123.1.1.2
6. Addresses
Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: Tokyo LAN

IP Address/Domain Name:
IP/Netmask: (select), 10.10.1.0/24
Zone: X1

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: Paris LAN

IP Address/Domain Name:
IP/Netmask: (select), 10.20.1.0/24
Zone: X2

318  Creating Back-to-Back VPNs

 Chapter 7: Advanced Virtual Private Network Features

7. Policies
Policy > (From: X1, To: X2) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), Tokyo LAN
Destination Address:
Address Book Entry: (select), Paris LAN
Service: ANY
Action: Permit
Position at Top: (select)

Policy > (From: X2, To: X1) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), Paris LAN
Destination Address:
Address Book Entry: (select), Tokyo LAN
Service: ANY
Action: Permit
Position at Top: (select)

CLI
1. Security Zones and Virtual Routers
unset interface ethernet3 ip
unset interface ethernet3 zone
set zone untrust vrouter untrust-vr
set zone untrust block
set zone name X1
set zone x1 vrouter trust-vr
set zone x1 block
set zone name x2
set zone x2 vrouter trust-vr
set zone x2 block
2. Interfaces
set interface ethernet3 zone untrust
set interface ethernet3 ip 123.1.1.1/24
set interface tunnel.1 zone x1
set interface tunnel.1 ip 10.10.1.2/24
set interface tunnel.2 zone x2
set interface tunnel.2 ip 10.20.1.2/24
3. VPN for Tokyo Office
set ike gateway Tokyo address 110.1.1.1 outgoing-interface ethernet3 preshare
netscreen1 sec-level compatible
set vpn VPN1 gateway Tokyo sec-level compatible
set vpn VPN1 bind interface tunnel.1
set vpn VPN1 proxy-id local-ip 10.20.1.0/24 remote-ip 10.10.1.0/24 any

Creating Back-to-Back VPNs  319

 Concepts & Examples ScreenOS Reference Guide

NOTE: When configuring the VPN tunnel on the security device protecting the Tokyo and
Paris offices, do either of the following:

(Route-based VPN) Enter the following commands: set vpn VPN1 proxy-id
local-ip 10.20.1.0/24 remote-ip 10.10.1.0/24 (Tokyo) and set vpn VPN1 proxy-id
local-ip 10.10.1.0/24 remote-ip 10.20.1.0/24 (Paris).

(Policy-based VPN) Make an entry in the Trust zone address book for 10.10.1.0/24
(Tokyo) and 10.20.1.0/24 (Paris) and another in the Untrust zone address book for
10.20.1.0/24 (Tokyo) and 10.10.1.0/24 (Paris). Use those as the source and
destination addresses in the policies referencing the VPN tunnel to the hub site.

4. VPN for Paris Office

set ike gateway Paris address 220.2.2.2 outgoing-interface ethernet3 preshare
netscreen2 sec-level compatible
set vpn VPN2 gateway Paris sec-level compatible
set vpn VPN2 bind interface tunnel.2
set vpn VPN2 proxy-id local-ip 10.10.1.0/24 remote-ip 10.20.1.0/24 any
5. Routes
set vrouter trust-vr route 0.0.0.0/0 vrouter untrust-vr
set vrouter untrust-vr route 0.0.0.0/0 interface ethernet3 gateway 123.1.1.2
6. Addresses
set address x1 “Tokyo LAN” 10.10.1.0/24
set address x2 “Paris LAN” 10.20.1.0/24
7. Policies
set policy top from x1 to x2 “Tokyo LAN” “Paris LAN” any permit
set policy top from x2 to x1 “Paris LAN” “Tokyo LAN” any permit
save

NOTE: You can ignore the following message, which appears because tunnel interfaces
are in NAT mode:

Warning: Some interfaces in the zone_name zone are in NAT mode. Traffic might
not pass through them!

320  Creating Back-to-Back VPNs

 Chapter 7: Advanced Virtual Private Network Features

Creating Hub-and-Spoke VPNs

If you create two VPN tunnels that terminate at a security device, you can set up a
pair of routes so that the security device directs traffic exiting one tunnel to the
other tunnel. If both tunnels are contained within a single zone, you do not need to
create a policy to permit the traffic to pass from one tunnel to the other. You only
need to define the routes. Such an arrangement is known as a hub-and-spoke VPN.

You can also configure multiple VPNs in one zone and route traffic between any two
tunnels.

Figure 88: Multiple Tunnels in a Hub-and-Spoke VPN Configuration

Untrust Zone

Multiple Hub-and-Spoke VPN Tunnels

The security device routes traffic between tunnels.

In this example, two branch offices in Tokyo and Paris communicate with each
other through a pair of VPN tunnels—VPN1 and VPN2. Each tunnel originates at the
remote site and terminates at the corporate site in New York. The security device at
the corporate site routes traffic exiting one tunnel into the other tunnel.

By disabling intrazone blocking, the security device at the corporate site only needs
to do a route lookup—not a policy lookup—when conducting traffic from tunnel to
tunnel because both remote endpoints are in the same zone (the Untrust Zone).

NOTE: Optionally, you can leave intrazone blocking enabled and define an intrazone
policy permitting traffic between the two tunnel interfaces.

You bind the tunnels to the tunnel interfaces—tunnel.1 and tunnel.2—which are
both unnumbered. The tunnels use AutoKey IKE, with the preshared keys. You
select the security level predefined as “Compatible” for both Phase 1 and Phase 2
proposals. You bind the Untrust zone to the untrust-vr. The Untrust zone interface is
ethernet3.

NOTE: The following configuration is for route-based VPNs. If you configure policy-based
hub-and-spoke VPNs, you must use the Trust and Untrust zones in the policies;
you cannot use user-defined security zones.

Creating Hub-and-Spoke VPNs  321

 Concepts & Examples ScreenOS Reference Guide

Figure 89: Hub-and-Spoke VPNs

Untrust Zone untrust-vr Routing Domain

Outgoing Default
Gateway Tokyo 2.2.2.2
Interface (Spoke)
ethernet3 IP 1.1.1.250
IP 1.1.1.1 Tokyo LAN
Internet 10.2.2.0/24
VPN1
Paris 3.3.3.3
VPN2 (Spoke)
New York – Corporate Site Interface: Paris LAN
(Hub) tunnel.1 10.3.3.0/24
Interface:
tunnel.2

WebUI (New York)

1. Security Zones and Virtual Routers
Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:

IP Address/Netmask: 0.0.0.0/0
Manage IP: 0.0.0.0

Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:

Zone Name: Null

Network > Zones > Edit (for Untrust): Enter the following, then click OK:

Virtual Router Name: untrust-vr

Block Intra-Zone Traffic: (clear)
2. Interfaces
Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:

Zone Name: Untrust

Static IP: (select this option when present)
IP Address/Netmask: 1.1.1.1/24

Network > Interfaces > New Tunnel IF: Enter the following, then click OK:

Tunnel Interface Name: tunnel.1

Zone (VR): Untrust (untrust-vr)
Unnumbered: (select)
Interface: ethernet3 (untrust-vr)

322  Creating Hub-and-Spoke VPNs

 Chapter 7: Advanced Virtual Private Network Features

Network > Interfaces > New Tunnel IF: Enter the following, then click OK:

Tunnel Interface Name: tunnel.2

Zone (VR): Untrust (untrust-vr)
Unnumbered: (select)
Interface: ethernet3 (untrust-vr)
3. VPN for Tokyo Office
VPNs > AutoKey IKE > New: Enter the following, then click OK:

VPN Name: VPN1

Security Level: Compatible
Remote Gateway: Create a Simple Gateway: (select)
Gateway Name: Tokyo
Type: Static IP: (select), Address/Hostname: 2.2.2.2
Preshared Key: netscreen1
Security Level: Compatible
Outgoing Interface: ethernet3

> Advanced: Enter the following advanced settings, then click Return to
return to the basic AutoKey IKE configuration page:

Proxy-ID: (select)
Local IP / Netmask: 0.0.0.0/0
Remote IP / Netmask: 0.0.0.0/0
Service: ANY
4. VPN for Paris Office
VPNs > AutoKey IKE > New: Enter the following, then click OK:

VPN Name: VPN2

Security Level: Compatible
Remote Gateway: Create a Simple Gateway: (select)
Gateway Name: Paris
Type: Static IP: (select), Address/Hostname: 3.3.3.3
Preshared Key: netscreen2
Security Level: Compatible
Outgoing Interface: ethernet3

> Advanced: Enter the following advanced settings, then click Return to
return to the basic AutoKey IKE configuration page:

Proxy-ID: (select)
Local IP / Netmask: 0.0.0.0/0
Remote IP / Netmask: 0.0.0.0/0
Service: ANY
5. Routes
Network > Routing > Routing Entries > untrust-vr New: Enter the following,
then click OK:

Network Address / Netmask: 10.2.2.0/24

Gateway: (select)
Interface: tunnel.1
Gateway IP Address: 0.0.0.0

Creating Hub-and-Spoke VPNs  323

 Concepts & Examples ScreenOS Reference Guide

Network > Routing > Routing Entries > untrust-vr New: Enter the following,
then click OK:

Network Address / Netmask: 10.3.3.0/24

Gateway: (select)
Interface: tunnel.2
Gateway IP Address: 0.0.0.0

Network > Routing > Routing Entries > untrust-vr New: Enter the following,
then click OK:

Network Address / Netmask: 0.0.0.0/0

Gateway: (select)
Interface: ethernet3
Gateway IP Address: 1.1.1.250

WebUI (Tokyo)
1. Security Zones and Virtual Routers
Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:

IP Address/Netmask: 0.0.0.0/0
Manage IP: 0.0.0.0

Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:

Zone Name: Null

Network > Zones > Edit (for Untrust): Enter the following, then click OK:

Virtual Router Name: untrust-vr

Block Intra-Zone Traffic: (select)
2. Interfaces
Network > Interfaces > Edit (for ethernet1): Enter the following, then click
Apply:

Zone Name: Trust

Static IP: (select this option when present)
IP Address/Netmask: 10.2.2.1/24
Select the following, then click OK:
Interface Mode: NAT

Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:

Zone Name: Untrust

Static IP: (select this option when present)
IP Address/Netmask: 2.2.2.2/24

Network > Interfaces > New Tunnel IF: Enter the following, then click OK:

Tunnel Interface Name: tunnel.1

Zone (VR): Untrust (untrust-vr)
Unnumbered: (select)
Interface: ethernet3 (untrust-vr)

324  Creating Hub-and-Spoke VPNs

 Chapter 7: Advanced Virtual Private Network Features

3. Address
Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: Paris

IP Address/Domain Name:
IP/Netmask: (select), 10.3.3.0/24
Zone: Untrust
4. VPN
VPNs > AutoKey IKE > New: Enter the following, then click OK:

VPN Name: VPN1

Security Level: Compatible
Remote Gateway: Create a Simple Gateway: (select)
Gateway Name: New York
Type: Static IP: (select), Address/Hostname: 1.1.1.1
Preshared Key: netscreen1
Security Level: Compatible
Outgoing Interface: ethernet3

> Advanced: Enter the following advanced settings, then click Return to
return to the basic AutoKey IKE configuration page:

Proxy-ID: (select)
Local IP / Netmask: 0.0.0.0/0
Remote IP / Netmask: 0.0.0.0/0
Service: ANY
5. Routes
Network > Routing > Routing Entries > trust-vr New: Enter the following,
then click OK:

Network Address / Netmask: 0.0.0.0/0

Next Hop Virtual Router Name: (select); untrust-vr

Network > Routing > Routing Entries > untrust-vr New: Enter the following,
then click OK:

Network Address / Netmask: 0.0.0.0/0

Gateway: (select)
Interface: ethernet3
Gateway IP Address: 2.2.2.250

Network > Routing > Routing Entries > untrust-vr New: Enter the following,
then click OK:

Network Address / Netmask: 10.3.3.0/24

Gateway: (select)
Interface: tunnel.1
Gateway IP Address: 0.0.0.0

Creating Hub-and-Spoke VPNs  325

 Concepts & Examples ScreenOS Reference Guide

6. Policies
Policies > (From: Trust, To: Untrust) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), Any
Destination Address:
Address Book Entry: (select), Paris
Service: ANY
Action: Permit

WebUI (Paris)
1. Security Zones and Virtual Routers
Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:

IP Address/Netmask: 0.0.0.0/0
Manage IP: 0.0.0.0

Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:

Zone Name: Null

Network > Zones > Edit (for Untrust): Enter the following, then click OK:

Virtual Router Name: untrust-vr

Block Intra-Zone Traffic: (select)
2. Interfaces
Network > Interfaces > Edit (for ethernet1): Enter the following, then click
Apply:

Zone Name: Trust

Static IP: (select this option when present)
IP Address/Netmask: 10.3.3.1/24
Select the following, then click OK:
Interface Mode: NAT

Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:

Zone Name: Untrust

Static IP: (select this option when present)
IP Address/Netmask: 3.3.3.3/24

Network > Interfaces > New Tunnel IF: Enter the following, then click OK:

Tunnel Interface Name: tunnel.1

Zone (VR): Untrust (untrust-vr)
Unnumbered: (select)
Interface: ethernet3 (untrust-vr)

326  Creating Hub-and-Spoke VPNs

 Chapter 7: Advanced Virtual Private Network Features

3. Address
Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: Tokyo

IP Address/Domain Name:
IP/Netmask: (select), 10.2.2.0/24
Zone: Untrust
4. VPN
VPNs > AutoKey IKE > New: Enter the following, then click OK:

VPN Name: VPN2

Security Level: Compatible
Remote Gateway: Create a Simple Gateway: (select)
Gateway Name: New York
Type: Static IP: (select), Address/Hostname: 1.1.1.1
Preshared Key: netscreen2
Security Level: Compatible
Outgoing Interface: ethernet3

> Advanced: Enter the following advanced settings, then click Return to
return to the basic AutoKey IKE configuration page:

Proxy-ID: (select)
Local IP / Netmask: 0.0.0.0/0
Remote IP / Netmask: 0.0.0.0/0
Service: ANY
5. Routes
Network > Routing > Routing Entries > trust-vr New: Enter the following,
then click OK:

Network Address / Netmask: 0.0.0.0/0

Next Hop Virtual Router Name: (select); untrust-vr

Network > Routing > Routing Entries > untrust-vr New: Enter the following,
then click OK:

Network Address / Netmask: 0.0.0.0/0

Gateway: (select)
Interface: ethernet3
Gateway IP Address: 3.3.3.250

Network > Routing > Routing Entries > untrust-vr New: Enter the following,
then click OK:

Network Address / Netmask: 10.2.2.0/24

Gateway: (select)
Interface: tunnel.1
Gateway IP Address: 0.0.0.0

Creating Hub-and-Spoke VPNs  327

 Concepts & Examples ScreenOS Reference Guide

6. Policies
Policies > (From: Trust, To: Untrust) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), Any
Destination Address:
Address Book Entry: (select), Tokyo
Service: ANY
Action: Permit

CLI (New York)

1. Security Zones and Virtual Routers
unset interface ethernet3 ip
unset interface ethernet3 zone
set zone untrust vrouter untrust-vr
unset zone untrust block
2. Interfaces
set interface ethernet3 zone untrust
set interface ethernet3 ip 1.1.1.1/24
set interface tunnel.1 zone untrust
set interface tunnel.1 ip unnumbered interface ethernet3
set interface tunnel.2 zone untrust
set interface tunnel.2 ip unnumbered interface ethernet3
3. VPN for Tokyo Office
set ike gateway Tokyo address 2.2.2.2 outgoing-interface ethernet3 preshare
netscreen1 sec-level compatible
set vpn VPN1 gateway Tokyo sec-level compatible
set vpn VPN1 bind interface tunnel.1
set vpn VPN1 proxy-id local-ip 0.0.0.0/0 remote-ip 0.0.0.0/0 any
4. VPN for Paris Office
set ike gateway Paris address 3.3.3.3 outgoing-interface ethernet3 preshare
netscreen2 sec-level compatible
set vpn VPN2 gateway Paris sec-level compatible
set vpn VPN2 bind interface tunnel.2
set vpn VPN2 proxy-id local-ip 0.0.0.0/0 remote-ip 0.0.0.0/0 any
5. Routes
set vrouter untrust-vr route 10.2.2.0/24 interface tunnel.1
set vrouter untrust-vr route 10.3.3.0/24 interface tunnel.2
set vrouter untrust-vr route 0.0.0.0/0 interface ethernet3 gateway 1.1.1.250
save

328  Creating Hub-and-Spoke VPNs

 Chapter 7: Advanced Virtual Private Network Features

CLI (Tokyo)
1. Security Zones and Virtual Routers
unset interface ethernet3 ip
unset interface ethernet3 zone
set zone untrust vrouter untrust-vr
2. Interfaces
set interface ethernet1 zone trust
set interface ethernet1 ip 10.2.2.1/24
set interface ethernet1 nat
set interface ethernet3 zone untrust
set interface ethernet3 ip 2.2.2.2/24
set interface tunnel.1 zone untrust
set interface tunnel.1 ip unnumbered interface ethernet3
3. Address
set address untrust Paris 10.3.3.0/24
4. VPN
set ike gateway “New York” address 1.1.1.1 outgoing-interface ethernet3 preshare
netscreen1 sec-level compatible
set vpn VPN1 gateway “New York” sec-level compatible
set vpn VPN1 bind interface tunnel.1
set vpn VPN1 proxy-id local-ip 0.0.0.0/0 remote-ip 0.0.0.0/0 any
5. Routes
set vrouter trust-vr route 0.0.0.0/0 vrouter untrust-vr
set vrouter untrust-vr route 0.0.0.0/0 interface ethernet3 gateway 2.2.2.250
set vrouter untrust-vr route 10.3.3.0/24 interface tunnel.1
6. Policies
set policy from trust to untrust any Paris any permit
set policy from untrust to trust Paris any any permit
save

CLI (Paris)
1. Security Zones and Virtual Routers
unset interface ethernet3 ip
unset interface ethernet3 zone
set zone untrust vrouter untrust-vr
2. Interfaces
set interface ethernet1 zone trust
set interface ethernet1 ip 10.3.3.1/24
set interface ethernet1 nat
set interface ethernet3 zone untrust
set interface ethernet3 ip 3.3.3.3/24
set interface tunnel.1 zone untrust
set interface tunnel.1 ip unnumbered interface ethernet3
3. Address
set address untrust Tokyo 10.2.2.0/24

Creating Hub-and-Spoke VPNs  329

 Concepts & Examples ScreenOS Reference Guide

4. VPN
set ike gateway “New York” address 1.1.1.1 outgoing-interface ethernet3 preshare
netscreen2 sec-level compatible
set vpn VPN2 gateway “New York” sec-level compatible
set vpn VPN2 bind interface tunnel.1
set vpn VPN2 proxy-id local-ip 0.0.0.0/0 remote-ip 0.0.0.0/0 an
5. Routes
set vrouter trust-vr route 0.0.0.0/0 vrouter untrust-vr
set vrouter untrust-vr route 0.0.0.0/0 interface ethernet3 gateway 3.3.3.250
set vrouter untrust-vr route 10.2.2.0/24 interface tunnel.1
6. Policies
set policy from trust to untrust any Tokyo any permit
set policy from untrust to trust Tokyo any any permit
save

330  Creating Hub-and-Spoke VPNs

Chapter 8
AutoConnect-Virtual Private Networks

This chapter describes the AutoConnect-virtual private network (AC-VPN) feature in

ScreenOS, explains how it works in a hub-and-spoke network topology, and
provides a configuration example of a typical scenario in which it might be used.

Overview
Small enterprise organizations that secure their remote satellite sites with virtual
private network (VPN) tunnels typically interconnect all sites in a full-mesh VPN,
because remote sites need to communicate with each other as well as with
headquarters. In this type of network, remote sites usually run low-end security
devices that support a maximum of 25 VPN tunnels. When the total number of sites
exceeds 25, however, the enterprise must either place security devices with greater
capacity at its remote sites (at considerable cost) or switch from full-mesh to a
hub-and-spoke network topology.

A hub-and-spoke configuration solves the problem of scalability, but its principle

drawback is that all communication between spokes must go through the hub. This
generally is not an issue when traffic is simple data, even with more than one
thousand spokes. However, if traffic is video or Voice over Internet Protocol (VoIP),
the processing overhead on the hub can cause latency, a critical problem for such
applications.

AC-VPN provides a way for you to configure your hub-and-spoke network so that
spokes can dynamically create VPN tunnels directly between each other as needed.
This not only solves the problem of latency between spokes but also reduces
processing overhead on the hub and thus improves overall network performance.
Additionally, because AC-VPN creates dynamic tunnels that time out when traffic
ceases to flow through them, network administrators are freed from the
time-consuming task of maintaining a complex network of static VPN tunnels.

How It Works
AC-VPN is designed to be implemented in a hub-and-spoke network in which all
spokes are connected to the hub by VPN tunnels. After you set up a static VPN
tunnel between the hub and each of the spokes, you configure AC-VPN on the hub
and the spokes and then enable the Next Hop Resolution Protocol (NHRP). The hub
uses NHRP to obtain a range of information about each spoke, including its
public-to-private address mappings, subnetmask length, and routing and hop count
information, which the hub caches. Then, when any spoke begins communicating
with another spoke (through the hub), the hub uses this information, in

Overview  331
 Concepts & Examples ScreenOS Reference Guide

combination with information obtained from the AC-VPN configuration on the

spokes, to enable the spokes to set up an AC-VPN tunnel between themselves.
While the tunnel is being negotiated, communication continues to flow between the
two spokes through the hub. When the dynamic tunnel becomes active, the hub
drops out of the link and traffic flows directly between the two spokes. When traffic
ceases to flow through the dynamic tunnel, the tunnel times out.

NHRP Messages
In the context of NHRP, the hub in a hub-and-spoke network is called the Next Hop
Server (NHS), and the spoke is called the Next Hop Client (NHC). NHRP
communication between NHS and NHC takes place though a formal exchange of
NHRP messages. The nonbroadcast multi access (NBMA) Next Hop Resolution
Protocol (RFC 2332) defines seven NHRP messages. To these seven messages,
ScreenOS adds two more. These nine messages and their operation in an AC-VPN
hub-and-spoke network are defined as follows:

 Registration Request—After a static VPN tunnel becomes active between an

NHC and its NHS, the NHC sends an NHRP Registration Request message to the
NHS. The message contains a number of Client Information Entries (CIEs),
which include such things as the NHC’s public-to-private address mappings,
subnetmask length, and routing and hop-count information.

NOTE: In the current ScreenOS implementation, NHRP does not redistribute any routes
to its peers, and BGP and OSPF do not redistribute NHRP routes to their peers.

 Registration Reply—The NHS can ACK or NAK a registration request. If the

NHS does not recognize the packet, the packet is not acknowledged (NAK) and
is dropped. Upon successful registration, the NHS caches the CIEs contained in
the registration request and sends a Registration Reply ACK.

 Resolution Request, Resolution Reply—With the introduction of the ScreenOS

proprietary Resolution-set and Resolution-ack messages, the function of the
NHRP Resolution Request and Resolution Reply message pair is relegated to
keeping cached CIEs on the NHS current. The NHCs do this in conjunction with
the holding time configured on the NHS, which specifies the lifetime of cached
entries for each NHC. To ensure that the NHS has current information about
their subnetworks, NHCs periodically send Resolution Request messages to the
NHS. If any devices have been added to or removed from their subnetworks,
that information is contained in the Resolution Request message, and the NHS
updates its cache and sends a Resolution Reply.

 Purge Request, Purge Reply—When an administrator shuts down an NHC, the

device sends a Purge Request message to the NHS. Upon receipt of the Purge
Request, the NHS removes all cached entries for that NHC and sends a Purge
Reply. If the NHC experiences system failure and goes off line, the NHS
removes cached entries for the device after the configured lifetime for the
cache expires.

 Error Indication—This message logs NHRP error conditions.

332  How It Works

 Chapter 8: AutoConnect-Virtual Private Networks

To support AC-VPN, ScreenOS adds the following message pair:

 Resolution-set, Resolution-ack—When the NHS detects traffic from one static

VPN tunnel to another, it sends Resolution-set messages to the NHCs at the end
of each static tunnel. These messages contain all the information each NHC
needs about the other to set up an AC-VPN tunnel. When the NHCs reply with
Resolution-ack messages, the NHS directs one of the NHCs to initiate AC-VPN
tunnel negotiation.

AC-VPN Tunnel Initiation

Figure 90 illustrates how ScreenOS triggers the setup of an AC-VPN tunnel using the
NHRP Registration Request and Registration Reply messages, and the custom
ScreenOS Resolution-set and Resolution-ack messages. For simplification, the figure
does not show the exchange of Resolution Request and Resolution Reply messages,
nor the Purge and Error messages. (The abbreviations S1 and S2 refer to Spoke 1
and Spoke 2, respectively; D1 and D2 refer to destinations behind those spokes.)

Figure 90: AC-VPN Set Up Via NHRP

NHC - Spoke 1 NHS - Hub NHC - Spoke 2

1. S1 comes up
Registration Request
2.
(sends protected subnets, self-cert-hash, local ID)

Registration Reply
3.
S2 comes up 4.
(sends AC-VPN profile)
Registration Request
5.
(sends protected subnets, self-cert-hash, local ID)
Registration Reply
6.
(sends AC-VPN profile)
D1 behind S1 sends new traffic to D2 behind S2 Hub forwards traffic to S2
7.
Hub sends Resolution-set with details about S1
8.
S2 sends Resolution-ack
9.
Hub sends Resolution-set with details about S2
10.

S1 sends Resolution-ack
11.

S1 initiates AC-VPN tunnel with S2

12.

Traffic between D1 and D2 flows between S1 and S2 in AC-VPN tunnel

How It Works  333

 Concepts & Examples ScreenOS Reference Guide

Configuring AC-VPN
The following general restrictions apply:

 All VPN tunnels configured toward the hub must be route based.

 Automatic key management in phase 1 must be in aggressive mode.

 The authentication method must be self-signed certificate and generic PKI.

 All spokes must be connected to a single zone on the hub.

 Configuring NHRP in multiple instances of virtual routers is supported only on

the NHS.

Network Address Translation

The following restrictions apply with NAT:

 Nat-Traversal—AC-VPN can create a dynamic tunnel between two spokes if one

of the spokes is behind a NAT device in the path toward the hub; if both spokes
are behind NAT devices, however, a dynamic tunnel will not be created and
communication between the spokes will proceed through the hub. See
NAT-Traversal on page 242 for a discussion of NAT-Traversal.

 NAT is supported only with mapped Internet Protocol (MIP) addressing.

 Port Address Translation (PAT) is supported only between one spoke and the
hub. For example, you can have a NAT device between one spoke and the hub
and a dynamic tunnel can be created between that spoke and another spoke as
long as there is no NAT device between that other spoke and the hub. In this
scenario, the hub will force the spoke behind the NAT device to initiate the
tunnel to the other spoke.

 PAT directly in front of the hub is supported.

 PAT between spokes is not supported.

Configuration on the Hub

The spoke configuration includes the following:

1. Create a static gateway and VPN.

2. Create static tunnels to the spokes and bind the VPNs to the tunnels.

3. Create an AC-VPN gateway profile.

4. Create an AC-VPN VPN profile.

5. Enable NHRP on the virtual router.

6. Select the ACVPN-Profile for NHRP.

7. Eanble NHRP on the tunnel interface.

8. Configure routing.

334  How It Works

 Chapter 8: AutoConnect-Virtual Private Networks

Configuration on Each Spoke

The hub includes the following:

1. Create a static tunnel to the hub.

2. Create a gateway.

3. Create a VPN gateway.

4. Create an ACVPN-Dynamic gateway.

5. Create ACVPN-Dynamic VPN

6. Enable NHRP on the virtual router

7. Configure the NHS IP address

8. Enable NHRP on the tunnel interface.

9. Configure routing.

How It Works  335

 Concepts & Examples ScreenOS Reference Guide

Example
In this example, a high-end security device acting as the hub in a hub and spoke
network is configured to act as the Next Hop Server (NHS) in an AC-VPN
configuration in which Spoke1 and Spoke2 (low-end security devices) are Next Hop
Clients (NHCs). After configuring interfaces on the devices, you configure static VPN
tunnels between the hub and each of the spokes, then configure AC-VPN and enable
NHRP on the connecting interfaces. Although this example uses the Open Shortest
Path First (OSPF) routing protocol, ScreenOS supports all dynamic routing protocols
with AC-VPN.

NOTE:AC-VPN also supports Dynamic Host Control Protocol (DHCP).

10.1.1.0/24

Hub
t.1--10.0.0.2 e2/1--1.1.1.1

Internet

t.1--10.0.0.2 e0/0--2.2.2.1/24 e0/0--3.3.3.1 t.1--10.0.0.3/24

Spoke--1 Spoke--2
Dynamic Tunnel

10.1.2.0/24 10.1.3.0/24

WebUI (Hub)

NOTE: After you configure static gateways and static VPNs from the hub to the spokes
and from the spokes to the hub, you can use the AC-VPN wizard to complete the
AC-VPN configuration.

1. Interfaces
Network > Interfaces > Edit (for ethernet2/1): Enter the following, then click
Apply:

Zone Name: Untrust

IP Address/Netmask: 1.1.1.1/24
Interface Mode: Route

336  How It Works

 Chapter 8: AutoConnect-Virtual Private Networks

Network > Interfaces > Edit (for ethernet2/2): Enter the following, then click
Apply:

Zone Name: Trust

IP Address/Netmask: 10.1.1.1/24
Interface Mode: NAT

Network > Interfaces > New (Tunnel IF): Enter the following, then click Apply:

Tunnel Interface Name: 1

Zone (VR): Trust-vr
Fixed IP
IP Address/Netmask: 10.0.0.1/24
Unnumbered
Interface:
NHRP Enable: (Select)
2. Configure tunnels to spoke1 and to spoke 2
VPNs > AutoKey Advanced > Gateway > New: Configure the IKE gateway,
click Advanced and set the security level, then click Return to go back to the
IKE gateway configuration page and click OK:

Gateway Name: Spoke1

Remote Gateway: (Select)
Static IP Address: (Select) IPv4/v6 Address/Hostname: 2.2.2.1

Preshare key: Juniper

Outgoing interface: (select) ethernet2/1
Security Level: Standard

VPNs > AutoKey Advanced > Gateway > New: Configure the IKE gateway,
click Advanced and set the security level, then click Return to go back to the
IKE gateway configuration page and click OK:

Gateway Name: Spoke2

Remote Gateway: (Select)
Static IP Address: (Select) IPv4/v6 Address/Hostname: 3.3.3.1

Preshare key: Juniper

Outgoing interface: (select) ethernet2/1
Security Level: Standard
3. Configure VPN spoke to gateway
VPNs > AutoKey IKE > New: Configure the IKE gateway, click Advanced and
set the security level, then click Return to go back to the IKE gateway
configuration page and click OK:

VPN Name: spoke1

Remote Gateway: (select) Predefined
(select appropriate gateway name from predefined list in drop-down list)
Security Level (select) Standard
Bind To: (select) Tunnel Interface
(select Tunnel.1 from the drop-down list)

How It Works  337

 Concepts & Examples ScreenOS Reference Guide

VPNs > AutoKey IKE > New: Configure the IKE gateway, click Advanced and
set the security level, then click Return to go back to the IKE gateway
configuration page and click OK:

VPN Name: spoke2

Remote Gateway: (select) Predefined
(select appropriate gateway name from predefined list from drop-down list)

Security Level (select) Standard)

Bind To: (select) Tunnel Interface
(select Tunnel.1 from the drop-down list)
4. Configure the ACVPN-Profile
VPNs > AutoKey Advanced > Gateway > New: Configure the IKE gateway,
click Advanced and set the security level, then click Return to go back to the
IKE gateway configuration page and click OK:

Gatewary Name: ac-spoke-gw

ACVPN-Profile: (select)

Security Level: (select) Standard

VPNs > AutoKey IKE > New: Configure the ACVPN Profile, click Advanced and
set the security level and Replay Protection, then click Return to go back to the
VPN configuration page and click OK

VPN Name: ac-vpn

ACVPN-Profile: (select)
Binding to tunnel: (select) ac-spoke-gw
Security Level: (select) Standard
Replay Protection: (select)
5. Configure vrouter
Network > Routing > Virtual Router > (for trust-vr) Edit: Enter the following, then
click Apply:

Next Hop Resolution Protocol(NHRP) Support

NHRP: (select) NHRP Setting
NHS Setting: (select)
Profile: (select) ACVPN-Profile name
6. Enable NHRP on the tunnel interface
Network > Interfaces > New (for TunnelIF): Enter the following, then click Apply:

Tunnel Interface Name: 1

NHRP Enable: (select)
7. Configure routing
Network > Routing > Destination > New: Enter the following, then click
Apply:

IP Address/netmask: 0.0.0.0
Gateway (select)
Gateway IP Address: 1.1.1.2

338  How It Works

 Chapter 8: AutoConnect-Virtual Private Networks

CLI (Hub)
set interface ethernet2/1 zone Untrust
set interface ethernet2/2 zone Trust
set interface tunnel.1 zone Trust

set interface ethernet2/1 ip 1.1.1.1/24

set interface ethernet2/1 route
set interface ethernet2/2 ip 10.1.1.1/24
set interface ethernet2/2 nat
set interface tunnel.1 ip 10.0.0.1/24

set ike gateway spoke2 address 3.3.3.1 Main outgoing-interface ethernet2/1

preshare juniper== sec-level standard
set ike gateway spoke1 address 2.2.2.1 Main outgoing-interface ethernet2/1
preshare juniper== sec-level standard

set vpn spoke2 gateway spoke2 no-replay tunnel idletime 0 sec-level standard
set vpn spoke2 id 1 bind interface tunnel.1
set vpn spoke1 gateway spoke1 no-replay tunnel idletime 0 sec-level standard
set vpn spoke1 id 2 bind interface tunnel.1

set ike gateway ac-spoke-gw acvpn-profile sec-level standard

set vpn ac-vpn acvpn-profile ac-spoke-gw no-replay tunnel idletime 0 sec-level
standard

set vrouter trust-vr

set protocol nhrp
set protocol nhrp acvpn-profile ac-vpn
exit
set interface tunnel.1 protocol nhrp enable

set vr trust protocol ospf

set vr trust protocol ospf enable
set vr trust protocol ospf area 10
set interface ethernet2/2 protocol ospf area 0.0.0.10
set interface ethernet2/2 protocol ospf enable
set interface tunnel.1 protocol ospf area 0.0.0.0
set interface tunnel.1 protocol ospf link-type p2mp
set interface tunnel.1 protocol ospf enable

set route 0.0.0.0/0 gateway 1.1.1.2

WebUI (Spoke1)
1. Interfaces
Network > Interfaces > Edit (for ethernet0/0): Enter the following, then click
Apply:

Zone Name: Untrust

IP Address/Netmask: 2.2.2.1/24
Interface Mode: Route

Network > Interfaces > Edit (for bgroup0): Enter the following, then click
Apply:

Zone Name: Trust

How It Works  339

 Concepts & Examples ScreenOS Reference Guide

Network > Interfaces > Edit (for ethernet2/2): Enter the following, then click
Apply:

Zone Name: Trust

IP Address/Netmask: 10.1.2.1/24
Interface Mode: NAT

Network > Interfaces > Edit (for ethernet2/2), Select Bind Port, enter the
following, then click Apply:

ethernet0/2 bgroup0: (select) Bind to Current Bgroup

Network > Interfaces > New (Tunnel IF): Enter the following, then click Apply:

Tunnel Interface Name: 1

Zone (VR): Trust-vr
Fixed IP
IP Address/Netmask: 10.0.0.2/24
NHRP Enable: (Select)
2. Configure tunnel to the hub
VPNs > AutoKey Advanced > Gateway > New: Configure the IKE gateway,
click Advanced and set the security level, then click Return to go back to the
IKE gateway configuration page and click OK:

Gateway Name: hub-gw

Remote Gateway: (Select)
Static IP Address: (Select) IPv4/v6 Address/Hostname: 1.1.1.1

Preshare key: Juniper

Outgoing interface: (select) ethernet2/1
Security Level: Standard
3. Configure VPN spoke to gateway
VPNs > AutoKey IKE > New: Configure the IKE gateway, click Advanced and
set the security level, then click Return to go back to the IKE gateway
configuration page and click OK:

VPN Name: vpn-hub

Remote Gateway: (select) Predefined
(select appropriate gateway name from predefined list from drop-down list)

Security Level (select) Standard

Bind To: (select) Tunnel Interface
(select Tunnel.1 from the drop-down list)
4. Configure ACVPN-Dynamic
VPNs > AutoKey Advanced > Gateway > New: Enter the following, then click
OK:

Gateway Name: ac-hub-gw

ACVPN-Dynamic: (select)

340  How It Works

 Chapter 8: AutoConnect-Virtual Private Networks

VPNs > AutoKey > New: Enter the following, then click OK:

VPN Name: ac-hub-vpn

ACVPN-Dynamic: (select)
Gateway (select): ac-hub-gw
Tunnel Towards Hub: (select) vpn-hub
5. Configure the virtual router
Network > Routing > Virtual Router > (for trust-vr) Edit: Enter the following,
then click Apply:

Next Hop Resolution Protocol(NHRP) Support

NHRP Enable: (select)
NHC Setting: (select)
NHS IP Address: 10.1.1.1
6. Enable NHRP on the tunnel interface
Network > Interfaces > New (for TunnelIF): Enter the following, then click
Apply:

Tunnel Interface Name: 1

NHRP Enable: (select)
7. Configure routing
Network > Routing > Destination > New: Enter the following, then click
Apply:

IP Address/netmask: 0.0.0.0
Gateway (select)
Gateway IP Address: 2.2.2.2

CLI (Spoke1)
set interface ethernet0/0 zone Untrust
set interface bgroup0 zone Trust
set interface bgroup0 port ethernet0/2
set interface tunnel.1 zone Trust

set interface ethernet0/0 ip 2.2.2.1/24

set interface ethernet0/0 route
set interface bgroup0 ip 10.1.2.1/24
set interface bgroup0 nat
set interface tunnel.1 ip 10.0.0.2/24

set ike gateway hub-gw address 1.1.1.1 Main outgoing-interface ethernet0/0

preshare juniper== sec-level standard
set vpn vpn-hub id 1 bind interface tunnel.1

set ike gateway ac-hub-gw acvpn-dynamic

set vpn ac-hub-vpn acvpn-dynamic ac-hub-gw vpn-hub

set vrouter trust-vr

set protocol nhrp
set protocol nhrp nhs 10.0.0.1
exit
set interface tunnel.1 protocol nhrp enable

How It Works  341

 Concepts & Examples ScreenOS Reference Guide

set vr trust protocol ospf

set vr trust protocol ospf enable
set vr trust protocol ospf area 20

set interface bgroup0 protocol ospf area 0.0.0.20

set interface bgroup0 protocol ospf enable
set interface tunnel.1 protocol ospf area 0.0.0.0
set interface tunnel.1 protocol ospf enable
set route 0.0.0.0/0 gateway 2.2.2.2

WebUI (Spoke2)
1. Interfaces
Network > Interfaces > Edit (for ethernet0/0): Enter the following, then click
Apply:

Zone Name: Untrust

IP Address/Netmask: 3.3.3.1/24
Interface Mode: Route

Network > Interfaces > Edit (for bgroup0): Enter the following, then click
Apply:

Zone Name: Trust

Network > Interfaces > Edit (for ethernet2/2): Enter the following, then click
Apply:

Zone Name: Trust

IP Address/Netmask: 10.1.3.1/24
Interface Mode: NAT

Network > Interfaces > Edit (for ethernet2/2), Select Bind Port, enter the
following, then click Apply:

ethernet0/2 bgroup0: (select) Bind to Current Bgroup

Network > Interfaces > New (Tunnel IF): Enter the following, then click Apply:

Tunnel Interface Name: 1

Zone (VR): Trust-vr
Fixed IP
IP Address/Netmask: 10.0.0.3/24
NHRP Enable: (Select)
2. Configure tunnel to the hub
VPNs > AutoKey Advanced > Gateway > New: Configure the IKE gateway,
click Advanced and set the security level, then click Return to go back to the
IKE gateway configuration page and click OK:

Gateway Name: hub-gw

Remote Gateway: (Select)
Static IP Address: (Select) IPv4/v6 Address/Hostname: 1.1.1.1

Preshare key: Juniper

Outgoing interface: (select) ethernet2/1
Security Level: Standard

342  How It Works

 Chapter 8: AutoConnect-Virtual Private Networks

3. Configure VPN spoke to gateway

VPNs > AutoKey IKE > New: Configure the IKE gateway, click Advanced and
set the security level, then click Return to go back to the IKE gateway
configuration page and click OK:

VPN Name: vpn-hub

Remote Gateway: (select) Predefined
(select appropriate gateway name from predefined list from drop-down list)

Security Level (select) Standard

Bind To: (select) Tunnel Interface
(select Tunnel.1 from the drop-down list)
4. Configure ACVPN-Dynamic
VPNs > AutoKey Advanced > Gateway > New: Enter the following, then click
OK:

Gatewary Name: ac-hub-gw

ACVPN-Dynamic: (select)

VPNs > AutoKey > New: Enter the following, then click OK:

VPN Name: ac-hub-vpn

ACVPN-Dynamic: (select)
Gateway (select): ac-hub-gw
Tunnel Towards Hub: (select) vpn-hub
5. Configure vrouter
Network > Routing > Virtual Router > (for trust-vr) Edit: Enter the following,
then click Apply:

Next Hop Resolution Protocol(NHRP) Support

NHRP Enable: (select)
NHC Setting: (select)
NHS IP Address: 1.1.1.1
6. Enable NHRP on the tunnel interface
Network > Interfaces > New (for TunnelIF): Enter the following, then click
Apply:

Tunnel Interface Name: 1

NHRP Enable: (select)
7. Configure routing
Network > Routing > Destination > New: Enter the following, then click
Apply:

IP Address/netmask: 0.0.0.0
Gateway (select)
Gateway IP Address: 3.3.3.3

CLI (Spoke2)
set interface ethernet0/0 zone Untrust
set interface bgroup0 zone Trust
set interface bgroup0 port ethernet0/2
set interface tunnel.1 zone Trust

How It Works  343

 Concepts & Examples ScreenOS Reference Guide

set interface ethernet0/0 ip 3.3.3.1/24

set interface ethernet0/0 route
set interface bgroup0 ip 10.1.3.1/24
set interface bgroup0 nat
set interface tunnel.1 ip 10.0.0.3/24
set ike gateway hub-gw address 1.1.1.1 Main outgoing-interface ethernet0/0
preshare juniper== sec-level standard
set vpn vpn-hub id 1 bind interface tunnel.1

set ike gateway ac-hub-gw acvpn-dynamic

set vpn ac-hub-vpn acvpn-dynamic ac-hub-gw vpn-hub

set vrouter trust-vr

set protocol nhrp
set protocol nhrp nhs 10.0.0.1
exit

set interface tunnel.1 protocol nhrp enable

set vr trust protocol ospf

set vr trust protocol ospf enable
set vr trust protocol ospf area 30
set interface bgroup0 protocol ospf area 0.0.0.30
set interface bgroup0 protocol ospf enable
set interface tunnel.1 protocol ospf area 0.0.0.0
set interface tunnel.1 protocol ospf enable
set route 0.0.0.0/0 gateway 3.3.3.3

344  How It Works

Index
Numerics IPSec protocols ..................................................63, 70
3DES .................................................................................6 key methods ............................................................59
PFS ......................................................................63, 69
A Phase 1 modes ..................................................59, 66
Advanced Encryption Standard (AES) ...........................6 site-to-site ........................................................58 to 65
Aggressive mode............................................................10 site-to-site VPN recommendations ........................65
AH..................................................................................3, 5 Transport mode .......................................................70
anti-replay checking ................................................62, 69 Tunnel mode ............................................................70
attacks
Replay .......................................................................12 D
authentication Data Encryption Standard (DES) ....................................6
algorithms ..........................................6, 61, 64, 67, 71 DES ....................................................................................6
Authentication Header (AH) ...........................................5 DH
AutoKey IKE VPN .............................................................7 IKEv2 ........................................................................18
AutoKey IKE VPN management .....................................7 Diffie-Hellman ................................................................10
digital signature ..............................................................30
C DIP pools
CA certificates ..........................................................32, 35 extended interfaces...............................................150
Certificate Revocation List ......................................33, 44 NAT for VPNs .........................................................150
loading ......................................................................33 distinguished name (DN) ............................................193
certificates ........................................................................7 DN .................................................................................193
CA........................................................................32, 35 DNS, L2TP settings ......................................................221
loading ......................................................................38
loading CRL ..............................................................33 E
local...........................................................................35 EAP messages ................................................................25
requesting ................................................................36 Encapsulating Security Payload
revocation ..........................................................35, 44 See ESP
via email ...................................................................35 encryption
Challenge Handshake Authentication Protocol algorithms .............................................6, 61, 64 to 71
See CHAP ESP ............................................................................3, 5, 6
CHAP .....................................................................218, 221 authenticate only .....................................................64
containers .....................................................................196 encrypt and authenticate .................................64, 70
CREATE ...........................................................................11 encrypt only .............................................................64
CRL exchanges
See Certificate Revocation List CHILD_SA .................................................................11
cryptographic options ..........................................58 to 71 informational ...........................................................19
anti-replay checking ..........................................62, 69 initial .........................................................................17
authentication algorithms ....................61, 64, 67, 71 Extensible Authentication Protocol passthrough .......25
authentication types .........................................60, 66
certificate bit lengths ........................................60, 66 G
dialup ...............................................................65 to 71 group IKE ID
dialup VPN recommendations ...............................71 certificates ...................................................193 to 202
encryption algorithms .............................61 to 67, 71 preshared keys ...........................................202 to 208
ESP ......................................................................64, 70
IKE ID ...............................................61 to 62, 67 to 68

Index  IX-I
 Concepts & Examples ScreenOS Reference Guide

H K
hash-based message authentication code .................... 6 keepalive
HMAC ................................................................................ 6 frequency, NAT-T ..................................................247
L2TP ........................................................................226
I keys
IKE............................................................... 7, 96, 105, 170 manual............................................................128, 134
group IKE ID user ....................................... 193 to 208 preshared ...............................................................170
group IKE ID, container ....................................... 196
group IKE ID, wildcards ....................................... 196 L
heartbeats .............................................................. 304 L2TP ...................................................................215 to 240
hello messages ...................................................... 304 access concentrator: See LAC
IKE ID ...............................................61 to 62, 67 to 68 bidirectional ...........................................................218
IKE ID recommendations ...................................... 80 compulsory configuration ....................................215
IKE ID, Windows 2000 ................................. 229, 237 decapsulation .........................................................219
local ID, ASN1-DN ................................................. 195 default parameters ................................................221
Phase 1 proposals, predefined ................................ 9 encapsulation.........................................................218
Phase 2 proposals, predefined .............................. 11 hello signal .....................................................226, 231
proxy IDs ................................................................. 11 Keep Alive ......................................................226, 231
redundant gateways .................................. 301 to 314 L2TP-only on Windows 2000 ..............................217
remote ID, ASN1-DN ............................................ 195 network server: See LNS
shared IKE ID user ..................................... 208 to 214 operational mode ..................................................218
IKEv2 RADIUS server .......................................................221
Diffie-Hellman ......................................................... 18 ScreenOS support .................................................217
EAP passthrough ..................................................... 25 SecurID server .......................................................221
enabling.................................................................... 17 tunnel......................................................................223
enabling on a security device ................................ 19 voluntary configuration ........................................215
messages .................................................................. 25 Windows 2000 tunnel authentication ........226, 231
SA .............................................................................. 17 L2TP-over-IPSec ...............................................4, 223, 228
informational exchanges .............................................. 19 bidirectional ...........................................................218
initial exchanges ............................................................ 17 tunnel......................................................................223
interfaces LAC ................................................................................215
extended ................................................................ 150 NetScreen-Remote 5.0..........................................215
null ............................................................................ 95 Windows 2000 ......................................................215
Internet Key Exchange Layer 2 Tunneling Protocol
See IKE See L2TP
Internet Key Exchange version 2 LNS ................................................................................215
See IKEv2 local certificate ...............................................................35
Internet Protocol (IP) addresses
See IP addresses M
IP addresses Main mode .......................................................................9
extended ................................................................ 150 Manual Key
IP Security management..............................................................7
See IPSec manual keys .........................................................128, 134
IPSec MD5...................................................................................6
AH ................................................................... 2, 63, 70 Message Digest version 5 (MD5)....................................6
digital signature ....................................................... 30 messages
ESP .................................................................. 2, 63, 70 EAP ...........................................................................25
L2TP-over-IPSec ........................................................ 4 IKEv2 ........................................................................25
SAs .................................................................... 2, 8, 11 MIB files, importing .....................................................263
SPI ............................................................................... 2 MIP, VPNs .....................................................................150
Transport mode ................................ 4, 218, 223, 228 modes
tunnel ......................................................................... 2 Aggressive ................................................................10
Tunnel mode ............................................................. 4 L2TP operational ...................................................218
tunnel negotiation ..................................................... 8 Main ............................................................................9

IX-II  Index
 Index

Phase 1 cryptographic ......................................59, 66 Phase 2 ...........................................................................11

Transport ......................................4, 70, 218, 223, 228 proposals ..................................................................11
Tunnel ...................................................................4, 70 proposals, predefined .............................................11
modulus ..........................................................................10 PKI ...................................................................................32
Point-to-Point Protocol
N See PPP
NAT policies
IPSec and NAT .......................................................242 bidirectional VPNs .................................................135
NAT servers............................................................242 policy-based VPNs .........................................................72
NAT-dst PPP ................................................................................216
VPNs .......................................................................150 preshared key ...................................................................7
NAT-src preshared keys .............................................................170
VPNs .......................................................................152 proposals
NAT-T ..................................................................242 to 250 Phase 1 .................................................................9, 79
enabling ..................................................................249 Phase 2 ...............................................................11, 79
IKE packet ..............................................................245 Protected EAP ................................................................24
initiator and responder .........................................247 protocols
IPSec packet...........................................................246 CHAP.......................................................................218
keepalive frequency ..............................................247 PAP..........................................................................218
obstacles for VPNs ................................................245 PPP ..........................................................................216
probing for NAT..........................................243 to 244 proxy IDs ........................................................................11
NAT-Traversal matching ............................................................73, 79
See NAT-T VPNs and NAT ............................................150 to 151
NetScreen-Remote Public key infrastructure
AutoKey IKE VPN ..................................................170 See PKI
dynamic peer .................................................176, 183 Public/private key pair...................................................33
NAT-T option .........................................................242
NHTB table ........................................................265 to 269 R
addressing scheme ...............................................267 RADIUS
automatic entries ..................................................268 L2TP ........................................................................221
manual entries .......................................................268 redundant gateways .........................................301 to 314
mapping routes to tunnels ...................................265 recovery procedure ...............................................305
null route ........................................................................95 TCP SYN flag checking..........................................307
rekey option, VPN monitoring ...................................253
O replay protection ............................................................12
OCSP (Online Certificate Status Protocol)...................44 request/response pairs ..................................................18
client .........................................................................44 route-based VPNs..................................................72 to 73
responder .................................................................44 routes
null ............................................................................95
P
packet flow S
inbound VPN...................................................76 to 78 SAs ...............................................................................8, 11
outbound VPN .........................................................76 check in packet flow ...............................................75
policy-based VPN ...........................................78 to 79 SCEP (Simple Certificate Enrollment Protocol) ..........40
route-based VPN .............................................73 to 78 Secure Hash Algorithm-1
PAP ........................................................................218, 221 See SHA-1
Password Authentication Protocol SecurID
See PAP L2TP ........................................................................221
Perfect Forward Secrecy security associations
See PFS IKEv2 ........................................................................17
PFS ......................................................................11, 63, 69 See SAs
Phase 1 .............................................................................9 SHA-1 ................................................................................6
proposals ....................................................................9 SKEYSEED ......................................................................18
proposals, predefined ...............................................9 SNMP

Index  IX-III
 Concepts & Examples ScreenOS Reference Guide

MIB files, importing .............................................. 263 replay protection .....................................................12

VPN monitoring .................................................... 263 route- vs policy-based .............................................72
SAs ..............................................................................8
T Transport mode .........................................................4
TCP tunnel always up ...................................................253
SYN flag checking ................................................. 307 VPN groups ............................................................302
TLS .................................................................................. 24 VPN monitoring and rekey ..................................253
Transport mode ....................................... 4, 218, 223, 228
Triple DES W
See 3DES wildcards ......................................................................196
Tunnel mode .................................................................... 4 WINS
Tunneled TLS ................................................................. 24 L2TP settings .........................................................221

U X
UDP XAuth
checksum ............................................................... 247 VPN monitoring .....................................................254
NAT-T encapsulation ............................................ 242
users
group IKE ID ............................................... 193 to 208
shared IKE ID ............................................. 208 to 214

V
Verisign ........................................................................... 44
VPN monitoring ................................................ 252 to 263
destination address .................................... 254 to 256
destination address, XAuth .................................. 254
ICMP echo requests .............................................. 263
outgoing interface ...................................... 254 to 256
policies ................................................................... 255
rekey option .................................................. 253, 269
routing design.......................................................... 81
SNMP ...................................................................... 263
status changes ............................................... 252, 255
VPNs
Aggressive mode ..................................................... 10
AutoKey IKE .............................................................. 7
configuration tips ........................................... 79 to 81
cryptographic options.................................... 58 to 71
Diffie-Hellman exchange........................................ 10
FQDN aliases ......................................................... 140
FQDN for gateways ................................... 139 to 150
Main mode ................................................................. 9
MIP.......................................................................... 150
multiple tunnels per tunnel interface ...... 265 to 299
NAT for overlapping addresses ................ 150 to 161
NAT-dst................................................................... 150
NAT-src ................................................................... 152
packet flow ..................................................... 73 to 79
Phase 1 ....................................................................... 9
Phase 2 ..................................................................... 11
policies for bidirectional ....................................... 135
proxy IDs, matching ............................................... 79
redundant gateways .................................. 301 to 314
redundant groups, recovery procedure .............. 305

IX-IV  Index
Concepts & Examples
ScreenOS Reference Guide

Volume 6:
Voice-over-Internet Protocol

Release 6.1.0, Rev. 02

Juniper Networks, Inc.

1194 North Mathilda Avenue
Sunnyvale, CA 94089
USA
408-745-2000
www.juniper.net
 Copyright Notice
Copyright © 2008 Juniper Networks, Inc. All rights reserved.

Juniper Networks, the Juniper Networks logo, JUNOS, NetScreen, ScreenOS, and Steel-Belted Radius are registered trademarks of Juniper Networks, Inc.
in the United States and other countries. JUNOSe is a trademark of Juniper Networks, Inc. All other trademarks, service marks, registered trademarks, or
registered service marks are the property of their respective owners.

All specifications are subject to change without notice. Juniper Networks assumes no responsibility for any inaccuracies in this document or for any
obligation to update information in this document. Juniper Networks reserves the right to change, modify, transfer, or otherwise revise this publication
without notice.

FCC Statement
The following information is for FCC compliance of Class A devices: This equipment has been tested and found to comply with the limits for a Class A
digital device, pursuant to part 15 of the FCC rules. These limits are designed to provide reasonable protection against harmful interference when the
equipment is operated in a commercial environment. The equipment generates, uses, and can radiate radio-frequency energy and, if not installed and
used in accordance with the instruction manual, may cause harmful interference to radio communications. Operation of this equipment in a residential
area is likely to cause harmful interference, in which case users will be required to correct the interference at their own expense.

The following information is for FCC compliance of Class B devices: The equipment described in this manual generates and may radiate radio-frequency
energy. If it is not installed in accordance with Juniper Networks’ installation instructions, it may cause interference with radio and television reception.
This equipment has been tested and found to comply with the limits for a Class B digital device in accordance with the specifications in part 15 of the FCC
rules. These specifications are designed to provide reasonable protection against such interference in a residential installation. However, there is no
guarantee that interference will not occur in a particular installation.

If this equipment does cause harmful interference to radio or television reception, which can be determined by turning the equipment off and on, the user
is encouraged to try to correct the interference by one or more of the following measures:

 Reorient or relocate the receiving antenna.

 Increase the separation between the equipment and receiver.

 Consult the dealer or an experienced radio/TV technician for help.

 Connect the equipment to an outlet on a circuit different from that to which the receiver is connected.

Caution: Changes or modifications to this product could void the user's warranty and authority to operate this device.

Disclaimer
THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED
WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED
WARRANTY, CONTACT YOUR JUNIPER NETWORKS REPRESENTATIVE FOR A COPY.

ii 
Table of Contents
About This Volume vii
Document Conventions................................................................................. viii
Web User Interface Conventions ........................................................... viii
Command Line Interface Conventions ................................................... viii
Naming Conventions and Character Types .............................................. ix
Illustration Conventions ............................................................................ x
Requesting Technical Support .......................................................................... x
Self-Help Online Tools and Resources....................................................... xi
Opening a Case with JTAC ........................................................................ xi
Document Feedback ....................................................................................... xi

Chapter 1 H.323 Application Layer Gateway 1

Overview ......................................................................................................... 1
Alternate Gatekeeper ....................................................................................... 2
Examples ......................................................................................................... 2
Example: Gatekeeper in the Trust Zone ..................................................... 2
Example: Gatekeeper in the Untrust Zone ................................................. 4
Example: Outgoing Calls with NAT ............................................................ 5
Example: Incoming Calls with NAT............................................................ 8
Example: Gatekeeper in the Untrust Zone with NAT................................ 10

Chapter 2 Session Initiation Protocol Application Layer Gateway 15

Overview ....................................................................................................... 15
SIP Request Methods ............................................................................... 16
Classes of SIP Responses ......................................................................... 18
SIP Application Layer Gateway ................................................................ 19
Session Description Protocol Sessions ..................................................... 20
Pinhole Creation ...................................................................................... 21
Session Inactivity Timeout....................................................................... 22
SIP Attack Protection ............................................................................... 23
Example: SIP Protect Deny ............................................................... 23
Example: UDP Flooding Protection ................................................... 24
SIP with Network Address Translation ........................................................... 25
Outgoing Calls ......................................................................................... 26
Incoming Calls......................................................................................... 26
Forwarded Calls....................................................................................... 27
Call Termination ...................................................................................... 27
Call Re-INVITE Messages ......................................................................... 27
Call Session Timers.................................................................................. 27
Call Cancellation ...................................................................................... 27
Forking .................................................................................................... 28
SIP Messages ........................................................................................... 28
SIP Headers ............................................................................................. 28

Table of Contents  iii

 Concepts & Examples ScreenOS Reference Guide

SIP Body.................................................................................................. 30
SIP NAT Scenario..................................................................................... 30
Examples ....................................................................................................... 32
Incoming SIP Call Support Using the SIP Registrar................................... 33
Example: Incoming Call (Interface DIP)............................................. 34
Example: Incoming Call (DIP Pool)....................................................37
Example: Incoming Call with MIP ..................................................... 39
Example: Proxy in the Private Zone .................................................. 41
Example: Proxy in the Public Zone ................................................... 44
Example: Untrust Intrazone .............................................................. 49
Example: Trust Intrazone.................................................................. 53
Example: Full-Mesh VPN for SIP........................................................ 55
Bandwidth Management for VoIP Services .............................................. 64

Chapter 3 Media Gateway Control Protocol Application Layer Gateway 67

Overview ....................................................................................................... 67
MGCP Security ............................................................................................... 68
About MGCP................................................................................................... 68
Entities in MGCP...................................................................................... 68
Endpoint ........................................................................................... 69
Connection ....................................................................................... 69
Call.................................................................................................... 69
Call Agent ......................................................................................... 69
Commands..............................................................................................70
Response Codes ...................................................................................... 72
Examples ....................................................................................................... 73
Media Gateway in Subscribers’ Homes—Call Agent at the ISP ................. 73
ISP-Hosted Service................................................................................... 76

Chapter 4 Skinny Client Control Protocol Application Layer Gateway 81

Overview ....................................................................................................... 81
SCCP Security ................................................................................................ 82
About SCCP.................................................................................................... 83
SCCP Components................................................................................... 83
SCCP Client ....................................................................................... 83
Call Manager ..................................................................................... 83
Cluster ..............................................................................................83
SCCP Transactions................................................................................... 84
Client Initialization ............................................................................ 84
Client Registration............................................................................. 84
Call Setup.......................................................................................... 85
Media Setup ...................................................................................... 85
SCCP Control Messages and RTP Flow..................................................... 86
SCCP Messages........................................................................................ 87
Examples ....................................................................................................... 87
Example: Call Manager/TFTP Server in the Trust Zone...................... 88
Example: Call Manager/TFTP Server in the Untrust Zone .................. 90
Example: Three-Zone, Call Manager/TFTP Server in the DMZ ........... 92
Example: Intrazone, Call Manager/TFTP Server in Trust Zone ........... 95
Example: Intrazone, Call Manager/TFTP Server in Untrust Zone ....... 99
Example: Full-Mesh VPN for SCCP ..................................................101

iv  Table of Contents
 Table of Contents

Chapter 5 Apple iChat Application Layer Gateway 111

Overview .....................................................................................................111
Configuring the AppleiChat ALG ...................................................................112
Configuration Examples ...............................................................................113
Scenario 1: Private–Public Network.......................................................113
Scenario 2: Intrazone Call Within Private Network ................................117
Scenario 3: Users Across Different Networks .........................................120

Index..........................................................................................................................IX-I

Table of Contents  v
 Concepts & Examples ScreenOS Reference Guide

vi  Table of Contents
About This Volume

Volume 6: Voice-over-Internet Protocol describes the supported VoIP Application

Layer Gateways (ALGs) and contains the following chapters:

 Chapter 1, “H.323 Application Layer Gateway,” describes the H.323 protocol

and provides examples of typical scenarios.

 Chapter 2, “Session Initiation Protocol Application Layer Gateway,” describes

the Session Initiation Protocol (SIP) and shows how the SIP ALG processes calls
in Route and Network Address Translation (NAT) modes. Examples of typical
scenarios follow a summary of the SIP architecture.

 Chapter 3, “Media Gateway Control Protocol Application Layer Gateway,”

presents an overview of the Media Gateway Control Protocol (MGCP) ALG and
lists the firewall security features of the implementation. Examples of typical
scenarios follow a summary of the MGCP architecture.

 Chapter 4, “Skinny Client Control Protocol Application Layer Gateway,”

presents an overview of the Skinny Client Control Protocol (SCCP) ALG and lists
the firewall security features of the implementation. Examples of typical
scenarios follow a summary of the SCCP architecture.

 Chapter 5, “Apple iChat Application Layer Gateway,” presents an overview of

the AppleiChat ALG and lists the firewall security features of the
implementation. Examples of typical scenarios follow a summary of the
AppleiChat architecture.

 vii
 Concepts & Examples ScreenOS Reference Guide

Document Conventions
This document uses the conventions described in the following sections:

 “Web User Interface Conventions” on page viii

 “Command Line Interface Conventions” on page viii

 “Naming Conventions and Character Types” on page ix

 “Illustration Conventions” on page x

Web User Interface Conventions

The Web user interface (WebUI) contains a navigational path and configuration
settings. To enter configuration settings, begin by clicking a menu item in the
navigation tree on the left side of the screen. As you proceed, your navigation path
appears at the top of the screen, with each page separated by angle brackets.

The following example shows the WebUI path and parameters for defining an
address:

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: addr_1

IP Address/Domain Name:
IP/Netmask: (select), 10.2.2.5/32
Zone: Untrust

To open Online Help for configuration settings, click the question mark (?) in the
upper left of the screen.

The navigation tree also provides a Help > Config Guide configuration page to help
you configure security policies and Internet Protocol Security (IPSec). Select an
option from the list, and follow the instructions on the page. Click the ? character in
the upper left for Online Help on the Config Guide.

Command Line Interface Conventions

The following conventions are used to present the syntax of command line
interface (CLI) commands in text and examples.

In text, commands are in boldface type and variables are in italic type.

In examples:

 Variables are in italic type.

 Anything inside square brackets [ ] is optional.

 Anything inside braces { } is required.

viii  Document Conventions

 About This Volume

 If there is more than one choice, each choice is separated by a pipe ( | ). For
example, the following command means “set the management options for the
ethernet1, the ethernet2, or the ethernet3 interface”:

set interface { ethernet1 | ethernet2 | ethernet3 } manage

NOTE: When entering a keyword, you only have to type enough letters to identify the
word uniquely. Typing set adm u whee j12fmt54 will enter the command set
admin user wheezer j12fmt54. However, all the commands documented in this
guide are presented in their entirety.

Naming Conventions and Character Types

ScreenOS employs the following conventions regarding the names of objects—such
as addresses, admin users, auth servers, IKE gateways, virtual systems, VPN
tunnels, and zones—defined in ScreenOS configurations:

 If a name string includes one or more spaces, the entire string must be
enclosed within double quotes; for example:

set address trust “local LAN” 10.1.1.0/24

 Any leading spaces or trailing text within a set of double quotes are trimmed;
for example, “ local LAN ” becomes “local LAN”.

 Multiple consecutive spaces are treated as a single space.

 Name strings are case-sensitive, although many CLI keywords are

case-insensitive. For example, “local LAN” is different from “local lan”.

ScreenOS supports the following character types:

 Single-byte character sets (SBCS) and multiple-byte character sets (MBCS).

Examples of SBCS are ASCII, European, and Hebrew. Examples of MBCS—also
referred to as double-byte character sets (DBCS)—are Chinese, Korean, and
Japanese.

 ASCII characters from 32 (0x20 in hexadecimals) to 255 (0xff), except double

quotes ( “ ), which have special significance as an indicator of the beginning or
end of a name string that includes spaces.

NOTE: A console connection only supports SBCS. The WebUI supports both SBCS and
MBCS, depending on the character sets that your browser supports.

Document Conventions  ix
 Concepts & Examples ScreenOS Reference Guide

Illustration Conventions
Figure 1 shows the basic set of images used in illustrations throughout this volume.

Figure 1: Images in Illustrations

Autonomous System Local Area Network (LAN)

or with a Single Subnet
Virtual Routing Domain or
Security Zone

Dynamic IP (DIP) Pool

Internet

Security Zone Interfaces: Policy Engine

White = Protected Zone Interface
(example = Trust Zone)
Black = Outside Zone Interface
(example = Untrust Zone)
Generic Network Device

Tunnel Interface

Server

VPN Tunnel

Router

Juniper Networks
Switch Security Devices

Hub

Requesting Technical Support

Technical product support is available through the Juniper Networks Technical
Assistance Center (JTAC). If you are a customer with an active J-Care or JNASC
support contract, or are covered under warranty, and need postsales technical
support, you can access our tools and resources online or open a case with JTAC.

 JTAC policies—For a complete understanding of our JTAC procedures and

policies, review the JTAC User Guide located at
http://www.juniper.net/customers/support/downloads/710059.pdf.

 Product warranties—For product warranty information, visit

http://www.juniper.net/support/warranty/.

 JTAC hours of operation—The JTAC centers have resources available 24 hours a

day, 7 days a week, 365 days a year.

x  Requesting Technical Support

 About This Volume

Self-Help Online Tools and Resources

For quick and easy problem resolution, Juniper Networks has designed an online
self-service portal called the Customer Support Center (CSC) that provides you with
the following features:

 Find CSC offerings—http://www.juniper.net/customers/support/

 Find product documentation—http://www.juniper.net/techpubs/

 Find solutions and answer questions using our Knowledge Base—

http://kb.juniper.net/

 Download the latest versions of software and review your release notes—
http://www.juniper.net/customers/csc/software/

 Search technical bulletins for relevant hardware and software notifications—

http://www.juniper.net/alerts/

 Join and participate in the Juniper Networks Community Forum—

http://www.juniper.net/company/communities/

 Open a case online in the CSC Case Manager—

http://www.juniper.net/customers/cm/

 To verify service entitlement by product serial number, use our Serial Number
Entitlement (SNE) Tool—
https://tools.juniper.net/SerialNumberEntitlementSearch/

Opening a Case with JTAC

You can open a case with JTAC on the Web or by telephone.

 Use the Case Manager tool in the CSC at http://www.juniper.net/customers/cm/.

 Call 1-888-314-JTAC (1-888-314-5822—toll free in USA, Canada, and Mexico).

For international or direct-dial options in countries without toll-free numbers, visit

us at http://www.juniper.net/customers/support/requesting-support/.

Document Feedback
If you find any errors or omissions in this document, contact Juniper Networks at
[email protected].

Document Feedback  xi
 Concepts & Examples ScreenOS Reference Guide

xii  Document Feedback

Chapter 1
H.323 Application Layer Gateway

This chapter describes the H.323 protocol and provides examples for configuring
the H.323 Application Layer Gateway (ALG) on a Juniper Networks security device.
This chapter contains the following sections:

 “Overview” on page 1

 “Alternate Gatekeeper” on page 2

Overview
The H.323 Application Layer Gateway (ALG) allows you secure voice over IP (VoIP)
communication between terminal endpoints such as IP phones and multimedia
devices. In such a telephony system, gatekeeper devices manage call registration,
admission, and call status for VoIP calls. Gatekeepers can reside in the two different
zones or in the same zone.

Figure 2: H.323 Protocol

Gatekeeper Gatekeeper
Permit

Trust Zone Internet

Permit

Endpoint Endpoint Untrust Zone

NOTE: Illustrations in this chapter use IP phones for illustrative purposes, although it is
possible to make configurations for other hosts that use VoIP, such as NetMeeting
multimedia devices.

Overview  1
 Concepts & Examples ScreenOS Reference Guide

Alternate Gatekeeper
The H.323 ALG in ScreenOS supports the use of an alternate gatekeeper. All the IP
end points must register with a gatekeeper through the Registration, Admission,
and Status (RAS) protocol before they can attempt calls between them. During the
registration process, the primary gatekeeper sends Gatekeeper Confirm (GCF) and
Registration Confirm (RCF) messages to the endpoint. These messages contain the
list of available alternate gatekeepers.

The alternate gatekeeper provides high availability, redundancy and scalability for
the IP end points. If the primary gatekeeper fails, IP-enabled phones and other
multimedia devices registered with that gatekeeper are registered with the alternate
gatekeeper.

You can configure the primary and alternate gatekeepers in the Trust, Untrust, or
DMZ zones.

NOTE: Currently, the Juniper Networks H.323 ALG supports the gatekeeper and the
alternate gatekeeper in the same zone.

To use the alternate gatekeeper feature, you need to configure a security policy that
allows the endpoint device to reach the alternate gatekeeper when the endpoint
cannot reach the primary gatekeeper.

Examples
This section contains the following configuration scenarios:

 “Example: Gatekeeper in the Trust Zone” on page 2

 “Example: Gatekeeper in the Untrust Zone” on page 4

 “Example: Outgoing Calls with NAT” on page 5

 “Example: Incoming Calls with NAT” on page 8

 “Example: Gatekeeper in the Untrust Zone with NAT” on page 10

Example: Gatekeeper in the Trust Zone

In the following example, you set up two policies that allow H.323 traffic to pass
between IP phone hosts and a gatekeeper in the Trust zone, and an IP phone host
(2.2.2.5) in the Untrust zone. In this example, the security device can be in either
Transparent mode or Route mode. Both the Trust and Untrust security zones are in
the trust-vr routing domain.

2  Alternate Gatekeeper
 Chapter 1: H.323 Application Layer Gateway

Figure 3: H.323 Gatekeeper in the Trust Zone

Trust Zone Untrust Zone

Gatekeeper Internet

Endpoint Endpoint
IP Phones IP Phone
2.2.2.5

WebUI
1. Address
Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: IP_Phone

IP Address/Domain Name:
IP/Netmask: (select), 2.2.2.5/32
Zone: Untrust
2. Policies
Policies > (From: Trust, To: Untrust) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), Any
Destination Address:
Address Book Entry: (select), IP_Phone
Service: H.323
Action: Permit

Policies > (From: Untrust, To: Trust) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), IP_Phone
Destination Address:
Address Book Entry: (select), Any
Service: H.323
Action: Permit

CLI
1. Address
set address untrust IP_Phone 2.2.2.5/32
2. Policies
set policy from trust to untrust any IP_Phone h.323 permit
set policy from untrust to trust IP_Phone any h.323 permit
save

Examples  3
 Concepts & Examples ScreenOS Reference Guide

Example: Gatekeeper in the Untrust Zone

Because Transparent mode and Route mode do not require address mapping of any
kind, security device configuration for a gatekeeper in the Untrust zone is usually
identical to the configuration for a gatekeeper in the Trust zone.

In the following example, you set up two policies to allow H.323 traffic to pass
between IP phone hosts in the Trust zone, and the IP phone at IP address 2.2.2.5
(and the gatekeeper) in the Untrust zone. The device can be in Transparent or Route
mode. Both the Trust and Untrust security zones are in the trust-vr routing domain.

Figure 4: H.323 Gatekeeper in the Untrust Zone

Trust Zone Untrust Zone

Internet
LAN

IP_Phone
IP_Phones 2.2.2.5/32

WebUI
1. Addresses
Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: IP_Phone

IP Address/Domain Name:
IP/Netmask: (select), 2.2.2.5/32
Zone: Untrust

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: Gatekeeper

IP Address/Domain Name:
IP/Netmask: (select), 2.2.2.10/32
Zone: Untrust
2. Policies
Policies > (From: Trust, To: Untrust) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), Any
Destination Address:
Address Book Entry: (select), IP_Phone
Service: H.323
Action: Permit

Policies > (From: Untrust, To: Trust) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), IP_Phone
Destination Address:
Address Book Entry: (select), Any

4  Examples
 Chapter 1: H.323 Application Layer Gateway

Service: H.323
Action: Permit

Policies > (From: Trust, To: Untrust) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), Any
Destination Address:
Address Book Entry: (select), Gatekeeper
Service: H.323
Action: Permit

CLI
1. Addresses
set address untrust IP_Phone 2.2.2.5/32
set address untrust gatekeeper 2.2.2.10/32
2. Policies
set policy from trust to untrust any IP_Phone h.323 permit
set policy from trust to untrust any gatekeeper h.323 permit
set policy from untrust to trust IP_Phone any h.323 permit
set policy from untrust to trust gatekeeper any h.323 permit
save

Example: Outgoing Calls with NAT

When the security device uses NAT (Network Address Translation), a gatekeeper or
endpoint device in the Trust zone has a private address, and when it is in the
Untrust zone it has a public address. When you set a security device in NAT mode,
you must map a public IP address to each device that needs to receive incoming
traffic with a private address.

In this example, the devices in the Trust zone include the endpoint host (10.1.1.5)
and the gatekeeper device (10.1.1.25). IP_Phone2 (2.2.2.5) is in the Untrust zone.
You configure the security device to allow traffic between the endpoint host
IP_Phone1 and the gatekeeper in the Trust zone and the endpoint host IP_Phone2
in the Untrust zone. Both the Trust and Untrust security zones are in the trust-vr
routing domain.

Figure 5: Network Address Translation—Outgoing Calls

ethernet1 ethernet3
10.1.1.1/24 1.1.1.1/24
Trust Zone Untrust Zone

Gatekeeper Internet
10.1.1.25
IP_Phone1 MIP 1.1.1.25 -> 10.1.1.25 Gateway IP_Phone2
10.1.1.5 MIP 1.1.1.5 -> 10.1.1.5 1.1.1.250 2.2.2.5

Examples  5
 Concepts & Examples ScreenOS Reference Guide

WebUI
1. Interfaces
Network > Interfaces > Edit (for ethernet1): Enter the following, then click
Apply:

Zone Name: Trust

Static IP: (select this option when present)
IP Address/Netmask: 10.1.1.1/24
Select the following, then click OK:
Interface Mode: NAT

Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:

Zone Name: Untrust

Static IP: (select this option when present)
IP Address/Netmask: 1.1.1.1/24
2. Addresses
Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: IP_Phone1

IP Address/Domain Name:
IP/Netmask: (select), 10.1.1.5/32
Zone: Trust

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: Gatekeeper

IP Address/Domain Name:
IP/Netmask: (select), 10.1.1.25/32
Zone: Trust

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: IP_Phone2

IP Address/Domain Name:
IP/Netmask: (select), 2.2.2.5/32
Zone: Untrust
3. Mapped IP Addresses
Network > Interfaces > Edit (for ethernet3) > MIP > New: Enter the
following, then click OK:

Mapped IP: 1.1.1.5

Netmask: 255.255.255.255
Host IP Address: 10.1.1.5
Host Virtual Router Name: trust-vr

6  Examples
 Chapter 1: H.323 Application Layer Gateway

Network > Interfaces > Edit (for ethernet3) > MIP > New: Enter the
following, then click OK:

Mapped IP: 1.1.1.25

Netmask: 255.255.255.255
Host IP Address: 10.1.1.25
Host Virtual Router Name: trust-vr
4. Route
Network > Routing > Destination > trust-vr New: Enter the following, then
click OK:

Network Address/Netmask: 0.0.0.0/0

Gateway: (select)
Interface: ethernet3
Gateway IP Address: 1.1.1.250
5. Policies
Policies > (From: Trust, To: Untrust) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), IP_Phone1
Destination Address:
Address Book Entry: (select), IP_Phone2
Service: H.323
Action: Permit

Policies > (From: Trust, To: Untrust) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), Gatekeeper
Destination Address:
Address Book Entry: (select), IP_Phone2
Service: H.323
Action: Permit

Policies > (From: Untrust, To: Trust) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), IP_Phone2
Destination Address:
Address Book Entry: (select), MIP(1.1.1.5)
Service: H.323
Action: Permit

Policies > (From: Untrust, To: Trust) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), IP_Phone2
Destination Address:
Address Book Entry: (select), MIP(1.1.1.25)
Service: H.323
Action: Permit

Examples  7
 Concepts & Examples ScreenOS Reference Guide

CLI
1. Interfaces
set interface ethernet1 zone trust
set interface ethernet1 ip 10.1.1.1/24
set interface ethernet3 zone untrust
set interface ethernet3 ip 1.1.1.1/24
2. Addresses
set address trust IP_Phone1 10.1.1.5/32
set address trust gatekeeper 10.1.1.25/32
set address untrust IP_Phone2 2.2.2.5/32
3. Mapped IP Addresses
set interface ethernet3 mip 1.1.1.5 host 10.1.1.5
set interface ethernet3 mip 1.1.1.25 host 10.1.1.25
4. Route
set vrouter trust-vr route 0.0.0.0/0 interface ethernet3 gateway 1.1.1.250
5. Policies
set policy from trust to untrust IP_Phone1 IP_Phone2 h.323 permit
set policy from trust to untrust gatekeeper IP_Phone2 h.323 permit
set policy from untrust to trust IP_Phone2 mip(1.1.1.5) h.323 permit
set policy from untrust to trust IP_Phone2 mip (1.1.1.25) h.323 permit
save

Example: Incoming Calls with NAT

In this example, you configure the security device to accept incoming calls over a
NAT boundary. To do this, you can create a DIP address pool for dynamically
allocating destination addresses. This differs from most configurations, where a DIP
pool provides source addresses only.

Figure 6: Network Address Translation—Incoming Calls

ethernet1 ethernet3
10.1.1.1/24 1.1.1.1/24
Trust Zone Untrust Zone

Internet

LAN
DIP Pool ID 5
1.1.1.12 ~ 1.1.1.150

The name of the DIP pool can be DIP(id_num) for a user-defined DIP, or
DIP(interface) when the DIP pool uses the same address as an interface IP address.
You can use such address entries as destination addresses in policies, together with
the services H.323, SIP, or other VoIP (Voice-over-IP) protocols, to support incoming
calls.

The following example uses DIP in an H.323 VoIP configuration. The keyword
“incoming” instructs the device to add the DIP and interface addresses to the global
zone.

8  Examples
 Chapter 1: H.323 Application Layer Gateway

WebUI
1. Interfaces
Network > Interfaces > Edit (for ethernet1): Enter the following, then click
Apply:

Zone Name: Trust

Static IP: (select this option when present)
IP Address/Netmask: 10.1.1.1/24
Enter the following, then click OK:
Interface Mode: NAT

Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:

Zone Name: Untrust

Static IP: (select this option when present)
IP Address/Netmask: 1.1.1.1/24
2. DIP with Incoming NAT
Network > Interface > Edit (for ethernet3) > DIP > New: Enter the following,
then click OK:

ID: 5
IP Address Range: (select), 1.1.1.12 ~ 1.1.1.150
Port Translation: (select)
In the same subnet as the interface IP or its secondary IPs: (select)
Incoming NAT: (select)
3. Addresses
Policy > Policy Elements > Addresses > List > New (for Trust): Enter the
following, then click OK:

Address Name: IP_Phones1

IP Address/Domain Name:
IP/Netmask: (select), 10.1.1.5/24
Zone: Trust

Policy > Policy Elements > Addresses > List > New (for Untrust): Enter the
following, then click OK:

Address Name: IP_Phone2

IP Address/Domain Name:
IP/Netmask: (select), 2.2.2.5/32
Zone: Untrust
4. Policies
Policies > (From: Trust, To: Untrust) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), IP_Phones1
Destination Address:
Address Book Entry: (select), Any
Service: H.323
Action: Permit

Examples  9
 Concepts & Examples ScreenOS Reference Guide

Policies > (From: Untrust, To: Trust) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), IP_Phone2
Destination Address:
Address Book Entry: (select), DIP(5)
Service: H.323
Action: Permit

CLI
1. Interfaces
set interface ethernet1 zone trust
set interface ethernet1 ip 10.1.1.1/24
set interface ethernet3 zone untrust
set interface ethernet3 ip 1.1.1.1/24
2. DIP with Incoming NAT
set interface ethernet3 dip 5 1.1.1.12 1.1.1.150 incoming
3. Addresses
set address trust IP_Phones1 10.1.1.5/24
set address untrust IP_Phone2 2.2.2.5/32
4. Policies
set policy from trust to untrust IP_Phones1 any h.323 nat src dip 5 permit
set policy from untrust to trust IP_Phone2 dip(5) h.323 permit
save

Example: Gatekeeper in the Untrust Zone with NAT

In this example, the gatekeeper device (2.2.2.25) and host IP_Phone2 (2.2.2.5) are
in the Untrust zone and host IP_Phone1 (10.1.1.5) is in the Trust zone. You
configure the security device to allow traffic between host IP_Phone1 in the Trust
zone and host IP_Phone2 (and the gatekeeper) in the Untrust zone. Both the Trust
and Untrust security zones are in the trust-vr routing domain.

Figure 7: Gatekeeper in the Untrust Zone

ethernet1 ethernet3 Gatekeeper
10.1.1.1/24 1.1.1.1/24 2.2.2.25
NAT Mode Gateway 1.1.1.250

Trust Zone Untrust Zone

LAN Internet

IP_Phone1 IP_Phone2
MIP 1.1.1.5 -> 10.1.1.5 2.2.2.5
10.1.1.5

10  Examples
 Chapter 1: H.323 Application Layer Gateway

WebUI
1. Interfaces
Network > Interfaces > Edit (for ethernet1): Enter the following, then click
Apply:

Zone Name: Trust

Static IP: (select this option when present)
IP Address/Netmask: 10.1.1.1/24
Enter the following, then click OK:
Interface Mode: NAT

Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:

Zone Name: Untrust

Static IP: (select this option when present)
IP Address/Netmask: 1.1.1.1/24
2. Addresses
Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: IP_Phone1

IP Address/Domain Name:
IP/Netmask: (select), 10.1.1.5/32
Zone: Trust

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: Gatekeeper

IP Address/Domain Name:
IP/Netmask: (select), 2.2.2.25/32
Zone: Untrust

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: IP_Phone2

IP Address/Domain Name:
IP/Netmask: (select), 2.2.2.5/32
Zone: Untrust
3. Mapped IP Address
Network > Interfaces > Edit (for ethernet3) > MIP > New: Enter the
following, then click OK:

Mapped IP: 1.1.1.5

Netmask: 255.255.255.255
Host IP Address: 10.1.1.5

Examples  11
 Concepts & Examples ScreenOS Reference Guide

4. Route
Network > Routing > Destination > trust-vr New: Enter the following, then
click OK:

Network Address/Netmask: 0.0.0.0/0

Gateway: (select)
Interface: ethernet3
Gateway IP Address: 1.1.1.250
5. Policies
Policies > (From: Trust, To: Untrust) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), IP_Phone1
Destination Address:
Address Book Entry: (select), IP_Phone2
Service: H.323
Action: Permit

Policies > (From: Trust, To: Untrust) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), IP_Phone1
Destination Address:
Address Book Entry: (select), Gatekeeper
Service: H.323
Action: Permit

Policies > (From: Untrust, To: Trust) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), IP_Phone2
Destination Address:
Address Book Entry: (select), MIP(1.1.1.5)
Service: H.323
Action: Permit

Policies > (From: Untrust, To: Trust) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), Gatekeeper
Destination Address:
Address Book Entry: (select), MIP(1.1.1.5)
Service: H.323
Action: Permit

CLI
1. Interfaces
set interface ethernet1 zone trust
set interface ethernet1 ip 10.1.1.1/24
set interface ethernet3 zone untrust
set interface ethernet3 ip 1.1.1.1/24
2. Addresses
set address trust IP_Phone1 10.1.1.5/32
set address untrust gatekeeper 2.2.2.25/32
set address untrust IP_Phone2 2.2.2.5/32

12  Examples
 Chapter 1: H.323 Application Layer Gateway

3. Mapped IP Addresses
set interface ethernet3 mip 1.1.1.5 host 10.1.1.5
4. Route
set vrouter trust-vr route 0.0.0.0/0 interface ethernet3 gateway 1.1.1.250
5. Policies
set policy from trust to untrust IP_Phone1 IP_Phone2 h.323 permit
set policy from trust to untrust IP_Phone1 gatekeeper h.323 permit
set policy from untrust to trust IP_Phone2 mip(1.1.1.5) h.323 permit
set policy from untrust to trust gatekeeper mip(1.1.1.5) h.323 permit
save

Examples  13
 Concepts & Examples ScreenOS Reference Guide

14  Examples
Chapter 2
Session Initiation Protocol
Application Layer Gateway

This chapter describes the Session Initiation Protocol (SIP) Application Layer
Gateway (ALG) and contains the following sections:

 “Overview” on page 15

 “SIP with Network Address Translation” on page 25

 “Examples” on page 32

Overview
Session Initiation Protocol (SIP) is an Internet Engineering Task Force
(IETF)-standard protocol for initiating, modifying, and terminating multimedia
sessions over the Internet. Such sessions might include conferencing, telephony, or
multimedia, with features such as instant messaging and application-level mobility
in network environments.

Juniper Networks security devices support SIP as a service and can screen SIP
traffic, allowing and denying it based on a policy that you configure. SIP is a
predefined service in ScreenOS and uses port 5060 as the destination port.

SIP’s primary function is to distribute session-description information and, during

the session, to negotiate and modify the parameters of the session. SIP is also used
to terminate a multimedia session.

Session-description information is included in INVITE and ACK messages and

indicates the multimedia type of the session, for example, voice or video. Although
SIP can use different description protocols to describe the session, the Juniper
Networks SIP ALG supports only Session Description Protocol (SDP).

SDP provides information that a system can use to join a multimedia session. SDP
might include information such as IP addresses, port numbers, times, and dates.
Note that the IP address and port number in the SDP header (the “c=” and “m=”
fields, respectively) are the address and port where the client wants to receive the
media streams and not the IP address and port number from which the SIP request
originates (although they can be the same). See “Session Description Protocol
Sessions” on page 20 for more information.

Overview  15
 Concepts & Examples ScreenOS Reference Guide

SIP messages consist of requests from a client to a server and responses to the
requests from a server to a client with the purpose of establishing a session (or a
call). A User Agent (UA) is an application that runs at the endpoints of the call and
consists of two parts: the User Agent Client (UAC), which sends SIP requests on
behalf of the user; and a User Agent Server (UAS), which listens to the responses
and notifies the user when they arrive. Examples of UAs are SIP proxy servers and
phones.

SIP Request Methods

The SIP transaction model includes a number of request and response messages,
each of which contains a method field that denotes the purpose of the message.
ScreenOS supports the following method types and response codes:

 INVITE—A user sends an INVITE request to invite another user to participate in

a session. The body of an INVITE request may contain the description of the
session. In NAT mode, the IP addresses in the Via:, From:, To:, Call-ID:,
Contact:, Route:, and Record-Route: header fields are modified as shown in
Table 2 on page 29.

 ACK—The user from whom the INVITE originated sends an ACK request to
confirm reception of the final response to the INVITE request. If the original
INVITE request did not contain the session description, the ACK request must
include it. In NAT mode, the IP addresses in the Via:, From:, To:, Call-ID:,
Contact:, Route:, and Record-Route: header fields are modified as shown in
Table 2 on page 29.

 OPTIONS—Used by the User Agent (UA) to obtain information about the

capabilities of the SIP proxy. A server responds with information about what
methods, session description protocols, and message encoding it supports. In
NAT mode, when the OPTIONS request is sent from a UA outside NAT to a
proxy inside NAT, the SIP ALG translates the address in the Request-URI and the
IP address in the To: field to the appropriate IP address of the internal client.
When the UA is inside NAT and the proxy is outside NAT, the SIP ALG translates
the From:, Via:, and Call-ID: fields as shown in Table 2 on page 29.

 BYE—A user sends a BYE request to abandon a session. A BYE request from
either user automatically terminates the session. In NAT mode, the IP addresses
in the Via:, From:, To:, Call-ID:, Contact:, Route:, and Record-Route: header
fields are modified as shown in Table 2 on page 29.

 CANCEL—A user can send a CANCEL request to cancel a pending INVITE

request. A CANCEL request has no effect if the SIP server processing the INVITE
had sent a final response for the INVITE before it received the CANCEL. In NAT
mode, the IP addresses in the Via:, From:, To:, Call-ID:, Contact:, Route:, and
Record-Route: header fields are modified as shown in Table 2 on page 29.

16  Overview
 Chapter 2: Session Initiation Protocol Application Layer Gateway

 REGISTER—A user sends a REGISTER request to a SIP registrar server to inform

it of the current location of the user. A SIP registrar server records all the
information it receives in REGISTER requests and makes this information
available to any SIP server attempting to locate a user. In NAT mode, REGISTER
requests are handled as follows:

 REGISTER requests from an external client to an internal registrar—When

the SIP ALG receives the incoming REGISTER request it translates the IP
address, if any, in the Request-URI. Incoming REGISTER messages are
allowed only to a MIP or VIP address. No translation is needed for the
outgoing response.

 REGISTER requests from an internal client to an external registrar—When

the SIP ALG receives the outgoing REGISTER request it translates the IP
addresses in the To:, From:, Via:, Call-ID:, and Contact: header fields. A
backward translation is performed for the incoming response.

 Info—Used to communicate mid-session signaling information along the

signaling path for the call. In NAT mode, the IP addresses in the Via:, From:, To:,
Call-ID:, Contact:, Route:, and Record-Route: header fields are modified as
shown in Table 2 on page 29.

 Subscribe—Used to request current state and state updates from a remote

node. In NAT mode, the address in the Request-URI is changed to a private IP
address if the messages is coming from the external network into the internal
network. The IP addresses in Via:, From:, To:, Call-ID:, Contact:, Route:, and
Record-Route: header fields are modified as shown in the table in Table 2 on
page 29.

 Notify—Sent to inform subscribers of changes in state to which the subscriber

has a subscription. In NAT mode, the IP address in the Request-URI: header
field is changed to a private IP address if the message is coming from the
external network into the internal network. The IP address in the Via:, From:,
To:, Call-ID:, Contact:, Route:, and Record-Route: header fields are modified as
shown in Table 2 on page 29.

 Refer—Used to refer the recipient (identified by the Request-URI) to a third

party by the contact information provided in the request. In NAT mode, the IP
address in the Request-URI is changed to a private IP address if the message is
coming from the external network into the internal network. The IP addresses
in the Via:, From:, To:, Call-ID:, Contact:, Route:, and Record-Route: header
fields are modified as shown in Table 2 on page 29.

For example, if user A in a private network refers user B, in a public network, to

user C, who is also in the private network, the SIP ALG allocates a new IP
address and port number for user C so that user C can be contacted by user B.
If user C is registered with a registrar, however, its port mapping is stored in the
ALG NAT table and is reused to perform the translation.

 Update—Used to open pinhole for new or updated SDP information. The Via:,
From:, To:, Call-ID:, Contact:, Route:, and Record-Route: header fields are
modified as shown in Table 2 on page 29.

 1xx, 202, 2xx, 3xx, 4xx, 5xx, 6xx Response Codes—Used to indicate the status
of a transaction. Header fields are modified as shown in Table 2 on page 29.

Overview  17
 Concepts & Examples ScreenOS Reference Guide

Classes of SIP Responses

SIP responses provide status information about SIP transactions and include a
response code and a reason phrase. SIP responses are grouped into the following
classes:

 Informational (100 to 199)—Request received, continuing to process the

request.

 Success (200 to 299)—Action successfully received, understood, and accepted.

 Redirection (300 to 399)—Further action required to complete the request.

 Client Error (400 to 499)—Request contains bad syntax or cannot be fulfilled at

this server.

 Server Error (500 to 599)—Server failed to fulfill an apparently valid request.

 Global Failure (600 to 699)—Request cannot be fulfilled at any server.

Table 1 provides a complete list of current SIP responses, all of which are supported
on Juniper Networks security devices.

Table 1: Session Initiation Protocol Responses

Class Response Code-Reason Phrase Response Code-Reason Phrase Response Code-Reason Phrase
Informational 100 Trying 180 Ringing 181 Call is being forwarded
182 Queued 183 Session progress
Success 200 OK 202 Accepted
Redirection 300 Multiple choices 301 Moved permanently 302 Moved temporarily
305 Use proxy 380 Alternative service
Client Error 400 Bad request 401 Unauthorized 402 Payment required
403 Forbidden 404 Not found 405 Method not allowed
406 Not acceptable 407 Proxy authentication required 408 Request time-out
409 Conflict 410 Gone 411 Length required
413 Request entity too large 414 Request-URL too large 415 Unsupported media type
420 Bad extension 480 Temporarily not available 481 Call leg/transaction does not
exist
482 Loop detected 483 Too many hops 484 Address incomplete
485 Ambiguous 486 Busy here 487 Request canceled
488 Not acceptable here
Server Error 500 Server internal error 501 Not implemented 502 Bad gateway
502 Service unavailable 504 Gateway time-out 505 SIP version not supported
Global Failure 600 Busy everywhere 603 Decline 604 Does not exist anywhere
606 Not acceptable

18  Overview
 Chapter 2: Session Initiation Protocol Application Layer Gateway

SIP Application Layer Gateway

There are two types of SIP traffic, the signaling and the media stream. SIP signaling
traffic consists of request and response messages between client and server and
uses transport protocols such as User Datagram Protocol (UDP) or Transmission
Control Protocol (TCP). The media stream carries the data (audio data, for example)
and uses Application Layer protocols such as Real Time Protocol (RTP) over UDP.

Juniper Networks security devices support SIP signaling messages on port 5060.
You can simply create a policy that permits SIP service, and the security device
filters SIP signaling traffic like any other type of traffic, permitting or denying it. The
media stream, however, uses dynamically assigned port numbers that can change
several times during the course of a call. Without fixed ports, it is impossible to
create a static policy to control media traffic. In this case, the security device
invokes the SIP ALG. The SIP ALG reads SIP messages and their SDP content and
extracts the port-number information it needs to dynamically open pinholes and let
the media stream traverse the security device.

NOTE: We refer to a pinhole as the limited opening of a port to allow exclusive traffic.

The SIP ALG monitors SIP transactions and dynamically creates and manages
pinholes based on the information it extracts from these transactions. The Juniper
Networks SIP ALG supports all SIP methods and responses (see “SIP Request
Methods” on page 16 and “Classes of SIP Responses” on page 18). You can allow
SIP transactions to traverse the Juniper Networks firewall by creating a static policy
that permits SIP service. This policy enables the security device to intercept SIP
traffic and do one of the following actions: permit or deny the traffic or enable the
SIP ALG to open pinholes to pass the media stream. The SIP ALG needs to open
pinholes only for the SIP requests and responses that contain media information
(SDP). For SIP messages that do not contain SDP, the security device simply lets
them through.

The SIP ALG intercepts SIP messages that contain SDP and, using a parser, extracts
the information it requires to create pinholes. The SIP ALG examines the SDP
portion of the packet, and a parser extracts information such as IP addresses and
port numbers, which the SIP ALG records in a pinhole table. The SIP ALG uses the IP
addresses and port numbers recorded in the pinhole table to open pinholes and
allow media streams to traverse the security device.

NOTE: Juniper Networks security devices do not support encrypted SDP. If a security
device receives a SIP message in which SDP is encrypted, the SIP ALG permits it
through the firewall but generates a log message informing the user that it cannot
process the packet. If SDP is encrypted, the SIP ALG cannot extract the
information it needs from SDP to open pinholes. As a result, the media content
that SDP describes cannot traverse the security device.

Overview  19
 Concepts & Examples ScreenOS Reference Guide

Session Description Protocol Sessions

An SDP session description is text-based and consists of a set of lines. It can contain
session-level and media-level information. The session-level information applies to
the whole session, while the media-level information applies to a particular media
stream. An SDP session description always contains session-level information,
which appears at the beginning of the description, and might contain media-level
information, which comes after.

NOTE: In the SDP session description, the media-level information begins with the m=
field.

Of the many fields in the SDP description, two are particularly useful to the SIP ALG
because they contain Transport Layer information. The two fields are the following:

 c= for connection information

This field can appear at the session or media level. It displays in this format:

 c=<network type><address type><connection address>

Currently, the security device supports "IN" (for Internet) as the network type,
"IP4 and IP6" as address types, and a unicast IP address or domain name as
the destination (connection) IP address.

NOTE: Generally, the destination IP address can also be a multicast IP address, but
ScreenOS does not currently support multicast with SIP.

If the destination IP address is a unicast IP address, the SIP ALG creates

pinholes using the IP address and port numbers specified in the media
description field m=.

 m= for media announcement

This field appears at the media level and contains the description of the media.
It displays in this format:

m=<media><port><transport><fmt list>

Currently, the security device supports only “audio” as the media and “RTP” as
the Application Layer transport protocol. The port number indicates the
destination (not the origin) of the media stream. The format list (fmt list)
provides information about the Application Layer protocol that the media uses.

In this release of ScreenOS, the security device opens ports only for RTP and
RTCP. Every RTP session has a corresponding Real Time Control Protocol
(RTCP) session. Therefore, whenever a media stream uses RTP, the SIP ALG
must reserve ports (create pinholes) for both RTP and RTCP traffic. By default,
the port number for RTCP is one higher than the RTP port number.

20  Overview
 Chapter 2: Session Initiation Protocol Application Layer Gateway

NOTE: Generally, the destination IP address can also be a multicast IP address, but
ScreenOS does not currently support multicast with SIP.

Pinhole Creation
Both pinholes for the RTP and RTCP traffic share the same destination IP address.
The IP address comes from the c= field in the SDP session description. Because the
c= field can appear in either the session-level or media-level portion of the SDP
session description, the parser determines the IP address based on the following
rules (in accordance with SDP conventions):

 First, the SIP ALG parser verifies if there is a c= field containing an IP address
in the media level. If there is one, the parser extracts that IP address, and the
SIP ALG uses it to create a pinhole for the media.

 If there is no c= field in the media level, the SIP ALG parser extracts the IP
address from the c= field in the session level, and the SIP ALG uses it to create
a pinhole for the media. If the session description does not contain a c= field
in either level, this indicates an error in the protocol stack, and the security
device drops the packet and logs the event.

The following lists the information the SIP ALG needs to create a pinhole. This
information comes from the SDP session description and parameters on the
security device:

 Protocol: UDP.

 Source IP: Unknown.

 Source port: Unknown.

 Destination IP: The parser extracts the destination IP address from the c= field
in the media or session level.

 Destination port: The parser extracts the destination port number for RTP from
the m= field in the media level and calculates the destination port number for
RTCP using the following formula:

RTP port number + one

 Lifetime: This value indicates the length of time (in seconds) during which a
pinhole is open to allow a packet through. A packet must go through the
pinhole before the lifetime expires. When the lifetime expires, the SIP ALG
removes the pinhole.

When a packet goes through the pinhole within the lifetime period,
immediately afterwards the SIP ALG removes the pinhole for the direction from
which the packet came.

Figure 8 describes a call setup between two SIP clients and how the SIP ALG
creates pinholes to allow RTP and RTCP traffic. The illustration assumes that the
security device has a policy that permits SIP, thus opening port 5060 for SIP
signaling messages.

Overview  21
 Concepts & Examples ScreenOS Reference Guide

Figure 8: SIP ALG Call Setup

Client A 1.1.1.1 Trust Zone Security Device SIP Proxy Untrust Zone Client B 2.2.2.2

1.Client A sends an INVITE request

destined for Client B to the SIP proxy
through port 5060 on the security 2. Per SDP, SIP ALG
device (SDP 1.1.1.1:2000) creates a pinhole for 3. The SIP proxy forwards an INVITE request
1.1.1.1: 2000 to Client B

5. The SIP proxy forwards the Ringing 4. Client B replies to the SIP proxy with a
response from Client B to Client A Ringing response
through port 5060 on the security device
7. Per SDP, SIP ALG 6. Client B sends a 200 OK response to the
creates pinhole for SIP proxy in reply to the INVITE request
8. The SIP proxy forwards a 200 OK (SDP: 2.2.2.2: 3000)
response from Client B to Client A 2.2.2.2: 3000
through the security device

9. Client A sends an ACK response

destined for Client B to the SIP proxy
through port 5060 on the security device
10. The SIP proxy forwards the ACK
response to Client B

11. Client B sends the media traffic

Pinhole 1 (RTP/RTCP) to Client A through pinhole 1
12. Client A sends the media traffic
(RTP/RTCP) to Client B through pinhole 2 Pinhole 2

NOTE: The SIP ALG does not create pinholes for RTP and RTCP traffic when the
destination IP address is 0.0.0.0, which indicates that the session is on hold. To
put a session on hold, during a telephone communication, for example, a user
(User A) sends the other user (User B) a SIP message in which the destination IP
address is 0.0.0.0. Doing so indicates to User B not to send any media until further
notice. If User B sends media anyway, the security device drops the packets.

Session Inactivity Timeout

Typically a call ends when one of the clients sends a BYE or CANCEL request. The
SIP ALG intercepts the BYE or CANCEL request and removes all media sessions for
that call. There could be reasons or problems preventing clients in a call from
sending BYE or CANCEL requests, for example, a power failure. In this case, the call
might go on indefinitely, consuming resources on the security device. The
inactivity-timeout feature helps the security device to monitor the liveliness of the
call and terminate it if there is no activity for a specific period of time.

A call can have one or more voice channels. Each voice channel has two sessions
(or two media streams), one for RTP and one for RTCP. When managing the
sessions, the security device considers the sessions in each voice channel as one
group. Settings such as the inactivity timeout apply to a group as opposed to each
session.

22  Overview
 Chapter 2: Session Initiation Protocol Application Layer Gateway

There are two types of inactivity timeouts that determine the lifetime of a group:

 Signaling-inactivity timeout: This parameter indicates the maximum length of

time (in seconds) a call can remain active without any SIP-signaling traffic. Each
time a SIP-signaling message occurs within a call, this timeout resets. The
default setting is 43200 seconds (12 hours).

 Media-inactivity timeout: This parameter indicates the maximum length of

time (in seconds) a call can remain active without any media (RTP or RTCP)
traffic within a group. Each time an RTP or RTCP packet occurs within a call,
this timeout resets. The default setting is 120 seconds.

If either of these timeouts expires, the security device removes all sessions for this
call from its table, thus terminating the call.

SIP Attack Protection

The ability of the SIP proxy server to process calls can be affected by repeat SIP
INVITE requests, whether malicious or through client or server error, that it initially
denied. To prevent the SIP proxy server from being overwhelmed by such requests,
you can use the sip protect deny command to configure the security device to
monitor INVITE requests and proxy server replies to them. The sip protect deny
command supports both IPv4 and IPv6 addresses. If a reply contains a 3xx, 4xx, or
5xx response code (see “Classes of SIP Responses” on page 18), the ALG stores the
source IP address of the request and the IP address of the proxy server in a table.
Subsequently, the security device checks all INVITE requests against this table and,
for a configurable number of seconds (the default is 3), discards any packets that
match entries in the table. You can also configure the security device to monitor
INVITE request to a specific proxy server by specifying the destination IP address.
SIP attack protection is configured globally.

Example: SIP Protect Deny

In this example, you configure the security device to protect a single SIP proxy
server (1.1.1.3/24) from repeat SIP requests to which it has already denied service.
Packets are dropped for a period of 5 seconds, after which the security device
resumes forwarding INVITE requests from those sources.

WebUI
You must use the CLI to protect SIP proxy servers from being inundated by SIP
messages.

CLI
set alg sip app-screen protect deny dst-ip 1.1.1.3/24
set alg sip protect deny timeout 5
save

Overview  23
 Concepts & Examples ScreenOS Reference Guide

Example: Signaling-Inactivity and Media-Inactivity Timeouts

In this example, you configure the signaling-inactivity timeout to 30,000 seconds
and the media-inactivity timeout to 90 seconds.

WebUI

NOTE: You must use the CLI to set SIP-signaling and media-inactivity timeouts.

CLI
set alg sip signaling-inactivity-timeout 30000
set alg sip media-inactivity-timeout 90
save

Example: UDP Flooding Protection

You can protect the security device against UDP flooding by zone and destination
address. In this example, you set a threshold of 80,000 per second for the number
of UDP packets that can be received on IP address 1.1.1.5, in the Untrust zone,
before the security device generates an alarm and drops subsequent packets for the
remainder of that second.

NOTE: This example uses a general ScreenOS command and is not necessarily
SIP-specific. For more information about UDP flood protection and how to
determine effective settings, see “UDP Flood” on page 4-51.

WebUI
Security > Screening > Screen: Enter the following, then click Apply:

Zone: Untrust
UDP Flood Protection (select)

> Destination IP: Enter the following, then click the Back arrow in your
browser to return to the Screen configuration page:

Destination IP: 1.1.1.5

Threshold: 80000
Add: (select)

CLI
set zone untrust screen udp-flood dst-ip 1.1.1.5 threshold 80000
save

24  Overview
 Chapter 2: Session Initiation Protocol Application Layer Gateway

Example: SIP Connection Maximum

In this example, you prevent flood attacks on the SIP network from attackers in the
Untrust zone by setting a maximum of 20 concurrent sessions from a single IP
address. If the security device detects more than 20 connection attempts from the
same IP address, it begins dropping subsequent attempts until the number of
sessions drops below the specified maximum.

NOTE: This example uses a general ScreenOS command and is not necessarily
SIP-specific. For more information about source-based session limits and how to
determine effective settings, see “Source-Based and Destination-Based Session
Limits” on page 4-28.

WebUI
Screening > Screen (Zone: Untrust): Enter the following, then click OK:

Source IP Based Session Limit: (select)

Threshold: 20 Sessions

CLI
set zone untrust screen limit-session source-ip-based 20
save

SIP with Network Address Translation

The Network Address Translation (NAT) protocol enables multiple hosts in a private
subnet to share a single public IP address to access the Internet. For outgoing traffic,
NAT replaces the private IP address of the host in the private subnet with the public
IP address. For incoming traffic, the public IP address is converted back into the
private address, and the message is routed to the appropriate host in the private
subnet.

Using NAT with the SIP service is more complicated because SIP messages contain
IP addresses in the SIP headers as well as in the SIP body. The SIP headers contain
information about the caller and the receiver, and the security device translates this
information to hide it from the outside network. The SIP body contains the Session
Description Protocol (SDP) information, which includes IP addresses and port
numbers for transmission of the media. The security device translates SDP
information for allocating resources to send and receive the media.

How IP addresses and port numbers in SIP messages are replaced depends on the
direction of the message. For an outgoing message, the private IP address and port
number of the client are replaced with the public IP address and port number of the
Juniper Networks firewall. For an incoming message, the public address of the
firewall is replaced with the private address of the client.

When an INVITE message is sent out across the firewall, the SIP ALG collects
information from the message header into a call table, which it uses to forward
subsequent messages to the correct end point. When a new message arrives, for
example an ACK or 200 OK, the ALG compares the From:, To:, and Call-ID: fields
against the call table to identify the call context of the message. If a new INVITE
message arrives that matches the existing call, the ALG processes it as a REINVITE.

SIP with Network Address Translation  25

 Concepts & Examples ScreenOS Reference Guide

When a message containing SDP information arrives, the ALG allocates ports and
creates a NAT mapping between them and the ports in the SDP. Because the SDP
requires sequential ports for the Real Time Protocol (RTP) and Real Time Control
Protocol (RTCP) channels, the ALG provides consecutive even-odd ports. If it is
unable to find a pair of ports it discards the SIP message.

Outgoing Calls
When a SIP call is initiated with a SIP request message from the internal to the
external network, NAT replaces the IP addresses and port numbers in the SDP and
creates a binding to map the IP addresses and port numbers to the Juniper
Networks firewall. Via:, Contact:, Route:, and Record-Route: SIP header fields, if
present, are also bound to the firewall IP address. The ALG stores these mappings
for use in retransmissions and for SIP response messages.

The SIP ALG then opens pinholes in the firewall to allow media through the security
device on the dynamically assigned ports negotiated based on information in the
SDP and the Via:, Contact:, and Record-Route: header fields. The pinholes also
allow incoming packets to reach the Contact:, Via:, and Record-Route: IP addresses
and ports. When processing return traffic, the ALG inserts the original Contact:,
Via:, Route:, and Record-Route: SIP fields back into the packets.

Incoming Calls
Incoming calls are initiated from the public network to public mapped IP (MIP)
addresses or to interface IP addresses on the security device. MIPs are statically
configured IP addresses that point to internal hosts; interface IP addresses are
dynamically recorded by the ALG as it monitors REGISTER messages sent by
internal hosts to the SIP registrar. (For more information, see “Examples” on
page 32.) When the security device receives an incoming SIP packet, it sets up a
session and forwards the payload of the packet to the SIP ALG.

The ALG examines the SIP request message (initially an INVITE) and, based on
information in the SDP, opens gates for outgoing media. When a 200 OK response
message arrives, the SIP ALG performs NAT on the IP addresses and ports and
opens pinholes in the outbound direction. (The opened gates have a short
time-to-live, and time out if a 200 OK response message is not received quickly.)

When a 200 OK response arrives, the SIP proxy examines the SDP information and
reads the IP addresses and port numbers for each media session. The SIP ALG on
the security device performs NAT on the addresses and port numbers, opens
pinholes for outbound traffic, and refreshes the timeout for gates in the inbound
direction.

When the ACK arrives for the 200 OK, it also passes through the SIP ALG. If the
message contains SDP information, the SIP ALG ensures that the IP addresses and
port numbers are not changed from the previous INVITE—if they are, the ALG
deletes old pinholes and creates new pinholes to allow media to pass through. The
ALG also monitors the Via:, Contact:, and Record-Route: SIP fields and opens new
pinholes if it determines that these fields have changed.

26  SIP with Network Address Translation

 Chapter 2: Session Initiation Protocol Application Layer Gateway

Forwarded Calls
A forwarded call is when, for example, user A outside the network calls user B
inside the network, and user B forwards the call to user C outside the network. The
SIP ALG processes the INVITE from user A as a normal incoming call. But when the
ALG examines the forwarded call from B to C outside the network and notices that
B and C are reached using the same interface, it does not open pinholes in the
firewall, because media will flow directly between user A and user C.

Call Termination
The BYE message is used to terminate a call. When the security device receives a
BYE message, it translates the header fields just as it does for any other message,
But because a BYE message must be acknowledged by the receiver with a 200 OK,
the ALG delays call teardown for five seconds to allow time for transmission of the
200 OK.

Call Re-INVITE Messages

Re-INVITE messages are used to add new media sessions to a call, and to removing
existing media sessions. When new media sessions are added to a call, new
pinholes are opened in the firewall and new address bindings created. The process
is identical to the original call setup. When one or more media sessions are
removed from a call, pinholes are closed and bindings released just as with a BYE
message.

Call Session Timers

The SIP ALG uses the Session-Expires value to time out a session if a Re-INVITE or
UPDATE message is not received. The ALG gets the Session-Expires value, if present,
from the 200 OK response to the INVITE and uses this value for signaling timeout. If
the ALG receives another INVITE before the session times out, it resets all timeout
values to this new INVITE or to default values, and the process is repeated.

As a precautionary measure, the SIP ALG uses hard timeout values to set the
maximum amount of time a call can exist. This ensures that the security device is
protected in the event of the following:

 End systems crash during a call and a BYE message is not received.

 Malicious users never send a BYE in an attempt to attack a SIP ALG.

 Poor implementations of sip proxy fail to process Record-Route and never send
a BYE message.

 Network failures prevent a BYE message from being received.

Call Cancellation
Either party can cancel a call by sending a CANCEL message. Upon receiving a
CANCEL message, the SIP ALG closes pinholes through the firewall—if any have
been opened—and releases address bindings. Before releasing the resources, the
ALG delays the control channel age-out for approximately five seconds to allow time
for the final 200 OK to pass through. The call is terminated when the five second
timeout expires, regardless of whether a 487 or non-200 response arrives.

SIP with Network Address Translation  27

 Concepts & Examples ScreenOS Reference Guide

Forking
Forking enables a SIP proxy to send a single INVITE message to multiple
destinations simultaneously. When the multiple 200 OK response messages arrive
for the single call, the SIP ALG parses but updates call information with the first 200
OK message it receives.

SIP Messages
The SIP message format consists of a SIP header section, and the SIP body. In
request messages, the first line of the header section is the request line, which
includes the method type, Request-URI, and protocol version. In response
messages, the first line is the status line, which contains a status code. SIP headers
contain IP addresses and port numbers used for signaling. The SIP body, separated
from the header section by a blank line, is reserved for session description
information, which is optional. Juniper Networks security devices currently support
the Session Description Protocol (SDP) only. The SIP body contains IP addresses
and port numbers used to transport the media.

In NAT mode, the security device translates information in the SIP headers to hide
the information from the outside network. NAT is performed on SIP body
information to allocate resources, that is, port numbers where the media is to be
received.

SIP Headers
In the following sample SIP request message, NAT replaces the IP addresses in the
header fields—shown in bold font—to hide them from the outside network.

INVITE [email protected] SIP/2.0

Via: SIP/2.0/UDP 10.150.20.3:5434
From: [email protected]
To: [email protected]
Call-ID: [email protected]
Contact: [email protected]:5434
Route: <sip:[email protected]:5060>
Record-Route: <sip:[email protected]:5060>

28  SIP with Network Address Translation

 Chapter 2: Session Initiation Protocol Application Layer Gateway

How IP address translation is performed depends on the type and direction of the
message, which can be any of the following:

 Inbound request

 Outbound response

 Outbound request

 Inbound response

Table 2 shows how NAT is performed in each of these cases. Note that for several of
the header fields the ALG must know more than just whether the messages comes
from inside or outside the network. It must also know what client initiated the call,
and whether the message is a request or response.

Table 2: Requesting Messages with NAT

Message Type Fields Action

Inbound Request To: Replace ALG address with local address
(from public to private) From: None
Call-ID: None
Via: None
Request-URI: Replace ALG address with local address
Contact: None
Record-Route: None
Route: None
Outbound Response To: Replace ALG address with local address
(from private to public) From: None
Call-ID: None
Via: None
Request-URI: N/A
Contact: Replace local address with ALG address
Record-Route: Replace local address with ALG address
Route: None
Outbound Request To: None
(from private to public) From: Replace local address with ALG address
Call-ID: Replace local address with ALG address
Via: Replace local address with ALG address
Request-URI: None
Contact: Replace local address with ALG address
Record-Route: Replace local address with ALG address
Route: Replace ALG address with local address

SIP with Network Address Translation  29

 Concepts & Examples ScreenOS Reference Guide

Message Type Fields Action

Outbound Response To: None
(from public to private) From: Replace ALG address with local address
Call-ID: Replace ALG address with local address
Via: Replace ALG address with local address
Request-URI: N/A
Contact: None
Record-Route: Replace ALG address with local address
Route: Replace ALG address with local address

SIP Body
The SDP information in the SIP body includes IP addresses the ALG uses to create
channels for the media stream. Translation of the SDP section also allocates
resources, that is, port numbers to send and receive the media.

The following except from a sample SDP section shows the fields that are translated
for resource allocation.

o=user 2344234 55234434 IN IP4 10.150.20.3

c=IN IP4 10.150.20.3
m=audio 43249 RTP/AVP 0

SIP messages can contain more than one media stream. The concept is similar to
attaching multiple files to an email message. For example, an INVITE message sent
from a SIP client to a SIP server might have the following fields:

c=IN IP4 10.123.33.4

m=audio 33445 RTP/AVP 0
c=IN IP4 10.123.33.4
m=audio 33447 RTP/AVP 0
c=IN IP4 10.123.33.4
m=audio 33449 RTP/AVP 0

Juniper Networks security devices support up to 6 SDP channels negotiated for each
direction, for a total of 12 channels per call. For more information, see “Session
Description Protocol Sessions” on page 20.

SIP NAT Scenario

In Figure 9, ph1 sends a SIP INVITE message to ph2. Note how the IP addresses in
the header fields—shown in bold font—are translated by the security device.

The SDP section of the INVITE message indicates where the caller is willing to
receive media. Note that the Media Pinhole contains two port numbers, 52002 and
52003, for RTCP and RTP. The Via/Contact Pinhole provides port number 5060 for
SIP signaling.

Observe how, in the 200 OK response message, the translations performed in the
INVITE message are reversed. The IP addresses in this message, being public, are
not translated, but gates are opened to allow the media stream access to the private
network.

30  SIP with Network Address Translation

 Chapter 2: Session Initiation Protocol Application Layer Gateway

Figure 9: SIP NAT Scenario 1

Security Device

SIP ph1 5.5.5.1 5.5.5.2 6.6.6.1 6.6.6.2 SIP ph2

Internal Network External Network

INVITE Sip: ph2@ 6.6.6.6 SIP/2.0 INVITE Sip: ph2@ 6.6.6.6 SIP/2.0
Via: SIP/2.0/UDP 5.5.5.1:5060 Via: SIP/2.0/UDP 6.6.6.1:5060
Call-ID: [email protected] Call-ID: [email protected]
From: [email protected] From: [email protected]
To: [email protected] To: [email protected]
CSeq 1 INVITE CSeq 1 INVITE
Content-type: application/sdp Content-type: application/sdp
Content-Length: 98 Content-Length: 98
V=0 V=0
o=ph1 3123 1234 IP IP4 5.5.5.1 o=ph1 3123 1234 IP IP4 6.6.6.1
o=IN IPv4 5.5.5.1 o=IN IPv4 6.6.6.1
m=audio 62002 RTP/AVP 0 m=audio 52002 RTP/AVP 0

Media Pinhole

5.5.5.1
6.6.6.1 Any IP
52002/52003 Any Port
45002/45003

Via/Contact Pinhole

5.5.5.1
6.6.6.1 Any IP
1234 Any Port
5060

SIP with Network Address Translation  31

 Concepts & Examples ScreenOS Reference Guide

Figure 10: SIP NAT Scenario 2

Security Device

SIP ph1 5.5.5.1 5.5.5.2 6.6.6.1 6.6.6.2 SIP ph2

Internal Network External Network

SIP/2.0 200 OK SIP/2.0 200 OK
Via: SIP/2.0/UDP 5.5.5.1:5060 Via: SIP/2.0/UDP 6.6.6.1:1234
Call-ID: [email protected] Call-ID: [email protected]
From: [email protected] From: [email protected]
To: [email protected] To: [email protected]
CSeq 1 INVITE CSeq 1 INVITE
Content-type: application/sdp Content-type: application/sdp
Content-Length: 98 Content-Length: 98
V=0 Contact SIP: 6.6.6.6:5060
o=ph2 5454 565642 IP IP4 V=0
6.6.6.2 o=ph2 5454 565642 IP IP4
c=IN IP4 6.6.6.2 6.6.6.2
m=audio 62002 RTP/AVP 0 c=IN IP4 6.6.6.2
m=audio 62002 RTP/AVP 0

Media Pinhole

Any IP 6.6.6.2
Any Port 62002/62003

Via/Contact Pinhole

Any IP 6.6.6.2
Any Port 5060

ACK SIP:[email protected] SIP/2.0 ACK SIP:[email protected] SIP/2.0

.... ....

Examples
This section contains the following sample scenarios:

 “Incoming SIP Call Support Using the SIP Registrar” on page 33

 “Example: Incoming Call with MIP” on page 39

 “Example: Proxy in the Private Zone” on page 41

 “Example: Proxy in the Public Zone” on page 44

 “Example: Three-Zone, Proxy in the DMZ” on page 46

 “Example: Untrust Intrazone” on page 49

 “Example: Trust Intrazone” on page 53

 “Example: Full-Mesh VPN for SIP” on page 55

32  Examples
 Chapter 2: Session Initiation Protocol Application Layer Gateway

Incoming SIP Call Support Using the SIP Registrar

SIP registration provides a discovery capability by which SIP proxies and location
servers are able to identify the location or locations where users want to be
contacted. A user registers one or more contact locations by sending a REGISTER
message to the registrar. The To: and Contact: fields in the REGISTER message
contain the address-of-record URI and one or more contact URIs, as shown in
Figure 11. Registration creates bindings in a location service that associates the
address-of-record with the contact address or addresses.

The security device monitors outgoing REGISTER messages, performs NAT on these
addresses, and stores the information in an Incoming DIP table. Then, when an
INVITE message is received from outside the network, the security device uses the
Incoming DIP table to identify which internal host to route the INVITE message to.
You can take advantage of SIP proxy registration service to allow incoming calls by
configuring Interface DIP or DIP pools on the egress interface of the security device.
Interface DIP is adequate for handling incoming calls in a small office, while we
recommend setting up DIP pools for larger networks or an enterprise environment.

NOTE: Incoming call support using Interface DIP or a DIP pool is supported for SIP and
H.323 services only.

For incoming calls, security devices currently support UDP and TCP only. Domain
name resolution is also currently not supported; therefore, URIs must contain IP
addresses, as shown in Figure 11.

Examples  33
 Concepts & Examples ScreenOS Reference Guide

Figure 11: Incoming SIP

Incoming DIP Table

5.5.5.1 : 1234 6.6.6.1 : 5555 3600

Security Device

SIP ph1 5.5.5.1 5.5.5.2 6.6.6.1 Registrar 6.6.6.2

Internal Network External Network

REGISTER sip: 6.6.6.2 SIP/2.0

From: [email protected] Add entry to
To: [email protected] Incoming DIP
CSeq 1 INVITE table REGISTER sip:6.6.6.2 SIP/2.0
Contact <sip: 5.5.5.1:1234> From: [email protected]
Expires: 7200 To: [email protected]
CSeq 1 INVITE
Contact <sip: 6.6.6.1:5555>
Expires: 7200

200 OK
From: [email protected]
200 OK To: [email protected]
From: [email protected] Update CSeq 1 INVITE
To: [email protected] Timeout Contact <sip: 6.6.6.1:5555>
CSeq 1 INVITE value Expires: 3600
Contact <sip: 5.5.5.1:1234>
Expires: 3600

Example: Incoming Call (Interface DIP)

In this example, phone1 is on the ethernet1 interface in the Trust zone, and phone2
and the proxy server are on the ethernet3 interface in the Untrust zone. You set
Interface DIP on the ethernet3 interface to do NAT on incoming calls, then create a
policy permitting SIP traffic from the Untrust zone to the Trust zone and reference
that DIP in the policy. You also create a policy that permits SIP traffic from the Trust
to the Untrust zone using NAT Source. This enables phone1 in the Trust zone to
register with the proxy in the Untrust zone. For an explanation of how incoming DIP
works with the SIP registration service, see “Examples” on page 32.

34  Examples
 Chapter 2: Session Initiation Protocol Application Layer Gateway

Figure 12: Incoming Call with Interface DIP on ethernet3 Interface

ethernet1 ethernet3
10.1.1.1/24 1.1.1.1/24

Trust Untrust
Security Device
LAN Internet

Interface DIP on
ethernet 3
phone2 Proxy Server
phone1 1.1.1.3
10.1.1.3 1.1.1.4

WebUI
1. Interfaces
Network > Interfaces > Edit (for ethernet1): Enter the following, then click
Apply:

Zone Name: Trust

Static IP: (select this option when present)
IP Address/Netmask: 10.1.1.1/24
Enter the following, then click OK:
Interface Mode: NAT

Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:

Zone Name: Untrust

Static IP: (select this option when present)
IP Address/Netmask: 1.1.1.1/24
Interface Mode: Route
2. Addresses
Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: phone1

IP Address/Domain Name:
IP/Netmask: (select), 10.1.1.3/24
Zone: Trust

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: phone2

IP Address/Domain Name:
IP/Netmask: (select), 1.1.1.4/24
Zone: Untrust

Examples  35
 Concepts & Examples ScreenOS Reference Guide

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: proxy

IP Address/Domain Name:
IP/Netmask: (select), 1.1.1.3/24
Zone: Untrust
3. DIP with Incoming NAT
Network > Interface > Edit (for ethernet3) > DIP > New: Select the Incoming
NAT option, then click OK.

4. Policies
Policies > (From: Trust, To: Untrust) New: Enter the following, then click OK:

Source Address
Address Book Entry: (select), phone1
Destination Address
Address Book Entry: (select), any
Service: SIP
Action: Permit

> Advanced: Enter the following, then click Return to set the advanced
options and return to the basic configuration page:

NAT:
Source Translation: (select)
(DIP on): None (Use Egress Interface IP)

Policies > (From: Untrust, To: Trust) New: Enter the following, then click OK:

Source Address
Address Book Entry: (select), Any
Destination Address
Address Book Entry: (select), DIP(ethernet3)
Service: SIP
Action: Permit

CLI
1. Interfaces
set interface ethernet1 zone trust
set interface ethernet1 ip 10.1.1.1/24
set interface ethernet3 zone untrust
set interface ethernet3 ip 1.1.1.1/24
set interface ethernet3 route
2. Addresses
set address trust phone1 10.1.1.3/24
set address untrust phone2 1.1.1.4/24
set address untrust proxy 1.1.1.3/24
3. DIP with Incoming NAT
set interface ethernet3 dip interface-ip incoming
set dip sticky

36  Examples
 Chapter 2: Session Initiation Protocol Application Layer Gateway

4. Policies
set policy from trust to untrust phone1 any sip nat src permit
set policy from untrust to trust any dip(ethernet3) sip permit
save

Example: Incoming Call (DIP Pool)

This example, phone1 is in the Trust zone, and phone2 and the proxy server are in
the Untrust zone. You set a DIP pool on the ethernet3 interface to do NAT on
incoming calls, then set a policy permitting SIP traffic from the Untrust zone to the
Trust zone and reference that DIP pool in the policy. You also create a policy that
permits SIP traffic from the Trust to the Untrust zone using NAT Source. This
enables phone1 in the Trust zone to register with the proxy in the Untrust zone. For
an explanation of how DIP works with the SIP registration service, see “Examples”
on page 32.

Figure 13: Incoming Call with DIP Pool

ethernet1 ethernet3
10.1.1.1/24 1.1.1.1/24

Trust Untrust
Security Device
LAN Internet

DIP Pool on ethernet3

1.1.1.20 ->1.1.1.40
phone1 phone2 Proxy Server
10.1.1.3 1.1.1.4 1.1.1.3

WebUI
1. Interfaces
Network > Interfaces > Edit (for ethernet1): Enter the following, then click
Apply:

Zone Name: Trust

Static IP: (select this option when present)
IP Address/Netmask: 10.1.1.1/24
Enter the following, then click OK:
Interface Mode: NAT

Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:

Zone Name: Untrust

Static IP: (select this option when present)
IP Address/Netmask: 1.1.1.1/24
Interface Mode: Route

Examples  37
 Concepts & Examples ScreenOS Reference Guide

2. Addresses
Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: phone1

IP Address/Domain Name:
IP/Netmask: (select), 10.1.1.3/24
Zone: Trust

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: phone2

IP Address/Domain Name:
IP/Netmask: (select), 1.1.1.4/24
Zone: Untrust

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: proxy

IP Address/Domain Name:
IP/Netmask: (select), 1.1.1.3/24
Zone: Untrust
3. DIP Pool with Incoming NAT
Network > Interface > Edit (for ethernet3) > DIP > New: Enter the following,
then click OK:

ID: 5
IP Address Range: (select), 1.1.1.20 ~ 1.1.1.40
Port Translation: (select)
In the same subnet as the interface IP or its secondary IPs: (select)
Incoming NAT: (select)
4. Policies
Policies > (From: Trust, To: Untrust) New: Enter the following, then click OK:

Source Address
Address Book Entry: (select), phone1
Destination Address
Address Book Entry: (select), Any
Service: SIP
Action: Permit

> Advanced: Enter the following, then click Return to set the advanced
options and return to the basic configuration page:

NAT:
Source Translation: (select)
(DIP on): 5 (1.1.1.20-1.1.1.40)/port-xlate

38  Examples
 Chapter 2: Session Initiation Protocol Application Layer Gateway

Policies > (From: Untrust, To: Trust) New: Enter the following, then click OK:

Source Address
Address Book Entry: (select), Any
Destination Address
Address Book Entry: (select), DIP(5)
Service: SIP
Action: Permit

CLI
1. Interfaces
set interface ethernet1 zone trust
set interface ethernet1 ip 10.1.1.1/24
set interface ethernet3 zone untrust
set interface ethernet3 ip 1.1.1.1/24
set interface ethernet3 route
2. Addresses
set address trust phone1 10.1.1.3/24
set address untrust phone2 1.1.1.4/24
set address untrust proxy 1.1.1.3/24
3. DIP Pool with Incoming NAT
set interface ethernet3 dip 5 1.1.1.20 1.1.1.40 incoming
set dip sticky
4. Policies
set policy from trust to untrust phone1 any sip nat src dip 5 permit
set policy from untrust to trust any dip(5) sip permit
save

Example: Incoming Call with MIP

In this example, phone1 is on the ethernet1 interface in the Trust zone, and phone2
and the proxy server are on the ethernet3 interface in the Untrust zone. You put a
MIP on the ethernet3 interface to phone1, then create a policy that allows SIP traffic
from the Untrust zone to the Trust zone and reference that MIP in the policy. You
also create a policy allowing phone1 to register with the proxy server in the Untrust
zone. This example is similar to the previous two examples (“Example: Incoming
Call (Interface DIP)” on page 34 and “Example: Incoming Call (DIP Pool)” on
page 37), except that with a MIP you need one public address for each private
address in the Trust zone, while with Interface DIP or a DIP pool a single interface
address can serve multiple private addresses.

Examples  39
 Concepts & Examples ScreenOS Reference Guide

Figure 14: Incoming Call with MIP

ethernet1 ethernet3
10.1.1.1/24 1.1.1.1/24
Trust Untrust
Security Device
LAN Internet

Proxy Server

Virtual Device
phone1 MIP on ethernet3
1.1.1.1/24 phone2
10.1.1.3 1.1.1.4

WebUI
1. Interfaces
Network > Interfaces > Edit (for ethernet1): Enter the following, then click
Apply:

Zone: Trust
Static IP: (select this option when present)
IP Address/Netmask: 10.1.1.1/24
Enter the following, then click OK:
Interface Mode: NAT

Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:

Zone: Untrust
IP Address/Netmask: 1.1.1.1/24
Interface Mode: Route
2. Addresses
Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: phone1

IP Address/Domain Name:
IP/Netmask: (select), 10.1.1.3/24
Zone: Trust

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: phone2

IP Address/Domain Name:
IP/Netmask: (select), 1.1.1.4/24
Zone: Untrust

40  Examples
 Chapter 2: Session Initiation Protocol Application Layer Gateway

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: proxy

IP Address/Domain Name:
IP/Netmask: (select), 1.1.1.3/24
Zone: Untrust
3. MIP
Network > Interfaces > Edit (for ethernet3) > MIP > New: Enter the
following, then click OK:

Mapped IP: 1.1.1.3

Netmask: 255.255.255.255
Host IP Address: 10.1.1.3
4. Policy
Policies > (From: Untrust, To: Trust) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), any
Destination Address:
Address Book Entry: (select), MIP(1.1.1.3)
Service: SIP
Action: Permit

CLI
1. Interfaces
set interface ethernet1 zone trust
set interface ethernet1 ip 10.1.1.1/24
set interface ethernet3 zone untrust
set interface ethernet3 ip 1.1.1.1/24
set interface ethernet3 route
2. Addresses
set address trust phone1 10.1.1.3/24
set address untrust phone2 1.1.1.4/24
set address untrust proxy 1.1.1.3/24
3. MIP
set interface ethernet3 mip 1.1.1.3 host 10.1.1.3
4. Policy
set policy from untrust to trust any mip(1.1.1.3) sip permit
save

Example: Proxy in the Private Zone

In this example, phone1 and the SIP proxy server are on the ethernet1 interface in
the Trust (private) zone, and phone2 is on the ethernet3 interface in the Untrust
zone. You put a MIP on the ethernet3 interface to the proxy server to allow phone2
to register with the proxy, then create a policy allowing SIP traffic from the Untrust
to the Trust zone and reference that MIP in the policy. You also create a policy from
the Trust to the Untrust zone to allow phone1 to call out.

Examples  41
 Concepts & Examples ScreenOS Reference Guide

Figure 15: Proxy in the Private Zone

ethernet1 ethernet3
10.1.1.1/24 1.1.1.1/24

Trust Untrust
Security Device
LAN Internet

Virtual Device
MIP on ethernet3
Proxy Server phone1 1.1.1.2 -> 10.1.1.4 phone2
10.1.1.4 10.1.1.3 1.1.1.4

WebUI
1. Interfaces
Network > Interfaces > Edit (for ethernet1): Enter the following, then click
OK:

Zone: Trust
Static IP: (select this option when present)
IP Address/Netmask: 10.1.1.1/24
Enter the following, then click OK:
Interface Mode: NAT

Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:

Zone: Untrust
IP Address/Netmask: 1.1.1.1/24
Interface Mode: Route
2. Addresses
Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: phone1

IP Address/Domain Name:
IP/Netmask: (select), 10.1.1.3/24
Zone: Trust

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: phone2

IP Address/Domain Name:
IP/Netmask: (select), 1.1.1.4/24
Zone: Untrust

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: proxy

IP Address/Domain Name:
IP/Netmask: (select), 10.1.1.4/24
Zone: Trust

42  Examples
 Chapter 2: Session Initiation Protocol Application Layer Gateway

3. MIP
Network > Interfaces > Edit (for loopback.3) > MIP > New: Enter the
following, then click OK:

Mapped IP: 1.1.1.2

Netmask: 255.255.255.255
Host IP Address: 10.1.1.4
Host Virtual Router Name: trust-vr
4. Policies
Policies > (From: Trust, To: Untrust) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select) any
Destination Address:
Address Book Entry: (select) phone2
Service: SIP
Action: Permit

> Advanced: Enter the following, then click Return to set the advanced
options and return to the basic configuration page:

NAT:
Source Translation: (select)
(DIP on): None (Use Egress Interface IP)

Policies > (From: Untrust, To: Trust) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), phone2
Destination Address:
Address Book Entry: (select), MIP(1.1.1.2)
Service: SIP
Action: Permit

CLI
1. Interfaces
set interface ethernet1 zone trust
set interface ethernet1 ip 10.1.1.1/24
set interface ethernet3 zone untrust
set interface ethernet3 ip 1.1.1.1/24
set interface ethernet3 route
2. Addresses
set address trust phone1 10.1.1.3/24
set address untrust phone2 1.1.1.4/24
set address trust proxy 10.1.1.4/24
3. MIP
set interface ethernet3 mip 1.1.1.2 host 10.1.1.4
4. Policies
set policy from trust to untrust any phone2 sip nat src permit
set policy from untrust to trust phone2 mip(1.1.1.2) sip permit
save

Examples  43
 Concepts & Examples ScreenOS Reference Guide

Example: Proxy in the Public Zone

In this example, phone1 is on the ethernet1 interface in the Trust zone, and the
proxy server and phone2 are on the ethernet3 interface in the Untrust (public) zone.
You configure Interface DIP on the Untrust interface, then create a policy permitting
SIP traffic from the Untrust zone to the Trust zone and reference that DIP in the
policy. You also create a policy from Trust to Untrust to allow phone1 to register
with the proxy server in the Untrust zone. This example is similar to the previous
incoming call examples (see “Example: Incoming Call (DIP Pool)” on page 37 and
“Example: Incoming Call with MIP” on page 39) and, as with those examples, you
can use DIP or MIP on the Untrust interface.

Figure 16: Proxy in the Public Zone

ethernet1 ethernet3
10.1.1.1/24 1.1.1.1/24

Trust Untrust
Security Device

LAN Internet

Interface DIP
on ethernet3
phone1 phone2 Proxy Server
10.1.1.3 1.1.1.4 1.1.1.3

WebUI
1. Interfaces
Network > Interfaces > Edit (for ethernet1): Enter the following, then click
Apply:

Zone: Trust
Static IP: (select this option when present)
IP Address/Netmask: 10.1.1.1/24
Enter the following, then click OK:
Interface Mode: NAT

Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:

Zone: Untrust
IP Address/Netmask: 1.1.1.1/24
Interface Mode: Route
2. Addresses
Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: phone1

IP Address/Domain Name:
IP/Netmask: (select), 10.1.1.3/24
Zone: Trust

44  Examples
 Chapter 2: Session Initiation Protocol Application Layer Gateway

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: phone2

IP Address/Domain Name:
IP/Netmask: (select), 1.1.1.4/24
Zone: Untrust

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: proxy

IP Address/Domain Name:
IP/Netmask: (select), 1.1.1.3/24
Zone: Untrust
3. Interface DIP
Network > Interface > Edit (for ethernet3) > DIP: Select the Incoming NAT
check box.

4. Policies
Policies > (From: Trust, To: Untrust) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select) phone1
Destination Address:
Address Book Entry: (select) Any
Service: SIP
Action: Permit

> Advanced: Enter the following, then click Return to set the advanced
options and return to the basic configuration page:

NAT:
Source Translation: (select)
(DIP on): None (Use Egress Interface IP)

Policies > (From: Untrust, To: Trust) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), Any
Destination Address:
Address Book Entry: (select), DIP(ethernet3)
Service: SIP
Action: Permit

CLI
1. Interfaces
set interface ethernet1 zone trust
set interface ethernet1 ip 10.1.1.1/24
set interface ethernet3 zone untrust
set interface ethernet3 ip 1.1.1.1/24
2. Addresses
set address trust phone1 10.1.1.3/24
set address untrust phone2 1.1.1.4/24
set address untrust proxy 1.1.1.3/24

Examples  45
 Concepts & Examples ScreenOS Reference Guide

3. Interface DIP
set interface ethernet3 dip interface-ip incoming
4. Policies
set policy from trust to untrust phone1 any sip nat src permit
set policy from untrust to trust any dip(ethernet3) sip permit
save

Example: Three-Zone, Proxy in the DMZ

In this example, phone1 is on the ethernet1 interface in the Trust zone, phone2 is
on the ethernet3 interface in the Untrust zone, and the proxy server is on the
ethernet2 interface in the DMZ. You put a MIP on the ethernet2 interface to phone1
in the Trust zone, and create a policy from the DMZ to the Trust zone and reference
that MIP in the policy. In fact, with three zones, you need to create bidirectional
policies between each of the zones. The arrows in Figure 17 show the flow of SIP
signaling traffic when phone2 in the Untrust zone places a call to phone1 in the
Trust zone. After the session is initiated, the media flows directly between phone1
and phone2.

Figure 17: Proxy in the DMZ

Untrust

Internet
phone2
1.1.1.4

ethernet3
1.1.1.1/24
ethernet2
2.2.2.2/24 DMZ

Security
Device Proxy Server
2.2.2.4

ethernet1
10.1.1.1/24

Virtual Device
MIP on ethernet2
2.2.2.3-> 10.1.1.3
LAN

phone1
10.1.1.3
Trust

46  Examples
 Chapter 2: Session Initiation Protocol Application Layer Gateway

WebUI
1. Interfaces
Network > Interfaces > Edit (for ethernet1): Enter the following, then click
Apply:

Zone: Trust
Static IP: (select when this option is present)
IP Address/Netmask: 10.1.1.1/24
Enter the following, then click OK:
Interface Mode: NAT

Network > Interfaces > Edit (for ethernet2): Enter the following, then click
OK:

Zone Name: DMZ

Static IP: (select when this option is present)
IP Address/Netmask: 2.2.2.2/24

Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:

Zone Name: Untrust

Static IP: (select when this option is present)
IP Address/Netmask: 1.1.1.1/24
2. Address
Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: phone1

IP Address/Domain Name:
IP/Netmask: (select), 10.1.1.3/24
Zone: Trust

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: phone2

IP Address/Domain Name:
IP/Netmask: (select), 1.1.1.4/24
Zone: Untrust

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: proxy

IP Address/Domain Name:
IP/Netmask: (select), 2.2.2.4/24
Zone: DMZ
3. MIP
Network > Interfaces > Edit (for ethernet2) > MIP > New: Enter the
following, then click OK:

Mapped IP: 2.2.2.3

Netmask: 255.255.255.255
Host IP Address: 10.1.1.3

Examples  47
 Concepts & Examples ScreenOS Reference Guide

4. Policies
Policies > (From: Trust, To: DMZ) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), phone1
Destination Address:
Address Book Entry: (select), proxy
Service: SIP
Action: Permit

> Advanced: Enter the following, then click Return to set the advanced
options and return to the basic configuration page:

NAT:
Source Translation: Enable
(DIP on): None (Use Egress Interface IP)

Policies > (From: DMZ, To: Untrust) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), proxy
Destination Address:
Address Book Entry: (select), phone2
Service: SIP
Action: Permit

Policies > (From: Untrust, To: Trust) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), phone2
Destination Address:
Address Book Entry: (select), phone1
Service: SIP
Action: Permit

Policies > (From: Untrust, To: DMZ) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), phone2
Destination Address:
Address Book Entry: (select), proxy
Service: SIP
Action: Permit

Policies > (From: DMZ, To: Trust) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), proxy
Destination Address:
Address Book Entry: (select), MIP(2.2.2.3)
Service: SIP
Action: Permit

48  Examples
 Chapter 2: Session Initiation Protocol Application Layer Gateway

Policies > (From: Trust, To: Untrust) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), phone1
Destination Address:
Address Book Entry: (select), phone2
Service: SIP
Action: Permit

> Advanced: Enter the following, then click Return to set the advanced
options and return to the basic configuration page:

NAT:
Source Translation: Enable
(DIP on): None (Use Egress Interface IP)

CLI
1. Interfaces
set interface ethernet1 zone trust
set interface ethernet1 ip 10.1.1.1/24
set interface ethernet3 zone untrust
set interface ethernet3 ip 1.1.1.1/24
set interface ethernet3 route
set interface ethernet2 zone dmz
set interface ethernet2 ip 2.2.2.2/24
set interface ethernet2 route
2. Addresses
set address trust phone1 10.1.1.3/24
set address untrust phone2 1.1.1.4/24
set address dmz proxy 2.2.2.4
3. MIP
set interface2 mip 2.2.2.3 host 10.1.1.3
4. Policies
set policy from trust to dmz phone1 proxy sip nat src permit
set policy from dmz to untrust proxy phone2 sip permit
set policy from untrust to trust phone2 phone1 sip permit
set policy from untrust to dmz phone2 proxy sip permit
set policy from dmz to trust proxy mip(2.2.2.3) sip permit
set policy from trust to untrust phone1 phone2 sip nat src permit
save

Example: Untrust Intrazone

In this example, phone1 is on the ethernet4 interface in the Untrust zone, phone2 is
in a subnet on the ethernet3 interface in the Untrust zone, and the proxy server is
on the ethernet1 interface in the Trust zone. To allow intrazone SIP traffic between
the two phones in the Untrust zone, you create a loopback interface, add ethernet3
and ethernet4 to a loopback group, then put a MIP on the loopback interface to the
IP address of the proxy server. Creating a loopback interface enables you to use a
single MIP for the proxy server in the Trust zone. Because blocking is on by default
in the Untrust zone, you must also turn off blocking to allow intrazone
communication. For more information about using loopback interfaces, see “MIP
and the Loopback Interface” on page 8-73.

Examples  49
 Concepts & Examples ScreenOS Reference Guide

Figure 18: Untrust Intrazone

Untrust

phone1 phone2
1.1.1.4 1.1.2.4
Internet

ethernet4 ethernet3
1.1.1./24 1.1.1.1/24

Loopback 1
1.1.4.1/24

MIP on Loopback.1
1.1.4.5-> 10.1.1.5

ethernet1
10.1.1.1/24

LAN

proxy
10.1.1.5
Trust

WebUI
1. Interfaces
Network > Interfaces > Edit (for ethernet1): Enter the following, then click
Apply:

Zone: Trust
Static IP: (select when this option is present)
IP Address/Netmask: 10.1.1.1/24

Enter the following, then click OK:

Interface Mode: NAT

Network > Interfaces > Edit (for ethernet4): Enter the following, then click
OK:

Zone: Untrust
Static IP: (select when this option is present)
IP Address/Netmask: 1.1.1.1/24

50  Examples
 Chapter 2: Session Initiation Protocol Application Layer Gateway

Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:

Zone: Untrust
Static IP: (select when this option is present)
IP Address/Netmask: 1.1.2.1/24

Network > Interfaces > New Loopback IF: Enter the following, then click OK:

Interface Name: loopback.1

Zone: Untrust (trust-vr)
IP Address/Netmask: 1.1.4.1/24
2. Addresses
Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: proxy

IP Address/Domain Name:
IP/Netmask: (select), 10.1.1.5/32
Zone: Trust

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: phone1

IP Address/Domain Name:
IP/Netmask: (select), 1.1.1.4/32
Zone: Untrust

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: phone2

IP Address/Domain Name:
IP/Netmask: (select), 1.1.2.4/32
Zone: Untrust
3. Loopback Group
Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:

As member of loopback group: (select) loopback.1

Zone Name: Untrust

Network > Interfaces > Edit (for ethernet4): Enter the following, then click
OK:

As member of loopback group: (select) loopback.1

Zone Name: Untrust

Examples  51
 Concepts & Examples ScreenOS Reference Guide

4. MIP
Network > Interfaces > Edit (for loopback.1) > MIP > New: Enter the
following, then click OK:

Mapped IP: 1.1.4.5

Netmask: 255.255.255.255
Host IP Address: 10.1.1.5
Host Virtual Router Name: trust-vr
5. Blocking
Network > Zones > Edit (for Untrust): Enter the following, then click OK:

Block Intra-Zone Traffic: (clear)

6. Policies
Policies > (From: Trust, To: Untrust) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), proxy
Destination Address:
Address Book Entry: (select), Any
Service: SIP
Action: Permit

> Advanced: Enter the following, then click Return to set the advanced
options and return to the basic configuration page:

NAT:
Source Translation: Enable
(DIP on): None (Use Egress Interface IP)

Policies > (From: Untrust, To: Trust) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), Any
Destination Address:
Address Book Entry: (select), MIP(1.1.4.5)
Service: SIP
Action: Permit

CLI
1. Interfaces
set interface ethernet1 zone trust
set interface ethernet1 ip 10.1.1.1/24
set interface ethernet3 zone untrust
set interface ethernet3 ip 1.1.2.1/24
set interface ethernet3 route
set interface ethernet4 zone untrust
set interface ethernet4 ip 1.1.1.1/24
set interface ethernet4 route
set interface loopback.1 zone untrust
set interface loopback.1 ip 1.1.4.1/24
set interface loopback.1 route

52  Examples
 Chapter 2: Session Initiation Protocol Application Layer Gateway

2. Addresses
set address trust proxy 10.1.1.5/32
set address untrust phone1 1.1.1.4/32
set address untrust phone2 1.1.2.4/32
3. Loopback Group
set interface ethernet3 loopback-group loopback.1
set interface ethernet4 loopback-group loopback.1
4. MIP
set interface loopback.1 mip 1.1.4.5 host 10.1.1.5
5. Blocking
unset zone untrust block
6. Policies
set policy from trust to untrust proxy any sip nat src permit
set policy from untrust to trust any mip(1.1.4.5) sip permit
save

Example: Trust Intrazone

In this example, phone1 is on the ethernet1 interface in the Trust zone, phone 2 is
on the ethernet2 interface in a subnet in the Trust zone, and the proxy server is on
the ethernet3 interface in the Untrust zone. To allow both phones in the Trust zone
to communicate with each other, you configure Interface DIP on the ethernet3
interface to allow them to contact the proxy server, then set policies to allow
bidirectional SIP traffic between the Trust and the Untrust zones. Blocking is off by
default in the Trust zone (as it is in custom zones you define).

Figure 19: Trust Intrazone

phone1 ethernet1 ethernet3 Proxy Server
10.1.1.3 10.1.1.1/24 3.3.3.3/24 3.3.3.4

Trust Untrust
Security Device
Internet
LAN

Interface DIP
phone2 ethernet2 on ethernet3
10.1.2.2 10.1.2.1/24

WebUI
1. Interfaces
Network > Interfaces > Edit (for ethernet1): Enter the following, then click
Apply:

Zone: Trust
Static IP: (select when this option is present)
IP Address/Netmask: 10.1.1.1/24
Enter the following, then click OK:
Interface Mode: NAT

Examples  53
 Concepts & Examples ScreenOS Reference Guide

Network > Interfaces > Edit (for ethernet2): Enter the following, then click
Apply:

Zone: Trust
Static IP: (select when this option is present)
IP Address/Netmask: 10.1.2.1/24
Enter the following, then click OK:
Interface Mode: NAT

Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:

Zone: Untrust
Static IP: (select when this option is present)
IP Address/Netmask: 3.3.3.3/24
2. Addresses
Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: phone1

IP Address/Domain Name:
IP/Netmask: (select), 10.1.1.3/24
Zone: Trust

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: phone2

IP Address/Domain Name:
IP/Netmask: (select), 10.1.2.2/24
Zone: Trust

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: proxy

IP Address/Domain Name:
IP/Netmask: (select), 3.3.3.4/24
Zone: Untrust
3. DIP with Incoming NAT
Network > Interface > Edit (for ethernet3) > DIP > New: Enter the following,
then click OK:

Incoming NAT: (select)

4. Policies
Policies > (From: Trust, To: Untrust) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), Any
Destination Address:
Address Book Entry: (select), proxy
Service: SIP
Action: Permit

54  Examples
 Chapter 2: Session Initiation Protocol Application Layer Gateway

> Advanced: Enter the following, then click Return to set the advanced
options and return to the basic configuration page:

NAT:
Source Translation: Enable
(DIP on): None (Use Egress Interface IP)

Policies > (From: Untrust, To: Trust) New: Enter the following, then click OK:

Source Address
Address Book Entry: (select) proxy
Destination Address
Address Book Entry: (select) Any
Service: SIP
Action: Permit

> Advanced: Enter the following, then click Return to set the advanced
options:

NAT:
Source Translation: (select)
(DIP on): None (Use Egress Interface IP)

CLI
1. Interfaces
set interface ethernet1 zone trust
set interface ethernet1 ip 10.1.1.1/24
set interface ethernet2 zone trust
set interface ethernet2 ip 10.1.2.1/24
set interface ethernet2 nat
set interface ethernet3 zone untrust
set interface ethernet3 ip 3.3.3.3/24
set interface ethernet3 route
2. Addresses
set address trust phone1 10.1.1.3/24
set address trust phone2 10.1.2.2/24
set address untrust proxy 3.3.3.4/24
3. Interface DIP
set interface ethernet3 dip interface-ip incoming
4. Policies
set policy from trust to untrust any proxy sip nat src permit
set policy from untrust to trust proxy dip(ethernet3) sip permit
save

Example: Full-Mesh VPN for SIP

In this example, the central office and two branch offices are linked by a full-mesh
VPN. Each site has a single security device. The proxy server is in the Trust zone at
the Central Office, phone1 is in the Trust zone at Branch Office One, and phone2 is
in the Trust zone at Branch Office Two. All interfaces connecting the devices are in
their respective Untrust zones. On each device, you configure two tunnels, one to
each of the other devices, to create a fully meshed network.

Examples  55
 Concepts & Examples ScreenOS Reference Guide

NOTE: The security devices used in this example must have at least three independently
configurable interfaces available.

Figure 20: Full-Mesh VPN for SIP

Proxy
Note: The Untrust Zone for Central Office 10.1.3.3
each device is not shown Trust Zone

Trust
eth2/8-10.1.3.1

tunnel 1
tunnel 2
6.6.6.6 Central 7.7.7.7
Untrust eth2/1: Untrust eth2/2
1.1.1.1 1.1.2.1

Gateway Router Gateway Router

To central: 1.1.1.1 To central: 1.1.2.1
To branch: 3.3.3.3 To branch: 2.2.2.2
VPN 1 VPN 2
Untrust eth3 Untrust eth3
3.3.3.3 2.2.2.2.
tunnel.1 interface VPN 3 tunnel.2 interface
unnumbered Branch-1 Branch-2 unnumbered

Trust eth1 Untrust Untrust Trust eth1

10.1.1.1 eth4-4.4.4.4 eth4-5.5.5.5 10.1.2.1
Gateway Router
Trust Zone To branch-1: 4.4.4.4 Trust Zone
To branch-2: 5.5.5.5

Branch Office One tunnel.3 interface tunnel.3 interface Branch Office Two
phone1 unnumbered unnumbered phone2
10.1.1.3 10.1.2.3

WebUI (for Central)

1. Interfaces
Network > Interfaces > Edit (for ethernet2/1): Enter the following, then click
Apply:

Zone: Untrust
Static IP: (select when this option is present)
IP Address/Netmask: 1.1.1.1/24

Network > Interfaces > Edit (for ethernet2/2): Enter the following, then click
Apply:

Zone: Untrust
Static IP: (select when this option is present)
IP Address/Netmask: 1.1.2.1/24

56  Examples
 Chapter 2: Session Initiation Protocol Application Layer Gateway

Network > Interfaces > Edit (for ethernet2/8): Enter the following, then click
Apply:

Zone: Trust
Static IP: (select when this option is present)
IP Address/Netmask: 10.1.3.1/24
Enter the following, then click OK:
Interface mode: route

Network > Interfaces > New Tunnel IF: Enter the following, then click Apply:

Tunnel Interface Name: 1

Zone (VR): Untrust
IP Address / Netmask: 6.6.6.6/24

Network > Interfaces > New Tunnel IF: Enter the following, then click Apply:

Tunnel Interface Name: 2

Zone (VR): Untrust
IP Address / Netmask: 7.7.7.7/24
2. Address
Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: Proxy

IPv4/Netmask: 10.1.3.3/32
Zone: Trust
3. VPN
VPNs > AutoKey Advanced > Gateway > New: Enter the following, then click
OK:

Gateway Name: to-branch-1

Security Level: Standard
IPvc4/v6 Address/Hostname: 3.3.3.3
Preshare Key: netscreen
Outgoing Interface: ethernet2/1

VPNs > AutoKey IKE > New: Enter the following, then click OK:

VPN Name: vpn-branch-1

Advanced: Enter the following advanced settings, then click Return to

return to the basic Gateway configuration page:

Bind to: (select) Tunnel Interface, tunnel.1

VPNs > AutoKey Advanced > Gateway > New: Enter the following, then click
OK:

Gateway Name: to-branch-2

Security Level: Standard
IPvc4/v6 Address/Hostname: 2.2.2.2
Preshare Key: netscreen
Outgoing Interface: ethernet2/2

Examples  57
 Concepts & Examples ScreenOS Reference Guide

VPNs > AutoKey IKE > New: Enter the following, then click OK:

VPN Name: vpn-branch-2

Advanced: Enter the following advanced settings, then click Return to

return to the basic Gateway configuration page:

Bind to: (select) Tunnel Interface, tunnel.2

4. Routing
Network > Routing > Destination > New: Enter the following, then click OK:

Network Address / Netmask: 10.1.1.0/24

Interface (select): tunnel.1

Network > Routing > Destination > New: Enter the following, then click OK:

Network Address / Netmask: 10.1.2.0/24

Interface (select): tunnel.2
5. Policies
Policies > (From: Trust, To: Untrust) New Enter the following, then click OK:

Source Address (select) Address Book Entry: Proxy

Destination Address (select) Address Book Entry: Any-IPv4
Service: SIP
Action: Permit

Policies > (From: Untrust, To: Trust) > New: Enter the following, then click OK:

Source Address (select) Address Book Entry: Any-IPv4

Destination Address (select) Address Book Entry: Proxy
Service: SIP
Action: Permit

CLI (for Central)

1. Interfaces
set interface ethernet2/1 zone untrust
set interface ethernet2/1 ip 1.1.1.1/24
set interface ethernet2/2 zone untrust
set interface ethernet2/2 ip 1.1.2.1/24
set interface ethernet2/8 zone trust
set interface ethernet2/8 ip 10.1.3.1/24
set interface ethernet2/8 route
set interface tunnel.1 zone untrust
set interface tunnel.1 ip 6.6.6.6/24
set interface tunnel.2 zone untrust
set interface tunnel.2 ip 7.7.7.7/24
2. Address
set address trust proxy 10.1.3.3/32
3. VPN
set ike gateway to-branch-1 address 3.3.3.3 main outgoing-interface ethernet2/1
preshare netscreen sec-level standard
set ike gateway to-branch-2 address 2.2.2.2 main outgoing-interface ethernet2/2
preshare netscreen sec-level standard

58  Examples
 Chapter 2: Session Initiation Protocol Application Layer Gateway

set vpn vpn_branch-1 gateway to-branch-1 no-reply tunnel idletime 0 sec-level

standard
set vpn vpn-branch-1 id 1 bind interface tunnel.1
set vpn vpn-branch-2 gateway to-branch-2 no-reply tunnel idletime 0 sec-level
standard
set vpn vpn-branch-2 id 2 bind interface tunnel.2
4. Routing
set route 10.1.2.0/24 interface tunnel.2
set route 10.1.1.0/24 interface tunnel.1
5. Policies
set policy from untrust to trust any proxy sip permit
set policy from trust to untrust proxy any sip permit
save

WebUI (for Branch Office 1)

1. Interfaces
Network > Interfaces > Edit (for ethernet1): Enter the following, then click
Apply:

Zone: Trust
Static IP: (select when this option is present)
IP Address/Netmask: 10.1.1.1/24
Interface mode: NAT

Network > Interfaces > Edit (for ethernet3): Enter the following, then click
Apply:

Zone: Untrust
Static IP: (select when this option is present)
IP Address/Netmask: 3.3.3.3/24

Network > Interfaces > Edit (for ethernet4): Enter the following, then click
Apply:

Zone: Untrust
Static IP: (select when this option is present)
IP Address/Netmask: 4.4.4.4/24

Network > Interfaces > New Tunnel IF: Enter the following, then click Apply:

Tunnel Interface Name: 2

Zone (VR): Untrust
Unnumbered (select) Interface: ethernet3

Network > Interfaces > New Tunnel IF: Enter the following, then click Apply:

Tunnel Interface Name: 3

Zone (VR): Untrust
Unnumbered (select) Interface: ethernet4

Examples  59
 Concepts & Examples ScreenOS Reference Guide

2. Address
Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: phone1

IPv4/Netmask: 10.1.1.3/32
Zone: V1-Trust
3. VPN
VPNs > AutoKey Advanced > Gateway > New: Enter the following, then click
OK:

Gateway Name: to-central

Security Level: Standard
IPvc4/v6 Address/Hostname: 1.1.2.1
Preshare Key: netscreen
Outgoing Interface: ethernet3

VPNs > AutoKey IKE > New: Enter the following, then click OK:

VPN Name: vpn-central

Advanced: Enter the following advanced settings, then click Return to

return to the basic Gateway configuration page:

Bind to (select): Tunnel Interface, tunnel.1

VPNs > AutoKey Advanced > Gateway > New: Enter the following, then click
OK:

Gateway Name: to-ns50

Security Level: Standard
IPvc4/v6 Address/Hostname: 5.5.5.5
Preshare Key: netscreen
Outgoing Interface: ethernet4

VPNs > AutoKey IKE > New: Enter the following, then click OK:

VPN Name: vpn-ns50

Advanced: Enter the following advanced settings, then click Return to

return to the basic Gateway configuration page:

Bind to (select): Tunnel Interface, tunnel.3

4. Routing
Network > Routing > Destination > New: Enter the following, then click OK:

Network Address / Netmask: 10.1.2.0/24

Interface (select): tunnel.3

Network > Routing > Destination > New: Enter the following, then click OK:

Network Address / Netmask: 10.1.3.0/24

Interface (select): tunnel.1
5. Policies
Policies > (From: Trust, To: Untrust) > New: Enter the following, then click OK:

60  Examples
 Chapter 2: Session Initiation Protocol Application Layer Gateway

Source Address (select) Address Book Entry: phone2

Destination Address (select) Address Book Entry: Any-IPv4
Service: SIP
Action: Permit

Policies > (From: Untrust, To: Trust) > New: Enter the following, then click OK:

Source Address (select) Address Book Entry: Any-IPv4

Destination Address (select) Address Book Entry: phone2
Service: SIP
Action: Permit

CLI (for Branch Office 1)

1. Interfaces
set interface ethernet1 zone trust
set interface ethernet1 ip 10.1.1.1/24
set interface ethernet1 route
set interface ethernet3 zone untrust
set interface ethernet3 ip 3.3.3.3/24
set interface ethernet4 zone untrust
set interface ethernet4 ip 4.4.4.4/24
set interface tunnel.2 zone untrust
set interface tunnel.2 ip unnumbered interface ethernet3
set interface tunnel.3 zone untrust
set interface tunnel.3 ip unnumbered interface ethernet4
2. Address
set address trust phone1 10.1.1.3/32
3. VPN
set ike gateway to-central address 1.1.1.1 main outgoing-interface ethernet3
preshare netscreen sec-level standard
set ike gateway to-ns50 address 5.5.5.5 main outgoing-interface ethernet4
preshare netscreen sec-level standard
set vpn vpncentral gateway to-central no-replay tunnel idletime 0 sec-level standard
set vpn vpncentral bind interface tunnel.1
set vpn vpn-ns50 gateway to-ns50 no-replay tunnel idletime 0 sec-level standard
set vpn vpn-ns50 bind interface tunnel.3
4. Routes
set route 10.1.2.0/24 interface tunnel.3
set route 10.1.3.0/24 interface tunnel.1
5. Policies
set policy from trust to untrust phone1 any sip permit
set policy from untrust to trust any phone1 sip permit
save

WebUI (for Branch Office 2)

1. Interfaces
Network > Interfaces > Edit (for ethernet1): Enter the following, then click
Apply:

Zone: Trust
Static IP: (select when this option is present)
IP Address/Netmask: 10.1.2.1/24

Examples  61
 Concepts & Examples ScreenOS Reference Guide

Enter the following, then click OK:

Interface mode: NAT

Network > Interfaces > Edit (for ethernet3): Enter the following, then click
Apply:

Zone: Untrust
Static IP: (select when this option is present)
IP Address/Netmask: 2.2.2.2/24

Network > Interfaces > Edit (for ethernet4): Enter the following, then click
Apply:

Zone: Untrust
Static IP: (select when this option is present)
IP Address/Netmask: 4.4.4.4/24

Network > Interfaces > New Tunnel IF: Enter the following, then click Apply:

Tunnel Interface Name: 2

Zone (VR): Untrust
Unnumbered (select) Interface: ethernet3

Network > Interfaces > New Tunnel IF: Enter the following, then click Apply:

Tunnel Interface Name: 3

Zone (VR): Untrust
Unnumbered (select) Interface: ethernet4

2. Address
Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: phone2

IPv4/Netmask: 10.1.2.3/32
Zone: Trust
3. VPN
VPNs > AutoKey Advanced > Gateway > New: Enter the following, then click
OK:

Gateway Name: to-central

Security Level: Standard
IPvc4/v6 Address/Hostname: 1.1.2.1
Preshare Key: netscreen
Outgoing Interface: ethernet3

VPNs > AutoKey IKE > New: Enter the following, then click OK:

VPN Name: vpn-central

Advanced: Enter the following advanced settings, then click Return to

return to the basic Gateway configuration page:

Bind to (select): Tunnel Interface, tunnel.2

VPNs > AutoKey Advanced > Gateway > New: Enter the following, then click
OK:

62  Examples
 Chapter 2: Session Initiation Protocol Application Layer Gateway

Gateway Name: to-ns50

Security Level: Standard
IPvc4/v6 Address/Hostname: 4.4.4.4
Preshare Key: netscreen
Outgoing Interface: ethernet4

VPNs > AutoKey IKE > New: Enter the following, then click OK:

VPN Name: vpn-ns50

Advanced: Enter the following advanced settings, then click Return to

return to the basic Gateway configuration page:

Bind to (select): Tunnel Interface, tunnel.3

4. Routing
Network > Routing > Destination > New: Enter the following, then click OK:

Network Address / Netmask: 10.1.3.0/24

Interface (select): tunnel.2

Network > Routing > Destination > New: Enter the following, then click OK:

Network Address / Netmask: 10.1.1.0/24

Interface (select): tunnel.3
5. Policies
Policies > (From: Trust, To: Untrust) New Enter the following, then click OK:

Source Address (select) Address Book Entry: phone2

Destination Address (select) Address Book Entry: Any-IPv4
Service: SIP
Action: Permit

Policies > (From: Untrust, To: Trust) > New: Enter the following, then click OK:

Source Address (select) Address Book Entry: Any-IPv4

Destination Address (select) Address Book Entry: phone2
Service: SIP
Action: Permit

Examples  63
 Concepts & Examples ScreenOS Reference Guide

CLI (for Branch Office 2)

1. Interfaces
set interface ethernet1 zone trust
set interface ethernet1 ip 10.1.2.1/24
set interface ethernet3 zone untrust
set interface ethernet3 ip 2.2.2.2/24
set interface ethernet4 zone untrust
set interface ethernet4 ip 4.4.4.4/24
set interface tunnel.2 zone untrust
set interface tunnel.2 ip unnumbered interface ethernet3
set interface tunnel.3 zone untrust
set interface tunnel.3 ip unnumbered interface ethernet4
2. Address
set address trust phone2 10.1.2.3/32
3. VPN
set ike gateway to-central address 1.1.2.1 Main outgoing-interface ethernet3
preshare netscreen sec-level standard
set ike gateway to-ns50 address 4.4.4.4Main outgoing-interface ethernet4
preshare netscreen sec-level standard
set vpn vpncentral gateway to-central no-replay tunnel idletime 0 sec-level standard
set vpn vpncentral id 4 bind interface tunnel.2
set vpn vpn-ns50 gateway to-ns50 no-replay tunnel idletime 0 sec-level standard
set vpn vpn-ns50 id 5 bind interface tunnel.3
4. Routes
set route 10.1.3.0/24 interface tunnel.2
set route 10.1.1.0/24 interface tunnel.3
5. Policies
set policy from trust to untrust phone2 any sip permit
set policy from untrust to trust any phone2 sip permit
save

Bandwidth Management for VoIP Services

We recommend the following ways to manage bandwidth for VoIP services, using
the standard ScreenOS traffic shaping mechanisms:

 Guarantee bandwidth for VoIP traffic—The most effective way to ensure quality
VoIP service, and still allow other types of traffic on the interface, is to create a
policy guaranteeing the minimum bandwidth necessary for the amount of VoIP
traffic you expect on the interface and set priority queuing to the highest level.
The advantage of this strategy is that VoIP traffic can use additional bandwidth
when it is available, and other types of traffic can use bandwidth not
guaranteed for VoIP when VoIP traffic is not using it.

 Limit bandwidth for non-VoIP traffic—By setting a maximum bandwidth for

non-VoIP traffic, you make the remaining bandwidth available to VoIP traffic.
You would also set priority queuing to the highest level for VoIP traffic. The
disadvantage of this method is that non-VoIP traffic cannot use additional
bandwidth even when VoIP traffic is not using it.

64  Examples
 Chapter 2: Session Initiation Protocol Application Layer Gateway

 Use priority queuing and Differentiated Services Codepoint (DSCP)

marking—Guaranteeing bandwidth for VoIP traffic and limiting bandwidth for
non-VoIP traffic both govern throughput on the security device. DSCP marking
enables you to preserve your priority-queuing settings downstream and to keep
or change the received DSCP value set by the originating networking device
upstream so that the next-hop router, typically the LAN or WAN edge router, can
enforce Quality of Service (QoS) in its DiffServ domain. In VPN configurations,
the security device marks the outer header of the IP packet (if the policy is
configured to do so), or leaves the TOS byte as 0 so that the next-hop router can
enforce the correct QoS on the encrypted traffic. For information about how
DSCP works with priority levels in policies, see “Traffic Shaping” on page 173.

Figure 21 on page 65 shows how priority-level settings can affect guaranteed

bandwidth (gbw) and maximum bandwidth (mbw) usage on an ethernet1 (2 Mbps)
interface. The illustration assumes you have determined you need to support at
least eight VoIP calls (8 x 64 Kbps bandwidth per call, for a total of 512 Kbps) and
occasionally as many as 16 calls. You have guaranteed the remaining bandwidth to
general office traffic and have set maximum bandwidth for your office traffic to
include bandwidth not guaranteed to VoIP. This creates a 512 Kbps overlap of
maximum bandwidth for VoIP and office-traffic services, shown by the dashed
lines.

The left side of Figure 21 shows what bandwidth usage with these settings looks like
with high office-traffic usage and low VoIP traffic usage on the interface. If VoIP
traffic suddenly needs more bandwidth, it cannot get it unless it has a higher
priority than the office-traffic services. The right side of Figure 21 shows what
bandwidth usage looks like in the same circumstance when you give VoIP traffic a
higher priority and set office traffic to a lower priority. For more information about
configuring bandwidth and priority levels, see “Traffic Shaping” on page 193.

Figure 21: Priority-Level Settings

Guaranteed and Adding priority

maximum bandwidth settings level settings

VoIP
gbw 512 Kbps VoIP Traffic
VoIP

2 Mbps Total mbw 1536 Kbps mbw 1024 Kbps 2 Mbps Total
Bandwidth Bandwidth

Office Traffic gbw 1024 Kbps

Office Traffic
Office Traffic

Examples  65
 Concepts & Examples ScreenOS Reference Guide

66  Examples
Chapter 3
Media Gateway Control Protocol
Application Layer Gateway

This chapter presents an overview of the Media Gateway Control Protocol (MGCP)
Application Layer Gateway (ALG) and lists the firewall security features of the
implementation. Examples of typical scenarios follow a summary of the MGCP
architecture. This chapter includes the following sections:

 “Overview” on page 67

 “MGCP Security” on page 68

 “About MGCP” on page 68

 “Examples” on page 73

Overview
The Media Gateway Control Protocol (MGCP) is supported on security devices in
Route, Transparent, and Network Address Translation (NAT) mode. MGCP is a
text-based Application Layer protocol used for call setup and control. MGCP is based
on a master-slave call control architecture in which the media gateway controller,
via the call agent, maintains call control intelligence, while the media gateways
carry out the instructions of the call agent.

The MGCP ALG performs the following procedures:

 Conducts VoIP signaling payload inspection. The payload of the incoming VoIP
signaling packet is fully inspected based on related RFCs and proprietary
standards. Any malformed packet attack is blocked by the ALG.

 Conducts MGCP signaling payload inspection. The payload of the incoming

MGCP signaling packet is fully inspected in accordance with RFC 3435. Any
malformed-packet attack is blocked by the ALG.

 Provides stateful processing. The corresponding VoIP-based state machines are

invoked to process the parsed information. Any out-of-state or
out-of-transaction packet is identified and properly handled.

Overview  67
 Concepts & Examples ScreenOS Reference Guide

 Performs Network Address Translation (NAT). Any embedded IP address and

port information in the payload is properly translated based on the existing
routing information and network topology, and is replaced with the translated
IP address and port number, if necessary.

 Manages pinholes for VoIP traffic. To keep the VoIP network secure, the IP
address and port information used for media or signaling is identified by the
ALG, and any needed pinhole is dynamically created and closed during call
setup.

MGCP Security
The MGCP ALG includes the following security features:

 Denial of Service (DoS) attack protection—the ALG performs stateful inspection

at the UDP packet level, the transaction level, and at the call level. MGCP
packets matching the RFC 3435 message format, transaction state, and call
state, are processed. All other messages are dropped.

 Firewall policy enforcement between gateway and gateway controller (signaling

policy).

 Firewall policy enforcement between gateways (media policy).

 Per-gateway MGCP message flooding control. Any malfunctioning or hacked

gateway will not disrupt the whole VoIP network. Combined with per-gateway
flooding control, damage is contained within the impacted gateway.

 Per-gateway MGCP connection flooding control.

 Seamless switchover/failover if calls, including calls in progress, are switched to

the standby firewall in case of system failure.

About MGCP
MGCP is a text-based, application layer protocol that can be used for call setup and
control. The protocol is based on a master/slave call control architecture: the media
gateway controller (call agent) maintains call control intelligence, and media
gateways carry out the instructions from the call agent.

Entities in MGCP
There are four basic entities in MGCP:

 “Endpoint” on page 69

 “Connection” on page 69

 “Call” on page 69

 “Call Agent” on page 69

68  MGCP Security
 Chapter 3: Media Gateway Control Protocol Application Layer Gateway

Endpoint
A media gateway (MG) is a collection of endpoints. An endpoint can be an analog
line, trunk, or any other access point. An endpoint is named as below:

local-endpoint-name@domain-name

The following are some valid endpoint IDs:

group1/[email protected]

group2/Trk1/*@[192.168.10.8] (wild-carding)

[email protected] (any endpoint within the MG)

*@voiptel.net (all endpoints within the MG)

Connection
Connections are created on each endpoint by a MG during call setup. A typical VoIP
call involves two connections. A complex call, for example a three-party call or
conference call, might require more connections. The media gateway controller
(MGC) can instruct media gateways to create, modify, delete and audit a connection.

A connection is identified by its connection ID which is created by the MG when it

is requested to create a connection. Connection ID is presented as a hexadecimal
string, and its maximum length is 32 characters.

Call
A call is identified by its call ID, which is created by the MGC when establishing a
new call. Call ID is a hexadecimal string with a maximum length of 32 characters.
Call ID is unique within the MGC. Two or more connections can have the same call
ID if they belong to the same call.

Call Agent
One or more call agents (also called media gateway controllers) are supported in
MGCP to enhance reliability in VoIP network. The following are two examples of call
agent names:

[email protected]

voipCA.mynetwork.com

Several network addresses can be associated under one domain name in the
Domain Name System (DNS). By keeping track of the time to live (TTL) of DNS
query/response data and implementing retransmission using other alternative
network addresses, switchover and failover is achieved in MGCP.

The concept of notified entity is essential in MGCP. The notified entity for an
endpoint is the call agent currently controlling that endpoint. An endpoint should
send any MGCP command to its notified entity. However, different call agents might
send MGCP commands to this endpoint.

About MGCP  69
 Concepts & Examples ScreenOS Reference Guide

The notified entity is set to a provisioned value upon startup, but could be changed
by a call agent through the use of a Notified Entity parameter contained in a MGCP
message. If the notified entity for an endpoint is empty or has not been set
explicitly, its value defaults to the source address of the last successful non-audit
MGCP command received for that endpoint.

Commands
The MGCP protocol defines nine commands for controlling endpoints and
connections. All commands are composed of a command header, optionally
followed by session description protocol (SDP) information. A command header has
the following elements:

 A command line: command verb + transaction ID + endpointId + MGCP

version.

 Zero or more parameter lines, composed of a parameter name followed by a

parameter value.

Table 3 lists supported MGCP commands, with a description of each, the command
syntax, and examples. Refer to RFC 2234 for a complete explanation of command
syntax.

Table 3: MGCP Commands (page 1 of 3)

Command
Verb Description Command Syntax Examples
EPCF EndpointConfiguration—used by ReturnCode EPCF 2012 wxx/[email protected]
a call agent to inform a gateway [PackageList] MGCP 1.0
of coding characteristics (a-law EndpointConfiguration (EndpointId, B: e:mu
or mu-law) expected by the line [BearerInformation])
side of the endpoint.
CRCX CreateConnection—used by a ReturnCode, CRCX 1205 aaln/[email protected]
call agent to instruct the gateway [ConnectionId,] MGCP 1.0
to create a connection with, and [SpecificEndPointId,] C: A3C47F21456789F0
endpoint inside, the gateway. [LocalConnectionDescriptor,] L: p:10, a:PCMU
[SecondEndPointId,] M: sendrecv
[SecondConnectionId,][Pac X: 0123456789AD
kageList] R: L/hd
CreateConnection (CallId, S: L/rg
EndpointId, v=0
[NotifiedEntity,] o=- 25678 753849 IN IP4
[LocalConnectionOption,] 128.96.41.1
Mode, s=-
[{RemoteConnectionDescriptor | c=IN IP4 128.96.41.1
SecondEndpoindId},] t=0 0
[encapsulated RQNT,] m=audio 3456 RTP/AVP 0
[encapsulated EPCF])

70  About MGCP
 Chapter 3: Media Gateway Control Protocol Application Layer Gateway

Table 3: MGCP Commands (page 2 of 3)

Command
Verb Description Command Syntax Examples
MDCX ModifyConnection—used by a ReturnCode, MDCX 1210 aaln/[email protected]
call agent to instruct a gateway to [LocalConnectionDescriptor,] MGCP 1.0
change the parameters for an [PackageList] C: A3C47F21456789F0
existing connection. ModifyConnection (CallId, I: FDE234C8
EndpointId, M: recvonly
ConnectionId, X: 0123456789AE
[NotifiedEntity,] R: L/hu
[LocalConnectionOption,] S: G/rt
[Mode,] v=0
[RemoteConnectionDescriptor,] o=- 4723891 7428910 IN IP4
[encapsulated RQNT,] 128.96.63.25
[encapsulated EPCF]) s=-
c=IN IP4 128.96.63.25
t=0 0
m=audio 3456 RTP/AVP 0
DLCX DeleteConnection—used by a ReturnCode, Example 1: MGC -> MG
call agent to instruct a gateway to ConnectionParameters, DLCX 9210 aaln/[email protected]
delete an existing connection. [PackageList] MGCP 1.0
DeleteConnection can also be DeleteConnection (CallId, C: A3C47F21456789F0
used by a gateway to release a EndpointId, I: FDE234C8
connection that can no longer be ConnectionId,
[NotifiedEntity,] Example 2: MG -> MGC
sustained.
[encapsulated RQNT,] DLCX 9310 aaln/[email protected]
[encapsulated EPCF]) MGCP 1.0
C: A3C47F21456789F0
I: FDE234C8
E: 900 - Hardware error
P: PS=1245, OS=62345, PR=780,
OR=45123, PL=10, JI=27, LA=48
RQNT The NotificationRequest ReturnCode, RQNT 1205 aaln/[email protected]
command is used by a call agent [PackageList] MGCP 1.0
to instruct a MG to monitor for NotificationRequest[(EndpointId, N: [email protected]
certain event(s) or signal(s) for a [NotifiedEntity,] X: 0123456789AA
specific endpoint. [RequestedEvents,] R: L/hd(A,
RequestIdentifier, E(S(L/dl),R(L/oc,L/hu,D/[0-9#*T](D))))
[DigitMap,] D:
[SignalRequests,] (0T|00T|xx|91xxxxxxxxxx|9011x.T)
[QuarantineHandling,] S:
[DetectEvents,] T: G/ft
[encapsulated EPCF])
NTFY Notify—used by a gateway to ReturnCode, NTFY 2002 aaln/[email protected]
inform the call agent when [PackageList] MGCP 1.0
requested event(s) or signal(s) Notify (EndpointID, N: [email protected]:5678
occur. [NotifiedEntity,] X: 0123456789AC
RequestIdentifier, O:
ObservedEvents) L/hd,D/9,D/1,D/2,D/0,D/1,D/8,D/2,D/
9,D/4, D/2,D/6,D/6

About MGCP  71
 Concepts & Examples ScreenOS Reference Guide

Table 3: MGCP Commands (page 3 of 3)

Command
Verb Description Command Syntax Examples
AUEP AuditEndpoint—used by a call ReturnCode, Example 1:
agent to audit the status of the EndPointIdList, | { AUEP 1201 aaln/[email protected]
endpoint. [RequestedEvents,] MGCP 1.0
[QuarantineHandling,] F: A, R,D,S,X,N,I,T,O
[DigitMap,] Example 2:
[SignalRequests,] AUEP 1200 *@rgw-25.att.net MGCP
[RequestedIdentifier,] 1.0
[NotifiedEntity,]
[ConnectionIdentifier,]
[DetectEvents,]
[ObservedEvents,]
[EventStats,]
[BearerInformation,]
[BearerMethod,]
[RestartDelay,]
[ReasonCode,]
[MaxMGCPDatagram,]
[Capabilities]}
[PackageList]
AuditEndpoint (EndpointId,
[RequestedInfo])
AUCX AuditConnection—used by a call ReturnCode, AUCX 3003 aaln/[email protected]
agent to collect the parameters [CallId,] MGCP 1.0
applied to a connection. [NotifiedEntity,] I: 32F345E2
[LocalConnectionOptions,] F: C,N,L,M,LC,P
[Mode,]
[RemoteConnectionDescriptor,]
[LocalConnectionDescriptor,]
[ConnectionParameters,]
[PackageList]
AuditConnection (EndpointId,
ConnectionId,
RequestedInfo)
RSIP RestartInProgress—used by a ReturnCode, RSIP 5200 aaln/[email protected]
gateway to notify a call agent [NotifiedEntity,] MGCP 1.0
that one or more endpoints are [PackageList] RM: graceful
being taken out of service or RestartInProgress (EndpointId, RD: 300
placed back in service. RestartMethod,
[RestartDelay,]
[ReasonCode])

Response Codes
Every command sent by the calling agent or gateway, whether successful or not,
requires a response code. The response code is in the header of the response
message, and optionally is followed by session description information.

The response header is composed of a response line, followed by zero or more

parameter lines, each containing a parameter name letter followed by its
value. The response header is composed of a 3-digit response code,
transaction ID, and optionally followed by commentary. The response
header in the following response message shows the response code 200
(successful completion), followed by ID 1204, and the comment: OK:

72  About MGCP
 Chapter 3: Media Gateway Control Protocol Application Layer Gateway

200 1204 OK
I: FDE234C8

v=0
o=- 25678 753849 IN IP4 128.96.41.1
s=-
c=IN IP4 128.96.41.1
t=0 0
m=audio 3456 RTP/AVP 96
a=rtpmap:96 G726-32/8000

The ranges of response codes are defined as follows:

 000 – 099: indicate a response acknowledgement.

 100 – 199: indicate a provisional response.

 200 – 299: indicate a successful completion (final response).

 400 – 499: indicate a transient error (final response).

 500 – 599: indicate a permanent error (final response).

Refer to RFC 3661 for detailed information about response codes.

A response to a command is sent to the source address of the command, not to the
current notified entity. A media gateway can receive MGCP commands from various
network addresses simultaneously, and send back responses to corresponding
network addresses. However, it sends all MGCP commands to its current notified
entity.

Examples
This section includes the following configuration scenarios:

 “Media Gateway in Subscribers’ Homes—Call Agent at the ISP” on page 73

 “ISP-Hosted Service” on page 76

Media Gateway in Subscribers’ Homes—Call Agent at the ISP

In this example (see Figure 22) you configure a security device at a Cable Service
Provider to support MGCP for their network of residential subscribers. The security
device and the call agent are on the cable service provider’s premises. An integrated
Access Device (IAD), or set-top box, is in each subscriber’s home, acting as a
gateway—each IAD represents a separate residence. The call agent is in the trust_ca
zone; residential customers are in the res_cust zone.

After creating zones—untrust_subscriber for the customers and trust_ca for the
service provider, you configure addresses, and then policies. Although gateways
frequently reside in different zones, requiring policies for media traffic, in this
example both gateways are in the same subnet. RTP traffic between the gateways
never passes through the firewall, therefore no policy is needed for media.

Examples  73
 Concepts & Examples ScreenOS Reference Guide

Figure 22: Media Gateway in Subscribers’ Home

Untrust

IAD

IP Phone
IAD

Security Device Ethernet 3

2.2.2.0/24
IP Phone
Cable Service IAD
Provider Network
Ethernet 4
10.1.1.2
IP Phone
IAD
Trust
Call Agent
IP Phone

WebUI
1. Zones
Network > Zones > New: Enter the following, then click OK:

Zone Name: untrust_subscriber

Network > Zones > New: Enter the following, then click OK:

Zone Name: trust_ca

2. Addresses
Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: SubscriberSubNet

Comment: Our subscribers’ network
IP Address/Domain Name:
IP/Netmask: (select), 2.2.2.0/24
Zone: untrust-subscriber

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: call_agent1

Comment: Our No. 1 call agent
IP Address/Domain Name:
IP/Netmask: (select), 10.1.1.101/32
Zone: trust_ca

74  Examples
 Chapter 3: Media Gateway Control Protocol Application Layer Gateway

3. Interfaces
Network > Interfaces > Edit (for ethernet3): Enter the following, then click
Apply:

Zone Name: untrust_subscriber

Static IP: (select this option when present)
IP Address/Netmask: 2.2.2.0/24
Enter the following, then click OK:
Interface Mode: route

Network > Interfaces > Edit (for ethernet4): Enter the following, then click
Apply:

Zone Name: trust_ca

Static IP: (select this option when present)
IP Address/Netmask: 10.1.1.101/32
Enter the following, then click OK:
Interface Mode: route
4. Policies
Policies > (From: trust-ca, To: untrust_subscriber) New: Enter the following,
then click OK:

Name: Pol-CA-To-Subscribers
Source Address
Address Book Entry: (select), call_agent1
Destination Address
Address Book Entry: (select), SubscriberSubNet
Service: MGCP-UA
Action: Permit

Policies > (From: untrust_subscriber, To: trust-ca) New: Enter the following,
then click OK:

Name: Pol-Subscribers-To-CA
Source Address
Address Book Entry: (select), SubscriberSubNet
Destination Address
Address Book Entry: (select), call_agent1
Service: MGCP-CA
Action: Permit

CLI
1. Zones
set zone name untrust_subscriber
set zone name trust_ca
2. Addresses
set address untrust_subscriber SubscriberSubNet 2.2.2.0 255.255.255.0 “Our
subscribers' network”
set address trust_ca call_agent1 10.1.1.101 255.255.255.255 “Our No. 1 call
agent”

Examples  75
 Concepts & Examples ScreenOS Reference Guide

3. Interfaces
set interface ethernet3 zone untrust_subscriber “Our subscribers’ network”
set interface ethernet3 ip 2.2.2.0/24
set interface ethernet3 route

set interface ethernet4 zone trust_ca “Our No. 1 call agent”

set interface ethernet4 ip 10.1.1.2/24
set interface ethernet4 route
4. Policies
set policy name Pol-CA-TO-Subscribers from trust_ca to untrust_subscriber
call_agent1 SubscriberSubNet mgcp-ua permit
set policy name Pol-Subscribers-To-CA from untrust_subscriber to trust_ca
SubscriberSubNet call_agent1 mgcp-ca permit

ISP-Hosted Service
In this example, (see Figure 23) an ISP located on the American west coast provides
MGCP service to customers in Asia and San Francisco. Asia customers are in the
Untrust zone, and supported by the gateway: asia_gw (3.3.3.110); San Francisco
customers are in the Trust zone, and supported by the gateway: sf_gw (2.2.2.201).
The call agent: west_ca (10.1.1.101) is in the DMZ.

After setting addresses for the gateways and the call agent, you configure the
interfaces, putting ethernet4 and ethernet5, which are trusted, in route mode to
allow them to stream media directly after call setup. To protect the IP address of the
call agent in the DMZ from exposure, you place a MIP on ethernet6, that is, you
map the IP address of the call agent (10.1.1.101) to an IP address from the pool of
addresses on the ethernet6 interface, in this case: 3.3.3.101.

Finally, you create policies. To allow MGCP signaling between the call agent in the
DMZ and the gateway in the Untrust zone, you create one policy for each direction,
referencing the MIP that protects the call agent. You create another pair of policies
to allow signaling between the call agent and the gateway in the Trust zone. A single
policy is sufficient to allow bidirectional communication between gateways in the
Trust and Untrust zones.

76  Examples
 Chapter 3: Media Gateway Control Protocol Application Layer Gateway

Figure 23: ISP-Hosted Service

Virtual Device
DMZ MIP on Ethernet6 -
3.3.3.101 - 10.1.1.101
west_ca
10.1.1.101

Eth5 - 10.1.1.2 Security Device

asia_gw
3.3.3.110
ISP Network
Eth6 - 3.3.3.10 Untrust Zone
Eth4 - 2.2.2.10
IP Phone

Trust Zone

sf_gw
2.2.2.201 IP Phone

WebUI
1. Addresses
Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: sf_gw

Comment: gateway in asia
IP Address/Domain Name:
IP/Netmask: (select), 2.2.2.201/32
zone: Trust

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: asia_gw

Comment: gateway in asia
IP Address/Domain Name:
IP/Netmask: (select), 3.3.3.110/32
zone: Untrust

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: west_ca

Comment: ca in west coast
IP Address/Domain Name:
IP/Netmask: (select), 10.1.1.101/32
zone: DMZ

Examples  77
 Concepts & Examples ScreenOS Reference Guide

2. Interfaces
Network > Interfaces > Edit (for ethernet4): Enter the following, then click
Apply:

Zone Name: Trust

Static IP: (select this option when present)
IP Address/Netmask: 2.2.2.10/24
Enter the following, then click OK:
Interface Mode: route

Network > Interfaces > Edit (for ethernet5): Enter the following, then click
Apply:

Zone Name: DMZ

Static IP: (select this option when present)
IP Address/Netmask: 10.1.1.2/24
Enter the following, then click OK:
Interface Mode: route

Network > Interfaces > Edit (for ethernet6): Enter the following, then click
Apply:

Zone Name: Untrust

Static IP: (select this option when present)
IP Address/Netmask: 3.3.3.10/24
Enter the following, then click OK:
Interface Mode: NAT
3. MIP
Network > Interfaces > Edit (for ethernet6) > MIP > New: Enter the
following, then click OK:

Mapped IP: 3.3.3.101

Netmask: 255.255.255.255
Host IP Address: 10.1.1.101
Host Virtual Router Name: trust-vr
4. Policies
Policies > (From: DMZ To: Untrust) New: Enter the following, then click OK:

Source Address
Address Book Entry: (select), west_ca
Destination Address
Address Book Entry: (select), asia_gw
Service: MGCP-UA
Action: Permit

Policies > (From: Untrust To: DMZ) New: Enter the following, then click OK:

Source Address
Address Book Entry: (select), asia_gw
Destination Address
Address Book Entry: (select), west_ca
Service: MGCP-CA
Action: Permit

78  Examples
 Chapter 3: Media Gateway Control Protocol Application Layer Gateway

Policies > (From: Trust To: DMZ) New: Enter the following, then click OK:

Source Address
Address Book Entry: (select), sf_gw
Destination Address
Address Book Entry: (select), west_ca
Service: MGCP-CA
Action: Permit

Policies > (From: DMZ To: Trust) New: Enter the following, then click OK:

Source Address
Address Book Entry: (select), west_ca
Destination Address
Address Book Entry: (select), sf_gw
Service: MGCP-UA
Action: Permit

Policies > (From: Trust To: Untrust) New: Enter the following, then click OK:

Source Address
Address Book Entry: (select), sf_gw
Destination Address
Address Book Entry: (select), asia_gw
Service: MGCP-UA
Action: Permit

> Advanced: Enter the following, then click Return to set the advanced
options and return to the basic configuration page:

NAT:
Source Translation: (select)
DIP on: None (Use Egress Interface IP)

CLI
1. Addresses
set address trust sf_gw 2.2.2.201/32 “gateway in s.f.”
set address untrust asia_gw 3.3.3.110/32 “gateway in asia”
set address dmz west_ca 10.1.1.101/32 “ca in west coast”
2. Interfaces
set interface ethernet4 ip 2.2.2.10/24
set interface ethernet4 route
set interface ethernet4 zone trust

set interface ethernet5 ip 10.1.1.2/24

set interface ethernet5 route
set interface ethernet5 zone dmz

set interface ethernet6 ip 3.3.3.10/24

set interface ethernet6 zone untrust
3. Mapped IP Address
set interface ethernet6 mip 3.3.3.101 host 10.1.1.101 netmask
255.255.255.255 vrouter trust-vr

Examples  79
 Concepts & Examples ScreenOS Reference Guide

4. Policies
set policy from dmz to untrust west_ca asia_gw mgcp-ua permit
set policy from untrust to dmz asia_gw mip(3.3.3.101) mgcp-ca permit

set policy from trust to dmz sf_gw west_ca mgcp-ca permit

set policy from dmz to trust west_ca sf_gw mgcp-ua permit

set policy from trust to untrust sf_gw asia_gw mgcp-ua nat src permit

80  Examples
Chapter 4
Skinny Client Control Protocol
Application Layer Gateway

This chapter presents an overview of the Skinny Client Control Protocol (SCCP)
Application Layer Gateway (ALG) and lists the firewall security features of the
implementation. Examples of typical scenarios follow a summary of the SCCP
architecture. This chapter includes the following sections:

 “Overview” on page 81

 “SCCP Security” on page 82

 “Examples” on page 87

Overview
Skinny Client Control Protocol (SCCP) is supported on security devices in Route,
Transparent, and Network Address Translation (NAT) modes. SCCP is a binary-based
Application Layer protocol used for Voice-over-Internet Protocol (VoIP) call setup
and control. In the SCCP architecture, a Cisco H.323 proxy, known as the Call
Manager, does most of the processing. IP phones, also called End Stations, run the
Skinny client and connect to a primary (and, if available, a secondary) Call Manager
over TCP on port 2000 and register with the primary Call Manager. This connection
is then used to establish calls coming to or from the client.

The SCCP ALG supports the following:

 Call flow from a Skinny client, through the Call Manager, to another Skinny
client.

 Seamless failover—switches over all calls in process to the standby firewall

during failure of the primary.

 VoIP signaling payload inspection—fully inspects the payload of incoming VoIP

signaling packets based on related RFCs and proprietary standards. Any
malformed packet attack is blocked by the ALG.

 SCCP signaling payload inspection—fully inspects the payload of incoming

SCCP signaling packets in accordance with RFC 3435. Any malformed-packet
attack is blocked by the ALG.

Overview  81
 Concepts & Examples ScreenOS Reference Guide

 Stateful processing—invokes the corresponding VoIP-based state machines to

process the parsed information. Any out-of-state or out-of-transaction packet is
identified and properly handled.

 Network Address Translation (NAT)—translates any embedded IP address and

port information in the payload, based on the existing routing information and
network topology, with the translated IP address and port number, if necessary.

 Pinhole creation and management for VoIP traffic—identifies IP address and

port information used for media or signaling and dynamically opens (and
closes) pinholes to securely stream the media.

SCCP Security
The SCCP ALG includes the following security features:

 Denial of Service (DoS) attack protection—The ALG performs stateful inspection

at the UDP packet level, the transaction level, and the call level. Packets
matching the SCCP message format, transaction state, and call state are
processed. All other messages are dropped.

 Firewall policy enforcement between Cisco IP phones and the Call Manager
(Intra-Cluster).

 Firewall policy enforcement between Call Managers (Inter-Cluster).

 Call Manager flood control—Protects the Call Manager from being flooded with
new calls either by an already compromised connected client or by a faulty
device.

 Firewall policy enforcement between gateways (media policy).

 Per-gateway SCCP connection flooding control.

 Seamless switchover/failover if calls, including calls in progress, are switched to

the standby firewall in case of system failure.

82  SCCP Security
 Chapter 4: Skinny Client Control Protocol Application Layer Gateway

About SCCP
The following sections give a brief overview of SCCP and how it works:

 “SCCP Components” on page 83

 “SCCP Transactions” on page 84

 “SCCP Messages” on page 87

SCCP Components
The principle components of the SCCP VoIP architecture include the following:

 SCCP Client

 Call Manager

 Cluster

SCCP Client
The SCCP client runs on an IP phone, also called an End Station, which uses SCCP
for signaling and for making calls. In order for a Skinny client to make a call, it must
first register with a Primary Call Manager (and a secondary, if available). The
connection between the client and the Call Manager is over TCP on port 2000. This
connection is then used to establish calls to or from the client. Transmission of
media is over RTP, UDP, and IP.

Call Manager
The Call Manager is a Cisco H.323 server with overall control of all devices and
communication in the SCCP VoIP network. Its functions include defining,
monitoring and controlling SCCP groups, regions of numbers, and route
plans;providing initialization, admission and registration of devices on the network;
providing a redundant database that contains addresses, phone numbers, and
number formats; and initiating contact with called devices or their agents to
establish logical sessions in which voice communication can flow.

Cluster
A Cluster is a collection of SCCP clients and a Call Manager. The Call Manager in the
cluster knows about all SCCP clients in the cluster. There can be more than one Call
Manager for backup in a cluster. Call Manager behavior varies in each of the
following cluster scenarios:

 Intra-Cluster, in which the Call Manager knows about each SCCP client, and the
call is between SCCP clients of the same cluster.

 Inter-Cluster, in which the Call Manager needs to communicate with another

Call Manager using H.323 for call setup.

 Inter-Cluster calls using the gatekeeper for admission control and address
resolution.

About SCCP  83
 Concepts & Examples ScreenOS Reference Guide

Call Manager behavior also varies with calls between an SCCP client and a
phone in a Public Switched Telephone Network (PSTN), and with calls between
an SCCP client and a phone in another administrative domain that is using
H323.

SCCP Transactions
SCCP transactions are the processes that need to take place in order for an SCCP
call to proceed. SCCP transactions include the following:

 Client Initialization

 Client Registration

 Call Setup

 Media Setup

Client Initialization
To initialize, the SCCP client needs to know the IP address of the Call Manager, its
own IP address, and other information about the IP gateway and DNS servers.
Initialization takes place on the local LAN. The client sends a Dynamic Host Control
Protocol (DHCP) request to get an IP address, the DNS server address, and the TFTP
server name and address. The client needs the TFTP server name to download the
configuration file: sepmacaddr.cnf. If the TFTP name is not given, the client uses the
default filename in the IP phone. The client then downloads the configuration file
.cnf (xml) from TFTP server. CNF files contain the IP address or addresses of the
primary and secondary Cisco Call Manager. With this information, the client
contacts the Call Manager to register.

Client Registration
The SCCP client, after initialization, registers with the Call Manager over a TCP
connection on well-known default port 2000. The client registers by providing the
Call Manager with its IP address, the MAC address of the phone, and other
information, such as protocol and version. The client cannot initiate or receive calls
until it is registered. Keepalive messages keep this TCP connection open between
the client and Call Manager so that the client can initiate or receive calls at any time,
provided that a policy on the security device allows this.

Table 4 lists SCCP messages and indicates messages that are of interest to the
security device.

84  About SCCP
 Chapter 4: Skinny Client Control Protocol Application Layer Gateway

Table 4: SCCP Registration Messages

From Client From Call Manager Of Interest to Security Device

RegisterMessage b
IPortMessage b
RegisterAckMessage b
CapabilititsRequest
CapabilitiesResMessage
ButtonTemplateReqMessage
ButtonTemplateResMessage
SoftKeyTemplateReqMessage
SoftKeyTemplateResMessage
LineStatReqMessage b
LineStatMessage b

Call Setup
IP phone-to-IP phone call-setup using SCCP is always handled by the Call Manager.
Messages for call setup are sent to the Call Manager, which returns messages
appropriate to the status of the call. If call setup is successful, and a policy on the
security device allows the call, the Call Manager sends the media setup messages to
the client.

Media Setup
The Call Manager sends the IP address and port number of the called party to the
calling party. The Call Manager also sends the media IP address and port number of
the calling party to the called party. After media setup, media is transmitted directly
between clients. When the call ends, the Call Manager is informed and terminates
the media streams. At no time during this process does the Call Manager hand over
call-setup function to the client. Media is streamed directly between clients through
RTP/UDP/IP.

About SCCP  85
 Concepts & Examples ScreenOS Reference Guide

SCCP Control Messages and RTP Flow

Figure 24 shows the SCCP control messages used to set up and tear down a simple
call between Phone1 and Phone2. Except for the OffHook message initiating the call
from Phone1 and the OnHook message signaling the end of the call, all aspects of
the call are controlled by the Call Manager.

Figure 24: Call Setup and Teardown

Phone1 Call Manager Phone2

OffHook
CallState(offhook, ln 1, CID 16777332)
keypadbutton
Callstate(RingIn, ln 1, CID 16777333)
CallInfo(Inbound, ln 1, 2001->2002, Orig: 2002. CID16777333)
CallState(Proceed, ln 1, CID 16777332)
CallInfo(Outbound, ln 1, 2001->2002, Orig: 2002. CID16777332)
CallState(Ringout, ln 1, CID 16777332)
CallInfo(Outbound, ln 1, 2001->2002, CID16777332)
OffHook
CallState(OffHook, ln 1, CID 16777333)
OpenRcvChn1(PPID 16778577, CnfrId: 0)
OpenRcvChn1(PPID 16778561, CnfrId: 0)
CallState(Connected, ln 1, CID 16777333)
CallInfo(Inbound, ln 1, 2001->2002, Orig: 2002. CID16777333)
CallState(Connected, ln 1, CID 16777332)
CallInfo(outboundcall, ln 1, 2001->2002, CID16777332)
OpenRcvChnAck1(PPID 16778561, IP:10.10.10.10/Port:24038)
StartMediaX(PPID 16778577, IP:10.10.10.10/Port:24038), CnfrnId:0
OpenRcvChnAck1(PPID 16778577, IP:10.10.10.20/Port:30198)
StartMediaX(PPID 16778561, IP:10.10.10.20/Port:30198), CnffId:0

RTP/UDP (10.10.10.10/24038 -> 10.10.10.20/30198, 10.10.10.20/30198 -> 10.10.10.10/24038)

CallState(OnHook, ln 1, CID 16777332)

CloseRcvChn1(PPID 16778561, CnfrId:0) CloseRcvChn1(PPID 16778577, CnfrId:0)
StopMediaX(PPID 16778561, CnffId:0) StopMediaX(PPID 16778577, CnffId:0)

CallState(Terminate, ln 1, CID 16777332)

86  About SCCP
 Chapter 4: Skinny Client Control Protocol Application Layer Gateway

SCCP Messages
Table 5, Table 6, Table 7, and Table 8 list the SCCP call message IDs in the four
intervals allowed by the security device.

Table 5: Station to Call Manager Messages

Message Range
#define STATION_REGISTER_MESSAGE 0x00000001
#define STATION_IP_PORT_MESSAGE 0x00000002
#define STATION_ALARM_MESSAGE 0x00000020
#define STATION_OPEN_RECEIVE_CHANNEL_ACK 0x00000022

Table 6: Call Manager to Station Messages

Message Range
#define STATION_START_MEDIA_TRANSMISSION 0x00000001
#define STATION_STOP_MEDIA_TRANSMISSION 0x00000002
#define STATION_CALL_INFO_MESSAGE 0x00000020
#define STATION_OPEN_RECEIVE_CHANNEL_ACK 0x00000022
#define STATION_CLOSE_RECEIVE_CHANNEL 0x00000106

Table 7: Call Manager 4.0 Messages and Post Skinny 6.2

Message Range
#define STATION_REGISTER_TOKEN_REQ_MESSAGE 0x00000029
#define STATION_MEDIA_TRANSMISSION_FAILURE 0x0000002A
#define STATION_OPEN_MULTIMEDIA_RECEIVE_CHANNEL_ACK 0x00000031

Table 8: Call Manager to Station

Message Range
#define STATION_OPEN_MULTIMEDIA_RECEIVE_CHANNEL 0x00000131
#define STATION_START_MULTIMEDIA_TRANSMISSION 0x00000132
#define STATION_STOP_MULTIMEDIA_TRANSMISSION 0x00000133
#define STATION_CLOSE_MULTIMEDIA_RECEIVE_CHANNEL 0x00000136

Examples
This section contains the following sample scenarios:

 “Example: Call Manager/TFTP Server in the Trust Zone” on page 88

 “Example: Call Manager/TFTP Server in the Untrust Zone” on page 90

 “Example: Three-Zone, Call Manager/TFTP Server in the DMZ” on page 92

Examples  87
 Concepts & Examples ScreenOS Reference Guide

 “Example: Intrazone, Call Manager/TFTP Server in Trust Zone” on page 95

 “Example: Intrazone, Call Manager/TFTP Server in Untrust Zone” on page 99

 “Example: Full-Mesh VPN for SCCP” on page 101

Example: Call Manager/TFTP Server in the Trust Zone

In this example, phone1 and the Call Manager/TFTP Server are on the ethernet1
interface in the Trust (private) zone, and phone2 is on the ethernet3 interface in the
Untrust zone. You put a MIP for the Call Manager/TFTP Server on the ethernet3
interface, so that when phone2 boots up it can contact the TFTP Server and obtain
the IP address of the Call Manager. (We recommend that you change the IP address
of the Call Manager in the TFTP Server config file (sep <mac_addr>.cnf) to the
MIP IP address of the Call Manager.) You then create a policy allowing SCCP traffic
from the Untrust to the Trust zone and reference that MIP in the policy. You also
create a policy from the Trust to the Untrust zone to allow phone1 to call out.

Figure 25: Call Manager/TFTP Server in the Private Zone

ethernet1 ethernet3
10.1.1.1/24 1.1.1.1/24

Trust Untrust
Security Device

LAN Internet

Virtual Device
phone1 MIP on ethernet3 phone2
CM/TFTP Server 1.1.1.2 -> 10.1.1.4
10.1.1.4 10.1.1.3 1.1.1.4

WebUI
1. Interfaces
Network > Interfaces > Edit (for ethernet1): Enter the following, then click
OK:

Zone: Trust
Static IP: (select this option when present)
IP Address/Netmask: 10.1.1.1/24
Enter the following, then click OK:
Interface Mode: route

Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:

Zone: Untrust
IP Address/Netmask: 1.1.1.1/24
Interface Mode: Route

88  Examples
 Chapter 4: Skinny Client Control Protocol Application Layer Gateway

2. Addresses
Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: phone1

IP Address/Domain Name:
IP/Netmask: (select), 10.1.1.3/24
Zone: Trust

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: phone2

IP Address/Domain Name:
IP/Netmask: (select), 1.1.1.4/24
Zone: Untrust

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: CM-TFTP_Server

IP Address/Domain Name:
IP/Netmask: (select), 10.1.1.4/24
Zone: Trust
3. MIP
Network > Interfaces > Edit (for loopback.3) > MIP > New: Enter the
following, then click OK:

Mapped IP: 1.1.1.2

Netmask: 255.255.255.255
Host IP Address: 10.1.1.4
Host Virtual Router Name: trust-vr
4. Policies
Policies > (From: Trust, To: Untrust) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select) any
Destination Address:
Address Book Entry: (select) phone2
Service: SCCP
Action: Permit

> Advanced: Enter the following, then click Return to set the advanced
options and return to the basic configuration page:

NAT:
Source Translation: (select)
(DIP on): None (Use Egress Interface IP)

Examples  89
 Concepts & Examples ScreenOS Reference Guide

Policies > (From: Untrust, To: Trust) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), phone2
Destination Address:
Address Book Entry: (select), MIP(1.1.1.2)
Service: SCCP
Action: Permit

CLI
1. Interfaces
set interface ethernet1 zone trust
set interface ethernet1 ip 10.1.1.1/24
set interface ethernet1 route
set interface ethernet3 zone untrust
set interface ethernet3 ip 1.1.1.1/24
set interface ethernet3 route
2. Addresses
set address trust phone1 10.1.1.3/24
set address untrust phone2 1.1.1.4/24
set address trust cm-tftp_server 10.1.1.4/24
3. MIP
set interface ethernet3 mip 1.1.1.2 host 10.1.1.4
4. Policies
set policy from trust to untrust any phone2 sccp nat src permit
set policy from untrust to trust phone2 mip(1.1.1.2) sccp permit
save

NOTE: It is always more secure to specify a service explicitly, as shown in this example
configuration, than to use the keyword any.

Example: Call Manager/TFTP Server in the Untrust Zone

In this example, phone1 is on the ethernet1 interface in the Trust zone, and phone2
and the Call Manager/TFTP Server are on the ethernet3 interface in the Untrust
zone. After configuring interfaces and addresses, you create policy from the Trust
zone to the Untrust. This allows phone1 to register with the Call Manager/TFTP
Server in the Untrust zone.

90  Examples
 Chapter 4: Skinny Client Control Protocol Application Layer Gateway

Figure 26: Call Manager/TFTP Server in the Untrust Zone

ethernet1 ethernet3
10.1.1.1/24 1.1.1.1/24

Trust Untrust
Security Device
Internet

LAN

CM/TFTP Server
phone1 phone2 1.1.1.3
10.1.1.3 1.1.1.4

WebUI
1. Interfaces
Network > Interfaces > Edit (for ethernet1): Enter the following, then click
Apply:

Zone Name: Trust

Static IP: (select this option when present)
IP Address/Netmask: 10.1.1.1/24
Enter the following, then click OK:

Interface Mode: route

Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:

Zone Name: Untrust

Static IP: (select this option when present)
IP Address/Netmask: 1.1.1.1/24
Interface Mode: Route
2. Addresses
Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: phone1

IP Address/Domain Name:
IP/Netmask: (select), 10.1.1.3/24
Zone: Trust

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: phone2

IP Address/Domain Name:
IP/Netmask: (select), 1.1.1.4/24
Zone: Untrust

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: CM/TFTP Server

Examples  91
 Concepts & Examples ScreenOS Reference Guide

IP Address/Domain Name:
IP/Netmask: (select), 1.1.1.3/24
Zone: Untrust
3. Policies
Policies > (From: Trust, To: Untrust) New: Enter the following, then click OK:

Source Address
Address Book Entry: (select) phone1
Destination Address
Address Book Entry: (select) any
Service: SCCP
Action: Permit

> Advanced: Enter the following, then click Return to set the advanced
options and return to the basic configuration page:

NAT:
Source Translation: (select)
(DIP on): None (Use Egress Interface IP)

CLI
1. Interfaces
set interface ethernet1 zone trust
set interface ethernet1 ip 10.1.1.1/24
set interface ethernet1 route
set interface ethernet3 zone untrust
set interface ethernet3 ip 1.1.1.1/24
set interface ethernet3 route
2. Addresses
set address trust phone1 10.1.1.3/24
set address untrust phone2 1.1.1.4/24
set address untrust cm-tftp_server 1.1.1.3/24
3. Policies
set policy from trust to untrust phone1 any sccp nat src permit
save

NOTE: It is always more secure to specify a service explicitly, as shown in this example
configuration, than to use the keyword any.

Example: Three-Zone, Call Manager/TFTP Server in the DMZ

In this example, phone1 is on the ethernet1 interface in the Trust zone, phone2 is
on the ethernet3 interface in the Untrust zone, and the Call Manager/TFTP Server is
on the ethernet2 interface in the DMZ. For signaling, you create a policy from the
Trust zone to the DMZ to allow phone1 to communicate with the Call Manager/TFTP
Server, and you create a policy from the Untrust zone to the DMZ to allow phone2 to
communicate with the Call Manager/TFTP Server. For transmission of media, you
create a policy from Trust to Untrust to allow phone1 and phone2 to communicate
directly. The arrows in Figure 27 show the flow of SCCP signaling traffic when
phone2 in the Untrust zone places a call to phone1 in the Trust zone. After the
session is initiated, the media flows directly between phone1 and phone2.

92  Examples
 Chapter 4: Skinny Client Control Protocol Application Layer Gateway

Figure 27: Call Manager/TFTP Server in the DMZ

Untrust

phone2
1.1.1.4 Internet

CM/TFTP Server
ethernet3 2.2.2.4
1.1.1.1/24
ethernet2
2.2.2.2/24
DMZ
Security Device

LAN
ethernet1
10.1.1.1/24

LAN
phone1
10.1.1.3

Trust

WebUI
1. Interfaces
Network > Interfaces > Edit (for ethernet1): Enter the following, then click
Apply:

Zone: Trust
Static IP: (select when this option is present)
IP Address/Netmask: 10.1.1.1/24
Enter the following, then click OK:
Interface Mode: NAT

Network > Interfaces > Edit (for ethernet2): Enter the following, then click
OK:

Zone Name: DMZ

Static IP: (select when this option is present)
IP Address/Netmask: 2.2.2.2/24

Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:

Zone Name: Untrust

Static IP: (select when this option is present)
IP Address/Netmask: 1.1.1.1/24

Examples  93
 Concepts & Examples ScreenOS Reference Guide

2. Address
Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: phone1

IP Address/Domain Name:
IP/Netmask: (select), 10.1.1.3/24
Zone: Trust

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: phone2

IP Address/Domain Name:
IP/Netmask: (select), 1.1.1.4/24
Zone: Untrust

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: CM-TFTP_Server

IP Address/Domain Name:
IP/Netmask: (select), 2.2.2.4/24
Zone: DMZ
3. Policies
Policies > (From: Trust, To: DMZ) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), phone1
Destination Address:
Address Book Entry: (select), CM-TFTP_Server
Service: SCCP
Action: Permit

> Advanced: Enter the following, then click Return to set the advanced
options and return to the basic configuration page:

NAT:
Source Translation: Enable
(DIP on): None (Use Egress Interface IP)

Policies > (From: Untrust, To: DMZ) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), phone2
Destination Address:
Address Book Entry: (select), CM-TFTP_Server
Service: SCCP
Action: Permit

Policies > (From: Trust, To: Untrust) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), phone1
Destination Address:
Address Book Entry: (select), phone2

94  Examples
 Chapter 4: Skinny Client Control Protocol Application Layer Gateway

Service: SCCP
Action: Permit

> Advanced: Enter the following, then click Return to set the advanced
options and return to the basic configuration page:

NAT:
Source Translation: Enable
(DIP on): None (Use Egress Interface IP)

CLI
1. Interfaces
set interface ethernet1 zone trust
set interface ethernet1 ip 10.1.1.1/24
set interface ethernet1 route
set interface ethernet3 zone untrust
set interface ethernet3 ip 1.1.1.1/24
set interface ethernet3 route
set interface ethernet2 zone dmz
set interface ethernet2 ip 2.2.2.2/24
set interface ethernet2 route
2. Addresses
set address trust phone1 10.1.1.3/24
set address untrust phone2 1.1.1.4/24
set address dmz cm-tftp_server 2.2.2.4
3. Policies
set policy from trust to dmz phone1 cm-tftp_server sccp nat src permit
set policy from untrust to dmz phone2 cm-tftp_server sccp permit
set policy from trust to untrust phone1 phone2 sccp nat src permit
save

NOTE: It is always more secure to specify a service explicitly, as shown in this example
configuration, than to use the keyword any.

Example: Intrazone, Call Manager/TFTP Server in Trust Zone

In this example, phone1 is on the ethernet4 interface in the Untrust zone, phone2 is
in a subnet on the ethernet3 interface in the Untrust zone, and the Call
Manager/TFTP Server is on the ethernet1 interface in the Trust zone. To allow
intrazone SCCP traffic between the two phones in the Untrust zone, you create a
loopback interface, add ethernet3 and ethernet4 to a loopback group, then put a
MIP on the loopback interface to the IP address of the Call Manager/TFTP Server.
Creating a loopback interface enables you to use a single MIP for the Call
Manager/TFTP Server in the Trust zone. (For more information about using
loopback interfaces, see “MIP and the Loopback Interface” on page 8-73.) And
finally, because intrazone blocking is on by default, you unset blocking in the
Untrust zone to allow intrazone communication.

Examples  95
 Concepts & Examples ScreenOS Reference Guide

Figure 28: Intrazone, Call Manager/TFTP Server in Trust Zone

Untrust

phone1 phone2
1.1.1.4 1.1.2.4
Internet

ehternet4 ehternet3
1.1.1.1/24 1.1.2.1/24

loopback 1
1.1.4.1/24

Security Device

MIP on loopback 1
1.1.4.5 -> 10.1.1.5

ehternet1
10.1.1.1/24

CM/TFTP Server
10.1.1.5 LAN

Trust

WebUI
1. Interfaces
Network > Interfaces > Edit (for ethernet1): Enter the following, then click
Apply:

Zone: Trust
Static IP: (select when this option is present)
IP Address/Netmask: 10.1.1.1/24

Enter the following, then click OK:

Interface Mode: NAT

Network > Interfaces > Edit (for ethernet4): Enter the following, then click
OK:

Zone: Untrust
Static IP: (select when this option is present)
IP Address/Netmask: 1.1.1.1/24

96  Examples
 Chapter 4: Skinny Client Control Protocol Application Layer Gateway

Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:

Zone: Untrust
Static IP: (select when this option is present)
IP Address/Netmask: 1.1.2.1/24

Network > Interfaces > New Loopback IF: Enter the following, then click OK:

Interface Name: loopback.1

Zone: Untrust (trust-vr)
IP Address/Netmask: 1.1.4.1/24
2. Addresses
Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: CM-TFTP_Server

IP Address/Domain Name:
IP/Netmask: (select), 10.1.1.5/32
Zone: Trust

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: phone1

IP Address/Domain Name:
IP/Netmask: (select), 1.1.1.4/32
Zone: Untrust

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: phone2

IP Address/Domain Name:
IP/Netmask: (select), 1.1.2.4/32
Zone: Untrust
3. Loopback Group
Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:

As member of loopback group: (select) loopback.1

Zone Name: Untrust

Network > Interfaces > Edit (for ethernet4): Enter the following, then click
OK:

As member of loopback group: (select) loopback.1

Zone Name: Untrust
4. MIP
Network > Interfaces > Edit (for loopback.1) > MIP > New: Enter the
following, then click OK:

Mapped IP: 1.1.4.5

Netmask: 255.255.255.255
Host IP Address: 10.1.1.5

Examples  97
 Concepts & Examples ScreenOS Reference Guide

Host Virtual Router Name: trust-vr

5. Blocking
Network > Zones > Edit (for Untrust): Enter the following, then click OK:

Block Intra-Zone Traffic: (clear)

6. Policies
Policies > (From: Trust, To: Untrust) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), CM-TFTP_Server
Destination Address:
Address Book Entry: (select), Any
Service: SCCP
Action: Permit

> Advanced: Enter the following, then click Return to set the advanced
options and return to the basic configuration page:

NAT:
Source Translation: Enable
(DIP on): None (Use Egress Interface IP)

Policies > (From: Untrust, To: Trust) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), Any
Destination Address:
Address Book Entry: (select), MIP(1.1.4.5)
Service: SCCP
Action: Permit

CLI
1. Interfaces
set interface ethernet1 zone trust
set interface ethernet1 ip 10.1.1.1/24
set interface ethernet1 route
set interface ethernet3 zone untrust
set interface ethernet3 ip 1.1.2.1/24
set interface ethernet3 route
set interface ethernet4 zone untrust
set interface ethernet4 ip 1.1.1.1/24
set interface ethernet4 route
set interface loopback.1 zone untrust
set interface loopback.1 ip 1.1.4.1/24
set interface loopback.1 route
2. Addresses
set address trust cm-tftp_server 10.1.1.5/32
set address untrust phone1 1.1.1.4/32
set address untrust phone2 1.1.2.4/32
3. Loopback Group
set interface ethernet3 loopback-group loopback.1
set interface ethernet4 loopback-group loopback.1

98  Examples
 Chapter 4: Skinny Client Control Protocol Application Layer Gateway

4. MIP
set interface loopback.1 mip 1.1.4.5 host 10.1.1.5
5. Blocking
unset zone untrust block
6. Policies
set policy from trust to untrust cm/tftp_server any sccp nat src permit
set policy from untrust to trust any mip(1.1.4.5) sccp permit
save

NOTE: Although, in this example, you unset blocking in the Untrust zone to allow
intrazone communication, you can accomplish the same thing by creating the
following policy:

set policy from untrust to untrust any any sccp permit

Note, also, that it is always more secure to specify a service explicitly, as shown in
this example configuration, than to use the keyword any.

Example: Intrazone, Call Manager/TFTP Server in Untrust Zone

In this example, phone1 is on the ethernet1 interface in the Trust zone, phone 2 is
on the ethernet2 interface in a subnet in the Trust zone, and the Call Manager/TFTP
Server is on the ethernet3 interface in the Untrust zone. After configuring interfaces
and addresses, you create a policy from Trust to Untrust to allow phone1 and
phone2 to register with the Call Manager/TFTP Server in the Untrust zone. Blocking
is off by default in the Trust zone (as it is in custom zones you define), so it is not
necessary to create. However, for greater security, you could optionally turn
blocking off, and create a policy from Trust to Trust. This would allow you to specify
the SCCP service, and restrict intrazone calls to phone1 and phone2.

Figure 29: Intrazone, Call Manager/TFTP Server in Trust Zone

phone1 ethernet3 CM/TFTP Server
10.1.1.3 ethernet1
3.3.3.3/24 3.3.3.4
10.1.1.1/24
Trust Untrust
Security Device
LAN Internet

ethernet2
phone2 10.1.2.1/24
10.1.2.2

WebUI
1. Interfaces
Network > Interfaces > Edit (for ethernet1): Enter the following, then click
Apply:

Zone: Trust
Static IP: (select when this option is present)
IP Address/Netmask: 10.1.1.1/24

Examples  99
 Concepts & Examples ScreenOS Reference Guide

Enter the following, then click OK:

Interface Mode: route

Network > Interfaces > Edit (for ethernet2): Enter the following, then click
Apply:

Zone: Trust
Static IP: (select when this option is present)
IP Address/Netmask: 10.1.2.1/24
Enter the following, then click OK:
Interface Mode: route

Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:

Zone: Untrust
Static IP: (select when this option is present)
IP Address/Netmask: 3.3.3.3/24
2. Addresses
Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: phone1

IP Address/Domain Name:
IP/Netmask: (select), 10.1.1.3/24
Zone: Trust

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: phone2

IP Address/Domain Name:
IP/Netmask: (select), 10.1.2.2/24
Zone: Trust

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: CM/TFTP Server

IP Address/Domain Name:
IP/Netmask: (select), 3.3.3.4/24
Zone: Untrust
3. Policies
Policies > (From: Trust, To: Untrust) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), Any
Destination Address:
Address Book Entry: (select), CM/TFTP Server
Service: SCCP
Action: Permit

> Advanced: Enter the following, then click Return to set the advanced
options and return to the basic configuration page:

100  Examples
 Chapter 4: Skinny Client Control Protocol Application Layer Gateway

NAT:
Source Translation: Enable
(DIP on): None (Use Egress Interface IP)

CLI
1. Interfaces
set interface ethernet1 zone trust
set interface ethernet1 ip 10.1.1.1/24
set interface ethernet2 zone trust
set interface ethernet2 ip 10.1.2.1/24
set interface ethernet3 zone untrust
set interface ethernet3 ip 3.3.3.3/24
set interface ethernet3 route
2. Addresses
set address trust phone1 10.1.1.3/24
set address trust phone2 10.1.2.2/24
set address untrust cm-tftp_server 3.3.3.4/24
3. Policies
set policy from trust to untrust any cm-tftp_server sccp nat src permit
save

NOTE: It is always more secure to specify a service explicitly, as shown in this example
configuration, than to use the keyword any.

Example: Full-Mesh VPN for SCCP

In this example, the central office and two branch offices are linked by a full-mesh
VPN. Each site has a single security device. The Call Manager/TFTP Server is in the
Trust zone at the Central Office, phone1 is in the Trust zone at Branch Office One,
and phone2 is in the Trust zone at Branch Office Two. All interfaces connecting the
devices are in their respective Untrust zones. On each device, you configure two
tunnels, one to each of the other devices, to create a fully meshed network.

NOTE: The security devices used in this example must have at least three independently
configurable interfaces available.

Examples  101
 Concepts & Examples ScreenOS Reference Guide

Figure 30: Full-Mesh VPN for SCCP

Note: The Untrust Zone for Central Office CM/TFTP Server

each device is not shown 10.1.3.3
Trust Zone

Trust
eth2/8-10.1.3.1

tunnel.1 tunnel 2
Central
6.6.6.6 7.7.7.7
Untrust eth2/1: Untrust
1.1.1.1 eth2/2-1.1.2.1

Gateway Router Gateway Router

To central: 1.1.1.1 To central: 1.1.2.1
To branch: 3.3.3.3 VPN 1 VPN 2 To branch: 2.2.2.2

Untrust
Untrust eth3
eth3-2.2.2.2.
3.3.3.3
tunnel.1 interface tunnel.2 interface
Branch-1 VPN 3 unnumbered
unnumbered Branch-2

Trust eth1 Untrust Untrust Trust eth1

10.1.1.1 eth4-4.4.4.4 eth4-5.5.5.5 10.1.2.1
Gateway Router
To branch-1: 4.4.4.4
Trust Zone To branch-2: 5.5.5.5 Trust Zone

Branch Office One Branch Office Two

tunnel.3 interface tunnel.3 interface
phone1 unnumbered unnumbered phone2
10.1.1.3 10.1.2.3

NOTE: It is always more secure to explicitly specify a service, as shown in this example
configuration, than to use the keyword any.

WebUI (for Central)

1. Interfaces
Network > Interfaces > Edit (for ethernet2/1): Enter the following, then click
Apply:

Zone: Untrust
Static IP: (select when this option is present)
IP Address/Netmask: 1.1.1.1/24

Network > Interfaces > Edit (for ethernet2/2): Enter the following, then click
Apply:

Zone: Untrust
Static IP: (select when this option is present)
IP Address/Netmask: 1.1.2.1/24

102  Examples
 Chapter 4: Skinny Client Control Protocol Application Layer Gateway

Network > Interfaces > Edit (for ethernet2/8): Enter the following, then click
Apply:

Zone: Trust
Static IP: (select when this option is present)
IP Address/Netmask: 10.1.3.1/24
Enter the following, then click OK:
Interface mode: route

Network > Interfaces > New Tunnel IF: Enter the following, then click Apply:

Tunnel Interface Name: 1

Zone (VR): Untrust
IP Address / Netmask: 6.6.6.6/24

Network > Interfaces > New Tunnel IF: Enter the following, then click Apply:

Tunnel Interface Name: 2

Zone (VR): Untrust
IP Address / Netmask: 7.7.7.7/24
2. Address
Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: CM/TFTP Server

IPv4/Netmask: 10.1.3.3/32
Zone: Trust
3. VPN
VPNs > AutoKey Advanced > Gateway > New: Enter the following, then click
OK:

Gateway Name: to-branch-1

Security Level: Standard
IPvc4/v6 Address/Hostname: 3.3.3.3
Preshare Key: netscreen
Outgoing Interface: ethernet2/1

VPNs > AutoKey IKE > New: Enter the following, then click OK:

VPN Name: vpn-branch-1

Advanced: Enter the following advanced settings, then click Return to

return to the basic Gateway configuration page:

Bind to: (select) Tunnel Interface, tunnel.1

VPNs > AutoKey Advanced > Gateway > New: Enter the following, then click
OK:

Gateway Name: to-branch-2

Security Level: Standard
IPvc4/v6 Address/Hostname: 2.2.2.2
Preshare Key: netscreen
Outgoing Interface: ethernet2/2

Examples  103
 Concepts & Examples ScreenOS Reference Guide

VPNs > AutoKey IKE > New: Enter the following, then click OK:

VPN Name: vpn-branch-2

Advanced: Enter the following advanced settings, then click Return to

return to the basic Gateway configuration page:

Bind to: (select) Tunnel Interface, tunnel.2

4. Routing
Network > Routing > Destination > New: Enter the following, then click OK:

Network Address / Netmask: 10.1.1.0/24

Interface (select): tunnel.1

Network > Routing > Destination> New: Enter the following, then click OK:

Network Address / Netmask: 10.1.2.0/24

Interface (select): tunnel.2
5. Policies
Policies > (From: Trust, To: Untrust) New Enter the following, then click OK:

Source Address (select) Address Book Entry: CM/TFTP Server

Destination Address (select) Address Book Entry: Any-IPv4
Service: SCCP
Action: Permit

Policies > (From: Untrust, To: Trust) > New: Enter the following, then click OK:

Source Address (select) Address Book Entry: Any-IPv4

Destination Address (select) Address Book Entry: CM/TFTP Server
Service: SCCP
Action: Permit

CLI (for Central)

1. Interfaces
set interface ethernet2/1 zone untrust
set interface ethernet2/1 ip 1.1.1.1/24
set interface ethernet2/2 zone untrust
set interface ethernet2/2 ip 1.1.2.1/24
set interface ethernet2/8 zone trust
set interface ethernet2/8 ip 10.1.3.1/24
set interface ethernet2/8 route
set interface tunnel.1 zone untrust
set interface tunnel.1 ip 6.6.6.6/24
set interface tunnel.2 zone untrust
set interface tunnel.2 ip 7.7.7.7/24
2. Address
set address trust cm-tftp_server 10.1.3.3/32

104  Examples
 Chapter 4: Skinny Client Control Protocol Application Layer Gateway

3. VPN
set ike gateway to-branch-1 address 3.3.3.3 main outgoing-interface ethernet2/1
preshare netscreen sec-level standard
set ike gateway to-branch-2 address 2.2.2.2 main outgoing-interface ethernet2/2
preshare netscreen sec-level standard
set vpn vpn_branch-1 gateway to-branch-1 no-reply tunnel idletime 0 sec-level
standard
set vpn vpn-branch-1 id 1 bind interface tunnel.1
set vpn vpn-branch-2 gateway to-branch-2 no-reply tunnel idletime 0 sec-level
standard
set vpn vpn-branch-2 id 2 bind interface tunnel.2
4. Routing
set route 10.1.2.0/24 interface tunnel.2
set route 10.1.1.0/24 interface tunnel.1
5. Policies
set policy from trust to untrust cm-tftp_server any sccp permit
set policy from untrust to trust any cm-tftp_server sccp permit
save

WebUI (for Branch Office 1)

1. Interfaces
Network > Interfaces > Edit (for ethernet1): Enter the following, then click
Apply:

Zone: Trust
Static IP: (select when this option is present)
IP Address/Netmask: 10.1.1.1/24
Interface mode: route

Network > Interfaces > Edit (for ethernet3): Enter the following, then click
Apply:

Zone: Untrust
Static IP: (select when this option is present)
IP Address/Netmask: 3.3.3.3/24

Network > Interfaces > Edit (for ethernet4): Enter the following, then click
Apply:

Zone: Untrust
Static IP: (select when this option is present)
IP Address/Netmask: 4.4.4.4/24

Network > Interfaces > New Tunnel IF: Enter the following, then click Apply:

Tunnel Interface Name: 2

Zone (VR): Untrust
Unnumbered (select) Interface: ethernet3

Network > Interfaces > New Tunnel IF: Enter the following, then click Apply:

Tunnel Interface Name: 3

Zone (VR): Untrust
Unnumbered (select) Interface: ethernet4

Examples  105
 Concepts & Examples ScreenOS Reference Guide

2. Address
Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: phone1

IPv4/Netmask: 10.1.1.3/32
Zone: V1-Trust
3. VPN
VPNs > AutoKey Advanced > Gateway > New: Enter the following, then click
OK:

Gateway Name: to-central

Security Level: Standard
IPvc4/v6 Address/Hostname: 1.1.2.1
Preshare Key: netscreen
Outgoing Interface: ethernet3

VPNs > AutoKey IKE > New: Enter the following, then click OK:

VPN Name: vpn-central

Advanced: Enter the following advanced settings, then click Return to

return to the basic Gateway configuration page:

Bind to (select): Tunnel Interface, tunnel.1

VPNs > AutoKey Advanced > Gateway > New: Enter the following, then click
OK:

Gateway Name: to-ns50

Security Level: Standard
IPvc4/v6 Address/Hostname: 5.5.5.5
Preshare Key: netscreen
Outgoing Interface: ethernet4

VPNs > AutoKey IKE > New: Enter the following, then click OK:

VPN Name: vpn-ns50

Advanced: Enter the following advanced settings, then click Return to

return to the basic Gateway configuration page:

Bind to (select): Tunnel Interface, tunnel.3

4. Routing
Network > Routing > Destination> New: Enter the following, then click OK:

Network Address / Netmask: 10.1.2.0/24

Interface (select): tunnel.3

Network > Routing > Destination > New: Enter the following, then click OK:

Network Address / Netmask: 10.1.3.0/24

Interface (select): tunnel.1

106  Examples
 Chapter 4: Skinny Client Control Protocol Application Layer Gateway

5. Policies
Policies > (From: Trust, To: Untrust) > New: Enter the following, then click OK:

Source Address (select) Address Book Entry: phone2

Destination Address (select) Address Book Entry: Any-IPv4
Service: SCCP
Action: Permit

Policies > (From: Untrust, To: Trust) > New: Enter the following, then click OK:

Source Address (select) Address Book Entry: Any-IPv4

Destination Address (select) Address Book Entry: phone2
Service: SCCP
Action: Permit

CLI (for Branch Office 1)

1. Interfaces
set interface ethernet1 zone trust
set interface ethernet1 ip 10.1.1.1/24
set interface ethernet1 route
set interface ethernet3 zone untrust
set interface ethernet3 ip 3.3.3.3/24
set interface ethernet4 zone untrust
set interface ethernet4 ip 4.4.4.4/24
set interface tunnel.2 zone untrust
set interface tunnel.2 ip unnumbered interface ethernet3
set interface tunnel.3 zone untrust
set interface tunnel.3 ip unnumbered interface ethernet4
2. Address
set address trust phone1 10.1.1.3/32
3. VPN
set ike gateway to-central address 1.1.1.1 main outgoing-interface ethernet3
preshare netscreen sec-level standard
set ike gateway to-ns50 address 5.5.5.5 main outgoing-interface ethernet4
preshare netscreen sec-level standard
set vpn vpncentral gateway to-central no-replay tunnel idletime 0 sec-level standard
set vpn vpncentral bind interface tunnel.1
set vpn vpn-ns50 gateway to-ns50 no-replay tunnel idletime 0 sec-level standard
set vpn vpn-ns50 bind interface tunnel.3
4. Routes
set route 10.1.2.0/24 interface tunnel.3
set route 10.1.3.0/24 interface tunnel.1
5. Policies
set policy from trust to untrust phone1 any sccp permit
set policy from untrust to trust any phone1 sccp permit
save

Examples  107
 Concepts & Examples ScreenOS Reference Guide

WebUI (for Branch Office 2)

1. Interfaces
Network > Interfaces > Edit (for ethernet1): Enter the following, then click
Apply:

Zone: Trust
Static IP: (select when this option is present)
IP Address/Netmask: 10.1.2.1/24
Enter the following, then click OK:
Interface mode: route

Network > Interfaces > Edit (for ethernet3): Enter the following, then click
Apply:

Zone: Untrust
Static IP: (select when this option is present)
IP Address/Netmask: 2.2.2.2/24

Network > Interfaces > Edit (for ethernet4): Enter the following, then click
Apply:

Zone: Untrust
Static IP: (select when this option is present)
IP Address/Netmask: 4.4.4.4/24

Network > Interfaces > New Tunnel IF: Enter the following, then click Apply:

Tunnel Interface Name: 2

Zone (VR): Untrust
Unnumbered (select) Interface: ethernet3

Network > Interfaces > New Tunnel IF: Enter the following, then click Apply:

Tunnel Interface Name: 3

Zone (VR): Untrust
Unnumbered (select) Interface: ethernet4
2. Address
Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: phone2

IPv4/Netmask: 10.1.2.3/32
Zone: Trust
3. VPN
VPNs > AutoKey Advanced > Gateway > New: Enter the following, then click
OK:

Gateway Name: to-central

Security Level: Standard
IPvc4/v6 Address/Hostname: 1.1.2.1
Preshare Key: netscreen
Outgoing Interface: ethernet3

108  Examples
 Chapter 4: Skinny Client Control Protocol Application Layer Gateway

VPNs > AutoKey IKE > New: Enter the following, then click OK:

VPN Name: vpn-central

Advanced: Enter the following advanced settings, then click Return to

return to the basic Gateway configuration page:

Bind to (select): Tunnel Interface, tunnel.2

VPNs > AutoKey Advanced > Gateway > New: Enter the following, then click
OK:

Gateway Name: to-ns50

Security Level: Standard
IPvc4/v6 Address/Hostname: 4.4.4.4
Preshare Key: netscreen
Outgoing Interface: ethernet4

VPNs > AutoKey IKE > New: Enter the following, then click OK:

VPN Name: vpn-ns50

Advanced: Enter the following advanced settings, then click Return to

return to the basic Gateway configuration page:

Bind to (select): Tunnel Interface, tunnel.3

4. Routing
Network > Routing > Destination > New: Enter the following, then click OK:

Network Address / Netmask: 10.1.3.0/24

Interface (select): tunnel.2

Network > Routing > Destination > New: Enter the following, then click OK:

Network Address / Netmask: 10.1.1.0/24

Interface (select): tunnel.3
5. Policies
Policies > (From: Trust, To: Untrust) New Enter the following, then click OK:

Source Address (select) Address Book Entry: phone2

Destination Address (select) Address Book Entry: Any-IPv4
Service: SCCP
Action: Permit

Policies > (From: Untrust, To: Trust) > New: Enter the following, then click OK:

Source Address (select) Address Book Entry: Any-IPv4

Destination Address (select) Address Book Entry: phone2
Service: SCCP
Action: Permit

Examples  109
 Concepts & Examples ScreenOS Reference Guide

CLI (for Branch Office 2)

1. Interfaces
set interface ethernet1 zone trust
set interface ethernet1 ip 10.1.2.1/24
set interface ethernet1 route
set interface ethernet3 zone untrust
set interface ethernet3 ip 2.2.2.2/24
set interface ethernet4 zone untrust
set interface ethernet4 ip 4.4.4.4/24
set interface tunnel.2 zone untrust
set interface tunnel.2 ip unnumbered interface ethernet3
set interface tunnel.3 zone untrust
set interface tunnel.3 ip unnumbered interface ethernet4
2. Address
set address trust phone1 10.1.2.3/32
3. VPN
set ike gateway to-central address 1.1.1.1 Main outgoing-interface ethernet3
preshare netscreen sec-level standard
set ike gateway to-ns50 address 4.4.4.4 Main outgoing-interface ethernet4
preshare netscreen sec-level standard
set vpn vpncentral gateway to-central no-replay tunnel idletime 0 sec-level standard
set vpn vpncentral id 4 bind interface tunnel.2
set vpn vpn-ns50 gateway to-ns50 no-replay tunnel idletime 0 sec-level standard
set vpn vpn-ns50 id 5 bind interface tunnel.3
4. Routes
set route 10.1.3.0/24 interface tunnel.1
set route 10.1.2.0/24 interface tunnel.3
5. Policies
set policy from trust to untrust phone2 any sccp permit
set policy from untrust to trust any phone2 sccp permit
save

110  Examples
Chapter 5
Apple iChat Application Layer Gateway

This chapter describes the Apple iChat application and provides examples for
configuring the AppleiChat Application Layer Gateway (ALG) on a Juniper Networks
security device. It contains the following sections:

 “Overview” on page 111

 “Configuring the AppleiChat ALG” on page 112

 “Configuration Examples” on page 113

Overview
Apple iChat is an Instant Messaging (IM) application that lets you chat with other
iChat, Mac, or AOL Instant Messenger (AIM) users over the Internet using text,
audio, or video. ScreenOS currently supports iChat applications up to version 3.15.

The iChat application uses standard ports to send data to its servers and clients. The
AppleiChat ALG provides support for iChat applications by opening pinholes on
Juniper Networks security device, thereby allowing the text, audio, and video calls
to pass through the security device. Without the AppleiChat ALG, the ports are
blocked and need to be opened manually, which exposes the network to attack on
these ports.

Table 9 shows the standard ports iChat uses for various services.

Table 9: Standard iChat Service Ports

Port
Number Service Name Protocol Used For
5190 AOL TCP iChat and AOL instant messenger, file
transfer
5678 SNATMAP server UDP Determining the external Internet
addresses of hosts.
5060 Session Initiation Protocol UDP/TCP Initiating audio/video (AV) chat invitations.
(SIP)
16384 Real-Time Transport UDP iChat audio RTP/RTCP video RTP/RTCP
16403 Protocol (RTP) /Real-Time
Control Protocol (RTCP)

Overview  111
Concepts & Examples ScreenOS Reference Guide

For a list of well-known ports, see

http://docs.info.apple.com/article.html?artnum=106439

The iChat service uses the AOL and SIP protocols for its audio/video operations. It
uses the AIM protocol to connect to servers. SIP is used for setting audio/video
sessions between IM clients after they successfully negotiate ports. The SIP ALG
creates pinholes for audio/video sessions. SIP is a predefined service in ScreenOS
and uses port 5060 as the destination port. During iChat operation, the security
device creates separate sessions for AOL and SIP.

NOTE: The ALG does not open all ports when you enable the AppleiChat ALG on the
security device. ALG opens pinholes only for the ports that are exchanged during
iChat signaling messages.

The number of iChat sessions that the security device can handle is limited to the
maximum number of Network Address Translation (NAT) cookies available for that
particular security device.

NOTE: The NAT cookies available for a security device are shared by other ALGs like
H.323 and P2P ALG.

You can view the maximum number of NAT cookies available for a particular device
using the following CLI command:

get nat cookie

For information about running iChat in NAT mode, see

http://docs.info.apple.com/article.html?artnum=93208

Configuring the AppleiChat ALG

You configure the AppleiChat ALG with the WebUI or the CLI.

WebUI
Security>ALG>Apple iChat. Select the following, then click Apply:

AppleiChat Enable (select)

CLI
set alg appleichat enable

When you enable the AppleiChat ALG functionality, the security device opens
pinholes for the configured call-answer-time to establish the iChat audio/video
session. The call-answer-time is the duration of time for which the security device
opens the pinholes for establishing iChat audio/video session. The default value of
call-answer-time is 32 seconds. When this timer expires, the device closes the
pinholes. The range for configuring the call-answer-time is 20 to 90 seconds.

112  Configuring the AppleiChat ALG

 Chapter 5: Apple iChat Application Layer Gateway

To configure a call-answer-time of 30 seconds:

WebUI
Security>ALG>AppleiChat. Enter the following, then click Apply:

Call-Answer-Time: 30

CLI
set alg appleichat call-answer-time 30

The iChat application fragments the packets it sends to the receiver based on the
maximum segment size (MSS) of the receiver. The MSS is the maximum amount of
data, in bytes, a device can receive as a single unfragmented frame. The MSS value
depends on the network configuration of the receiver. The fragmented packet is
reassembled at the ALG for address translation. By default, the reassembly option is
disabled. You can enable reassembly with the WebUI or the CLI.

WebUI
Security>ALG>AppleiChat. Select the following, then click Apply:

Re-Assembly Enable (select)

CLI
set alg appleichat reassembly enable

Configuration Examples
This section includes the following configuration scenarios:

 One iChat user on a private network, another iChat user on a public network,
and an iChat server on a public network

 An intra-zone call between two iChat users within a private network

 Users across different firewalls

Scenario 1: Private–Public Network

In Figure 31, one iChat user is on a private network, another iChat user is on a
public network, and the iChat server is on public network. There is a NAT between
the private and the public network.

Figure 31: AppleiChat Scenario 1—Users on Public and Private Networks

Trust zone Untrust zone

Ethernet Ethernet
NAT

iChat UserB iChat Server

iChat UserA Juniper Networks Security Device

Configuration Examples  113

Concepts & Examples ScreenOS Reference Guide

NOTE: Because the administrator does not know the IP address details initially, we
recommend that the user put "ANY" in the destination address field of the policy.

WebUI
1. Configuration for Logging into the Server in NAT Mode
Policies > (From: Trust, To: Untrust) New: Enter the following, then click OK:

Source Address
Address Book Entry: (select), iChat UserA
Destination Address
Address Book Entry: (select), ANY
Service: (select) AppleiChat
Action: Permit

> Advanced: Enter the following, then click Return to set the advanced
options and return to the basic configuration page:

NAT:
Source Translation: (select)
(DIP on): (select)
2. Configuration for File Transfer from iChat UserA to iChat UserB in NAT Mode
Policies > (From: Trust, To: Untrust) New: Enter the following, then click OK:

Source Address
Address Book Entry: (select), iChat UserA
Destination Address
Address Book Entry: (select), iChatserver_IP_range
Service: (select) AppleiChat
Action: Permit

> Advanced: Enter the following, then click Return to set the advanced
options and return to the basic configuration page:

NAT:
Source Translation: (select)
(DIP on): (select)

Policies > (From: Trust, To: Untrust) New: Enter the following, then click OK:

Source Address
Address Book Entry: (select), iChat UserB
Destination Address
Address Book Entry: (select), ANY
Service: (select) AppleiChat
Action: Permit

> Advanced: Enter the following, then click Return to set the advanced
options and return to the basic configuration page:

NAT:
Source Translation: (select)
(DIP on): (select)

114  Configuration Examples

 Chapter 5: Apple iChat Application Layer Gateway

3. Configuration for Making Audio/Video Calls from iChat UserB in NAT Mode
Policies > (From: Trust, To: Untrust) New: Enter the following, then click OK:

Source Address
Address Book Entry: (select), iChat UserA
Destination Address
Address Book Entry: (select), iChatserver_IP_range
Service: (select) AppleiChat
Action: Permit

> Advanced: Enter the following, then click Return to set the advanced
options and return to the basic configuration page:

NAT:
Source Translation: (select)
(DIP on): (select)

Policies > (From: Trust, To: Untrust) New: Enter the following, then click OK:

Source Address
Address Book Entry: (select), iChat UserA
Destination Address
Address Book Entry: (select), iChat UserB
Service: (select) AppleiChat
Action: Permit

> Advanced: Enter the following, then click Return to set the advanced
options and return to the basic configuration page:

NAT:
Source Translation: (select)
(DIP on): (select)
4. Configuration for Making Audio/Video Calls from iChat UserB in Route Mode
Policies > (From: Trust, To: Untrust) New: Enter the following, then click OK:

Source Address
Address Book Entry: (select), iChat UserA
Destination Address
Address Book Entry: (select), iChatserver_IP_range
Service: (select) AppleiChat
Action: Permit

Policies > (From: Trust, To: Untrust) New: Enter the following, then click OK:

Source Address
Address Book Entry: (select), iChat UserA
Destination Address
Address Book Entry: (select), iChat UserB
Service: (select) AppleiChat
Action: Permit
5. Configuration for Making Audio/Video Calls from iChat UserA in NAT Mode
Policies > (From: Trust, To: Untrust) New: Enter the following, then click OK:

Source Address
Address Book Entry: (select), iChat UserA
Destination Address

Configuration Examples  115

Concepts & Examples ScreenOS Reference Guide

Address Book Entry: (select), iChatserver_IP_range

Service: (select) AppleiChat
Action: Permit

> Advanced: Enter the following, then click Return to set the advanced
options and return to the basic configuration page:

NAT:
Source Translation: (select)
(DIP on): (select)

Policies > (From: Trust, To: Untrust) New: Enter the following, then click OK:

Source Address
Address Book Entry: (select), iChat UserA
Destination Address
Address Book Entry: (select), iChat UserB
Service: (select) AppleiChat
Action: Permit

> Advanced: Enter the following, then click Return to set the advanced
options and return to the basic configuration page:

NAT:
Source Translation: (select)
(DIP on): (select)
6. Configuration for Making Audio/Video Calls from iChat UserA in Route Mode
Policies > (From: Trust, To: Untrust) New: Enter the following, then click OK:

Source Address
Address Book Entry: (select), iChat UserA
Destination Address
Address Book Entry: (select), iChatserver_IP_range
Service: (select) AppleiChat
Action: Permit

Policies > (From: Trust, To: Untrust) New: Enter the following, then click OK:

Source Address
Address Book Entry: (select), iChat UserA
Destination Address
Address Book Entry: (select), iChat UserB
Service: (select) AppleiChat
Action: Permit

CLI
1. Configuration for Logging into the Server in NAT Mode
set policy from trust to untrust "ichatUserA" "ANY" apple-ichat nat src permit

OR

set policy from trust to untrust "ichatUserA" "iChatserver_IP_range" apple-ichat

nat src permit

NOTE: Policies for route/transparent mode are same except the "nat src" option in policy.

116  Configuration Examples

 Chapter 5: Apple iChat Application Layer Gateway

2. Configuration for File Transfer from iChat UserA to iChat UserB in NAT Mode
set policy from trust to untrust "ichatUserA" "ANY" apple-ichat nat src permit

OR

set policy from trust to untrust "ichatUserA" "iChatserver_IP_range" apple-ichat

nat src permit
set policy from trust to untrust "ichatUserB" "ANY" apple-ichat nat src permit

OR

set policy from trust to untrust "ichatUserB" "iChatserver_IP_range" apple-ichat

nat src permit
3. Configuration for Making Audio/Video Calls from iChat UserB in NAT Mode
set policy from trust to untrust "ichatUserA" "ANY" apple-ichat nat src permit

OR

set policy from trust to untrust "ichatUserA" "iChatserver_IP_range" apple-ichat

nat src permit
set policy from trust to untrust "iChatUserA" "iChatUserB" apple-ichat nat src
permit
4. Configuration for Making Audio/Video Calls from iChat UserB in Route Mode
set policy from trust to untrust "ichatUserA" "ANY" apple-ichat permit

OR

set policy from trust to untrust "ichatUserA" "iChatserver_IP_range" apple-ichat

permit
set policy from trust to untrust "iChatUserA" "iChatuserB" apple-ichat permit
5. Configuration for Making Audio/Video Calls from iChat UserA in NAT Mode
set policy from trust to untrust "ichatUserA" "ANY" apple-ichat nat src permit

OR

set policy from trust to untrust "ichatUserA" "iChatserver_IP_range" apple-ichat

nat src permit
set policy from trust to untrust "ichatuserA" "iChatUserB" apple-ichat nat src
permit
6. Configuration for Making Audio/Video Calls from iChat UserA in Route Mode
set policy from trust to untrust "ichatUserA" "ANY" permit

OR

set policy from trust to untrust "ichatUserA" "iChatserver_IP_range" apple-ichat

permit
set policy from trust to untrust "ichatuserA" "iChatUserB" apple-ichat permit

Scenario 2: Intrazone Call Within Private Network

In the example shown in Figure 32, iChat userA and iChat userB are in the same
network and behind a firewall. The iChat server is in public network. There is a NAT
between the private and the public networks.

Configuration Examples  117

Concepts & Examples ScreenOS Reference Guide

Figure 32: AppleiChat Scenario 2—Intrazone Call Within a Private Network

Trust zone Untrust zone

Ethernet NAT Ethernet

iChat UserA
iChat Server
Juniper Networks Security Device

iChat UserB

WebUI
1. Configuring iChat userA to Log In iChat server in NAT Mode
Policies > (From: Trust, To: Untrust) New: Enter the following, then click OK:

Source Address
Address Book Entry: (select), iChat UserA
Destination Address
Address Book Entry: (select), any
Service: AppleiChat
Action: Permit

> Advanced: Enter the following, then click Return to set the advanced
options and return to the basic configuration page:

NAT:
Source Translation: (select)
(DIP on): (select)
2. Configuration for File Transfer from iChat UserA to iChat UserB
Policies > (From: Trust, To: Untrust) New: Enter the following, then click OK:

Source Address
Address Book Entry: (select), iChat UserA
Destination Address
Address Book Entry: (select), iChatserver_IP_range
Service: (select) AppleiChat
Action: Permit

> Advanced: Enter the following, then click Return to set the advanced
options and return to the basic configuration page:

NAT:
Source Translation: (select)
(DIP on): (select)

Policies > (From: Trust, To: Untrust) New: Enter the following, then click OK:

Source Address
Address Book Entry: (select), iChat UserB
Destination Address
Address Book Entry: (select), ANY
Service: (select) AppleiChat
Action: Permit

118  Configuration Examples

 Chapter 5: Apple iChat Application Layer Gateway

> Advanced: Enter the following, then click Return to set the advanced
options and return to the basic configuration page:

NAT:
Source Translation: (select)
(DIP on): (select)
3. Configuration for Making Audio/Video Calls from iChat UserA in NAT Mode
Policies > (From: Trust, To: Untrust) New: Enter the following, then click OK:

Source Address
Address Book Entry: (select), iChat UserA
Destination Address
Address Book Entry: (select), ANY
Service: (select) AppleiChat
Action: Permit

> Advanced: Enter the following, then click Return to set the advanced
options and return to the basic configuration page:

NAT:
Source Translation: (select)
(DIP on): (select)
4. Configuration for Making Audio/Video Calls from iChat UserA in Route Mode
Policies > (From: Trust, To: Untrust) New: Enter the following, then click OK:

Source Address
Address Book Entry: (select), iChat UserA
Destination Address
Address Book Entry: (select), ichatServer
Service: (select) AppleiChat
Action: Permit
5. Configuration for Making Audio/Video Calls from iChat UserB in NAT Mode
Policies > (From: Trust, To: Untrust) New: Enter the following, then click OK:

Source Address
Address Book Entry: (select), iChat UserB
Destination Address
Address Book Entry: (select), iChatServer
Service: (select) AppleiChat
Action: Permit

> Advanced: Enter the following, then click Return to set the advanced
options and return to the basic configuration page:

NAT:
Source Translation: (select)
(DIP on): (select)
6. Configuration for Making Audio/Video Calls from iChat UserB in Route Mode
Policies > (From: Trust, To: Untrust) New: Enter the following, then click OK:

Source Address
Address Book Entry: (select), iChat UserB
Destination Address
Address Book Entry: (select), iChatServer

Configuration Examples  119

Concepts & Examples ScreenOS Reference Guide

Service: (select) AppleiChat

Action: Permit

CLI
1. Configuring iChat UserA to Log Into iChat Server in NAT Mode
set policy from trust to untrust "ichatUserA" "ANY" apple-ichat nat src permit

OR

set policy from trust to untrust "ichatUserA" "iChatServer_IP_range" apple-ichat

nat src permit
2. Configuration for File Transfer Between UserA and UserB
set policy from trust to untrust "ichatUserA" "ANY" apple-ichat nat src permit

OR

set policy from trust to untrust "ichatUserA" "iChatServer_IP_range" apple-ichat

nat src permit
set policy from trust to untrust "ichatUserB" "ANY" apple-ichat nat src permit

OR

set policy from trust to untrust "ichatUserB" "iChatServer_IP_range" apple-ichat

nat src permit
3. Configuration for Making Audio/Video Calls from iChat UserA in NAT Mode
set policy from trust to untrust "ichatUserA" "ANY" apple-ichat nat src permit

OR

set policy from trust to untrust "ichatUserA" "iChatserver_IP_range" apple-ichat

nat src permit
4. Configuration for Making Audio/Video Calls from iChat UserA in Route Mode
set policy from trust to untrust "ichatUserA" "iChatserver_IP_range" apple-ichat
permit
5. Configuration for Making Audio/Video Calls from iChat UserB in NAT Mode
set policy from trust to untrust "ichatUserB" "iChatserver_IP_range" apple-ichat
nat src permit
6. Configuration for Making Audio/Video Calls from iChat UserB in Route Mode
set policy from trust to untrust "ichatUserB" "iChatserver_IP_range" apple-ichat
permit

Scenario 3: Users Across Different Networks

In Figure 33, iChat userA is on a private network and iChat userB and userC are on
another private network. The iChat server is on a public network. There is NAT
between private networks and the public network.

120  Configuration Examples

 Chapter 5: Apple iChat Application Layer Gateway

Figure 33: AppleiChat Scenario 3—Users Across Different Networks

Ethernet
NAT

iChat User A Device A

Untrust zone
Ethernet
Trust zones

Ethernet
iChat Server
iChat User B NAT

Device B

iChat User C

WebUI
1. Configuration on Firewall 1 for Login from iChat UserA in NAT Mode
Policies > (From: Trust, To: Untrust) New: Enter the following, then click OK:

Source Address
Address Book Entry: (select), iChat UserA
Destination Address
Address Book Entry: (select), any
Service: (select) AppleiChat
Action: Permit

> Advanced: Enter the following, then click Return to set the advanced
options and return to the basic configuration page:

NAT:
Source Translation: (select)
(DIP on): (select)
2. Configuration on Firewall 1 for File Transfer from iChat UserA to iChat UserB in NAT
Mode
Policies > (From: Trust, To: Untrust) New: Enter the following, then click OK:

Source Address
Address Book Entry: (select), iChat UserA
Destination Address
Address Book Entry: (select), iChatserver_IP_range
Service: (select) AppleiChat
Action: Permit

> Advanced: Enter the following, then click Return to set the advanced
options and return to the basic configuration page:

NAT:
Source Translation: (select)
(DIP on): (select)

Configuration Examples  121

Concepts & Examples ScreenOS Reference Guide

3. Configuration on Firewall 1 for Making Audio/Video Calls from iChat UserA in NAT
Mode
Policies > (From: Trust, To: Untrust) New: Enter the following, then click OK:

Source Address
Address Book Entry: (select), iChat UserA
Destination Address
Address Book Entry: (select), iChatserver_IP_range
Service: (select) AppleiChat
Action: Permit

> Advanced: Enter the following, then click Return to set the advanced
options and return to the basic configuration page:

NAT:
Source Translation: (select)
(DIP on): (select)

Policies > (From: Trust, To: Untrust) New: Enter the following, then click OK:

Source Address
Address Book Entry: (select), iChat UserA
Destination Address
Address Book Entry: (select), iChat UserB
Service: (select) AppleiChat
Action: Permit

> Advanced: Enter the following, then click Return to set the advanced
options and return to the basic configuration page:

NAT:
Source Translation: (select)
(DIP on): (select)
4. Configuration on Firewall 1 for Making Audio/Video Calls from iChat UserA in Route
Mode
Policies > (From: Trust, To: Untrust) New: Enter the following, then click OK:

Source Address
Address Book Entry: (select), iChat UserA
Destination Address
Address Book Entry: (select), iChatserver_IP_range
Service:(select) AppleiChat
Action: Permit
5. Configuration on Firewall 2 for Making Audio/Video Calls from iChat UserB in NAT
Mode
Policies > (From: Trust, To: Untrust) New: Enter the following, then click OK:

Source Address
Address Book Entry: (select), iChat UserB
Destination Address
Address Book Entry: (select), iChat server
Service: (select) AppleiChat
Action: Permit

> Advanced: Enter the following, then click Return to set the advanced
options and return to the basic configuration page:

122  Configuration Examples

 Chapter 5: Apple iChat Application Layer Gateway

NAT:
Source Translation: (select)
(DIP on): (select)

Policies > (From: Trust, To: Untrust) New: Enter the following, then click OK:

Source Address
Address Book Entry: (select), iChat UserB
Destination Address
Address Book Entry: (select), ichatUserA_public
Service: (select) AppleiChat
Action: Permit

> Advanced: Enter the following, then click Return to set the advanced
options and return to the basic configuration page:

NAT:
Source Translation: (select)
(DIP on): (select)
6. Configuration on Firewall 2 for Making Audio/Video Calls from iChat UserB in Route
Mode
Policies > (From: Trust, To: Untrust) New: Enter the following, then click OK:

Source Address
Address Book Entry: (select), iChat UserB
Destination Address
Address Book Entry: (select), iChatserver_IP_range
Service:(select) AppleiChat
Action: Permit

Policies > (From: Trust, To: Untrust) New: Enter the following, then click OK:

Source Address
Address Book Entry: (select), iChat UserB
Destination Address
Address Book Entry: (select), iChatserver_IP_range
Service:(select) AppleiChat
Action: Permit

CLI
1. Configuration on Firewall 1 for Login from iChat UserA in NAT Mode
set policy from trust to untrust "ichatUserA" "ANY" apple-ichat nat src permit

OR

set policy from trust to untrust "ichatUserA" "iChatServer_IP_range" apple-ichat

nat src permit
2. Configuration on Firewall 1 for File Transfer from iChat UserA to iChat UserB in NAT
Mode
set policy from trust to untrust "ichatUserA" "ANY" apple-ichat nat src permit

OR

set policy from trust to untrust "ichatUserA" "iChatServer_IP_range" apple-ichat

nat src permit

Configuration Examples  123

Concepts & Examples ScreenOS Reference Guide

3. Configuration on Firewall 1 for Making Audio/Video calls from iChat UserA in NAT
mode
set policy from trust to untrust "ichatUserA" "ANY" apple-ichat nat src permit

OR

set policy from trust to untrust "ichatUserA" "iChatserver_IP_range" apple-ichat

nat src permit
set policy from trust to untrust "iChatuserA" "iChatuserB_public" apple-ichat nat
src permit
4. Configuration on Firewall 1 for Making Audio/Video calls from iChat UserA in Route
Mode
set policy from trust to untrust "ichatUserA" "ANY" apple-ichat permit

OR

set policy from trust to untrust "ichatUserA" "iChatserver_IP_range" apple-ichat

permit
set policy from trust to untrust "iChatUserA" "iChatuserB_public" apple-ichat
permit
5. Configuration on Firewall 2 for Making Audio/Video Calls from iChat UserB in NAT
Mode
set policy from trust to untrust "ichatUserB" "ANY" apple-ichat nat src permit

OR

set policy from trust to untrust "ichatUserB" "iChatserver_IP_range" apple-ichat

nat src permit
set policy from trust to untrust "iChatUserB" "ichatUserA_public" apple-ichat nat
src permit
6. Configuration on Firewall 2 for Making Audio/Video Calls from iChat UserB in Route
Mode
set policy from trust to untrust "ichatUserB" "ANY" apple-ichat permit

OR

set policy from trust to untrust "ichatUserB" "iChatserver_IP_range" apple-ichat

permit
set policy from trust to untrust ""iChatUserB" ichatUserA_public" apple-ichat
permit

124  Configuration Examples

Index
A response codes ........................................................18
ALGs ................................................................................19 RTCP .........................................................................20
Apple iChat.............................................................111 RTP ............................................................................20
SIP .............................................................................15 SDP ..................................................................19 to 20
SIP NAT ....................................................................25 signaling ...................................................................19
alternate gatekeepers ......................................................2 SIP NAT
Apple iChat ALG ...........................................................111 call setup ............................................................25, 30
call-answer-time ....................................................112 defined ......................................................................25
reassembly .............................................................113 DIP pool, using a .....................................................37
DIP, using incoming ................................................33
C DIP, using interface .................................................34
call-answer-time, Apple iChat ALG ............................112 incoming, with MIP ...........................................37, 39
proxy in DMZ ...........................................................46
G proxy in private zone ........................................41, 88
Gatekeeper Confirm (GCF) messages ............................2 proxy in public zone ...............................................44
Trust intrazone ........................................................53
I untrust intrazone ...............................................49, 95
iChat ALG ......................................................................111 VPN, using full-mesh .......................................55, 101
SIP timeouts
inactivity ...................................................................22
M
messages media inactivity .................................................23, 24
GCF .............................................................................2 session inactivity .....................................................22
RCF .............................................................................2 signaling inactivity ............................................23, 24
multimedia sessions, SIP ..............................................15
V
voice-over IP
P
pinholes ..........................................................................21 bandwidth management ........................................64

R
reassembly, Apple iChat ALG .....................................113
Registration Confirm (RCF) messages ...........................2

S
SDP .........................................................................19 to 20
service book, service groups (WebUI) .........................65
SIP
ALG .....................................................................19, 22
connection information ..........................................20
defined .....................................................................15
media announcements ...........................................20
messages ..................................................................16
multimedia sessions ...............................................15
pinholes ....................................................................19
request methods .....................................................16

Index  IX-I
 Concepts & Examples ScreenOS Reference Guide

IX-II  Index
Concepts & Examples
ScreenOS Reference Guide

Volume 7:
Routing

Release 6.1.0, Rev. 02

Juniper Networks, Inc.

1194 North Mathilda Avenue
Sunnyvale, CA 94089
USA
408-745-2000
www.juniper.net
 Copyright Notice
Copyright © 2008 Juniper Networks, Inc. All rights reserved.

Juniper Networks, the Juniper Networks logo, JUNOS, NetScreen, ScreenOS, and Steel-Belted Radius are registered trademarks of Juniper Networks, Inc.
in the United States and other countries. JUNOSe is a trademark of Juniper Networks, Inc. All other trademarks, service marks, registered trademarks, or
registered service marks are the property of their respective owners.

All specifications are subject to change without notice. Juniper Networks assumes no responsibility for any inaccuracies in this document or for any
obligation to update information in this document. Juniper Networks reserves the right to change, modify, transfer, or otherwise revise this publication
without notice.

FCC Statement
The following information is for FCC compliance of Class A devices: This equipment has been tested and found to comply with the limits for a Class A
digital device, pursuant to part 15 of the FCC rules. These limits are designed to provide reasonable protection against harmful interference when the
equipment is operated in a commercial environment. The equipment generates, uses, and can radiate radio-frequency energy and, if not installed and
used in accordance with the instruction manual, may cause harmful interference to radio communications. Operation of this equipment in a residential
area is likely to cause harmful interference, in which case users will be required to correct the interference at their own expense.

The following information is for FCC compliance of Class B devices: The equipment described in this manual generates and may radiate radio-frequency
energy. If it is not installed in accordance with Juniper Networks’ installation instructions, it may cause interference with radio and television reception.
This equipment has been tested and found to comply with the limits for a Class B digital device in accordance with the specifications in part 15 of the FCC
rules. These specifications are designed to provide reasonable protection against such interference in a residential installation. However, there is no
guarantee that interference will not occur in a particular installation.

If this equipment does cause harmful interference to radio or television reception, which can be determined by turning the equipment off and on, the user
is encouraged to try to correct the interference by one or more of the following measures:

 Reorient or relocate the receiving antenna.

 Increase the separation between the equipment and receiver.

 Consult the dealer or an experienced radio/TV technician for help.

 Connect the equipment to an outlet on a circuit different from that to which the receiver is connected.

Caution: Changes or modifications to this product could void the user's warranty and authority to operate this device.

Disclaimer
THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED
WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED
WARRANTY, CONTACT YOUR JUNIPER NETWORKS REPRESENTATIVE FOR A COPY.

ii 
Table of Contents
About This Volume ix
Document Conventions.................................................................................... x
Web User Interface Conventions .............................................................. x
Command Line Interface Conventions ...................................................... x
Naming Conventions and Character Types .............................................. xi
Illustration Conventions .......................................................................... xii
Requesting Technical Support ........................................................................ xii
Self-Help Online Tools and Resources..................................................... xiii
Opening a Case with JTAC ...................................................................... xiii
Document Feedback ..................................................................................... xiii

Chapter 1 Static Routing 1

Overview ......................................................................................................... 2
How Static Routing Works ......................................................................... 2
When to Configure Static Routes ............................................................... 3
Configuring Static Routes........................................................................... 5
Setting Static Routes ........................................................................... 5
Setting a Static Route for a Tunnel Interface ....................................... 8
Enabling Gateway Tracking ....................................................................... 9
Forwarding Traffic to the Null Interface ......................................................... 10
Preventing Route Lookup in Other Routing Tables .................................. 10
Preventing Tunnel Traffic from Being Sent on Non-Tunnel Interfaces...... 10
Preventing Loops Created by Summarized Routes................................... 10
Permanently Active Routes ............................................................................ 11
Changing Routing Preference with Equal Cost Multipath................................ 11

Chapter 2 Routing 13
Overview ....................................................................................................... 14
Virtual Router Routing Tables......................................................................... 15
Destination-Based Routing Table ............................................................. 16
Source-Based Routing Table .................................................................... 17
Source Interface-Based Routing Table...................................................... 19
Creating and Modifying Virtual Routers.......................................................... 21
Modifying Virtual Routers ........................................................................ 21
Assigning a Virtual Router ID ................................................................... 22
Forwarding Traffic Between Virtual Routers ............................................ 23
Configuring Two Virtual Routers .............................................................. 23
Creating and Deleting Virtual Routers...................................................... 25
Creating a Custom Virtual Router ...................................................... 26
Deleting a Custom Virtual Router ...................................................... 26
Virtual Routers and Virtual Systems......................................................... 26
Creating a Virtual Router in a Vsys ....................................................27
Sharing Routes Between Virtual Routers ........................................... 28

Table of Contents  iii

 Concepts & Examples ScreenOS Reference Guide

Limiting the Number of Routing Table Entries ......................................... 29

Routing Features and Examples ..................................................................... 30
Route Selection........................................................................................ 30
Setting a Route Preference ................................................................ 30
Route Metrics .................................................................................... 31
Changing the Default Route Lookup Sequence .................................. 32
Route Lookup in Multiple Virtual Routers .......................................... 34
Configuring Equal Cost Multipath Routing ............................................... 35
Route Redistribution................................................................................ 37
Configuring a Route Map................................................................... 38
Route Filtering .................................................................................. 39
Configuring an Access List ................................................................ 40
Redistributing Routes into OSPF ....................................................... 40
Exporting and Importing Routes Between Virtual Routers .......................42
Configuring an Export Rule ............................................................... 42
Configuring Automatic Export........................................................... 43

Chapter 3 Open Shortest Path First 45

Overview ....................................................................................................... 46
Areas ....................................................................................................... 46
Router Classification ................................................................................ 47
Hello Protocol .......................................................................................... 47
Network Types ........................................................................................ 48
Broadcast Networks .......................................................................... 48
Point-to-Point Networks .................................................................... 48
Point-to-Multipoint Networks ............................................................ 48
Link-State Advertisements ....................................................................... 49
Basic OSPF Configuration .............................................................................. 49
Creating and Removing an OSPF Routing Instance ................................. 50
Creating an OSPF Instance................................................................ 50
Removing an OSPF Instance ............................................................. 51
Creating and Deleting an OSPF Area ....................................................... 51
Creating an OSPF Area...................................................................... 52
Deleting an OSPF Area...................................................................... 52
Assigning Interfaces to an OSPF Area ...................................................... 53
Assigning Interfaces to Areas ............................................................ 53
Configuring an Area Range ............................................................... 53
Enabling OSPF on Interfaces ................................................................... 54
Enabling OSPF on Interfaces............................................................. 54
Disabling OSPF on an Interface......................................................... 54
Verifying the Configuration...................................................................... 55
Redistributing Routes into Routing Protocols ................................................. 56
Summarizing Redistributed Routes ................................................................ 57
Summarizing Redistributed Routes.......................................................... 57
Global OSPF Parameters ................................................................................ 58
Advertising the Default Route .................................................................. 59
Virtual Links ............................................................................................ 59
Creating a Virtual Link....................................................................... 60
Creating an Automatic Virtual Link....................................................61
Setting OSPF Interface Parameters ................................................................ 62
Security Configuration.................................................................................... 64
Authenticating Neighbors ........................................................................ 64
Configuring a Clear-Text Password....................................................64
Configuring an MD5 Password .......................................................... 64

iv  Table of Contents
 Table of Contents

Configuring an OSPF Neighbor List.......................................................... 65

Rejecting Default Routes.......................................................................... 66
Protecting Against Flooding ..................................................................... 66
Configuring the Hello Threshold........................................................ 66
Configuring the LSA Threshold .......................................................... 67
Enabling Reduced Flooding............................................................... 67
Creating an OSPF Demand Circuit on a Tunnel Interface ............................... 67
Point-to-Multipoint Tunnel Interface............................................................... 68
Setting the OSPF Link-Type ..................................................................... 68
Disabling the Route-Deny Restriction ...................................................... 69
Creating a Point-to-Multipoint Network....................................................69

Chapter 4 Routing Information Protocol 73

Overview ....................................................................................................... 74
Basic RIP Configuration.................................................................................. 75
Creating and Deleting a RIP Instance....................................................... 75
Creating a RIP Instance ..................................................................... 76
Deleting a RIP Instance ..................................................................... 76
Enabling and Disabling RIP on Interfaces ................................................ 76
Enabling RIP on an Interface............................................................. 77
Disabling RIP on an Interface............................................................ 77
Redistributing Routes .............................................................................. 77
Viewing RIP Information................................................................................ 78
Viewing the RIP Database........................................................................ 78
Viewing RIP Details ................................................................................. 79
Viewing RIP Neighbor Information .......................................................... 80
Viewing RIP Details for a Specific Interface ............................................. 81
Global RIP Parameters ................................................................................... 82
Advertising the Default Route ........................................................................ 83
Configuring RIP Interface Parameters ............................................................ 84
Security Configuration.................................................................................... 85
Authenticating Neighbors by Setting a Password ..................................... 85
Configuring Trusted Neighbors ................................................................ 86
Rejecting Default Routes.......................................................................... 87
Protecting Against Flooding ..................................................................... 87
Configuring an Update Threshold...................................................... 88
Enabling RIP on Tunnel Interfaces ....................................................88
Optional RIP Configurations........................................................................... 89
Setting the RIP Version ............................................................................ 89
Enabling and Disabling a Prefix Summary............................................... 91
Enabling a Prefix Summary............................................................... 91
Disabling a Prefix Summary.............................................................. 92
Setting Alternate Routes .......................................................................... 92
Demand Circuits on Tunnel Interfaces..................................................... 93
Configuring a Static Neighbor .................................................................. 95
Configuring a Point-to-Multipoint Tunnel Interface......................................... 95

Chapter 5 Border Gateway Protocol 101

Overview .....................................................................................................102
Types of BGP Messages .........................................................................102
Path Attributes.......................................................................................103
External and Internal BGP .....................................................................103
Basic BGP Configuration...............................................................................104

Table of Contents  v
 Concepts & Examples ScreenOS Reference Guide

Creating and Enabling a BGP Instance ...................................................105

Creating a BGP Routing Instance.....................................................105
Removing a BGP Instance ...............................................................106
Enabling and Disabling BGP on Interfaces .............................................106
Enabling BGP on Interfaces .............................................................106
Disabling BGP on Interfaces ............................................................106
Configuring BGP Peers and Peer Groups................................................107
Configuring a BGP Peer ...................................................................108
Configuring an IBGP Peer Group .....................................................108
Verifying the BGP Configuration ............................................................110
Security Configuration..................................................................................111
Authenticating BGP Neighbors ...............................................................111
Rejecting Default Routes........................................................................112
Optional BGP Configurations........................................................................113
Redistributing Routes into BGP ..............................................................114
Configuring an AS-Path Access List........................................................114
Adding Routes to BGP............................................................................115
Conditional Route Advertisement....................................................116
Setting the Route Weight.................................................................116
Setting Route Attributes ..................................................................117
Route-Refresh Capability .......................................................................117
Requesting an Inbound Routing Table Update ................................118
Requesting an Outbound Routing Table Update ..............................118
Configuring Route Reflection .................................................................118
Configuring a Confederation..................................................................120
BGP Communities .................................................................................122
Route Aggregation .................................................................................123
Aggregating Routes with Different AS-Paths ....................................123
Suppressing More-Specific Routes in Updates .................................124
Selecting Routes for Path Attribute..................................................125
Changing Attributes of an Aggregated Route ...................................126

Chapter 6 Policy-Based Routing 127

Policy Based Routing Overview....................................................................128
Extended Access-Lists............................................................................128
Match Groups ........................................................................................128
Action Groups........................................................................................129
Route Lookup with PBR ...............................................................................130
Configuring PBR...........................................................................................130
Configuring an Extended Access List .....................................................131
Configuring a Match Group ....................................................................132
Configuring an Action Group .................................................................133
Configuring a PBR Policy .......................................................................134
Binding a PBR Policy .............................................................................134
Binding a PBR Policy to an Interface ...............................................134
Binding a PBR Policy to a Zone .......................................................134
Binding a PBR Policy to a Virtual Router .........................................135
Viewing PBR Output.....................................................................................135
Viewing an Extended Access List...........................................................135
Viewing a Match Group..........................................................................136
Viewing an Action Group .......................................................................136
Viewing a PBR Policy Configuration.......................................................137
Viewing a Complete PBR Configuration .................................................137
Advanced PBR Example...............................................................................138

vi  Table of Contents
 Table of Contents

Routing..................................................................................................139
PBR Elements........................................................................................140
Extended Access Lists .....................................................................140
Match Groups..................................................................................141
Action Group...................................................................................141
PBR Policies ....................................................................................142
Interface Binding ...................................................................................142
Advanced PBR with High Availability and Scalability....................................142
Resilient PBR Solution ...........................................................................142
Scalable PBR Solution ............................................................................143

Chapter 7 Multicast Routing 145

Overview .....................................................................................................145
Multicast Addresses ...............................................................................146
Reverse Path Forwarding.......................................................................146
Multicast Routing on Security Devices..........................................................147
Multicast Routing Table .........................................................................147
Configuring a Static Multicast Route ......................................................148
Access Lists ...........................................................................................149
Configuring Generic Routing Encapsulation on Tunnel Interfaces ..........149
Multicast Policies..........................................................................................151

Chapter 8 Internet Group Management Protocol 153

Overview .....................................................................................................154
Hosts .....................................................................................................154
Multicast Routers ...................................................................................155
IGMP on Security Devices ............................................................................155
Enabling and Disabling IGMP on Interfaces ...........................................155
Enabling IGMP on an Interface........................................................155
Disabling IGMP on an Interface .......................................................156
Configuring an Access List for Accepted Groups ....................................156
Configuring IGMP ..................................................................................157
Verifying an IGMP Configuration ...........................................................159
IGMP Operational Parameters ...............................................................160
IGMP Proxy..................................................................................................161
Membership Reports Upstream to the Source........................................162
Configuring IGMP Proxy ........................................................................163
Configuring IGMP Proxy on an Interface................................................164
Multicast Policies for IGMP and IGMP Proxy Configurations ..................165
Creating a Multicast Group Policy for IGMP .....................................165
Creating an IGMP Proxy Configuration............................................166
Setting Up an IGMP Sender Proxy .........................................................172

Chapter 9 Protocol Independent Multicast 179

Overview .....................................................................................................180
PIM-SM ..................................................................................................182
Multicast Distribution Trees.............................................................182
Designated Router...........................................................................183
Mapping Rendezvous Points to Groups ...........................................183
Forwarding Traffic on the Distribution Tree ....................................184
PIM-SSM ................................................................................................186
Configuring PIM-SM on Security Devices......................................................186
Enabling and Deleting a PIM-SM Instance for a VR ................................187

Table of Contents  vii

 Concepts & Examples ScreenOS Reference Guide

Enabling PIM-SM Instance...............................................................187

Deleting a PIM-SM Instance.............................................................187
Enabling and Disabling PIM-SM on Interfaces........................................187
Enabling PIM-SM on an Interface ....................................................188
Disabling PIM-SM on an Interface ...................................................188
Multicast Group Policies.........................................................................188
Static-RP-BSR Messages ..................................................................188
Join-Prune Messages .......................................................................189
Defining a Multicast Group Policy for PIM-SM .................................189
Setting a Basic PIM-SM Configuration...........................................................190
Verifying the Configuration ..........................................................................194
Configuring Rendezvous Points....................................................................196
Configuring a Static Rendezvous Point ..................................................196
Configuring a Candidate Rendezvous Point ...........................................197
Security Considerations................................................................................198
Restricting Multicast Groups ..................................................................198
Restricting Multicast Sources .................................................................199
Restricting Rendezvous Points...............................................................200
PIM-SM Interface Parameters.......................................................................201
Defining a Neighbor Policy ....................................................................201
Defining a Bootstrap Border ..................................................................202
Configuring a Proxy Rendezvous Point ........................................................202
PIM-SM and IGMPv3 ....................................................................................212

Chapter 10 ICMP Router Discovery Protocol 213

Overview .....................................................................................................213
Configuring ICMP Router Discovery Protocol ...............................................214
Enabling ICMP Router Discovery Protocol .............................................214
Configuring ICMP Router Discovery Protocol from the WebUI...............214
Configuring ICMP Router Discovery Protocol from the CLI ....................215
Advertising an Interface ..................................................................215
Broadcasting the Address................................................................215
Setting a Maximum Advertisement Interval ....................................215
Setting a Minimum Advertisement Interval .....................................215
Setting an Advertisement Lifetime Value.........................................216
Setting a Response Delay ................................................................216
Setting an Initial Advertisement Interval .........................................216
Setting a Number of Initial Advertisement Packets..........................216
Disabling IRDP .............................................................................................217
Viewing IRDP Settings..................................................................................217

Index..........................................................................................................................IX-I

viii  Table of Contents

About This Volume

Volume 7: Routing contains the following chapters:

 Chapter 1, “Static Routing,” explains route tables and how to configure static
routes for destination-based routing, source interface-based routing, or
source-based routing.

 Chapter 2, “Routing,” explains how to configure virtual routers on security

devices and how to redistribute routing table entries between protocols or
between virtual routers.

 Chapter 3, “Open Shortest Path First,” describes how to configure the OSPF
dynamic routing protocol on security devices.

 Chapter 4, “Routing Information Protocol,” explains how to configure Routing

Information Protocol l (RIP).

 Chapter 5, “Border Gateway Protocol,” explains how to configure Border

Gateway Protocol (BGP).

 Chapter 6, “Policy-Based Routing,” describes policy based routing (PBR). PBR

provides a flexible routing mechanism for data forwarding over networks that
rely on Application Layer support such as for antivirus (AV), deep inspection
(DI), or Web filtering.

 Chapter 7, “Multicast Routing,” explains multicast routing basics, including how

to configure static multicast routes.

 Chapter 8, “Internet Group Management Protocol,” explains how to configure

Internet Group Management Protocol (IGMP).

 Chapter 9, “Protocol Independent Multicast,” explains how to configure

Protocol Independent Multicast - Sparse Mode (PIM-SM) and Protocol
Independent Multicast - Source Specific Multicast (PIM-SSM).

 Chapter 10, “ICMP Router Discovery Protocol,” explains how to set up an

Internet Control Message Protocol (ICMP) exchange between a host and a
router.

 ix
 Concepts & Examples ScreenOS Reference Guide

Document Conventions
This document uses the conventions described in the following sections:

 “Web User Interface Conventions” on page x

 “Command Line Interface Conventions” on page x

 “Naming Conventions and Character Types” on page xi

 “Illustration Conventions” on page xii

Web User Interface Conventions

The Web user interface (WebUI) contains a navigational path and configuration
settings. To enter configuration settings, begin by clicking a menu item in the
navigation tree on the left side of the screen. As you proceed, your navigation path
appears at the top of the screen, with each page separated by angle brackets.

The following example shows the WebUI path and parameters for defining an
address:

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: addr_1

IP Address/Domain Name:
IP/Netmask: (select), 10.2.2.5/32
Zone: Untrust

To open Online Help for configuration settings, click the question mark (?) in the
upper left of the screen.

The navigation tree also provides a Help > Config Guide configuration page to help
you configure security policies and Internet Protocol Security (IPSec). Select an
option from the list, and follow the instructions on the page. Click the ? character in
the upper left for Online Help on the Config Guide.

Command Line Interface Conventions

The following conventions are used to present the syntax of command line
interface (CLI) commands in text and examples.

In text, commands are in boldface type and variables are in italic type.

In examples:

 Variables are in italic type.

 Anything inside square brackets [ ] is optional.

 Anything inside braces { } is required.

x  Document Conventions
 About This Volume

 If there is more than one choice, each choice is separated by a pipe ( | ). For
example, the following command means “set the management options for the
ethernet1, the ethernet2, or the ethernet3 interface”:

set interface { ethernet1 | ethernet2 | ethernet3 } manage

NOTE: When entering a keyword, you only have to type enough letters to identify the
word uniquely. Typing set adm u whee j12fmt54 will enter the command set
admin user wheezer j12fmt54. However, all the commands documented in this
guide are presented in their entirety.

Naming Conventions and Character Types

ScreenOS employs the following conventions regarding the names of objects—such
as addresses, admin users, auth servers, IKE gateways, virtual systems, VPN
tunnels, and zones—defined in ScreenOS configurations:

 If a name string includes one or more spaces, the entire string must be
enclosed within double quotes; for example:

set address trust “local LAN” 10.1.1.0/24

 Any leading spaces or trailing text within a set of double quotes are trimmed;
for example, “ local LAN ” becomes “local LAN”.

 Multiple consecutive spaces are treated as a single space.

 Name strings are case-sensitive, although many CLI keywords are

case-insensitive. For example, “local LAN” is different from “local lan”.

ScreenOS supports the following character types:

 Single-byte character sets (SBCS) and multiple-byte character sets (MBCS).

Examples of SBCS are ASCII, European, and Hebrew. Examples of MBCS—also
referred to as double-byte character sets (DBCS)—are Chinese, Korean, and
Japanese.

 ASCII characters from 32 (0x20 in hexadecimals) to 255 (0xff), except double

quotes ( “ ), which have special significance as an indicator of the beginning or
end of a name string that includes spaces.

NOTE: A console connection only supports SBCS. The WebUI supports both SBCS and
MBCS, depending on the character sets that your browser supports.

Document Conventions  xi
 Concepts & Examples ScreenOS Reference Guide

Illustration Conventions
Figure 1 shows the basic set of images used in illustrations throughout this volume.

Figure 1: Images in Illustrations

Autonomous System Local Area Network (LAN)
or with a Single Subnet
Virtual Routing Domain or
Security Zone

Dynamic IP (DIP) Pool

Internet

Policy Engine
Security Zone Interfaces:
White = Protected Zone Interface
(example = Trust Zone)
Black = Outside Zone Interface
(example = Untrust Zone)
Generic Network Device

Tunnel Interface

Server

VPN Tunnel

Router

Juniper Networks
Switch Security Devices

Hub

Requesting Technical Support

Technical product support is available through the Juniper Networks Technical
Assistance Center (JTAC). If you are a customer with an active J-Care or JNASC
support contract, or are covered under warranty, and need postsales technical
support, you can access our tools and resources online or open a case with JTAC.

 JTAC policies—For a complete understanding of our JTAC procedures and

policies, review the JTAC User Guide located at
http://www.juniper.net/customers/support/downloads/710059.pdf.

 Product warranties—For product warranty information, visit

http://www.juniper.net/support/warranty/.

 JTAC hours of operation—The JTAC centers have resources available 24 hours a

day, 7 days a week, 365 days a year.

xii  Requesting Technical Support

 About This Volume

Self-Help Online Tools and Resources

For quick and easy problem resolution, Juniper Networks has designed an online
self-service portal called the Customer Support Center (CSC) that provides you with
the following features:

 Find CSC offerings—http://www.juniper.net/customers/support/

 Find product documentation—http://www.juniper.net/techpubs/

 Find solutions and answer questions using our Knowledge Base—

http://kb.juniper.net/

 Download the latest versions of software and review your release notes—
http://www.juniper.net/customers/csc/software/

 Search technical bulletins for relevant hardware and software notifications—

http://www.juniper.net/alerts/

 Join and participate in the Juniper Networks Community Forum—

http://www.juniper.net/company/communities/

 Open a case online in the CSC Case Manager—

http://www.juniper.net/customers/cm/

 To verify service entitlement by product serial number, use our Serial Number
Entitlement (SNE) Tool—
https://tools.juniper.net/SerialNumberEntitlementSearch/

Opening a Case with JTAC

You can open a case with JTAC on the Web or by telephone.

 Use the Case Manager tool in the CSC at http://www.juniper.net/customers/cm/.

 Call 1-888-314-JTAC (1-888-314-5822—toll free in USA, Canada, and Mexico).

For international or direct-dial options in countries without toll-free numbers, visit

us at http://www.juniper.net/customers/support/requesting-support/.

Document Feedback
If you find any errors or omissions in this document, contact Juniper Networks at
[email protected].

Document Feedback  xiii

 Concepts & Examples ScreenOS Reference Guide

xiv  Document Feedback

Chapter 1
Static Routing

This chapter discusses static routing and explains when and how to set up static
routes. It contains the following sections:

 “Overview” on page 2

 “How Static Routing Works” on page 2

 “When to Configure Static Routes” on page 3

 “Configuring Static Routes” on page 5

 “Enabling Gateway Tracking” on page 9

 “Forwarding Traffic to the Null Interface” on page 10

 “Preventing Route Lookup in Other Routing Tables” on page 10

 “Preventing Tunnel Traffic from Being Sent on Non-Tunnel Interfaces”

on page 10

 “Preventing Loops Created by Summarized Routes” on page 10

 “Permanently Active Routes” on page 11

 “Changing Routing Preference with Equal Cost Multipath” on page 11

 1
 Concepts & Examples ScreenOS Reference Guide

Overview
A static route is a manually configured mapping of an IP network address to a
next-hop destination (another router) that you define on a Layer 3 forwarding
device, such as a router.

For a network that has few connections to other networks, or for networks where
inter-network connections are relatively unchanging, it is usually more efficient to
define static routes rather than dynamic routes. ScreenOS retains static routes until
you explicitly remove them. However, you can override static routes with dynamic
route information if necessary.

You can view static routes in the ScreenOS routing table. To force load-balancing,
you can configure Equal Cost Multi-Path (ECMP). To only use active gateways, you
can set gateway tracking.

You should set at least a null route as a default route (network address 0.0.0.0/0). A
default route is a catch-all entry for packets that are destined for networks other
than those defined in the routing table.

How Static Routing Works

When a host sends packets to another host that resides on a different network,
each packet header contains the address of the destination host. When a router
receives a packet, it compares the destination address to all addresses contained in
its routing table. The router selects the most specific route in the routing table to the
destination address and, from the selected route entry, determines the next-hop to
forward the packet.

NOTE: The most specific route is determined by first performing a bit-wise logical AND of
the destination address and network mask for each entry in the routing table. For
example, a bit-wise logical AND of the IP address 10.1.1.1 with the subnet mask
255.255.255.0 is 10.1.1.0. The route that has the highest number of bits set to 1
in the subnet mask is the most specific route (also called the “longest matching
route”).

Figure 2 represents a network that uses static routing and a sample IP packet. In
this example, host 1 in network A wants to reach host 2 in network C. The packet to
be sent contains the following data in the header:

 Source IP address

 Destination IP address

 Payload (message)

2  Overview
 Chapter 1: Static Routing

Figure 2: Static Routing Example

SRC DST
IP IP

Host 1 Host 2 Payload

Router Y

Router X

Network A Network B Network C

Host 1 Router 2 Host 2

Table 1 summarizes the routing table of each router.

Table 1: Routing Table Summary for Routers X, Y, and Z

Router X Router Y Router Z

Network Gateway Network Gateway Network Gateway
Net A Connected Net A Router X Net A Router X
Net B Connected Net B Connected Net B Connected
Net C Router Y Net C Connected Net C Connected

In Table 1, router X has a static route configured for network C with the gateway
(next-hop) as router Y. When router X receives the packet destined for host 2 in
network C, it compares the destination address in the packet with its routing table
and finds that the last route entry in the table is the most specific route to the
destination address. The last route entry specifies to send traffic destined for
network C to router Y for delivery. Router Y receives the packet, and, because it
knows that network C is directly connected, it sends the packet through the
interface connected to that network.

If router Y fails, or if the link between router Y and network C is unavailable, the
packet cannot reach host 2. While there is another route for network C through
router Z, that route has not been statically configured on router X, so router X does
not detect the alternate route.

When to Configure Static Routes

You need to define at least a few static routes even when using dynamic routing
protocols. You need to define static routes for conditions such as the following:

 You need to define a static route to add a default route (0.0.0.0/0) to the routing
table for a virtual router (VR). For example, if you are using two VRs on the
same security device, the trust-vr routing table could contain a default route
that specifies the untrust-vr as the next hop. This allows traffic for destinations
that are not in the trust-vr routing table to be routed to the untrust-vr. You can
also define a default route in the untrust-vr to route to a specific IP address
traffic for destinations not found in the untrust-vr routing table.

Overview  3
 Concepts & Examples ScreenOS Reference Guide

 If a network is not directly connected to the security device but is accessible

through a router from an interface within a VR, you need to define a static route
for the network with the IP address of the router. For example, the Untrust zone
interface can be on a subnet with two routers that each connect to different
Internet service providers (ISPs). You must define which router to use for
forwarding traffic to specific ISPs.

 If you are using two VRs on the same security device, and inbound traffic
arrives on an untrust-vr interface that is destined for a network connected to a
trust-vr interface, you need to define a static entry in the untrust-vr routing
table for the destination network with the trust-vr as the next hop. You can
avoid setting a static route in this case by exporting the routes in the trust-vr to
the untrust-vr.

 When the device is in transparent mode, you must define static routes that
direct management traffic originating from the device itself (as opposed to user
traffic traversing the firewall) to remote destinations. For example, you need to
define static routes directing syslog, SNMP, and WebTrends messages to a
remote administrator’s address. You must also define routes that direct
authentication requests to the RADIUS, SecurID, and LDAP servers, and URL
checks to the Websense server.

NOTE: When the security device is in Transparent mode, you must define a static route
for management traffic from the device even if the destination is on the same
subnet as the device.

 For outbound Virtual Private Network (VPN) traffic where there is more than
one outgoing interface to the destination, you need to set a route for directing
the outbound traffic through the desired interface to the external router.

 If an interface for a security zone in the trust-vr is NAT, and if you configured a
mapped IP (MIP) or virtual IP (VIP) on that interface to receive incoming traffic
from a source in the untrust-vr routing domain, then you must create a route to
the MIP or VIP in the untrust-vr that points to the trust-vr as the gateway.

 By default, the security device uses destination IP addresses to find the best
route on which to forward packets. You can also enable source-based or source
interface-based routing tables on a VR. Both source-based and source
interface-based routing tables contain static routes that you configure on the
VR.

4  Overview
 Chapter 1: Static Routing

Configuring Static Routes

To configure a static route, you need to define the following:

 Virtual router (VR) to which the route belongs.

 IP address and netmask of the destination network.

 Next hop for the route, which can be either another VR on the security device
or a gateway (router) IP address. If you specify another VR, make sure that an
entry for the destination network exists in the routing table of that VR.

 The interface through which the routed traffic is forwarded. The interface can
be any ScreenOS-supported interface, such as a physical interface (for example,
ethernet1/2) or a tunnel interface. You can also specify the Null interface for
certain applications. See “Forwarding Traffic to the Null Interface” on page 10.

Optionally, you can define the following elements:

 Route metric is used to select the active route when there are multiple routes to
the same destination network, all with the same preference value. The default
metric for static routes is 1.

 Route tag is a value that can be used as a filter when redistributing routes. For
example, you can choose to import into a VR only those routes that contain
specified tag values.

 Preference value for the route. By default, all static routes have the same
preference value, which is set in the VR.

 Whether the route is permanent (kept active even if the forwarding interface is
down or the IP address is removed from the interface).

This section contains the following examples:

 “Setting Static Routes” on page 5

 “Setting a Static Route for a Tunnel Interface” on page 8

Setting Static Routes

In Figure 3 on page 6, a security device operating with its Trust zone interface in
Network Address Translation (NAT) mode protects a multilevel network. There is
both local and remote management (via NetScreen-Security Manager). The security
device sends SNMP traps and syslog reports to the local administrator (located on a
network in the Trust zone) and it sends NetScreen-Security Manager reports to the
remote administrator (located on a network in the Untrust zone). The device uses a
SecurID server in the Demilitarized Zone (DMZ) to authenticate users and a
Websense server in the Trust zone to perform Web filtering.

NOTE: The following zones must be bound before this example can be completed:
ethernet1 to the Trust zone, ethernet2 to the DMZ zone, and ethernet3 to the
Untrust zone. The interface IP addresses are 10.1.1.1/24, 2.2.10.1/24, and
2.2.2.1/24, respectively.

Overview  5
 Concepts & Examples ScreenOS Reference Guide

The trust-vr and untrust-vr routing tables must contain routes for the following
destinations:

untrust-vr
1. Default gateway to the Internet (default route for the VR)

2. Remote administrator in the 3.3.3.0/24 subnet

3. 2.2.40.0/24 subnet in the DMZ

4. 2.20.0.0/16 subnet in the DMZ

trust-vr
5. untrust-vr for all addresses not found in the trust-vr routing table (default route
for the VR)

6. 10.10.0.0/16 subnet in the Trust zone

7. 10.20.0.0/16 subnet in the Trust zone

8. 10.30.1.0/24 subnet in the Trust zone

Figure 3: Static Route Configuration

Remote Management
NetScreen-Security Manager untrust-vr
3.3.3.10/32

Virtual Routing Domain 2 DMZ

Internet 2.2.10.3/24
1 2.2.10.0/24 2.20.30.1/24
Untrust Zone 3.3.3.0/24

2.2.10.0/24 4
200.20.2.2/24 2.2.40.1/24
2.20.30.0/24
2.2.2.2/24 3.3.3.1/24 3 2.2.40.0/24
2.2.2.3/24
2.2.2.0/24 2.20.30.2/24
2.2.45.7/32 2.20.3.1/24
2.20.4.1/24
2.20.3.0/24 2.20.4.0/24

5
Default Security Device
Route
= Router

10.1.1.0/24 Virtual Routing = SwitchHub

10.1.1.4/24 Domain
10.1.1.2/24 10.30.1.1/24
10.10.30.1/24
10.10.30.1/24 10.1.1.3/24
6 10.20.1.1/24 8 trust-vr
7
10.10.30.0/24 10.10.40.0/24 10.30.1.0/24
10.20.1.0/24
Local Management
10.10.30.5/32 10.20.1.1/24
Websense Server
10.30.4.7/32
10.20.3.1/24
10.20.4.1/24
10.20.3.0/24 10.20.4.0/24

Trust Zone

6  Overview
 Chapter 1: Static Routing

WebUI
1. untrust-vr
Network > Routing > Destination > untrust-vr New: Enter the following to
create the untrust default gateway, then click OK:

Network Address/Netmask: 0.0.0.0/0

Gateway: (select)
Interface: ethernet3
Gateway IP Address: 2.2.2.2

Network > Routing > Destination> untrust-vr New: Enter the following to
direct system reports generated by the security device to remote management,
then click OK:

Network Address/Netmask: 3.3.3.0/24

Gateway: (select)
Interface: ethernet3
Gateway IP Address: 2.2.2.3

Network > Routing > Destination > untrust-vr New: Enter the following, then
click OK:

Network Address/Netmask: 2.2.40.0/24

Gateway: (select)
Interface: ethernet2
Gateway IP Address: 2.2.10.2

Network > Routing > Destination > untrust-vr New: Enter the following, then
click OK:

Network Address/Netmask: 2.20.0.0/16

Gateway: (select)
Interface: ethernet2
Gateway IP Address: 2.2.10.3
2. trust-vr
Network > Routing > Destination > trust-vr New: Enter the following, then
click OK:

Network Address/Netmask: 0.0.0.0/0

Next Hop Virtual Router Name: (select); untrust-vr

Network > Routing > Destination > trust-vr New: Enter the following, then
click OK:

Network Address/Netmask: 10.10.0.0/16

Gateway: (select)
Interface: ethernet1
Gateway IP Address: 10.1.1.2

Network > Routing > Destination > trust-vr New: Enter the following, then
click OK:

Network Address/Netmask: 10.20.0.0/16

Gateway: (select)
Interface: ethernet1
Gateway IP Address: 10.1.1.3

Overview  7
 Concepts & Examples ScreenOS Reference Guide

Network > Routing > Destination > trust-vr New: Enter the following, then
click OK:

Network Address/Netmask: 10.30.1.0/24

Gateway: (select)
Interface: ethernet1
Gateway IP Address: 10.1.1.4

NOTE: To remove an entry, click Remove. A message appears prompting you to confirm
the removal. Click OK to proceed or Cancel to cancel the action.

CLI
1. untrust-vr
set vrouter untrust-vr route 0.0.0.0/0 interface ethernet3 gateway 2.2.2.2
set vrouter untrust-vr route 3.3.3.0/24 interface ethernet3 gateway 2.2.2.3
set vrouter untrust-vr route 2.2.40.0/24 interface ethernet2 gateway 2.2.10.2
set vrouter untrust-vr route 2.20.0.0/16 interface ethernet2 gateway 2.2.10.3
2. trust-vr
set vrouter trust-vr route 0.0.0.0/0 vrouter untrust-vr
set vrouter trust-vr route 10.10.0.0/16 interface ethernet1 gateway 10.1.1.2
set vrouter trust-vr route 10.20.0.0/16 interface ethernet1 gateway 10.1.1.3
set vrouter trust-vr route 10.30.1.0/24 interface ethernet1 gateway 10.1.1.4
save

Setting a Static Route for a Tunnel Interface

In Figure 4, a trusted host resides in a different subnet from the trusted interface. A
File Transfer Protocol (FTP) server receives inbound traffic through a VPN tunnel.
You need to set a static route to direct traffic exiting the tunnel interface to the
internal router leading to the subnet where the server resides.

Figure 4: Static Route for a Tunnel Interface

Trust Interface Untrust Interface
ethernet1 ethernet3 FTP Server
10.1.1.1/24 1.1.1.1/24 10.2.2.5

Trust Zone Untrust Zone

Internet

VPN Tunnel

tunnel.1 Router
10.10.1.1/24 1.1.1.250

WebUI
Network > Routing > Destination > trust-vr New: Enter the following, then
click OK:

Network Address/Netmask: 10.2.2.5/32

Gateway: (select)
Interface: tunnel.1
Gateway IP Address: 0.0.0.0

8  Overview
 Chapter 1: Static Routing

NOTE: For tunnel.1 to appear in the Interface drop-down list, you must first create the
tunnel.1 interface.

Network > Routing > Destination > trust-vr New: Enter the following, then
click OK:

Network Address/Netmask: 0.0.0.0/0

Gateway: (select)
Interface: ethernet3
Gateway IP Address: 1.1.1.250

CLI
set vrouter trust-vr route 10.2.2.5/32 interface tunnel.1
set vrouter trust-vr route 0.0.0.0/0 interface ethernet3 gateway 1.1.1.250
save

Enabling Gateway Tracking

The security device allows interface-independent static routes with gateways to be
tracked for reachability. By default, static routes are not tracked, but you can
configure a security device to track reachability for gateway routes. The security
device uses the routing table information to determine the reachability of each
gateway. The routing table displays the status of the route as active or inactive,
depending on the ability of a route to reach the tracked gateway.

To add a static route with gateway tracking, you need to explicitly set the route at
the virtual router (VR) level and at the gateway address. The security device tracks
only the specified gateway IP and does not depend on the route interface.

NOTE: You can use gateway tracking only to track remote gateway addresses. Gateway
tracking cannot be applied for the default gateway address of your local subnet. To
enable gateway tracking on a static route, you must use the IP address, not the
interface, to identify the gateway.

Use the CLI command given below to add a static route with a tracked gateway for
IP address 1.1.1.254 with prefix 1.1.1.0 and a length of 24.

WebUI
Network > Routing > Destination: Click New, then enter the following:

IPv4/Netmask: 1.1.1.0/24
Gateway: (select)
Gateway IP Address: 1.1.1.254

CLI
set vrouter trust route 1.1.1.0/24 gateway 1.1.1.254
unset vrouter trust route 1.1.1.0/24 gateway 1.1.1.254
save

Routes with gateway tracking are only applied locally in the device, so if the device
is participating in NSRP cluster it is necessary to manually set the route in the NSRP
peer as well.

Overview  9
 Concepts & Examples ScreenOS Reference Guide

Forwarding Traffic to the Null Interface

You can configure static routes with the Null interface as the outgoing interface. The
Null interface is always active, and traffic destined to the Null interface is always
dropped. To make the route to the Null interface a last resort route, you need to
define the route with a higher metric than other routes. The three purposes for
using static routes that forward traffic to the Null interface are as follows:

 Preventing route lookup in other routing tables

 Preventing tunnel traffic from being sent on non-tunnel interfaces

 Preventing traffic loops

Preventing Route Lookup in Other Routing Tables

If source interface-based routing is enabled, the security device by default performs
route lookup in the source interface-based routing table. (For information about
configuring source interface-based routing, see “Source Interface-Based Routing
Table” on page 19.) If the route is not found in the source interface-based routing
table and if source-based routing is enabled, the security device performs route
lookup in the source-based routing table. If the route is not found in the
source-based routing table, the security device performs route lookup in the
destination-based routing table. If you want to prevent route lookup in either the
source-based routing table or the destination-based routing table, you can create a
default route in the source interface-based routing table with the Null interface as
the outgoing interface. Use a higher metric than other routes to ensure that this
route is only used if no other source interface-based routes exist that match the
route.

Preventing Tunnel Traffic from Being Sent on Non-Tunnel Interfaces

You can use static or dynamic routes with outgoing tunnel interfaces to encrypt
traffic to specified destinations. If a tunnel interface becomes inactive, all routes
defined on the interface become inactive. If there is an alternate route on a
non-tunnel interface, traffic is sent unencrypted. To prevent traffic that is intended
to be encrypted from being sent on a non-tunnel interface, define a static route to
the same destination as the tunnel traffic with the Null interface as the outgoing
interface. Assign this route a higher metric than the tunnel interface route so that
the route only becomes active if the tunnel interface route is unavailable. If the
tunnel interface becomes inactive, the route with the Null interface becomes active
and traffic for the tunnel destination is dropped.

Preventing Loops Created by Summarized Routes

When the security device advertises summarized routes, the device might receive
traffic for prefixes that are not in its routing tables. It might then forward the traffic
based on its default route. The receiving router might then forward the traffic back
to the security device because of the summarized route advertisement. To avoid
such loops, you can define a static route for the summarized route prefix with the
Null interface as the outgoing interface and a high route metric. If the security
device receives traffic for prefixes that are in its summarized route advertisement
but not in its routing tables, the traffic is dropped.

10  Forwarding Traffic to the Null Interface

 Chapter 1: Static Routing

In this example, you set a NULL interface for the summarized route that you created
to the network 2.1.1.0/24 in the previous example. Within the network 2.1.1.0/24
you have hosts 2.1.1.2, 2.1.1.3, and 2.1.1.4. Any packets addressed to 2.1.1.10 fall
into the range for the summarized route. The security device accepts these packets
but has nowhere to forward them except back out to the origin and this begins a
network loop. To avoid this pattern, you set a NULL interface for this route. Setting a
high preference and metric are important when setting a NULL interface.

WebUI
Network > Routing >Destination > trust-vr New: Enter the following and then
click OK:

Network Address/Netmask: 2.1.1.0/24

Gateway: (Select)
Interface: Null
Gateway IP Address: 0.0.0.0
Preference: 255
Metric: 65535

CLI
set vrouter trust-vr route 2.1.1.0/24 interface null preference 255 metric 65535
save

Permanently Active Routes

Certain situations exist where you want a route to stay active in a routing table even
if the physical interface associated with that route goes down or does not have an
assigned IP address. For example, an XAuth server can assign an IP address to an
interface on a security device whenever there is traffic that needs to be sent to the
server. The route to the XAuth server needs to be kept active even when there is no
IP address assigned on the interface so that traffic that is intended for the XAuth
server is not dropped.

It is also useful to keep routes active through interfaces on which IP tracking is

configured. IP tracking allows the security device to reroute outgoing traffic through
a different interface if target IP addresses become unreachable through the original
interface. Even though the security device may reroute traffic to another interface, it
still needs to be able to send ping requests on the original interface to determine if
the targets become reachable again.

Changing Routing Preference with Equal Cost Multipath

You can also change the routing preference for static routes with Equal Cost
Multipath (ECMP). See “Configuring Equal Cost Multipath Routing” on page 35 for
more information.

Permanently Active Routes  11

 Concepts & Examples ScreenOS Reference Guide

12  Changing Routing Preference with Equal Cost Multipath

Chapter 2
Routing

This chapter describes routing and virtual router (VR) management. It contains the
following sections:

 “Overview” on page 14

 “Virtual Router Routing Tables” on page 15

 “Destination-Based Routing Table” on page 16

 “Source-Based Routing Table” on page 17

 “Source Interface-Based Routing Table” on page 19

 “Creating and Modifying Virtual Routers” on page 21

 “Modifying Virtual Routers” on page 21

 “Assigning a Virtual Router ID” on page 22

 “Forwarding Traffic Between Virtual Routers” on page 23

 “Configuring Two Virtual Routers” on page 23

 “Creating and Deleting Virtual Routers” on page 25

 “Virtual Routers and Virtual Systems” on page 26

 “Limiting the Number of Routing Table Entries” on page 29

 “Routing Features and Examples” on page 30

 “Route Selection” on page 30

 “Configuring Equal Cost Multipath Routing” on page 35

 “Route Redistribution” on page 37

 “Exporting and Importing Routes Between Virtual Routers” on page 42

 13
 Concepts & Examples ScreenOS Reference Guide

Overview
Routing is the process of forwarding packets from one network to another toward a
final destination. A router is a device that resides where one network meets another
network and directs traffic between those networks.

By default, a security device enters the Route operational mode and operate as a
Layer-3 router. However, you can configure a security device to operate in
Transparent mode as a Layer-2 switch.

NOTE: For either operational mode, you need to manually configure some routes.

Juniper Networks security devices accomplish routing through a process called a

virtual router (VR). A security device divides its routing component into two or more
VRs with each VR maintaining its own list of known networks in the form of a
routing table, routing logic, and associated security zones. A single VR can support
one or more of the following:

 Static or manually configured routes

 Dynamic routes, such as those learned by a dynamic routing protocol

 Multicast routes, such as a route to a group of host machines

Juniper Networks security devices have two predefined VRs:

 trust-vr, which by default contains all the predefined security zones and any
user-defined zones

 untrust-vr, which by default does not contain any security zones

You cannot delete the trust-vr or untrust-vr VRs. Multiple VRs can exist, but trust-vr
remains the default VR. In the VR table an asterisk (*) designates trust-vr as the
default VR in the command line interface (CLI). You can view the VR table with the
get vrouter CLI command. To configure zones and interfaces within other VRs, you
must specify the VR by name, such as untrust-vr. For more information about
zones, see “Zones” on page 2-25.

Some security devices allow you to create additional custom VRs. By separating
routing information into multiple VRs, you can control how much routing
information is visible to other routing domains. For example, you can keep the
routing information for all the security zones inside a corporate network on the
predefined VR trust-vr, and the routing information for all the zones outside the
corporate network on the other predefined VR untrust-vr. You can keep internal
network routing information separate from untrusted sources outside the company
because routing table details of one VR are not visible to the other.

14  Overview
 Chapter 2: Routing

Virtual Router Routing Tables

In a security device, each VR maintains its own routing tables. A routing table is an
up-to-date list of known networks and directions for reaching them. When a
security device processes an incoming packet, it performs a routing table lookup to
find the appropriate interface that leads to the destination address.

Each route table entry identifies the destination network to which traffic can be
forwarded. The destination network can be an IP network, subnetwork, supernet,
or host. Each routing table entry can be unicast (packet sent to single IP address
that references a single host machine) or multicast (packet sent to a single IP
address that references multiple host machines).

Routing table entries can originate from the following sources:

 Directly connected networks (the destination network is the IP address that you
assign to an interface in Route mode)

 Dynamic routing protocols, such as Open Shortest Path First (OSPF), Border
Gateway Protocol (BGP), or Routing Information Protocol (RIP)

 Other routers or virtual routers in the form of imported routes

 Statically configured routes

 Host routes

NOTE: When you set an IP address for an interface in Route mode, the routing table
automatically creates a connected route to the adjacent subnet for traffic
traversing the interface.

A VR supports three types of routing tables:

 The destination-based routing table allows the security device to perform route
lookups based on the destination IP address of an incoming data packet. By
default, the security device uses only destination IP addresses to find the best
route on which to forward packets.

 The source-based routing table allows the security device to perform route
lookups based on the source IP address of an incoming data packet. To add
entries to the source-based routing table, you must configure static routes for
specific source addresses on which the security device can perform route
lookup. This routing table is disabled by default. See “Source-Based Routing
Table” on page 17.

 The source interface-based routing table allows the security device to perform
route lookups based on the interface on which a data packet arrives on the
device. To add entries to the source interface-based routing table, you must
configure static routes for specific interfaces on which the VR performs route
lookup. This routing table is disabled by default. See “Source Interface-Based
Routing Table” on page 19.

Virtual Router Routing Tables  15

 Concepts & Examples ScreenOS Reference Guide

Destination-Based Routing Table

The destination-based routing table is always present in a VR. Additionally, you can
enable source-based or source interface-based routing tables, or both, in a VR. The
following is an example of ScreenOS destination-based routing tables:

device-> get route

IPv4 Dest-Routes for <untrust-vr> (0 entries)

--------------------------------------------------------------------------------
H: Host C: Connected S: Static A: Auto-Exported
I: Imported R: RIP P: Permanent D: Auto-Discovered
iB: IBGP eB: EBGP O: OSPF E1: OSPF external type 1
E2: OSPF external type 2

IPv4 Dest-Routes for <trust-vr> (11 entries)

--------------------------------------------------------------------------------
ID IP-Prefix Interface Gateway P Pref Mtr Vsys
--------------------------------------------------------------------------------
* 8 0.0.0.0/0 eth1/1 10.100.37.1 S 20 1 Root
* 7 1.1.1.1/32 eth1/2 0.0.0.0 H 0 0 Root
* 3 192.168.1.1/32 mgt 0.0.0.0 H 0 0 Root
* 2 192.168.1.0/24 mgt 0.0.0.0 C 0 0 Root
* 4 10.100.37.0/24 eth1/1 0.0.0.0 C 0 0 Root
* 5 10.100.37.170/32 eth1/1 0.0.0.0 H 0 0 Root
* 6 1.1.1.0/24 eth1/2 0.0.0.0 C 0 0 Root
* 9 11.3.3.0/24 agg1 0.0.0.0 C 0 0 Root
* 10 11.3.3.0/32 agg1 0.0.0.0 H 0 0 Root
* 11 3.3.3.0/24 tun.1 0.0.0.0 C 0 0 Root
* 12 3.3.3.0/32 tun.1 0.0.0.0 H 0 0 Root

For each destination network, the routing table contains the following information:

 The interface on the security device on which traffic for the destination network
is forwarded.

 The next-hop, which can be either another VR on the security device or a

gateway IP address (usually a router address).

 The protocol from which the route is derived. The protocol column of the
routing table allows you know the route type:

 Connected network (C)

 Static (S)

 Auto-exported (A)

 Imported (I)

 Dynamic routing protocols, such as RIP (R), Open Shortest Path First or
OSPF (O), OSPF external type 1 or type 2 (E1 or E2, respectively), internal
or external Border Gateway Protocol (iB or eB, respectively)

 Permanent (P)

16  Virtual Router Routing Tables

 Chapter 2: Routing

 Host (H)

A host-route entry with a 32-bit mask appears when you configure each
interface with an IP address. The host route is always active in the route
table so that route lookup always succeeds. The host routes automatically
update with configured changes, such as interface IP address deletion, and
they are never redistributed or exported. Host routes remove the possibility
of wandering traffic and conserve processing capability.

 The preference is used to select the route to use when there are multiple routes
to the same destination network. This value is determined by the protocol or
the origin of the route. The lower the preference value of a route, the more
likely the route is to be selected as the active route.

You can modify the preference value for each protocol or route origin on a
per-virtual router basis. See “Route Selection” on page 30 for more information.

 The metric can also be used to select the route to use when there are multiple
routes for the same destination network with the same preference value. The
metric value for connected routes is always 0. The default metric value for static
routes is 1, but you can specify a different value when defining a static route.

 The virtual system (vsys) to which this route belongs. For more information
about virtual routers and vsys, see “Virtual Routers and Virtual Systems” on
page 26. In this example, no entries appear under the untrust-vr table header;
eleven entries appear under the trust-vr table header.

Most routing tables include a default route (network address 0.0.0.0/0), which is a
catch-all entry for packets that are destined for networks other than those defined
in the routing table.

For an example of destination based routing, see “Configuring Static Routes” on

page 5.

Source-Based Routing Table

You can direct the security device to forward traffic based on the source IP address
of a data packet instead of the destination IP address. This feature allows traffic
from users on a specific subnet to be forwarded on one path while traffic from users
on a different subnet is forwarded on another path. When source-based routing is
enabled in a VR, the security device performs routing table lookup on the packet’s
source IP address in a source-based routing table. If the security device does not
find a route for the source IP address in the source-based routing table, then the
device uses the packet’s destination IP address for route lookup in the
destination-based routing table.

You define source-based routes as statically configured routes on specified VRs.

Source-based routes apply to the VR in which you configure them, but you can
specify another VR as the next hop for a source-based route. You cannot, however,
redistribute source-based routes into another VR or into a routing protocol.

Virtual Router Routing Tables  17

 Concepts & Examples ScreenOS Reference Guide

To use this feature:

1. Create one or more source-based routes by specifying this information:

 The name of the VR in which source-based routing applies.

 The source IP address, which appears as an entry in the source-based

routing table, on which the security device performs a routing table lookup.

 The name of the outgoing interface on which the packet is forwarded.

 The next-hop for the source-based route (If you have already specified a
default gateway for the interface with the CLI set interface interface
gateway ip_addr command, you do not need to specify the gateway
parameter; the interface’s default gateway is used as the next hop for the
source-based route. You can also specify another VR as the next-hop for the
source-based route with the set vrouter vrouter route source
ip_addr/netmask vrouter next-hop_vrouter.)

 The metric for the source-based route. (If there are multiple source-based
routes with the same prefix, only the route with the lowest metric is used
for route lookup; other routes with the same prefix are marked as
“inactive.”)

2. Enable source-based routing for the VR. The security device uses the source IP
of the packet for route lookup in the source-based routing table. If no route is
found for the source IP address, the destination IP address is used for the
routing table lookup.

In Figure 5, traffic from users on the 10.1.1.0/24 subnetwork is forwarded to ISP 1,

while traffic from users on the 10.1.2.0/24 subnetwork is forwarded to ISP 2. This
configuration requires two entries in the default trust-vr VR routing table and
enables source-based routing:

 The subnetwork 10.1.1.0/24, with ethernet3 as the forwarding interface, and

ISP 1’s router (1.1.1.1) as the next-hop

 The subnetwork 10.1.2.0/24, with ethernet4 as the forwarding interface, and

ISP 2’s router (2.2.2.2) as the next-hop

Figure 5: Source-Based Routing Example

10.1.1.0/24 ISP 1
1.1.1.1
ethernet1

ethernet2
ISP 2
10.1.2.0/24
2.2.2.2

18  Virtual Router Routing Tables

 Chapter 2: Routing

WebUI
Network > Routing > Source Routing > New (for trust-vr): Enter the following,
then click OK:

Network Address/Netmask: 10.1.1.0 255.255.255.0

Interface: ethernet3 (select)
Gateway IP Address: 1.1.1.1

Network > Routing > Source Routing > New (for trust-vr): Enter the following,
then click OK:

Network Address/Netmask: 10.1.2.0 255.255.255.0

Interface: ethernet4 (select)
Gateway IP Address: 2.2.2.2

NOTE: In the WebUI, the default preference and metric value are 1.

Network > Routing > Virtual Routers > Edit (for trust-vr): Select Enable
Source Based Routing, then click OK.

CLI
set vrouter trust-vr route source 10.1.1.0/24 interface ethernet3 gateway 1.1.1.1
metric 1
set vrouter trust-vr route source 10.1.2.0/24 interface ethernet4 gateway 2.2.2.2
metric 1
set vrouter trust-vr source-routing enable
save

Source Interface-Based Routing Table

Source interface-based routing (SIBR) allows the security device to forward traffic
based on the source interface (the interface on which the data packet arrives on the
security device). When SIBR is enabled in a virtual router (VR), the security device
performs route lookup in an SIBR routing table. If the security device does not find a
route entry in the SIBR routing table for the source interface, it can perform route
lookup in the source-based routing table (if source-based routing is enabled in the
VR) or the destination-based routing table.

You define source interface-based routes as static routes for specified source
interfaces. Source interface-based routes apply to the VR in which you configure
them, but you can also specify another VR as the next hop for a source
interface-based route. You cannot, however, export source interface-based routes
into another VR or redistribute them into a routing protocol.

To use this feature:

1. Create one or more source interface-based routes by specifying the following

information:

 The name of the VR in which source interface-based routing applies.

 The source interface on which the security device performs a lookup in the
SIBR table. (The interface appears as an entry in the routing table.)

 The IP address and netmask prefix for the route.

Virtual Router Routing Tables  19

 Concepts & Examples ScreenOS Reference Guide

 The name of the outgoing interface on which the packet is forwarded.

 The next-hop for the source interface-based route. (If you have already
specified a default gateway for the interface with the CLI set interface
interface gateway ip_addr command, you do not need to specify the
gateway parameter; the interface’s default gateway is used as the next hop
for the source interface-based route. You can also specify another VR as the
next-hop for the source-based route with the set vrouter vrouter route
source ip_addr/netmask vrouter next-hop_vrouter.)

 The metric for the source interface-based route. (If there are multiple
source interface-based routes with the same prefix, only the route with the
lowest metric is used for route lookup; other routes with the same prefix
are marked as “inactive.”)

2. Enable SIBR for the VR. The security device uses the source interface of the
packet for route lookup in the SIBR table.

In Figure 6, traffic from users on the 10.1.1.0/24 subnetwork arrives on the security
device on the ethernet1 interface and is forwarded to ISP 1, while traffic from users
on the 10.1.2.0/24 subnetwork arrives on the device on ethernet2 and is forwarded
to ISP 2. You need to configure two entries in the default trust-vr VR routing table
and enable SIBR:

 The subnetwork 10.1.1.0/24, with ethernet1 as the source interface and

ethernet3 as the forwarding interface, and ISP 1’s router (1.1.1.1) as the
next-hop

 The subnetwork 10.1.2.0/24, with ethernet2 as the source interface and

ethernet4 as the forwarding interface, and ISP 2’s router (2.2.2.2) as the
next-hop

Figure 6: Source Interface-Based Routing (SIBR) Example

10.1.1.0/24 ISP1
1.1.1.1
ethernet1 ethernet3

ethernet2 ethernet4
ISP2
10.1.2.0/24 2.2.2.2

20  Virtual Router Routing Tables

 Chapter 2: Routing

WebUI
Network > Routing > Source Interface Routing > New (for ethernet1): Enter
the following, then click OK:

Network Address/Netmask: 10.1.1.0 255.255.255.0

Interface: ethernet3 (select)
Gateway IP Address: 1.1.1.1

Network > Routing > Source Interface Routing > New (for ethernet2): Enter
the following, then click OK:

Network Address/Netmask: 10.1.2.0 255.255.255.0

Interface: ethernet4 (select)
Gateway IP Address: 2.2.2.2

NOTE: In the WebUI, the default preference and metric value are 1.

Network > Routing > Virtual Routers > Edit (for trust-vr): Select Enable
Source Interface Based Routing, then click OK.

CLI
set vrouter trust-vr route source in-interface ethernet1 10.1.1.0/24 interface
ethernet3 gateway 1.1.1.1 metric 1
set vrouter trust-vr route source in-interface ethernet2 10.1.2.0/24 interface
ethernet4 gateway 2.2.2.2 metric 1
set vrouter trust-vr sibr-routing enable
save

Creating and Modifying Virtual Routers

This section contains various examples and procedures for modifying existing
virtual routers (VRs) and for creating or deleting custom VRs.

Modifying Virtual Routers

You can modify a predefined or custom VR through either the WebUI or the CLI. For
example, to modify the trust-vr VR:

WebUI
Network > Routing > Virtual Router (trust-vr) > Edit

CLI
set vrouter trust-vr

You can modify the following parameters for VRs:

 Virtual router ID (see “Limiting the Number of Routing Table Entries” on

page 29).

 Maximum number of entries allowed in the routing table.

 Preference value for routes, based on protocol (see “Setting a Route Preference”
on page 30).

Creating and Modifying Virtual Routers  21

 Concepts & Examples ScreenOS Reference Guide

 Direct the VR to forward traffic based on the source IP address of a data packet
(by default, the VR forwards traffic based on the destination IP address of a data
packet. See “Source-Based Routing Table” on page 17.)

 Enable or disable automatic route exporting to the untrust-vr for interfaces

configured in Route mode (for the trust-vr only).

 Add a default route with another VR as the next hop (for the trust-vr only).

 Make SNMP traps for the dynamic routing MIBs private (for the default
root-level VR only).

 Allow routes on inactive interfaces to be considered for advertising (by default,

only active routes defined on active interfaces can be redistributed to other
protocols or exported to other VRs).

 Direct the VR to ignore overlapping subnet addresses for interfaces (by default,
you cannot configure overlapping subnet IP addresses for interfaces in the
same VR).

 Allow the VR to synchronize its configuration with the VR on its NetScreen

Redundancy Protocol (NSRP) peer.

Assigning a Virtual Router ID

With dynamic routing protocols, each routing device uses a unique router identifier
to communicate with other routing devices. The identifier can be in the form of a
dotted decimal notation, like an IP address, or an integer value. If you do not define
a specific virtual router ID (VR ID) before enabling a dynamic routing protocol,
ScreenOS automatically selects the highest IP address of the active interfaces in the
virtual router (VR) for the router identifier.

By default all security devices have IP address 192.168.1.1 assigned to the VLAN1
interface. If you do not specify a router ID before enabling a dynamic routing
protocol on a security device, the IP address chosen for the router ID will likely be
the default 192.168.1.1 address. This can cause a problem with routing because
there cannot be multiple security VRs with the same VR ID in a routing domain. We
recommend that you always explicitly assign a VR ID that is unique in the network.
You can set the VR ID to the loopback interface address, as long as the loopback
interface is not a Virtual Security Interface (VSI) in a NetScreen Redundancy
Protocol (NSRP) cluster. (See Volume 11: High Availability for more information about
configuring an NSRP cluster.)

In this example, you assign 0.0.0.10 as the router ID for the trust-vr.

NOTE: In the WebUI, you must enter the router ID in dotted decimal notation. In the CLI,
you can enter the router ID either in dotted decimal notation (0.0.0.10) or you can
simply enter 10 (this is converted by the CLI to 0.0.0.10).

22  Creating and Modifying Virtual Routers

 Chapter 2: Routing

WebUI
Network > Routing > Virtual Router (trust-vr) > Edit: Enter the following, then
click OK:

Virtual Router ID: Custom (select)

In the text box, enter 0.0.0.10

CLI
set vrouter trust-vr router-id 10
save

NOTE: You cannot assign or change a router ID if you have already enabled a dynamic
routing protocol in the VR. If you need to change the router ID, you must first
disable the dynamic routing protocol(s) in the VR. For information about disabling
a dynamic routing protocol in the VR, see the appropriate chapter in this volume.

Forwarding Traffic Between Virtual Routers

When two VRs exist on a security device, traffic from zones in one VR is not
automatically forwarded to zones in another VR even if there are policies that
permit the traffic. If traffic must pass between VRs, you need to take one of these
actions:

 Configure a static route in one VR that defines another VR as the next-hop for
the route. This route can even be the default route for the VR. For example, you
can configure a default route for the trust-vr with the untrust-vr as the next-hop.
If the destination in an outbound packet does not match any other entries in
the trust-vr routing table, it is forwarded to the untrust-vr. For information about
configuring static routes, see “Configuring Static Routes” on page 5.

 Export routes from the routing table in one VR into the routing table of another
VR. You can export and import specific routes. You can also export all routes in
the trust-vr routing table to the untrust-vr. This enables packets received in the
untrust-vr to be forwarded to destinations in the trust-vr. For information, see
“Exporting and Importing Routes Between Virtual Routers” on page 42.

Configuring Two Virtual Routers

When multiple VRs exist within a security device, each VR maintains separate
routing tables. By default, all predefined and user-defined security zones are bound
to the trust-vr. This also means that all interfaces that are bound to those security
zones also belong to the trust-vr. This section discusses how to bind a security zone
(and its interfaces) to the untrust-vr VR.

You can bind a security zone to only one VR. You can bind multiple security zones
to a single VR when there is no address overlap between zones. That is, all
interfaces in the zones must be in route mode. Once a zone is bound to a VR, all the
interfaces in that zone belong to the VR. You can change the binding of a security
zone from one VR to another, however, you must first remove all interfaces from the
zone. (For more information about binding and unbinding an interface to a security
zone, see “Interfaces” on page 2-35.)

Creating and Modifying Virtual Routers  23

 Concepts & Examples ScreenOS Reference Guide

The following are the basic steps in binding a security zone to the untrust-vr VR:

1. Remove all interfaces from the zone that you want to bind to the untrust-vr. You
cannot modify a zone-to-VR binding if there is an interface assigned to the
zone. If you have assigned an IP address to an interface, you need to remove
the address assignment before removing the interface from the zone.

2. Assign the zone to the untrust-vr VR.

3. Assign interface(s) back to the zone.

In the following example, the untrust security zone is bound by default to the
trust-vr, and the interface ethernet3 is bound to the untrust security zone. (There are
no other interfaces bound to the untrust security zone.) You must first set the IP
address and netmask of the ethernet3 interface to 0.0.0.0, then change the
bindings so that the untrust security zone is bound to the untrust-vr.

WebUI
1. Unbind Interface from Untrust Zone
Network > Interfaces (ethernet3) > Edit: Enter the following, then click OK:

Zone Name: Null

IP Address/Netmask: 0.0.0.0/0
2. Bind Untrust Zone to untrust-vr
Network > Zones (untrust) > Edit: Select untrust-vr from the Virtual Router
Name drop-down list, then click OK.

3. Bind Interface to Untrust Zone

Network > Interfaces (ethernet3) > Edit: Select Untrust from the Zone Name
drop-down list, then click OK.

CLI
1. Unbind Interface from Untrust Zone
unset interface ethernet3 ip
unset interface ethernet3 zone
2. Bind Untrust Zone to untrust-vr
set zone untrust vrouter untrust-vr
3. Bind Interface to Untrust Zone
set interface eth3 zone untrust
save

24  Creating and Modifying Virtual Routers

 Chapter 2: Routing

In the following example output, the get zone command shows the default
interface, zone, and VR bindings. In the default bindings, the untrust zone is bound
to the trust-vr.

device-> get zone

Total of 12 zones in vsys root. 7 policy configurable zone(s)
-------------------------------------------------------------
ID Name Type Attr VR Default-IF VSYS
0 Null Null Shared untrust-vr null Root
1 Untrust Sec(L3) Shared trust-vr ethernet3 Root
2 Trust Sec(L3) trust-vr ethernet1 Root
3 DMZ Sec(L3) trust-vr ethernet2 Root
4 Self Func trust-vr self Root
5 MGT Func trust-vr vlan1 Root
6 HA Func trust-vr null Root
10 Global Sec(L3) trust-vr null Root
11 V1-Untrust Sec(L2) trust-vr v1-untrust Root
12 V1-Trust Sec(L2) trust-vr v1-trust Root
13 V1-DMZ Sec(L2) trust-vr v1-dmz Root
16 Untrust-Tun Tun trust-vr null Root
-------------------------------------------------------------

You can choose to change the zone binding for the untrust-vr. Executing the get
zone command shows the changed interface, zone, and VR bindings; in this case,
the untrust zone is now bound to the untrust-vr.

device-> get zone

Total of 12 zones in vsys root. 7 policy configurable zone(s)
-------------------------------------------------------------
ID Name Type Attr VR Default-IF VSYS
0 Null Null Shared untrust-vr null Root
1 Untrust Sec(L3) Shared untrust-vr ethernet3 Root
2 Trust Sec(L3) trust-vr ethernet1 Root
3 DMZ Sec(L3) trust-vr ethernet2 Root
4 Self Func trust-vr self Root
5 MGT Func trust-vr vlan1 Root
6 HA Func trust-vr null Root
10 Global Sec(L3) trust-vr null Root
11 V1-Untrust Sec(L2) trust-vr v1-untrust Root
12 V1-Trust Sec(L2) trust-vr v1-trust Root
13 V1-DMZ Sec(L2) trust-vr v1-dmz Root
16 Untrust-Tun Tun trust-vr null Root
---------------------------------------------------------------

Creating and Deleting Virtual Routers

Some security devices allow you to create custom VRs in addition to the two
predefined VRs. You can modify all aspects of a user-defined VR, including the VR
ID, the maximum number of entries allowed in the routing table, and the
preference value for routes from specific protocols.

NOTE: Only certain security devices support custom VRs. To create custom VRs, you need
a software license key.

Creating and Modifying Virtual Routers  25

 Concepts & Examples ScreenOS Reference Guide

Creating a Custom Virtual Router

In this example, you create a custom VR called trust2-vr and you enable automatic
route exporting from the trust2-vr VR to the untrust-vr.

WebUI
Network > Routing > Virtual Routers > New: Enter the following, then click
OK:

Virtual Router Name: trust2-vr

Auto Export Route to Untrust-VR: (select)

CLI
set vrouter name trust2-vr
set vrouter trust2-vr auto-route-export
save

Deleting a Custom Virtual Router

In this example, you delete an existing user-defined VR named trust2-vr.

WebUI
Network > Routing > Virtual Routers: Click Remove for the trust2-vr.

When the prompt appears asking you to confirm the removal, click OK.

CLI
unset vrouter trust2-vr

When the prompt appears asking you to confirm the removal (vrouter unset,
are you sure? y/[n]), enter Y.

save

NOTE: You cannot delete the predefined untrust-vr and trust-vr VRs, but you can delete
any user-defined VR. To modify the name of a user-defined VR or change the VR
ID, you must first delete the VR and then recreate it with the new name or VR ID.

Virtual Routers and Virtual Systems

When a root-level administrator creates a vsys on virtual system-enabled systems,
the vsys automatically has the following VRs available for its use:

 Any root-level VRs that have been defined as sharable. The untrust-vr is, by
default, a shared VR that is accessible by any vsys. You can configure other
root-level VRs to be sharable.

 A vsys-level VR. When you create a vsys, a vsys-level VR is automatically

created that maintains the routing table for the Trust-vsysname zone. You can
choose to name the VR vsysname-vr or a user-defined name. A vsys-level VR
cannot be shared by other vsys.

26  Creating and Modifying Virtual Routers

 Chapter 2: Routing

NOTE: Only Juniper Networks security systems (NetScreen-5200, NetScreen-5400,

ISG 1000, and ISG 2000) support vsys. To create vsys objects, you need a software
license key.

You can define one or more custom VRs for a vsys. For more information about
virtual systems, see Volume 10: Virtual Systems. In Figure 7, each of the three vsys
has two VRs associated with it: a vsys-level VR named vsysname-vr and the
untrust-vr.

Figure 7: Virtual Routers Within a Vsys

trust-vr
untrust-vr Finance
(shared root-level
virtual router) DMZ

Mail Trust Eng

root sys vsys1-vr

Trust-vsys1

Untrust vsys1

vsys2-vr Automatically
vsys2 created when you
Trust-vsys2 create vsys
vsys3

vsys3-vr
Trust-vsys3

Creating a Virtual Router in a Vsys

In this example, you define a custom VR vr-1a with the VR ID 10.1.1.9 for the vsys
my-vsys1.

WebUI
Vsys > Configure > Enter (for my-vsys1) > Network > Routing > Virtual
Routers > New: Enter the following, then click Apply:

Virtual Router Name: vr-1a

Virtual Router ID: Custom (select)
In the text box, enter 10.1.1.9

Creating and Modifying Virtual Routers  27

 Concepts & Examples ScreenOS Reference Guide

CLI
set vsys my-vsys1
(my-vsys1) set vrouter name vr-1a
(my-vsys1/vr-1a) set router-id 10.1.1.9
(my-vsys1/vr-1a) exit
(my-vsys1) exit

Enter Y at the following prompt:

Configuration modified, save? [y]/n

The vsys-level VR that is created when you create the vsys is the default VR for a
vsys. You can change the default VR for a vsys to a custom VR. For example, you
can make the custom VR vr-1a that you created previously in this example the
default VR for the vsys my-vsys1:

WebUI
Vsys > Configure > Enter (for my-vsys1) > Network > Routing > Virtual
Routers > Edit (for vr-1a): Select Make This Vrouter Default-Vrouter for the
System, then click Apply.

CLI
set vsys my-vsys1
(my-vsys1) set vrouter vr-1a
(my-vsys1/vr-1a) set default-vrouter
(my-vsys1/vr-1a) exit
(my-vsys1) exit

Enter Y at the following prompt:

Configuration modified, save? [y]/n

The predefined Trust-vsysname security zone is bound by default to the vsys-level

VR that is created when you created the vsys. However, you can bind the predefined
Trust-vsysname security zone and any user-defined vsys-level security zone to any
VR available to the vsys.

The untrust-vr is shared by default across all vsys. While vsys-level VRs are not
sharable, you can define any root-level VR to be shared by the vsys. This allows you
to define routes in a vsys-level VR that use a shared root-level VR as the next-hop.
You can also configure route redistribution between a vsys-level VR and a shared
root-level VR.

Sharing Routes Between Virtual Routers

In this example, the root-level VR my-router contains route table entries for the
4.0.0.0/8 network. If you configure the root-level VR my-router to be shareable by
the vsys, then you can define a route in a vsys-level VR for the 4.0.0.0/8 destination
with my-router as the next-hop. In this example, the vsys is my-vsys1, and the
vsys-level VR is my-vsys1-vr.

28  Creating and Modifying Virtual Routers

 Chapter 2: Routing

WebUI
Network > Routing > Virtual Routers > New: Enter the following, then click
OK:

Virtual Router Name: my-router

Shared and accessible by other vsys (select)

Vsys > Configure > Enter (for my-vsys1) > Network > Routing > Routing
Entries > New (for my-vsys1-vr): Enter the following, then click OK:

Network Address/Netmask: 40.0.0.0 255.0.0.0

Next Hop Virtual Router Name: (select) my-router

CLI
set vrouter name my-router sharable
set vsys my-vsys1
(my-vsys1) set vrouter my-vsys1-vr route 40.0.0.0/8 vrouter my-router
(my-vsys1) exit

Enter Y at the following prompt:

Configuration modified, save? [y]/n

Limiting the Number of Routing Table Entries

Each VR is allocated the routing table entries it needs from a system-wide pool. The
maximum number of entries available depends upon the security device and the
number of VRs configured on the device. You can limit the maximum number of
routing table entries that can be allocated for a specific VR. This helps prevent one
VR from using up all the entries in the system.

NOTE: See the relevant product datasheet to determine the maximum number of routing
table entries available on your Juniper Networks security device.

In this example, you set the maximum number of routing table entries for the
trust-vr to 20.

WebUI
Network > Routing > Virtual Routers > Edit (for trust-vr): Enter the following,
then click OK:

Maximum Route Entry:

Set limit at: (select), 20

CLI
set vrouter trust-vr max-routes 20
save

Creating and Modifying Virtual Routers  29

 Concepts & Examples ScreenOS Reference Guide

Routing Features and Examples

After configuring the required VRs for your network, you can determine which
routing features you want to employ. These features affect routing behaviors and
routing table data. These features are applicable to static routing and dynamic
routing protocols.

This section explains the following topics:

 “Route Selection” on page 30

 “Configuring Equal Cost Multipath Routing” on page 35

 “Route Redistribution” on page 37

 “Exporting and Importing Routes Between Virtual Routers” on page 42

Route Selection
Multiple routes with the same prefix (IP address and mask) can exist in the routing
table. Where the routing table contains multiple routes to the same destination, the
preference values of each route are compared. The route that has the lowest
preference value is selected. If the preference values are the same, the metric values
are then compared. The route with the lowest metric value is then selected.

NOTE: If there are multiple routes to the same destination with the same preference
values and the same metric values, then any one of those routes can be selected.
In this case, selection of one specific route over another is not guaranteed or
predictable.

Setting a Route Preference

A route preference is a weight added to the route that influences the determination
of the best path for traffic to reach its destination. When importing or adding a
route to the routing table, the VR adds a preference value — determined by the
protocol by which the route is learned — to the route. A low preference value (a
number closer to 0) is preferable to a high preference value (a number further from
0).

In a VR, you can set the preference value for routes according to protocol. Table 2
lists the default preference values for routes of each protocol.

30  Routing Features and Examples

 Chapter 2: Routing

Table 2: Default Route Preference Values

Protocol Default Preference

Connected 0
Static 20
Auto-Exported 30
EBGP 40
OSPF 60
RIP 100
Imported 140
OSPF External Type 2 200
IBGP 250

You can also adjust the route preference value to direct traffic along preferred paths.

In this example, you specify a value of 4 as the preference for any “connected”
routes added to the route table for the untrust-vr.

NOTE: If the route preference changes for any type of route (for example, OSPF type 1
routes), the new preference displays in the route table but the new preference
does not take effect until the route is relearned (which can be achieved by
disabling, then enabling, the dynamic routing protocol), or, in the case of static
routes, deleted and added again.

Changing the route preference does not affect existing routes. To apply changes to
existing routes, you need to delete the routes then re-add them. For dynamic
routes, you need to disable the protocol then re-enable it or restart the device.

A route is connected when the router has an interface with an IP address in the
destination network.

WebUI
Network > Routing > Virtual Routers > Edit (for untrust-vr): Enter the
following, then click OK:

Route Preference:
Connected: 4

CLI
set vrouter untrust-vr preference connected 4
save

Route Metrics
Route metrics determine the best path a packet can take to reach a given
destination. Routers use route metrics to weigh two routes to the same destination
and determine the use of one route over the other. When there are multiple routes
to the same destination network with the same preference value, the route with the
lowest metric prevails.

Routing Features and Examples  31

 Concepts & Examples ScreenOS Reference Guide

A route metric can be based on any or a combination of the following elements:

 Number of routers a packet must traverse to reach a destination

 Relative speed and bandwidth of the path

 Dollar cost of the links making up the path

 Other factors

When routes are learned dynamically, the neighboring router from which the route
originates provides the metric. The default metric for connected routes is always 0.
The default metric for static routes is 1.

Changing the Default Route Lookup Sequence

If you enable both source-based routing and source interface-based routing in a VR,
the VR performs route lookup by checking the incoming packet against the routing
tables in a specific order. This section describes the default route lookup sequence
and how you can change the sequence by configuring preference values for each
routing table.

If an incoming packet does not match an existing session, the security device
performs First Packet Processing, a procedure that involves route lookup. Figure 8
shows the default route lookup sequence.

Figure 8: Default Route Lookup Sequence

incoming packet

SIBR Yes Route found

enabled in SIBR table

No No

SBR Yes Yes

Route found Forward packet on specified
enabled in SBR table outgoing interface or
next-hop

No

Yes
Route found
in DRT?

No

Drop packet

32  Routing Features and Examples

 Chapter 2: Routing

1. If source interface-based routing is enabled in the VR, the security device first
checks the source interface-based routing table for a route entry that matches
the interface on which the packet arrived. If the security device finds a route
entry for the source interface in the source interface-based routing table, it
forwards the packet as specified by the matching routing entry. If the security
device does not find a route entry for the source interface in the source
interface-based routing table, the device checks to see if source-based routing is
enabled in the VR.

2. If source based routing is enabled in the VR, the security device checks the
source based routing table for a route entry that matches the source IP address
of the packet. If the security device finds a matching route entry for the source
IP address, it forwards the packet as specified by the entry. If the security
device does not find a route entry for the source IP address in the source based
routing table, the device checks the destination-based routing table.

3. The security device checks the destination-based routing table for a route entry
that matches the destination IP address of the packet. If the security device
finds a matching route entry for the destination IP address, it forwards the
packet as specified by the entry. If the device does not find an exact matching
route entry for the destination IP address but a default route configured for the
VR, the device forwards the packet as specified by the default route. If the
security device does not find a route entry for the destination IP address and
there is no default route configured for the VR, the packet is dropped.

The order in which the security device checks routing tables for a matching route is
determined by a preference value assigned to each routing table. The routing table
with the highest preference value is checked first while the routing table with the
lowest preference value is checked last. By default, the source interface-based
routing table has the highest preference value (3), the source based routing table
has the next-highest preference value (2), and the destination-based routing table
has the lowest preference value (1).

You can reassign new preference values to a routing table to change the order in
which the security device performs route lookup in a VR. Remember that the device
checks routing tables from the highest to lowest preference values.

In the following example, you enable both SIBR and source-based routing in the
trust-vr. You want the security device to perform route lookups in the routing tables
in the following order: source-based routing first, SIBR, and then destination-based
routing. To configure this sequence of route table lookup, you need to configure
source-based routing with a higher preference value than SIBR — in this example,
you assign a preference value of 4 to source-based routing.

WebUI
Network > Routing > Virtual Router > Edit (for trust-vr): Enter the following,
then click OK:

Route Lookup Preference (1-255): (select)

For Source Based Routing: 4
Enable Source Based Routing: (select)
Enable Source Interface Based Routing: (select)

Routing Features and Examples  33

 Concepts & Examples ScreenOS Reference Guide

CLI
set vrouter trust-vr sibr-routing enable
set vrouter trust-vr source-routing enable
set vrouter trust-vr route-lookup preference source-routing 4
save

Route Lookup in Multiple Virtual Routers

You can specify another VR as the next-hop for a destination-based route entry only
and not for a source-based or source interface-based route entry. For example, the
default route in the destination-based routing table can specify the untrust-vr as the
next-hop; then the untrust-vr entry can specify another VR, such as a DMZ. The
device will check up to a total of three VRs. Where route lookup in one VR results in
a route lookup in another VR, the security device always performs a second route
lookup in the destination-based route table.

In the example, you enable source-based routing in both the trust-vr and untrust-vr
routing tables. The trust-vr has the following routing entries:

 A source-based routing entry for the subnetwork 10.1.1.0/24, with ethernet3 as

the forwarding interface, and the router at 1.1.1.1 as the next-hop

 A default route, with the untrust-vr as the next-hop.

The untrust-vr has the following routing entries:

 A source-based routing entry for the subnetwork 10.1.2.0/24, with ethernet4 as

the forwarding interface, and the router at 2.2.2.2 as the next-hop

 A default route, with ethernet3 as the forwarding interface and the router at
1.1.1.1 as the next-hop

Figure 9 shows how traffic from the subnetwork 10.1.2.0/24 will always be
forwarded on ethernet3 to the router at 1.1.1.1.

Figure 9: Route Lookup in Multiple VRs

ISP 1
10.1.1.0/24 1.1.1.1
ethernet1 ethernet3

ethernet2 ethernet4
ISP 2
10.1.2.0/24 2.2.2.2

The source-based routing table for the trust-vr includes the following entry:

ID IP-Prefix Interface Gateway P Pref Mtr Vsys

* 1 10.1.1.0/24 eth3 2.2.2.250 S 20 1 Root

34  Routing Features and Examples

 Chapter 2: Routing

The destination-based routing table for the untrust-vr includes the following entry:

ID IP-Prefix Interface Gateway P Pref Mtr Vsys

* 1 0.0.0.0/24 n/a untrust-vr S 20 0 Root

Traffic from 10.1.2.0/24 subnetwork arrives on the security device on ethernet2.

Because there is no matching source-based route entry, the security device
performs route lookup in the destination-based routing table. The default route in
the destination-based routing table specifies the untrust-vr as the next-hop.

Next, the security device does not check the source-based routing table for the
untrust-vr to find the following entry:

ID IP-Prefix Interface Gateway P Pref Mtr Vsys

* 1 10.1.2.0/24 eth4 2.2.2.250 S 20 1 Root

Instead, the security device checks the destination-based Routing Table and finds
the following entry:

ID IP-Prefix Interface Gateway P Pref Mtr Vsys

* 1 0.0.0.0/24 eth3 1.1.1.150 S 20 0 Root

In the untrust-vr, the security device performs route lookup in the destination-based
routing table only, even though the source-based routing table in the untrust-vr
contains an entry that would match the traffic. The matching route in the
destination-based routing table (the default route) forwards the traffic out on the
ethernet3 interface.

Configuring Equal Cost Multipath Routing

Juniper Networks security devices support equal cost multipath (ECMP) routing on a
per-session basis. Routes of equal cost have the same preference and metric values.
Once a security device associates a session with a route, the security device uses
that route until a better route is learned or the current route becomes unusable. The
eligible routes must have outgoing interfaces that belong to the same zone.

NOTE: If the outgoing interfaces do not belong to the same zone and the return packet
goes to a zone other than the intended one, a session match cannot occur and the
traffic may not go through.

NOTE: When ECMP is enabled and the outgoing interfaces are different and in NAT
mode, applications, such as HTTP, that create multiple sessions will not work
correctly. Applications, such as telnet or SSH, that create one session should work
correctly.

ECMP assists with load-balancing among two to four routes to the same destination
or increases the effective bandwidth usage among two or more destinations. When
ECMP is enabled, security devices use the statically defined routes or dynamically
learn multiple routes to the same destination through a routing protocol. The
security device assigns routes of equal cost in rotating (round-robin) fashion.

Routing Features and Examples  35

 Concepts & Examples ScreenOS Reference Guide

Without ECMP, the security device only uses the first learned or defined route.
Other routes that are of equal cost remain unused until the currently active route is
no longer active.

NOTE: When using ECMP, if you have two security devices in a neighbor relationship and
you notice packet loss and improper load-balancing, check the Address Resolution
Protocol (ARP) configuration of the neighbor device to make sure the arp
always-on-dest feature is disabled (default). For more information about
ARP-related commands, see “Down Interfaces and Traffic Flow” on page 2-74.

For example, consider the following two routes that appear in the trust-vr
destination-based routing table:

ID IP-Prefix Interface Gateway P Pref Mtr Vsys

* 8 0.0.0.0/0 ethernet3 1.1.1.250 C 0 1 Root

9 0.0.0.0/0 ethernet2 2.2.2.250 S 20 1 Root

In this example, two default routes exist to provide connections to two different
ISPs, and the goal is to use both default routes with ECMP.

The two routes have the same metric values; however, the first route is a connected
route (C with a preference of 0). The security device acquired the first route through
DHCP or PPP, and the device acquired the default route through manual
configuration. The second route is a manually configured static route (S with an
automatic preference of 20). With ECMP disabled, the security device forwards all
traffic to the connected route on ethernet3.

To achieve load-balancing with both routes, you change the route preference of the
static route to zero (0) to match the connected route by entering the set vrouter
trust-vr preference static 0 command and then enabling ECMP. With ECMP
enabled, the security device load-balances the traffic by alternating between the
two eligible ECMP routes. The following display shows the updated routing table.

ID IP-Prefix Interface Gateway P Pref Mtr Vsys

* 8 0.0.0.0/0 ethernet3 1.1.1.250 C 0 1 Root

* 9 0.0.0.0/0 ethernet2 2.2.2.250 S 0 1 Root

If you enable ECMP, and the security device finds more than one matching route of
the same cost in a routing table, the device selects a different equal-cost route for
each route lookup. With the routes shown above, the security device alternates
between ethernet3 and ethernet2 to forward traffic to the 0.0.0.0/0 network.

If more than two equal-cost routes to the network exist, the security device selects
from the routes in round-robin order up to the configured maximum so that the
device selects a different ECMP route for each route lookup.

ECMP is disabled by default (the maximum number of routes is 1). To enable ECMP
routing, you need to specify the maximum number of equal-cost routes on a
per-virtual router basis. You can specify up to four routes. Once you set the
maximum number of routes, the security device will not add or change routes even
if more routes are learned.

36  Routing Features and Examples

 Chapter 2: Routing

In the following example, you set the maximum number of ECMP routes in the
trust-vr to 2. Even though 3 or 4 routes of equal cost might exist within the same
zone and in the routing table, the security device only alternates between the
configured number of eligible routes. In this case, data only forwards along the 2
specified ECMP paths.

WebUI
Network > Routing > Virtual Routers > Edit (for trust-vr): Enter the following,
then click OK:

Maximum ECMP Routes:

Set Limit at: (select), 2

CLI
set vrouter trust-vr max-ecmp-routes 2
save

Route Redistribution
The routing table in a VR contains routes gathered by all dynamic routing protocols
running in the VR, as well as static routes and directly connected routes. By default,
a dynamic routing protocol (such as OSPF, RIP, or BGP) advertises to its neighbors
or peers only the routes that meet the following conditions:

 The routes must be active in the routing table.

 The routes must be learned by the dynamic routing protocol.

NOTE: OSPF, RIP, and BGP also advertise connected routes for the ScreenOS interfaces on
which these protocols are enabled.

To allow a dynamic routing protocol to advertise routes that were learned by

another protocol, including statically configured routes, you need to redistribute
routes from the source protocol into the advertising protocol.

You can redistribute routes learned from a routing protocol (including statically
configured routes) into a different routing protocol in the same VR. This allows the
receiving routing protocol to advertise the redistributed routes. When importing a
route, the current domain has to translate all the information, particularly known
routes, from the other protocol to its own protocol. For example, if a routing domain
uses OSPF and it connects to a routing domain using BGP, the OSPF domain has to
import all the routes from the BGP domain to inform all of its OSPF neighbors about
how to reach devices in the BGP domain.

Routes are redistributed between protocols according to a redistribution rule defined

by the system or network administrator. When a route is added to a routing table in
a VR, all redistribution rules defined in the VR are applied one-by-one to the route to
determine whether the route is to be redistributed. When a route is deleted from a
routing table, all redistribution rules defined in the VR are applied one-by-one to the
route to determine whether the route is to be deleted from another routing protocol
within the VR. Note that all redistribution rules are applied to the added or deleted
route. There is no concept of rule order or “first matching rule” for redistribution
rules.

Routing Features and Examples  37

 Concepts & Examples ScreenOS Reference Guide

NOTE: You can only define one redistribution rule between any two protocols.

On the security device, you configure a route map to specify which routes are to be
redistributed and the attributes of the redistributed routes.

Configuring a Route Map

A route map consists of a set of statements applied in sequential order to a route.
Each statement in the route map defines a condition that is compared to the route.
A route is compared to each statement in a specified route map in order of
increasing sequence number until there is a match, then the action specified by the
statement is applied. If the route matches the condition in the route map statement,
the route is either permitted or rejected. A route map statement can also modify
certain attributes of a matching route. There is an implicit deny at the end of every
route map; that is, if a route does not match any entry in the route map, the route is
rejected. Table 3 lists route map match conditions and gives a description of each.

Table 3: Route Map Match Conditions

Match Condition Description

BGP AS Path Matches a specified AS path access list. See “Route Filtering” on page 39.
BGP Community Matches a specified community list. See “Route Filtering” on page 39.
OSPF route type Matches OSPF internal, external type 1, or external type 2.
Interface Matches a specified interface.
IP address Matches a specified access list. See “Route Filtering” on page 39.
Metric Matches a specified route metric value.
Next-hop Matches a specified access list. See “Route Filtering” on page 39.
Tag Matches a specified route tag value or IP address.

For each match condition, you specify whether a route that matches the condition
is accepted (permitted) or rejected (denied). If a route matches a condition and is
permitted, you can optionally set attribute values for the route. Table 4 lists route
map attributes and descriptions of each.

38  Routing Features and Examples

 Chapter 2: Routing

Table 4: Route Map Attributes

Set Attributes Description

BGP AS Path Prepends a specified AS path access list to the path list attribute of the
matching route.
BGP Community Sets the community attribute of the matching route to the specified
community list.
BGP local preference Sets the local-pref attribute of the matching route to the specified value.
BGP weight Sets the weight of the matching route.
Offset metric Increments the metric of the matching route by the specified number.
This increases the metric on a less desirable path. For RIP routes, you
can apply the increment to either routes advertised (route-map out) or
routes learned (route-map in). For other routes, you can apply the
increment to routes that are exported into another VR.
OSPF metric type Sets the OSPF metric type of the matching route to either external type
1 or external type 2.
Metric Sets the metric of the matching route to the specified value.
Next-hop of route Sets the next-hop of the matching route to the specified IP address.
Preserve metric Preserves the metric of a matching route that is exported into another
VR.
Preserve preference Preserves the preference value of the matching route that is exported
into another VR.
Tag Sets the tag of the matching route to the specified tag value or IP
address.

Route Filtering
Route filtering allows you to control which routes to permit into a VR, which routes
to advertise to peers, and which routes to redistribute from one routing protocol to
another. You can apply filters to incoming routes sent by a routing peer or to
outgoing routes sent by the security VR to peer routers. You can use the following
filtering mechanisms:

 Access list—See ”Configuring an Access List” for information about configuring

an access list.

 BGP AS-path access list—An AS-path attribute is a list of autonomous systems

through which a route advertisement has passed and which is part of the route
information. An AS-path access list is a set of regular expressions that represent
specific ASs. You can use an AS-path access list to filter routes based on the AS
through which the route has traversed. See “Configuring an AS-Path Access List”
on page 114 for information about configuring an AS-path access list.

 BGP community list—A community attribute contains identifiers for the

communities to which a BGP route belongs. A BGP community list is a set of
BGP communities that you can use to filter routes based on the communities to
which a route belongs. See “BGP Communities” on page 122 for information
about configuring a BGP community list.

Routing Features and Examples  39

 Concepts & Examples ScreenOS Reference Guide

Configuring an Access List

An access list is a sequential list of statements against which a route is compared.
Each statement specifies the IP address/netmask of a network prefix and the
forwarding status (permit or deny the route). For example, a statement in an access
list can allow routes for the 1.1.1.0/24 subnet. Another statement in the same
access list can deny routes for the 2.2.2.0/24 subnet. If a route matches a statement
in the access list, the specified forwarding status is applied.

The sequence of statements in an access list is important because a route is

compared to the first statement in the access list and then to subsequent
statements until there is a match. If there is a match, all subsequent statements in
the access list are ignored. You should sequence the more specific statements
before less specific statements. For example, place the statement that denies routes
for the 1.1.1.1/30 subnet before the statement that permits routes for the
1.1.1.0/24 subnet.

You can also use access lists to control the flow of multicast traffic. For information,
see “Access Lists” on page 149.

In this example, you create an access list on the trust-vr. The access list has the
following characteristics:

 Identifier: 2 (you must specify an access list identifier when configuring the
access list)

 Forwarding Status: permit

 IP Address/Netmask Filtering: 1.1.1.1/24

 Sequence Number: 10 (positions this statement relative to other statements in

the access list)

WebUI
Network > Routing > Virtual Routers > Access List: > New (for trust-vr):
Enter the following, then click OK:

Access List ID: 2

Sequence No: 10
IP/Netmask: 1.1.1.1/24
Action: Permit

CLI
set vrouter trust-vr access-list 2 permit ip 1.1.1.1/24 10
save

Redistributing Routes into OSPF

In this example, you redistribute specified BGP routes that have passed through the
autonomous system 65000 into OSPF. You first configure an AS-path access list that
allows routes that have passed through AS 65000. (For more information about
configuring an AS-path access list, see “Configuring an AS-Path Access List” on
page 114.) Next, you configure a route map “rtmap1” to match routes in the AS
path access list. Finally, in OSPF, you specify a redistribution rule that uses the route
map “rtmap1” and then specifies BGP as the source protocol for the routes.

40  Routing Features and Examples

 Chapter 2: Routing

WebUI
1. BGP AS-Path Access List
Network > Routing > Virtual Routers > Edit (for trust-vr) > Edit BGP Instance
> AS Path: Enter the following, then click Add:

AS Path Access List ID: 1

Permit: (select)
AS Path String: _65000_
2. Route Map
Network > Routing > Virtual Routers > Route Map > New (for trust-vr): Enter
the following, then click OK:

Map Name: rtmap1

Sequence No.: 10
Action: permit (select)
Match Properties:
AS Path: (select), 1
3. Redistribution Rule
Network > Routing > Virtual Router > Edit (for trust-vr) > Edit OSPF Instance
> Redistributable Rules: Select the following, then click Add:

Route Map: rtmap1

Protocol: BGP

CLI
1. BGP AS-Path Access List
set vrouter trust-vr protocol bgp as-path-access-list 1 permit _65000_
2. Route Map
set vrouter trust-vr
device(trust-vr)-> set route-map name rtmap1 permit 10
device(trust-vr/rtmap1-10)-> set match as-path 1
device(trust-vr/rtmap1-10)-> exit
device(trust-vr)-> exit
3. Redistribution Rule
set vrouter trust-vr protocol ospf redistribute route-map rtmap1 protocol bgp
save

Routing Features and Examples  41

 Concepts & Examples ScreenOS Reference Guide

Exporting and Importing Routes Between Virtual Routers

If you have two VRs configured on a security device, you can allow specified routes
in one VR to be learned by the other VR. To do this, you must define export rules on
the source VR that will export routes to the destination VR. When exporting routes,
a VR allows other VRs to learn about its network. On the destination VR, you can
optionally configure import rules to control the routes that are allowed to be
imported from the source VR. If there are no import rules on the destination VR, all
exported routes are accepted.

To export and import routes between VRs:

1. On the source VR, define an export rule.

2. (Optional) On the destination VR, define an import rule. While this step is
optional, an import rule allows you to further control the routes that the
destination VR accepts from the source VR.

On the security device, you configure an export or import rule by specifying the
following:

 The destination VR (for export rules) or source VR (for import rules)

 The protocol of the routes to be exported/imported

 Which routes are to be exported/imported

 (Optional) New or modified attributes of the exported/imported routes

Configuring an export or import rule is similar to configuring a redistribution rule.

You configure a route map to specify which routes are to be exported/imported and
the attributes of the routes.

You can configure the trust-vr to automatically export all its route table entries to
the untrust-vr. You can also configure a user-defined VR to automatically export
routes to other VRs. Routes in networks directly connected to interfaces in NAT
mode cannot be exported.

Configuring an Export Rule

In this example, OSPF routes for the 1.1.1.1/24 network in the trust-vr are exported
to the untrust-vr routing domain. You first create an access list for the network
prefix 1.1.1.1/24, which is then used in the route map “rtmap1” to filter for
matches of routes for the 1.1.1.1/24 network. You then create a route export rule to
export matching OSPF routes from the trust-vr to the untrust-vr.

42  Routing Features and Examples

 Chapter 2: Routing

WebUI
trust-vr
1. Access List
Network > Routing > Virtual Routers > Access List: > New (for trust-vr):
Enter the following, then click OK:

Access List ID: 2

Sequence No: 10
IP/Netmask: 1.1.1.1/24
Action: Permit
2. Route Map
Network > Routing > Virtual Routers > Route Map > New (for trust-vr): Enter
the following, then click OK:

Map Name: rtmap1

Sequence No.: 10
Action: permit (select)
Match Properties:
Access List: (select), 2
3. Export Rule
Network > Routing > Virtual Routers > Export Rules > New (for trust-vr):
Enter the following, then click OK:

Destination Virtual Router: untrust-vr

Route Map: rtmap1
Protocol: OSPF

CLI
trust-vr
1. Access List
set vrouter trust-vr
device(trust-vr)-> set access-list 2 permit ip 1.1.1.1/24 10
2. Route Map
device(trust-vr)-> set route-map name rtmap1 permit 10
device(trust-vr/rtmap1-10)-> set match ip 2
device(trust-vr/rtmap1-10)-> exit
3. Export Rule
device(trust-vr)-> set export-to vrouter untrust-vr route-map rtmap1 protocol
ospf
device(trust-vr)-> exit
save

Configuring Automatic Export

You can configure the trust-vr to automatically export all of its routes to the
untrust-vr.

CAUTION: This feature can override the isolation between the trust-vr and
untrust-vr by making all trusted routes visible in the untrusted network.

Routing Features and Examples  43

 Concepts & Examples ScreenOS Reference Guide

If you define import rules for the untrust-vr, only routes that match the import rules
are imported. In this example, the trust-vr automatically exports all routes to the
untrust-vr, but an import rule on the untrust-vr allows only internal OSPF routes to
be exported.

WebUI
trust-vr
Network > Routing > Virtual Router > Edit (for trust-vr): Select Auto Export
Route to Untrust-VR, then click OK.

untrust-vr
Network > Routing > Virtual Router > Route Map (for untrust-vr) > New:
Enter the following, then click OK:

Map Name: from-ospf-trust

Sequence No.: 10
Action: permit (select)
Route Type: internal-ospf (select)

CLI
trust-vr
set vrouter trust-vr auto-route-export
untrust-vr
set vrouter untrust-vr
device(untrust-vr)-> set route-map name from-ospf-trust permit 10
device(untrust-vr/from-ospf-trust-10)-> set match route-type internal-ospf
device(untrust-vr/from-ospf-trust-10)-> exit
device(untrust-vr)-> set import-from vrouter trust-vr route-map from-ospf-trust
protocol ospf
device(untrust-vr)-> exit
save

44  Routing Features and Examples

Chapter 3
Open Shortest Path First

This chapter describes the Open Shortest Path First (OSPF) routing protocol on
security devices. It contains the following sections:

 “Overview” on page 46

 “Areas” on page 46

 “Router Classification” on page 47

 “Hello Protocol” on page 47

 “Network Types” on page 48

 “Link-State Advertisements” on page 49

 “Basic OSPF Configuration” on page 49

 “Creating and Removing an OSPF Routing Instance” on page 50

 “Creating and Deleting an OSPF Area” on page 51

 “Assigning Interfaces to an OSPF Area” on page 53

 “Enabling OSPF on Interfaces” on page 54

 “Verifying the Configuration” on page 55

 “Redistributing Routes into Routing Protocols” on page 56

 “Summarizing Redistributed Routes” on page 57

 “Global OSPF Parameters” on page 58

 “Advertising the Default Route” on page 59

 “Virtual Links” on page 59

 “Setting OSPF Interface Parameters” on page 62

 45
 Concepts & Examples ScreenOS Reference Guide

 “Security Configuration” on page 64

 “Authenticating Neighbors” on page 64

 “Configuring an OSPF Neighbor List” on page 65

 “Rejecting Default Routes” on page 66

 “Protecting Against Flooding” on page 66

 “Creating an OSPF Demand Circuit on a Tunnel Interface” on page 67

 “Point-to-Multipoint Tunnel Interface” on page 68

 “Setting the OSPF Link-Type” on page 68

 “Disabling the Route-Deny Restriction” on page 69

 “Creating a Point-to-Multipoint Network” on page 69

Overview
The Open Shortest Path First (OSPF) routing protocol is an Interior Gateway
Protocol (IGP) intended to operate within a single Autonomous System (AS). A
router running OSPF distributes its state information (such as usable interfaces and
neighbor reachability) by periodically flooding link-state advertisements (LSAs)
throughout the AS.

Each OSPF router uses LSAs from neighboring routers to maintain a link-state
database. The link-state database is a listing of topology and state information for
the surrounding networks. The constant distribution of LSAs throughout the routing
domain enables all routers in an AS to maintain identical link-state databases.

OSPF uses the link-state database to determine the best path to any network within
the AS. This is done by generating a shortest-path tree, which is a graphical
representation of the shortest path to any network within the AS. While all routers
have the same link state database, they all have unique shortest-path trees because
routers always generate the tree with themselves at the top of the tree.

Areas
By default, all routers are grouped into a single “backbone” area called area 0
(usually denoted as area 0.0.0.0). However, large geographically dispersed networks
are typically segmented into multiple areas. As networks grow, link-state databases
grow and dividing the link-state database into smaller groups allows for better
scalability.

Areas reduce the amount of routing information passed throughout the network
because a router only maintains a link-state database for the area in which it
resides. No link-state information is maintained for networks or routers outside the
area. A router connected to multiple areas maintains a link-state database for each
area to which it is connected. Areas must be directly connected to area 0 except
when creating a virtual link. For more information about virtual links, see “Virtual
Links” on page 59.

46  Overview
 Chapter 3: Open Shortest Path First

AS external advertisements describe routes to destinations in other ASs and are

flooded throughout an AS. Certain OSPF areas can be configured as stub areas; AS
external advertisements are not flooded into these areas. There are two common
types of areas used in OSPF:

 Stub area - An area that receives route summaries from the backbone area but
does not receive link-state advertisements from other areas for routes learned
through non-OSPF sources (BGP, for example). A stub area can be considered a
totally stubby area if no summary routes are allowed in the stub area.

 Not So Stubby Area (NSSA) - Like a normal stub area, NSSAs cannot receive
routes from non-OSPF sources outside the current area. However, external
routes learned within the area can be learned and passed to other areas.

Router Classification
Routers that participate in OSPF routing are classified according to their function or
location in the network:

 Internal Router - A router with all interfaces belonging to the same area.

 Backbone Router - A router that has an interface in the backbone area.

 Area Border Router - A router that attaches to multiple areas is called an area
border router (ABR). An ABR summarizes routes from non-backbone areas for
distribution to the backbone area. On security devices running OSPF, the
backbone area is created by default. If you create a second area in a virtual
router, the device functions as an ABR.

 AS Boundary Router - When an OSPF area borders another AS, the router
between the two autonomous systems is called an autonomous system
boundary router (ASBR). An ASBR is responsible for advertising external AS
routing information throughout an AS.

Hello Protocol
Two routers with interfaces on the same subnet are considered neighbors. Routers
use the Hello protocol to establish and maintain these neighbor relationships. When
two routers establish bidirectional communication, they are said to have established
an adjacency. If two routers do not establish an adjacency, they cannot exchange
routing information.

In cases were there are multiple routers on a network, it is necessary to establish

one router as the designated router (DR) and another as the backup designated router
(BDR). The DR is responsible for flooding the network with LSAs that contain a list
of all OSPF-enabled routers attached to the network. The DR is the only router that
can form adjacencies with other routers on the network. Therefore, the DR is the
only router on a network that can provide routing information to other routers. The
BDR is responsible for becoming the designated router if the DR should fail.

Overview  47
 Concepts & Examples ScreenOS Reference Guide

Network Types
Juniper Networks security devices support the following OSPF network types:

 Broadcast Networks

 Point-to-Point Networks

 Point-to-Multipoint Networks

Broadcast Networks
A broadcast network is a network that connects many routers together and can
send, or broadcast, a single physical message to all the attached routers. Pairs of
routers on a broadcast network are assumed to be able to communicate with each
other. Ethernet is an example of a broadcast network.

On broadcast networks, the OSPF router dynamically detects its neighbor routers
by sending hello packets to the multicast address 224.0.0.5. For broadcast
networks, the Hello protocol elects a Designated Router and Backup Designated
Router for the network.

A non-broadcast network is a network that connects many routers together but

cannot broadcast messages to attached routers. On non-broadcast networks, OSPF
protocol packets that are normally multicast need to be sent to each neighboring
router. Juniper Networks security devices do not support OSPF on non-broadcast
networks.

Point-to-Point Networks
A point-to-point network typically joins two routers over a Wide Area Network
(WAN). An example of a point-to-point network is two security devices connected
by an IPSec VPN tunnel. On point-to-point networks, the OSPF router dynamically
detects neighbor routers by sending hello packets to the multicast address
224.0.0.5.

Point-to-Multipoint Networks
A point-to-multipoint network is a non-broadcast network where OSPF treats
connections between routers as point-to-point links. No election of a designated
router or LSA flooding exists for the network. A router in a point-to-multipoint
network sends hello packets to all neighbors with which it can directly
communicate.

NOTE: On security devices, OSPF point-to-multipoint configuration is only supported on

tunnel interfaces, and you must disable route-deny for proper network operation.
You cannot configure a physical Ethernet interface for point-to-multipoint
connections. For more information, see “Point-to-Multipoint Tunnel Interface” on
page 68.

48  Overview
 Chapter 3: Open Shortest Path First

Link-State Advertisements
Each OSPF router sends out LSAs that define the local state information for the
router. Additionally, there are other types of LSAs that a router can send out,
depending upon the OSPF function of the router. Table 5 lists LSA types, where each
type is flooded, and the contents of each type of LSA.

Table 5: LSA Types and Content Summary

Flooded
LSA Type Sent By Throughout Information Sent in LSA
Router LSA All OSPF routers Area Describes the state of all router interfaces throughout the
area.
Network LSA Designated Router on broadcast Area Contains a list of all routers connected to the network.
and NBMA networks
Summary Area Border Routers Area Describes a route to a destination outside the area but still
LSA inside the AS. There are two types:
 Type 3 summary-LSAs describe routes to networks.
 Type 4 summary-LSAs describe routes to AS boundary
routers.
AS-External Autonomous System Boundary Autonomous Routes to networks in another AS. Often, this is the default
Router System route (0.0.0.0/0).

Basic OSPF Configuration

You create OSPF on a per-virtual router basis on a security device. If you have
multiple virtual routers (VRs) in a system, you can enable multiple instances of
OSPF, one instance for each VR.

NOTE: Before you configure a dynamic routing protocol on the security device, you
should assign a VR ID, as described in “Routing” on page 13.

This section describes the following basic steps to configure OSPF in a VR on a

security device:

1. Create and enable the OSPF routing instance in a VR. This step also
automatically creates an OSPF backbone area, with an area ID of 0.0.0.0,
which cannot be deleted.

2. (Optional) Unless all OSPF interfaces will be connected to the backbone area,
you need to define a new OSPF area with its own area ID. For example, if the
security device is to act as an ABR, you need to create a new OSPF area in
addition to the backbone area. You can configure the new area as a normal,
stub, or not-so-stubby area.

3. Assign one or more interfaces to each OSPF area. You must explicitly add
interfaces to an OSPF area, including the backbone area.

4. Enable OSPF on each interface.

5. Verify that OSPF is properly configured and operating.

Basic OSPF Configuration  49

 Concepts & Examples ScreenOS Reference Guide

In this example, you configure the security device as an ABR connecting to area 0
through the ethernet3 interface and connecting to area 10 through the ethernet1
interface. See Figure 10.

Figure 10: OSPF Configuration Example

Trust Zone ethernet1 ethernet3 Untrust Zone

Internet
10.1.1.0/24 10.1.2.0/24

Area 10
Area 0

You can optionally configure other OSPF parameters, such as the following:

 Global parameters, such as virtual links, that are set at the VR level for the OSPF
protocol (see “Global OSPF Parameters” on page 58).

 Interface parameters, such as authentication, that are set on a per-interface

basis for the OSPF protocol (see “Setting OSPF Interface Parameters” on
page 62).

 Security-related OSPF parameters that are set at either the VR level or on a

per-interface basis (see “Security Configuration” on page 64).

Creating and Removing an OSPF Routing Instance

You create and enable an OSPF routing instance on a specific VR on a security
device. To remove an OSPF routing instance you disable the OSPF instance and
then delete it. Creating the OSPF routing instance also automatically creates an
OSPF backbone area. When you create and enable an OSPF routing instance on a
VR, OSPF can transmit and receive packets on all OSPF-enabled interfaces in the
VR.

Creating an OSPF Instance

In the following example, you first assign 0.0.0.10 as the router ID for the trust-vr.
You then create an OSPF routing instance on the trust-vr. (For more information
about VRs and configuring a VR on security devices, see “Routing” on page 13.)

WebUI
1. Router ID
Network > Routing > Virtual Router (trust-vr) > Edit: Enter the following, then
click OK:

Virtual Router ID: Custom (select)

In the text box, enter 0.0.0.10
2. OSPF Routing Instance
Network > Routing > Virtual Router (trust-vr) > Edit > Create OSPF Instance:
Select OSPF Enabled, then click OK.

50  Basic OSPF Configuration

 Chapter 3: Open Shortest Path First

CLI
1. Router ID
set vrouter trust-vr router-id 10
2. OSPF Routing Instance
set vrouter trust-vr protocol ospf
set vrouter trust-vr protocol ospf enable
save

NOTE: In the CLI, you must first create the OSPF routing instance before you can enable
it. Thus, you must issue two separate CLI commands to enable an OSPF routing
instance.

Removing an OSPF Instance

In this example, you disable the OSPF routing instance in the trust-vr. OSPF stops
transmitting and processing OSPF packets on all OSPF-enabled interfaces in the
trust-vr.

WebUI
Network > Routing > Virtual Routers (trust-vr) > Edit > Edit OSPF Instance:
Uncheck OSPF Enabled, then click OK.

Network > Routing > Virtual Routers (trust-vr) > Edit > Delete OSPF
Instance, then click OK at the confirmation prompt.

CLI
unset vrouter trust-vr protocol ospf
deleting OSPF instance, are you sure? y/[n]
save

NOTE: In the CLI, you confirm the deletion of the OSPF instance.

Creating and Deleting an OSPF Area

Areas reduce the amount of routing information that needs to be passed through
the network because an OSPF router maintains a link-state database only for the
area it resides in. No link-state information is maintained for networks or routers
outside the area.

All areas must be connected to area 0, which is created when you configure an
OSPF routing instance on the virtual router. If you need to create an additional
OSPF area, you can optionally define the area as a stub area or not-so-stubby area.
See “Areas” on page 46 for more information about these types of areas.

Table 6 lists area parameters, with descriptions of each parameter, and gives the
default value for each.

Basic OSPF Configuration  51

 Concepts & Examples ScreenOS Reference Guide

Table 6: OSPF Areas Parameters and Default Values

Area Parameter Description Default Value

Metric for default route (NSSA and stub areas only) Specifies the metric for 1
the default route advertisement
Metric type for the default (NSSA area only) Specifies the external metric type 1
route (1 or 2) for the default route
No summary (NSSA and stub areas only) Specifies that summary Summary LSAs
LSAs are not advertised into the area are advertised
into the area
Range (All areas) Specifies a range of IP addresses to be —
advertised in summary LSAs and whether they are
advertised or not

Creating an OSPF Area

In the following example, you create an OSPF area with an area ID of 10.

WebUI
Network > Routing > Virtual Routers > Edit (trust-vr) > Edit OSPF Instance
> Area: Enter the following, then click OK:

Area ID: 10
Type: normal (select)
Action: Add

CLI
set vrouter trust-vr protocol ospf area 10
save

Deleting an OSPF Area

Before you can delete an OSPF area, you must disable the OSPF process for the VR.
In the following example, you stop the OSPF process and then delete an OSPF area
with an area ID of 10.

WebUI
Network > Routing > Virtual Routers (trust-vr) > Edit > Edit OSPF Instance:
Deselect OSPF Enabled, then click OK.

Network > Routing > Virtual Routers > Edit (trust-vr) > Edit OSPF Instance
> Area: Click Remove.

CLI
unset vrouter trust-vr protocol ospf enable
unset vrouter trust-vr protocol ospf area 0.0.0.10
save

52  Basic OSPF Configuration

 Chapter 3: Open Shortest Path First

Assigning Interfaces to an OSPF Area

Once an area is created, you can assign one or more interfaces to the area, using
either the WebUI or the CLI set interface command.

Assigning Interfaces to Areas

In the following example, you assign the ethernet1 interface to OSPF area 10 and
assign the ethernet3 interface to OSPF area 0.

WebUI
Network > Routing > Virtual Routers > Edit (trust-vr) > Edit OSPF Instance
> Area > Configure (Area 10): Use the Add button to move the ethernet1
interface from the Available Interface(s) column to the Selected Interfaces
column. Click OK.

Network > Routing > Virtual Routers > Edit (for trust-vr) > Edit OSPF
Instance > Area > Configure (Area 0): Use the Add button to move the
ethernet3 interface from the Available Interface(s) column to the Selected
Interfaces column. Click OK.

CLI
set interface ethernet1 protocol ospf area 10
set interface ethernet3 protocol ospf area 0
save

Configuring an Area Range

By default, an ABR does not aggregate routes sent from one area to another area.
Configuring an area range allows a group of subnets in an area to be consolidated
into a single network address to be advertised in a single summary link
advertisement to other areas. When you configure an area range, you specify
whether to advertise or withhold the defined area range in advertisements.

In the following example, you define the following area ranges for area 10:

 10.1.1.0/24 to be advertised

 10.1.2.0/24 not to be advertised

WebUI
Network > Routing > Virtual Routers > Edit (for trust-vr) > Edit OSPF
Instance > Area > Configure (0.0.0.10): Enter the following in the Area Range
section, then click Add:

IP / Netmask: 10.1.1.0/24
Type: (select) Advertise

Enter the following in the Area Range section, then click Add:

IP / Netmask: 10.1.2.0/24
Type: (select) No Advertise

Basic OSPF Configuration  53

 Concepts & Examples ScreenOS Reference Guide

CLI
set vrouter trust-vr protocol ospf area 10 range 10.1.1.0/24 advertise
set vrouter trust-vr protocol ospf area 10 range 10.1.2.0/24 no-advertise
save

Enabling OSPF on Interfaces

By default, OSPF is disabled on all interfaces in the virtual router (VR). You must
explicitly enable OSPF on an interface after you assign the interface to an area.
When you disable OSPF on an interface, OSPF does not transmit or receive packets
on the specified interface, but interface configuration parameters are preserved.

NOTE: If you disable the OSPF routing instance in the VR (see “Removing an OSPF
Instance” on page 51), OSPF stops transmitting and processing packets on all
OSPF-enabled interfaces in the VR.

Enabling OSPF on Interfaces

In this example, you enable the OSPF routing instance on the ethernet1 interface
(which was previously assigned to area 10) and on the ethernet3 interface (which
was previously assigned to area 0).

WebUI
Network > Interfaces > Edit (for ethernet1) > OSPF: Select Enable Protocol
OSPF, then click Apply.

Network > Interfaces > Edit (for ethernet3) > OSPF: Select Enable Protocol
OSPF, then click Apply.

CLI
set interface ethernet1 protocol ospf enable
set interface ethernet3 protocol ospf enable
save

Disabling OSPF on an Interface

In this example, you disable the OSPF routing instance only on the ethernet1
interface. Any other interfaces in the trust-vr virtual router (VR) on which you have
enabled OSPF are still able to transmit and process OSPF packets.

WebUI
Network > Interfaces > Edit (for ethernet1) > OSPF: Clear Enable Protocol
OSPF, then click Apply.

54  Basic OSPF Configuration

 Chapter 3: Open Shortest Path First

CLI
unset interface ethernet1 protocol ospf enable
save

NOTE: If you disable the OSPF routing instance in the VR, OSPF stops transmitting and
processing packets on all OSPF-enabled interfaces in the VR (see “Removing an
OSPF Instance” on page 51).

Verifying the Configuration

You can view the configuration you entered for the trust-vr by executing the
following CLI command at the prompt:

device-> get vrouter trust-vr protocol ospf config

VR: trust-vr RouterId: 10.1.1.250
----------------------------------
set protocol ospf
set enable
set area 0.0.0.10 range 10.1.1.0 255.255.255.0 advertise
set area 0.0.0.10 range 10.1.2.0 255.255.255.0 no-advertise
set interface ethernet1 protocol ospf area 0.0.0.10
set interface ethernet1 protocol ospf enable
set interface ethernet3 protocol ospf area 0.0.0.0
set interface ethernet3 protocol ospf enable

You can verify that OSPF is running on the virtual router with the get vrouter
trust-vr protocol ospf command.

device-> get vrouter trust-vr protocol ospf

VR: trust-vr RouterId: 10.1.1.250
----------------------------------
OSPF enabled
Supports only single TOS(TOS0) route
Internal Router
Automatic vlink creation is disabled
Numbers of areas is 2
Number of external LSA(s) is 0
SPF Suspend Count is 10 nodes
Hold time between SPFs is 3 second(s)
Advertising default-route lsa is off
Default-route discovered by ospf will be added to the routing table
RFC 1583 compatibility is disabled.
Hello packet flooding protection is not enabled
LSA flooding protection is not enabled
Area 0.0.0.0
Total number of interfaces is 1, Active number of interfaces is 1
SPF algorithm executed 2 times
Number of LSA(s) is 1
Area 0.0.0.10
Total number of interfaces is 1, Active number of interfaces is 1
SPF algorithm executed 2 times
Number of LSA(s) is 0

The highlighted areas show that OSPF is running and verify the active OSPF areas
and active interfaces in each OSPF area.

Basic OSPF Configuration  55

 Concepts & Examples ScreenOS Reference Guide

NOTE: We recommend that you explicitly assign a router ID rather than use the default
value. For information on setting a router ID, see “Routing” on page 13.

You can verify that OSPF is enabled on the interfaces and see the state of the
interfaces with the get vrouter trust-vr protocol ospf interface command.

device-> get vrouter trust-vr protocol ospf interface

VR: trust-vr RouterId: 10.1.1.250
----------------------------------
Interface IpAddr NetMask AreaId Status State
--------------------------------------------------------------------------------
ethernet3 2.2.2.2 255.255.255.0 0.0.0.0 enabled Designated Router
ethernet1 10.1.1.1 255.255.255.0 0.0.0.10 enabled Up

You can configure the priority of the virtual router to be elected the Designated
Router (DR) or the Backup Designated Router (BDR). In the example above, the
State column lists the priority of the virtual router.

You can verify that the OSPF routing instance on the security device has established
adjacencies with OSPF neighbors with the get vrouter trust-vr protocol ospf
neighbor command.

device-> get vrouter trust-vr protocol ospf neighbor

VR: trust-vr RouterId: 10.1.1.250
----------------------------------
Neighbor(s) on interface ethernet3 (Area 0.0.0.0)
IpAddr/If Index RouterId Priority State Options
------------------------------------------------------------------------------
2.2.2.2 2.2.2.250 1 Full E
Neighbor(s) on interface ethernet1 (Area 0.0.0.10)
IpAddr/If Index RouterId Priority State Options
------------------------------------------------------------------------------
10.1.1.1 10.1.1.252 1 Full E

In the State column in the example above, Full indicates full OSPF adjacencies with
neighbors.

Redistributing Routes into Routing Protocols

Route redistribution is the exchange of route information between routing
protocols. For example, you can redistribute the following types of routes into the
OSPF routing instance in the same virtual router:

 Routes learned from BGP or RIP

 Directly connected routes

 Imported routes

 Statically configured routes

When you configure route redistribution, you must first specify a route map to filter
the routes that are redistributed. For more information about creating route maps
for route redistribution, see “Routing” on page 13.

56  Redistributing Routes into Routing Protocols

 Chapter 3: Open Shortest Path First

In the following example, you redistribute a route that originated from a BGP
routing domain into the current OSPF routing domain. Both the CLI and WebUI
examples assume that you previously created a route map called add-bgp.

WebUI
Network > Routing > Virtual Routers > Edit (for trust-vr) > Edit OSPF
Instance > Redistributable Rules: Enter the following, then click Add:

Route Map: add-bgp

Protocol: BGP

CLI
set vrouter trust-vr protocol ospf redistribute route-map add-bgp protocol bgp
save

Summarizing Redistributed Routes

In large internetworks where thousands of network addresses can exist, some
routers might become overly congested with route information. Once you
redistribute a series of routes from an external protocol to the current OSPF routing
instance, you can bundle the routes into one generalized or summarized network
route. By summarizing multiple addresses, you enable a series of routes to be
recognized as one route, simplifying the lookup process.

An advantage to using route summarization in a large, complex network is that it

can isolate topology changes from other routers. For example, if a specific link in a
given domain is intermittently failing, the summary route would not change, so no
router external to the domain would need to repeatedly modify its routing table due
to the link failure.

In addition to creating fewer entries in the routing tables on the backbone routers,
route summarization prevents the propagation of LSAs to other areas when one of
the summarized networks goes down or comes up. You can also summarize
inter-area routes or external routes.

Sometimes a summarized route can create opportunities for loops to occur. You can
configure a route to a NULL interface to avoid loops. An example of creating a
summarized route and then an example of setting a NULL interface follows this
section.

Summarizing Redistributed Routes

In this example, you redistribute BGP routes into the current OSPF routing instance.
You then summarize the set of imported routes under the network address
2.1.1.0/24.

WebUI
Network > Routing > Virtual Routers > Edit (for trust-vr) > Edit OSPF
Instance > Redistributable Rules: Enter the following, then click Add:

Route Map: add-bgp

Protocol: BGP

Summarizing Redistributed Routes  57

 Concepts & Examples ScreenOS Reference Guide

Network > Routing > Virtual Routers > Edit (for trust-vr) > Edit OSPF
Instance > Summary Import: Enter the following, then click Add:

IP/Netmask: 2.1.1.0/24

CLI
set vrouter trust-vr protocol ospf redistribute route-map add-bgp protocol bgp
set vrouter trust-vr protocol ospf summary-import ip 2.1.1.0/24
save

Global OSPF Parameters

This section describes optional OSPF global parameters that you can configure at
the virtual router (VR) level. When you configure an OSPF parameter at the VR level,
the parameter setting affects operations on all OSPF-enabled interfaces. You can
modify global parameter settings through the OSPF routing protocol context in the
CLI or by using the WebUI.

Table 7 lists global OSPF parameters and their default values.

Table 7: Global OSPF Parameters and Default Values

OSPF Global
Parameters Description Default Value
Advertise default Specifies that an active default route (0.0.0.0/0) in the Default route is not
route VR route table is advertised into all OSPF areas. You advertised.
can also specify the metric value or whether the
route’s original metric is preserved, and the metric
type (ASE type 1 or type 2). You can also specify that
the default route is always advertised.
Reject default route Specifies that any default route learned in OSPF is Default route
not added to the route table. learned in OSPF is
added to the route
table.
Automatic virtual Specifies that the VR is to automatically create a Disabled.
link virtual link when it cannot reach the OSPF backbone.
Maximum hello Specifies the maximum number of OSPF hello 10.
packets packets that the VR can receive in a hello interval.
Maximum LSA Specifies the maximum number of OSPF LSA packets No default.
packets that the VR can receive within the specified number
of seconds.
RFC 1583 Specifies that the OSPF routing instance is OSPF version 2, as
compatibility compatible with RFC 1583, an earlier version of defined by
OSPF. RFC 2328.
Equal cost Specifies the maximum number of paths (1-4) to use Disabled (1).
multipath routing for load-balancing with destinations that have
(ECMP) multiple equal cost paths. See “Configuring Equal
Cost Multipath Routing” on page 35.
Virtual link Configures the OSPF area and router ID for the virtual No virtual link
configuration link. You can optionally configure the authentication configured.
method, hello interval, retransmit interval, transmit
delay, or neighbor dead interval for the virtual link.

58  Global OSPF Parameters

 Chapter 3: Open Shortest Path First

Advertising the Default Route

The default route, 0.0.0.0/0, matches every destination network in a routing table,
although a more specific prefix overrides the default route.

In this example, you advertise the default route of the current OSPF routing
instance.

WebUI
Network > Routing > Virtual Routers > Edit (for trust-vr) > Edit OSPF
Instance: Select Advertising Default Route Enable, then click OK.

NOTE: In the WebUI, the default metric (1) 62 must be manually entered, and the default
metric-type is ASE type 1.

CLI
set vrouter trust-vr protocol ospf advertise-default-route metric 1 metric-type 1
save

Virtual Links
Although all areas should be connected directly to the backbone, sometimes you
need to create a new area that cannot be physically connected to the backbone
area. To solve this problem, you can configure a virtual link. A virtual link provides a
remote area with a logical path to the backbone through another area.

You must configure the virtual link on the routers on both ends of the link. To
configure a virtual link on the security device, you need to define:

 The ID of the OSPF area through which the virtual link will pass. You cannot
create a virtual link that passes through the backbone area or a stub area.

 The ID of the router at the other end of the virtual link.

Table 8 lists optional parameters for virtual links.

Global OSPF Parameters  59

 Concepts & Examples ScreenOS Reference Guide

Table 8: Optional Parameters for Virtual Links

Virtual Link
Parameter Description Default Value
Authentication Specifies either clear text password or MD5 No authentication
authentication.
Dead interval Specifies the number of seconds that elapses with no 40 seconds
response from an OSPF neighbor before the neighbor is
determined to be not running.
Hello interval Specifies the number of seconds between OSPF hellos. 10 seconds
Retransmit Specifies the number of seconds that elapses before the 5 seconds
interval interface resends an LSA to a neighbor that did not
respond to the original LSA.
Transmit delay Specifies the number of seconds between transmissions 1 second
of link-state update packets sent on an interface.

Creating a Virtual Link

In the following example, you create a virtual link through OSPF area 10 from
Device-A with router ID 10.10.1.250 to Device-B with router ID 10.1.1.250. See
“Routing” on page 13 for information on how to configure router IDs on security
devices.) You also configure the virtual link for a transit delay of 10 seconds. On
each security device, you need to identify the router ID of the device at the other
end of the virtual link.

Figure 11 shows the example network setup for a virtual link.

Figure 11: Creating a Virtual Link

Area 0
Area 10 Device-B
ethernet1 ethernet2

Router ID Internet
10.1.1.250
Device-A ethernet 1
Router ID
10.1.1.250 Device-A and Device-B have a
virtual link to each other through
ethernet 2 OSPF area 10.

Area 20

NOTE: You must enable OSPF on both interfaces of each device and make sure that OSPF
is running on the interfaces in devices A and B before the virtual link becomes
active.

60  Global OSPF Parameters

 Chapter 3: Open Shortest Path First

WebUI (Device-A)
Network > Routing > Virtual Routers > Edit (for trust-vr) > Edit OSPF
Instance > Virtual Link: Enter the following, then click Add:

Area ID: 10 (select)

Router ID: 10.1.1.250

> Configure: In the Transmit Delay field, type 10, then click OK.

CLI (Device-A)
set vrouter trust-vr protocol ospf vlink area-id 10 router-id 10.1.1.250
set vrouter trust-vr protocol ospf vlink area-id 10 router-id 10.1.1.250 transit-delay
10
save

NOTE: In the CLI, you must first create the virtual link before you can configure any
optional parameters for the virtual link. Thus, in the CLI example above, you must
issue two separate commands to create and then configure the virtual link.

WebUI (Device-B)
Network > Routing > Virtual Routers > Edit (for trust-vr) > Edit OSPF
Instance > Virtual Link: Enter the following, then click Add:

Area ID: 10
Router ID: 10.10.1.250

> Configure: In the Transmit Delay field, type 10, then click OK.

CLI (Device-B)
set vrouter trust-vr protocol ospf vlink area-id 10 router-id 10.10.1.250
set vrouter trust-vr protocol ospf vlink area-id 10 router-id 10.10.1.250
transit-delay 10
save

Creating an Automatic Virtual Link

You can direct a virtual router (VR) to automatically create a virtual link for
instances when it cannot reach the network backbone. Having the VR automatically
create virtual links replaces the more time-consuming process of creating each
virtual link manually. In the following example, you configure automatic virtual link
creation.

WebUI
Network > Routing > Virtual Routers > Edit (for trust-vr) > Edit OSPF
Instance: Select Automatically Generate Virtual Links, then click OK.

CLI
set vrouter trust-vr protocol ospf auto-vlink
save

Global OSPF Parameters  61

 Concepts & Examples ScreenOS Reference Guide

Setting OSPF Interface Parameters

This section describes OSPF parameters that you configure at the interface level.
When you configure an OSPF parameter at the interface level, the parameter
setting affects the OSPF operation only on the specific interface. You can modify
interface parameter settings with interface commands in the CLI or by using the
WebUI.

Table 9 lists optional OSPF interface parameters and their default values.

Table 9: Optional OSPF Interface Parameters and Default Values

OSPF
Interface
Parameter Description Default Value
Authentication Specifies either clear text password or message No authentication used.
digest 5 (MD5) authentication to verify OSPF
communication on the interface. A clear text
password requires password string of up to 8 digits,
and an MD5 authentication password requires a
password string of up to 16 digits. The MD5
password also requires that you configure key
strings.
Cost Specifies the metric for the interface. The cost 1 for a 100MB or more
associated with an interface depends upon the link
bandwidth of the link to which the interface is 10 for a 10MB link
connected. The higher the bandwidth, the lower 100 for a 1MB link
(more desirable) the cost value.
Dead interval Specifies the number of seconds that elapses with 40 seconds.
no response from an OSPF neighbor before OSPF
determines the neighbor is not running.
Hello interval Specifies the interval, in seconds, at which OSPF 10 seconds.
sends out hello packets to the network.
Link type Specifies a tunnel interface as a point-to-point link Ethernet interfaces are
or as a point-to-multipoint link. See treated as broadcast
“Point-to-Multipoint Tunnel Interface” on page 68. interfaces.
Tunnel interfaces bound
to OSPF areas are
point-to-point by default.
Neighbor list Specifies subnets, in the form of an access list, on None (adjacencies are
which OSPF neighbors reside that are eligible to formed with all
form adjacencies. neighbors on the
interface).
Passive Specifies that the IP address of the interface is OSPF-enabled interfaces
interface advertised into the OSPF domain as an OSPF route transmit and receive
and not as an external route, but the interface does OSPF packets.
not transmit or receive OSPF packets. This option is
useful when BGP is also enabled on the interface.
Priority Specifies the priority for the virtual router to be 1.
elected the Designated Router or Backup
Designated Router. The router with the larger
priority value has the best chance (although not
guaranteed) chance of being elected.

62  Setting OSPF Interface Parameters

 Chapter 3: Open Shortest Path First

OSPF
Interface
Parameter Description Default Value
Retransmit Specifies the number of seconds that elapses before 5 seconds.
interval the interface resends an LSA to a neighbor that did
not respond to the original LSA.
Transit delay Specifies the number of seconds between 1 second.
transmissions of link-state update packets sent on
the interface.
Demand circuit (Tunnel interfaces only) Configures a tunnel Disabled.
interface as a demand circuit, per RFC 1793. See
“Creating an OSPF Demand Circuit on a Tunnel
Interface” on page 67.
Reduce flooding Specifies the reduction of LSA flooding on a demand Disabled.
circuit.
Ignore MTU Specifies that any mismatches in maximum Disabled.
transmission unit (MTU) values between the local
and remote interfaces that are found during OSPF
database negotiations are ignored. This option
should only be used when the MTU on the local
interface is lower than the MTU on the remote
interface.

NOTE: To form adjacencies, all OSPF routers in an area must use the same hello, dead,
and retransmit interval values.

In the following example, you configure the following OSPF parameters for the
ethernet1 interface:

 Increase the interval between OSPF hello messages to 15 seconds.

 Increase the interval between OSPF retransmissions to 7 seconds.

 Increase the interval between LSA transmissions to 2 seconds.

WebUI
Network > Interfaces > Edit (for ethernet1) > OSPF: Enter the following, then
click Apply:

Hello Interval: 15
Retransmit Interval: 7
Transit Delay: 2

CLI
set interface ethernet1 protocol ospf hello-interval 15
set interface ethernet1 protocol ospf retransmit-interval 7
set interface ethernet1 protocol ospf transit-delay 2
save

Setting OSPF Interface Parameters  63

 Concepts & Examples ScreenOS Reference Guide

Security Configuration
This section describes possible security problems in the OSPF routing domain and
methods of preventing attacks.

NOTE: To make OSPF more secure, you should configure all routers in the OSPF domain
to be at the same security level. Otherwise, a compromised OSPF router can bring
down the entire OSPF routing domain.

Authenticating Neighbors
An OSPF router can be easily spoofed, since LSAs are not encrypted and most
protocol analyzers provide decapsulation of OSPF packets. Authenticating OSPF
neighbors is the best way to fend off these types of attacks.

OSPF provides both simple password and MD5 authentication to validate OSPF
packets received from neighbors. All OSPF packets received on the interface that
are not authenticated are discarded. By default, there is no authentication enabled
on any OSPF interface.

MD5 authentication requires that the same key be used for both the sending and
receiving OSPF routers. You can specify more than one MD5 key on the security
device; each key is paired with a key identifier. If you configure multiple MD5 keys
on the security device, you can then select the key identifier of the key that is to be
used for authenticating communications with the neighbor router. This allows MD5
keys on pairs of routers to be changed periodically with minimal risk of packets
being dropped.

Configuring a Clear-Text Password

In this example, you set a clear-text password 12345678 for OSPF on interface
ethernet1.

WebUI
Network > Interfaces > Edit (for ethernet1) > OSPF: Enter the following, then
click Apply:

Password: (select), 12345678

CLI
set interface ethernet1 protocol ospf authentication password 12345678
save

Configuring an MD5 Password

In the following example, you set the two different MD5 keys on interface ethernet1
and select one of the keys to be the active key. Each MD5 key can be 16 characters
long. The key-id number must be between 0 and 255. The default key-id is 0 so you
do not have to specify the key-id for the first MD5 key you enter.

64  Security Configuration
 Chapter 3: Open Shortest Path First

WebUI
Network > Interfaces > Edit (for ethernet1) > OSPF: Enter the following, then
click Apply:

Authentication:
MD5 Keys: (select)
1234567890123456
9876543210987654
Key ID: 1
Preferred: (select)

CLI
set interface ethernet1 protocol ospf authentication md5 1234567890123456
set interface ethernet1 protocol ospf authentication md5 9876543210987654
key-id 1
set interface ethernet1 protocol ospf authentication md5 active-md5-key-id 1
save

Configuring an OSPF Neighbor List

Multi-access environments can allow devices, including routers, to be connected
into a network relatively easily. This can cause stability or performance issues if the
connected device is not reliable.

By default, the OSPF routing instance on a ScreenOS virtual router (VR) forms
adjacencies with all OSPF neighbors communicating on an OSPF-enabled interface.
You can limit the devices on an interface that can form adjacencies with the OSPF
routing instance by defining a list of subnets that contain eligible OSPF neighbors.
Only hosts or routers that reside in the specified subnets can form adjacencies with
the OSPF routing instance. To specify the subnets that contain eligible OSPF
neighbors, define an access list for the subnets at the VR level.

In this example, you configure an access list that permits the hosts on subnet
10.10.10.130/27. You then specify the access list to configure eligible OSPF
neighbors.

WebUI
Network > Routing > Virtual Router (trust-vr) > Access List > New: Enter the
following, then click OK:

Access List ID: 4

Sequence No.: 10
IP/Netmask: 10.10.10.130/27
Action: Permit (select)

Network > Interfaces > Edit (for ethernet1) > OSPF: Enter the following, then
click Apply:

Neighbor List: 4

CLI
set vrouter trust-vr access-list 4
set vrouter trust-vr access-list 4 permit ip 10.10.10.130/27 10
set interface ethernet1 protocol ospf neighbor-list 4
save

Security Configuration  65
 Concepts & Examples ScreenOS Reference Guide

Rejecting Default Routes

In a Route Detour Attack, a router injects a default route (0.0.0.0/0) into the routing
domain in order to detour packets to itself. The router can then either drop the
packets, causing service disruption, or it can obtain sensitive information in the
packets before forwarding them. On Juniper Networks security devices, OSPF by
default accepts any default routes that are learned in OSPF and adds the default
route to the routing table.

In the following example, you specify that a default route not be learned from OSPF.

WebUI
Network > Routing > Virtual Routers > Edit (for trust-vr) > Edit OSPF
Instance: Select the Do Not Add Default-route Learned in OSPF check box, then
click OK.

CLI
set vrouter trust-vr protocol ospf reject-default-route
save

Protecting Against Flooding

A malfunctioning or compromised router can flood its neighbors with OSPF hello
packets or with LSAs. Each router retrieves information from the LSAs sent by other
routers on the network to distill path information for the routing table. LSA flood
protection enables you to manage the number of LSAs entering the virtual router
(VR). If the VR receives too many LSAs, the router fails because of LSA flooding. An
LSA attack happens when a router generates an excessive number of LSAs in a
short period of time, thus keeping other OSPF routers in the network busy running
the SPF algorithm.

On VRs using ScreenOS, you can configure both the maximum number of hello
packets per hello interval and the maximum number of LSAs that can be received
on an OSPF interface within a certain interval. Packets that exceed a configured
threshold are dropped. By default, the OSPF hello packet threshold is 10 packets per
hello interval (the default hello interval for an OSPF interface is 10 seconds). There
is no default LSA threshold; if you do not set an LSA threshold, all LSAs are
accepted.

Configuring the Hello Threshold

In the following example, you configure a threshold of 20 packets per hello interval.
The hello interval, which is configurable on each OSPF interface, is not changed
from its default of 10 seconds.

WebUI
Network > Routing > Virtual Routers > Edit (for trust-vr) > Edit OSPF
Instance: Enter the following, then click OK:

Prevent Hello Packet Flooding Attack: On

Max Hello Packet: 20

66  Security Configuration
 Chapter 3: Open Shortest Path First

CLI
set vrouter trust-vr protocol ospf hello-threshold 20
save

Configuring the LSA Threshold

In this example, you create an OSPF LSA flood attack threshold of 10 packets per 20
seconds.

WebUI
Network > Routing > Virtual Routers > Edit (for trust-vr) > Edit OSPF
Instance: Enter the following, then click OK:

LSA Packet Threshold Time: 20

Maximum LSAs: 10

CLI
set vrouter trust-vr protocol ospf lsa-threshold 20 10
save

Enabling Reduced Flooding

You can enable the reduce flooding feature to suppress LSA flooding on
point-to-point interfaces—such as serial, tunnel, or Asynchronous Digital Subscriber
Line (ADSL)—or broadcast interfaces—such as Ethernet. In the following example,
you enable periodic LSA suppression without affecting hello packet flow for the
tunnel.1 interface.

WebUI
Network > Interfaces > Edit (for tunnel.1) > OSPF: Enter the following, then
click Apply:

Reduce Flooding: (select)

CLI
set interface tunnel.1 protocol ospf reduce-flooding
save

Creating an OSPF Demand Circuit on a Tunnel Interface

OSPF demand circuits, as defined in RFC 1793, are network segments where
connect time or usage affects the cost of using such connections. On a demand
circuit the traffic generated by OSPF needs to be limited to changes in network
topology. On Juniper Networks security devices, only point-to-point interfaces, such
as serial, tunnel, or ADSL Asynchronous Digital Subscriber Line (ADSL) interfaces,
can be demand circuits; and, for proper operation, both ends of the tunnel must be
manually configured as demand circuits.

On tunnel interfaces that are configured as demand circuits, the security device
suppresses sending OSPF hello packets and periodic refreshment of LSA flooding to
decrease overhead. After the OSPF neighbor reaches Full state (Hellos match and
router and network LSAs reflect all adjacent neighbors), the security device
suppresses periodic hello packets and LSA refreshes. The security device only floods
LSAs in which content has changed.

Creating an OSPF Demand Circuit on a Tunnel Interface  67

 Concepts & Examples ScreenOS Reference Guide

In the following example, you configure the tunnel.1 interface as a demand circuit.

NOTE: You need to configure the remote peer’s tunnel interface as a demand circuit.
However, you do not need to configure reduced LSA flooding on the remote peer.

WebUI
Network > Interfaces > Edit > OSPF: Enter the following, then click Apply:

Demand Circuit: (select)

CLI
set interface tunnel.1 protocol ospf demand-circuit
save

Point-to-Multipoint Tunnel Interface

When you bind a tunnel interface to an OSPF area on a security device, you create a
point-to-point OSPF tunnel by default. The point-to-point tunnel interface can form
an adjacency with only one OSPF router at the remote end. If the local tunnel
interface is to be bound to multiple tunnels, you must configure the local tunnel
interface as a point-to-multipoint interface and disable the route-deny feature on the
tunnel interface.

NOTE: You must configure a tunnel interface as a point-to-multipoint interface before

enabling OSPF on the interface. Once you configure the interface as a
point-to-multipoint interface, you cannot configure it as a demand circuit (see
“Creating an OSPF Demand Circuit on a Tunnel Interface” on page 67). You can,
however, configure the interface for reduced LSA flooding.

For an example of binding multiple tunnels to a tunnel interface, “Binding

Automatic Route and NHTB Table Entries” on page 5-288. The following sections
include examples for:

 Setting the link-type (see “Setting the OSPF Link-Type” on page 68)

 Setting the route-deny feature (see “Disabling the Route-Deny Restriction” on

page 69)

 Configuring a network with a point-to-multipoint tunnel interface (see “Creating

a Point-to-Multipoint Network” on page 69)

Setting the OSPF Link-Type

If you intend to form OSPF adjacencies on multiple tunnels, then you need to set
the link type as Point-to-Multipoint (p2mp).

In the following example, you set the link type of tunnel.1 to point-to-multipoint
(p2mp) to match your networking needs.

68  Point-to-Multipoint Tunnel Interface

 Chapter 3: Open Shortest Path First

WebUI
Network > Interface (Edit) > OSPF: Select Point-to-Multipoint from the Link
Type radio button list.

CLI
set interface tunnel.1 protocol ospf link-type p2mp
save

Disabling the Route-Deny Restriction

By default, the security device can potentially send and receive packets on the same
interface unless explicitly configured not to send and receive packets on the same
interface. In a point-to-multipoint scenario, you might desire this behavior. To
configure the security device to send and receive on the same interface, you must
disable the route-deny restriction. In this example, you disable the route-deny
restriction through the CLI on the point-to multipoint tunnel interface tunnel.1.

WebUI

NOTE: You must use the CLI to set the route-deny feature.

CLI
unset interface tunnel.1 route-deny
save

Creating a Point-to-Multipoint Network

Figure 12 shows a medium-sized enterprise that has a central office (CO) in San
Francisco and remote sites in Chicago, Los Angeles, Montreal, and New York. Each
office has a single security device.

The following are the configuration requirements particular to the security device in
the CO:

1. Configure the VR to run an instance of OSPF, enable OSPF, and then configure
the tunnel.1 interface.

2. Configure the four VPNs and bind them to the tunnel.1 interface.

The following are the configuration requirements particular to the remote security
devices:

1. Configure the VR to run an instance of OSPF and enable OSPF and then
configure the tunnel.1 interface.

2. Configure the VPN and bind it to tunnel.1 interface.

Timer values for all of the devices must match for adjacencies to form. Figure 12
shows the described network scenario.

Point-to-Multipoint Tunnel Interface  69

 Concepts & Examples ScreenOS Reference Guide

Figure 12: Point-to-MultiPoint Network Example

Los Angeles Montreal

tunnel.1 10.0.0.3 tunnel.1 10.0.0.4

untrust 3.3.3.3 untrust 4.4.4.4

New York Chicago

tunnel.1 10.0.0.2 tunnel.1 10.0.0.5

Untrust 2.2.2.2 Untrust 5.5.5.5

VPN 2 VPN 3

Internet
VPN 1 VPN 4

San Francisco (CO)

ethernet3 1.1.1.1
tunnel.1 10.0.0.1
4 VPNs bound to tunnel.1

In Figure 12, four VPNs originate from the San Francisco security device and radiate
out to remote offices in New York, Los Angeles, Montreal, and Chicago.

In this example, you configure the following settings on the CO security device:

1. Security Zone and Interfaces

2. VPN

3. Routes and OSPF

To complete the network configuration, you configure the following settings on

each of the four remote office security devices:

1. Interface and OSPF

2. VPN

3. Policy

NOTE: The WebUI procedures are abbreviated due to the length of the example. The CLI
portion of the example is complete. You can refer ahead to the CLI portion for the
exact settings and values to use.

70  Point-to-Multipoint Tunnel Interface

 Chapter 3: Open Shortest Path First

WebUI (Central Office Device)

1. Security Zone and Interfaces
Network > Interfaces > Click New Tunnel IF and continue to the Configuration
page.

Network > Interfaces > Edit (for ethernet3) and configure IP address and
zone.

Network > Interface > Edit (for tunnel.1) > OSPF: Select Point-to-Multipoint
from the Link Type radio button list.

2. VPN
VPNs > AutoKey Advanced > Gateway

3. Routes and OSPF

Network > Routing > Virtual Routers > Click Edit for the virtual router and
configure OSPF parameters.

CLI (Central Office Device)

1. Security Zone and Interfaces
set interface ethernet3 zone untrust
set interface ethernet3 ip 1.1.1.1/24
set interface tunnel.1 zone untrust
set interface tunnel.1 ip 10.10.10.1/24
2. VPN
set ike gateway gw1 address 2.2.2.2 main outgoing-interface ethernet3 preshare
ospfp2mp proposal pre-g2-3des-sha
set ike gateway gw2 address 3.3.3.3 main outgoing-interface ethernet3 preshare
ospfp2mp proposal pre-g2-3des-sha
set ike gateway gw3 address 4.4.4.4 main outgoing-interface ethernet3 preshare
ospfp2mp proposal pre-g2-3des-sha
set ike gateway gw4 address 5.5.5.5 main outgoing-interface ethernet3 preshare
ospfp2mp proposal pre-g2-3des-sha
set vpn vpn1 gateway gw1 no-replay tunnel idletime 0 proposal g2-esp-3des-sha
set vpn vpn1 monitor rekey
set vpn1 id 1 bind interface tunnel.1
set vpn vpn2 gateway gw2 no-replay tunnel idletime 0 proposal g2-esp-3des-sha
set vpn vpn2 monitor rekey
set vpn2 id 2 bind interface tunnel.1
set vpn vpn3 gateway gw3 no-replay tunnel idletime 0 proposal g2-esp-3des-sha
set vpn vpn3 monitor rekey
set vpn3 id 3 bind interface tunnel.1
set vpn vpn4 gateway gw4 no-replay tunnel idletime 0 proposal g2-esp-3des-sha
set vpn vpn4 monitor rekey
set vpn4 id 4 bind interface tunnel.1
3. Routes and OSPF
set vrouter trust router-id 10
set vrouter trust protocol ospf
set vrouter trust protocol ospf enable
set interface tunnel.1 protocol ospf area 0
set interface tunnel.1 protocol ospf enable
set interface tunnel.1 protocol ospf link-type p2mp
unset interface tunnel.1 route-deny
save

Point-to-Multipoint Tunnel Interface  71

 Concepts & Examples ScreenOS Reference Guide

NOTE: By default route-deny is disabled. However, if you enabled the route-deny feature
at some point, then you need to disable the feature for the proper operation of the
point-to-multipoint tunnel interface.

You can follow these steps to configure the remote office security device. Juniper
Networks security devices learn about neighbors through LSAs.

To complete the configuration shown in Figure 12 on page 70, you must repeat the
following section for each remote device and change the IP addresses, gateway
names and VPN names and set policies to match the network needs. For each
remote site, the trust and untrust zones change.

NOTE: The WebUI procedures are abbreviated due to the length of the example. The CLI
portion of the example is complete. You can refer ahead to the CLI portion for the
exact settings and values to use.

WebUI (Remote Office Device)

1. Interface and OSPF
Network > Interfaces > Click New Tunnel IF and continue to the
Configuration page.

2. VPN
VPNs > AutoKey Advanced > Gateway

3. Policy
Policies (from All zones to All zones) > Click New.

CLI (Remote Office Device)

1. Interface and OSPF
set vrouter trust protocol ospf
set vrouter trust protocol ospf enable
set interface untrust ip 2.2.2.2/24
set interface tunnel.1 zone untrust
set interface tunnel.1 ip 10.0.0.2/24
set interface tunnel.1 protocol ospf area 0
set interface tunnel.1 protocol ospf enable
2. VPN
set ike gateway gw1 address 1.1.1.1/24 main outgoing-interface untrust preshare
ospfp2mp proposal pre-g2-3des-sha
set vpn vpn1 gateway gw1 no-replay tunnel idletime 0 proposal g2-esp-3des-sha
set vpn vpn1 monitor rekey
set vpn vpn1 id 1 bind interface tunnel.1
3. Policy (configure as required)
set policy id 1 from trust to untrust any any any permit
set policy id 2 from untrust to trust any any any permit
save

You can view the new changes with the get vrouter vrouter protocol ospf config
command.

72  Point-to-Multipoint Tunnel Interface

Chapter 4
Routing Information Protocol

This chapter describes the Routing Information Protocol (RIP) version 2 on Juniper
Networks security devices. It contains the following sections:

 “Overview” on page 74

 “Basic RIP Configuration” on page 75

 “Creating and Deleting a RIP Instance” on page 75

 “Enabling and Disabling RIP on Interfaces” on page 76

 “Redistributing Routes” on page 77

 “Viewing RIP Information” on page 78

 “Viewing the RIP Database” on page 78

 “Viewing RIP Details” on page 79

 “Viewing RIP Neighbor Information” on page 80

 “Viewing RIP Details for a Specific Interface” on page 81

 “Global RIP Parameters” on page 82

 “Advertising the Default Route” on page 83

 “Configuring RIP Interface Parameters” on page 84

 “Security Configuration” on page 85

 “Authenticating Neighbors by Setting a Password” on page 85

 “Configuring Trusted Neighbors” on page 86

 “Rejecting Default Routes” on page 87

 “Protecting Against Flooding” on page 87

 73
 Concepts & Examples ScreenOS Reference Guide

 “Optional RIP Configurations” on page 89

 “Setting the RIP Version” on page 89

 “Enabling and Disabling a Prefix Summary” on page 91

 “Setting Alternate Routes” on page 92

 “Demand Circuits on Tunnel Interfaces” on page 93

 “Configuring a Static Neighbor” on page 95

 “Configuring a Point-to-Multipoint Tunnel Interface” on page 95

Overview
Routing Information Protocol (RIP) is a distance vector protocol used as an Interior
Gateway Protocol (IGP) in moderate-sized autonomous systems (AS). ScreenOS
supports RIP version 2 (RIPv2), as defined by RFC 2453. While RIPv2 supports only
simple password (plain text) authentication, the RIP implementation for ScreenOS
also supports MD5 authentication extensions, as defined in RFC 2082.

NOTE: RIP is not supported over unnumbered tunnel interfaces. All interfaces that use
RIP protocol must be numbered. Any attempt to configure and run an
unnumbered interface using RIP may lead to unpredictable routing failure.

RIP manages route information within a small, homogeneous, network such as a

corporate LAN. The longest path allowed in a RIP network is 15 hops. A metric
value of 16 indicates an invalid or unreachable destination (this value is also
referred to as “infinity” because it exceeds the 15-hop maximum allowed in RIP
networks).

RIP is not intended for large networks or networks where routes are chosen based
on real-time parameters such as measured delay, reliability, or load. RIP supports
both point-to-point networks (used with VPNs) and broadcast/multicast Ethernet
networks. RIP supports point-to-multipoint connections over tunnel interfaces with
or without a configured demand circuit. For more information about demand
circuits, see “Demand Circuits on Tunnel Interfaces” on page 93.

RIP sends out messages that contain the complete routing table to every
neighboring router every 30 seconds. These messages are normally sent as
multicasts to address 224.0.0.9 from the RIP port.

The RIP routing database contains one entry for every destination that is reachable
through the RIP routing instance. The RIP routing database includes the following
information:

 IPv4 address of a destination. Note that RIP does not distinguish between
networks and hosts.

 IP address of the first router along the route to the destination (the next hop).

 Network interface used to reach the first router.

74  Overview
 Chapter 4: Routing Information Protocol

 Metric that indicates the distance, or cost, of getting to the destination. Most
RIP implementations use a metric of 1 for each network.

 A timer that indicates the time that has elapsed since the database entry was
last updated.

Basic RIP Configuration

You create RIP on a per-virtual router basis on a security device. If you have
multiple virtual routers (VRs) within a system, you can enable multiple instances of
RIP, one instance of either version 1 or 2 for each VR. By default, Juniper Networks
security devices support RIP version 2.

NOTE: Before you configure a dynamic routing protocol on the security device, you
should assign a VR ID, as described in “Routing” on page 13.

This section describes the following basic steps to configure RIP on a security
device:

1. Create the RIP routing instance in a VR.

2. Enable the RIP instance.

3. Enable RIP on interfaces that connect to other RIP routers.

4. Redistribute routes learned from different routing protocols (such as OSPF, BGP,
or statically configured routes) into the RIP instance.

This section describes how to perform each of these tasks using either the CLI or
the WebUI.

Optionally, you can configure RIP parameters such as the following:

 Global parameters, such as timers and trusted RIP neighbors, that are set at the
VR level for RIP (see “Global RIP Parameters” on page 82)

 Interface parameters, such as neighbor authentication, that are set on a

per-interface basis for RIP (see “Configuring RIP Interface Parameters” on
page 84)

 Security-related RIP parameters, that are set at either the VR level or on a

per-interface basis (see “Security Configuration” on page 85)

Creating and Deleting a RIP Instance

You create and enable a RIP routing instance on a specific virtual router (VR) on a
security device. When you create and enable a RIP routing instance on a VR, RIP
transmits and receives packets on all RIP-enabled interfaces in the VR.

Deleting a RIP routing instance in a VR removes the corresponding RIP

configurations for all interfaces that are in the VR.

Basic RIP Configuration  75

 Concepts & Examples ScreenOS Reference Guide

For more information about VRs and configuring a VR on security devices, see
“Routing” on page 13.

Creating a RIP Instance

You create a RIP routing instance on the trust-vr and then enable RIP.

WebUI
Network > Routing > Virtual Router (trust-vr) > Edit: Enter a Virtual Router
ID and then Select Create RIP Instance.

Select Enable RIP, then click OK.

CLI
1. Router ID
set vrouter trust-vr router-id 10
2. RIP Routing Instance
set vrouter trust-vr protocol rip
set vrouter trust-vr protocol rip enable
save

NOTE: In the CLI, creating a RIP routing instance is a two-step process. You create the RIP
instance and then enable RIP.

Deleting a RIP Instance

In this example, you disable the RIP routing instance in the trust-vr. RIP stops
transmitting and processing packets on all RIP-enabled interfaces of the trust-vr.

WebUI
Network > Routing > Virtual Router (trust-vr) > Edit > Edit RIP Instance:
Deselect Enable RIP and then click OK.

Network > Routing > Virtual Router (trust-vr) > Edit > Delete RIP Instance
and then click OK at the confirmation prompt.

CLI
unset vrouter trust-vr protocol rip enable
unset vrouter trust-vr protocol rip
save

Enabling and Disabling RIP on Interfaces

By default, RIP is disabled on all interfaces in the virtual router (VR) and you must
explicitly enable it on an interface. When you disable RIP at the interface level, RIP
does not transmit or receive packets on the specified interface. Interface
configuration parameters are preserved when you disable RIP on an interface.

NOTE: If you disable the RIP routing instance in the VR (see “Deleting a RIP Instance” on
page 76), RIP stops transmitting and processing packets on all RIP-enabled
interfaces in the VR.

76  Basic RIP Configuration

 Chapter 4: Routing Information Protocol

Enabling RIP on an Interface

In this example, you enable RIP on the Trust interface.

WebUI
Network > Interface > Edit (for Trust) > RIP: Select Protocol RIP Enable, then
click Apply.

CLI
set interface trust protocol rip enable
save

Disabling RIP on an Interface

In this example, you disable RIP on the Trust interface. To completely remove the
RIP configuration enter the second CLI command before saving.

WebUI
Network > Interface (for Trust) > RIP: Clear Protocol RIP Enable, then click
Apply.

CLI
unset interface trust protocol rip enable
unset interface trust protocol rip
save

Redistributing Routes
Route redistribution is the exchange of route information between routing
protocols. For example, you can redistribute the following types of routes into the
RIP routing instance in the same virtual router (VR):

 Routes learned from BGP

 Routes learned from OSPF

 Directly connected routes

 Imported routes

 Statically configured routes

You need to configure a route map to filter the routes that are redistributed. For
more information about creating route maps for route redistribution, see “Routing”
on page 13.

Routes imported into RIP from other protocols have a default metric of 10. You can
change the default metric (see “Global RIP Parameters” on page 82).

In this example, you redistribute static routes that are in the subnetwork
20.1.0.0/16 to RIP neighbors in the trust-vr. To do this, you first create an access list
to permit addresses in the 20.1.0.0/16 subnetwork. Then, configure a route map
that permits addresses that match the access list you configured. Use the route map
to specify the redistribution of static routes into the RIP routing instance.

Basic RIP Configuration  77

 Concepts & Examples ScreenOS Reference Guide

WebUI
Network > Routing > Virtual Router (trust-vr) > Access List > New: Enter the
following, then click OK:

Access List ID: 20

Sequence No.: 1
IP/Netmask: 20.1.0.0/16
Action: Permit (select)

Network > Routing > Virtual Router (trust-vr) > Route Map > New: Enter the
following, then click OK:

Map Name: rtmap1

Sequence No.: 1
Action: Permit (select)
Match Properties:
Access List: (select), 20 (select)

Network > Routing > Virtual Router (trust-vr) > Edit > Edit RIP Instance >
Redistributable Rules: Enter the following, then click Add:

Route Map: rtmap1 (select)

Protocol: Static (select)

CLI
set vrouter trust-vr access-list 20 permit ip 20.1.0.0/16 1
set vrouter trust-vr route-map name rtmap1 permit 1
set vrouter trust-vr route-map rtmap1 1 match ip 20
set vrouter trust-vr protocol rip redistribute route-map rtmap1 protocol static
save

Viewing RIP Information

After modifying RIP parameters, you can view the following types of RIP details:

 Database, which shows routing information

 Protocol, which gives RIP and interface details for a virtual router (VR)

 Neighbor

Viewing the RIP Database

You can verify RIP routing information from the CLI. You can choose to view a
complete list of all RIP database entries or a single entry.

In this example, you view detailed information from the RIP database. You can
choose to view all database entries or limit the output to a single database entry by
appending the IP address and mask of the desired VR.

In this example, you specify the trust-vr and append the prefix and IP address
10.10.10.0/24 to view only a single table entry.

78  Viewing RIP Information

 Chapter 4: Routing Information Protocol

WebUI

NOTE: You must use the CLI to view the RIP database.

CLI
get vrouter trust-vr protocol rip database prefix 10.10.10.0/24
save

After you enter the following CLI command, you can view the RIP database entry:

device-> get vrouter trust-vr protocol rip database 10.10.10.0/24

VR: trust-vr
-------------------------------------------------------------------------
Total database entry: 3
Flags: Added in Multipath - M, RIP - R, Redistributed - I,
Default (advertised) - D, Permanent - P, Summary - S,
Unreachable - U, Hold - H
DBID Prefix Nexthop Ifp Cost Flags Source
7 10.10.10.0/24 20.20.20.1 eth1 2 MR 20.20.20.1
-------------------------------------------------------------------------

The RIP database contains the following fields:

 DBID, the database identifier for the entry

 Prefix, the IP address and prefix

 Nexthop, the address of the next hop (router)

 Ifp, the type of connection (Ethernet or tunnel)

 Cost metric assigned to indicate the distance form the source

Flags can be one or more of the following: multipath (M), RIP (R), Redistributed (I),
Advertised default (D), Permanent (P), Summary (S), Unreachable (U), or Hold (H).

In this example, the database identifier is 7, the IP address and prefix is

10.10.10.0/24, and the next hop is 20.20.20.1. It is an Ethernet connection with a
cost of 2. The flags are M and R and indicate that this route is multipath and uses
RIP.

Viewing RIP Details

You can view RIP details to verify that the RIP configuration matches your network
needs. You can limit output to only the interface summary table by appending
interface to the CLI command.

You can view complete RIP information to check a configuration or verify that saved
changes are active.

WebUI

NOTE: You must use the CLI to view the RIP details.

Viewing RIP Information  79

 Concepts & Examples ScreenOS Reference Guide

CLI
get vrouter trust-vr protocol rip

This command produces output similar to the following output:

device-> get vrouter trust-vr protocol rip

VR: trust-vr
----------------------------------------------------------------------------
State: enabled
Version: 2
Default metric for routes redistributed into RIP: 10
Maximum neighbors per interface: 16
Not validating neighbor in same subnet: disabled
RIP update transmission not scheduled
Maximum number of Alternate routes per prefix: 2
Advertising default route: disabled
Default routes learnt by RIP will not be accepted
Incoming routes filter and offset-metric: not configured
Outgoing routes filter and offset-metric: not configured
Update packet threshold is not configured
Total number of RIP interfaces created on vr(trust-vr): 1
Update| Invalid| Flush| DC Retransmit| DC Poll| Hold Down (Timers in seconds)
----------------------------------------------------------------------------
30| 180| 120| 5| 40|90
Flags: Split Horizon - S, Split Horizon with Poison Reverse - P, Passive - I
Demand Circuit - D
Interface IP-Prefix Admin State Flags NbrCnt Metric Ver-Rx/Tx
-----------------------------------------------------------------------------
tun.1 122.1.2.114/8 enabled disabled SD 1 1 v1v2/v1v

You can view RIP settings, packet details, RIP timer information, and a summarized
interface table.

Viewing RIP Neighbor Information

You can view details about RIP neighbors for a virtual router (VR). You can retrieve a
list of information about all neighbors or an entry for a specific neighbor by
appending the IP address of the desired neighbor. You can check the status of a
route and verify the connection between the neighbor and the security device from
these statistics.

In the following example you view RIP neighbor information for the trust-vr.

WebUI

NOTE: You must use the CLI to view RIP neighbor information.

80  Viewing RIP Information

 Chapter 4: Routing Information Protocol

CLI
get vrouter trust-vr protocol rip neighbors

This command produces output similar to the following output:

device-> get vrouter trust-vr protocol rip neighbors

VR: trust-vr
--------------------------------------------------------------------------------
Flags : Static - S, Demand Circuit - T, NHTB - N, Down - D, Up - U, Poll - P,
Demand Circuit Init - I
Neighbors on interface tunnel.1
--------------------------------------------------------------------------------
IpAddress Version Age Expires BadPackets BadRoutes Flags
--------------------------------------------------------------------------------
10.10.10.1 v2 - - 0 0 TSD

In addition to viewing the IP address and RIP version, you can view the following
RIP neighbor information:

 Age of the entry

 Expiration time

 Number of bad packets

 Number of bad routes

 Flags: static (S), demand circuit (T), NHTB (N), down (D), up (U), poll (P), or
demand circuit init (I)

Viewing RIP Details for a Specific Interface

You can view all pertinent RIP information for all interfaces and a summary of
neighboring router details. Optionally, you can append the IP address of a specific
neighbor to limit the output.

In the following example, you can view information about the tunnel.1 interface for
the neighbor residing at IP address 10.10.10.2.

WebUI

NOTE: You must use the CLI to view the RIP interface details.

CLI
get interface tunnel.1 protocol rip neighbor 10.10.10.2

This command produces output similar to the following output:

device-> get interface tunnel.1 protocol rip

VR: trust-vr
----------------------------------------------------------------------------
Interface: tunnel.1, IP: 10.10.10.2/8, RIP: enabled, Router: enabled
Receive version v1v2, Send Version v1v2
State: Down, Passive: No
Metric: 1, Split Horizon: enabled, Poison Reverse: disabled
Demand Circuit: configured
Incoming routes filter and offset-metric: not configured

Viewing RIP Information  81

 Concepts & Examples ScreenOS Reference Guide

Outgoing routes filter and offset-metric: not configured

Authentication: none
Current neighbor count: 1
Update not scheduled
Transmit Updates: 0 (0 triggered), Receive Updates: 0
Update packets dropped because flooding: 0
Bad packets: 0, Bad routes: 0
Flags : Static - S, Demand Circuit - T, NHTB - N, Down - D, Up - U, Poll - P
Neighbors on interface tunnel.1
----------------------------------------------------------------------------
IpAddress Version Age Expires BadPackets BadRoutes Flags
----------------------------------------------------------------------------
10.10.10.1 - - - 0 0 TSD
f

From this summary of information you can view the number of bad packets or bad
routes present, verify any overhead that RIP adds to the connection, and view
authentication settings.

Global RIP Parameters

This section describes RIP global parameters that you can configure at the virtual
router (VR) level. When you configure a RIP parameter at the VR level, the
parameter setting affects operations on all RIP-enabled interfaces. You can modify
global parameter settings through the RIP routing protocol context in the CLI or by
using the WebUI.

Table 10 lists the RIP global parameters and their default values.

Table 10: Global RIP Parameters and Default Values

Default
RIP Global Parameter Description Value(s)
Default metric Default metric value for routes imported into RIP from other protocols, such as OSPF 10
and BGP.
Update timer Specifies, in seconds, when to issue updates of RIP routes to neighbors. 30 seconds
Maximum packets per Specifies the maximum number of packets received per update. No maximum
update
Invalid timer Specifies, in seconds, when a route becomes invalid from the time a neighbor stops 180 seconds
advertising the route.
Flush timer Specifies, in seconds, when a route is removed from the time the route is 120 seconds
invalidated.
Maximum neighbors The maximum number of RIP neighbors allowed. Depends on
platform
Trusted neighbors Specifies an access list that defines RIP neighbors. If no neighbors are specified, RIP All neighbors
uses multicasting or broadcasting to detect neighbors on an interface. See are trusted
“Configuring Trusted Neighbors” on page 86.
Allow neighbors on Specifies that RIP neighbors on different subnets are allowed. Disabled
different subnet
Advertise default route Specifies whether the default route (0.0.0.0/0) is advertised. Disabled
Reject default routes Specifies whether RIP rejects a default route learned from another protocol. See Disabled
“Rejecting Default Routes” on page 87.
Incoming route map Specifies the filter for routes to be learned by RIP. None
Outgoing route map Specifies the filter for routes to be advertised by RIP. None

82  Global RIP Parameters

 Chapter 4: Routing Information Protocol

Default
RIP Global Parameter Description Value(s)
Maximum alternate Specifies the maximum number of RIP routes for the same prefix that can be added 0
routes into the RIP route database. See “Setting Alternate Routes” on page 92.
Summarize advertised Specifies advertising of a summary route that corresponds to all routes that fall None
routes within a summary range. See “Enabling and Disabling a Prefix Summary” on
page 91.
RIP protocol version Specifies the version of RIP the VR uses. You can override the version on a Version 2
per-interface basis. See “Setting the RIP Version” on page 89.
Hold-timer Prevents route flapping to the route table. You can specify a value between the 90 seconds
minimum (three times the value of the update timer) and the maximum (sum of the
update timer and the hold timer, not to exceed the value of the flush timer) values.
Retransmit timer Specifies the retransmit interval of triggered responses over a demand circuit. You 5 seconds
can set the retransmit timer and assign a retry count that matches your network 10 retries
needs.
Poll-timer Checks the remote neighbor for the demand circuit to see if that neighbor is up. You 180 seconds
can configure the poll timer in minutes and assign a retry count that matches your 0 retries
network needs. A retry count of zero (0) means to poll forever.

Advertising the Default Route

You can change the RIP configuration to include the advertisement of the default
route (a non-RIP route) and change the metric associated with the default route
present in a particular VR routing table.

By default, the default route (0.0.0.0/0) is not advertised to RIP neighbors. The
following command advertises the default route to RIP neighbors in the trust-vr VR
with a metric of 5 (you must enter a metric value). The default route must exist in
the routing table.

WebUI
Network > Routing > Virtual Router (trust-vr) > Edit > Edit RIP Instance:
Enter the following, then click OK:

Advertising Default Route: (select)

Metric: 5

CLI
set vrouter trust-vr protocol rip advertise-def-route metric number 5
save

NOTE: Refer to the ScreenOS CLI Reference Guide: IPv4 Command Descriptions for more
information about global parameters that you can configure in the RIP routing
protocol context.

Advertising the Default Route  83

 Concepts & Examples ScreenOS Reference Guide

Configuring RIP Interface Parameters

This section describes RIP parameters that you configure at the interface level.
When you configure a RIP parameter at the interface level, the parameter setting
affects the RIP operation only on the specific interface. You can modify interface
parameter settings with interface commands in the CLI or by using the WebUI.

Table 11 lists the RIP interface parameters and their default values.

Table 11: RIP Interface Parameters and Default Values

RIP Interface Parameter Description Default Value

Split-horizon Specifies whether to enable split-horizon (do not Split-horizon is enabled. Poison
advertise routes learned from an interface in updates reverse is disabled.
sent to the same interface). If split horizon is enabled
with the poison-reverse option, routes that are
learned from an interface are advertised with a
metric of 16 in updates sent to the same interface.
RIP metric Specifies the RIP metric for the interface. 1
Authentication Specifies either clear text password or MD5 No authentication used.
authentication. See “Authenticating Neighbors by
Setting a Password” on page 85.
Passive mode Specifies that the interface is to receive but not No
transmit RIP packets.
Incoming route map Specifies the filter for routes to be learned by RIP. None.
Outgoing route map Specifies the filter for routes to be advertised by RIP. None.
RIP version for sending or receiving Specifies the RIP version used for sending or Version configured for the
updates receiving updates on the interface. The version of the virtual router.
interface used for sending updates does not need to
be the same as the version for receiving updates. See
“Setting the RIP Version” on page 89.
Route summarization Specifies whether route summarization is enabled on Disabled.
the interface. See “Enabling and Disabling a Prefix
Summary” on page 91.
Demand-circuit Specifies the demand circuit on a specified tunnel None.
interface. Only when changes occur, the security
device sends update messages. See “Demand Circuits
on Tunnel Interfaces” on page 93.
Static neighbor IP Specifies the IP address of a manually assigned RIP None.
neighbor.

You can define incoming and outgoing route maps at the virtual router (VR) level or
at the interface level. A route map that you define at the interface-level takes
precedence over a route map defined at the VR-level. For example, if you define an
incoming route map at the VR level and a different incoming route map at the
interface level, the incoming route map defined at the interface level takes
precedence. For more information, see “Configuring a Route Map” on page 38.

84  Configuring RIP Interface Parameters

 Chapter 4: Routing Information Protocol

In the following example, you configure the following RIP parameters for the trust
interface:

 Set MD5 authentication, with the key 1234567898765432 and the key ID 215.

 Enable split horizon with poison reverse for the interface.

WebUI
Network > Interfaces > Edit (for Trust) > RIP: Enter the following, then click
OK:

Authentication: MD5 (select)

Key: 1234567898765432
Key ID: 215
Split Horizon: Enabled with poison reverse (select)

CLI
set interface trust protocol rip authentication md5 1234567898765432 key-id
215
set interface trust protocol rip split-horizon poison-reverse
save

Security Configuration
This section describes possible security problems in the RIP routing domain and
methods of preventing attacks.

NOTE: To make RIP more secure, you should configure all routers in the RIP domain to be
at the same security level. Otherwise, a compromised RIP router can bring down
the entire RIP routing domain.

Authenticating Neighbors by Setting a Password

A RIP router can be easily spoofed, since RIP packets are not encrypted and most
protocol analyzers provide decapsulation of RIP packets. Authenticating RIP
neighbors is the best way to fend off these types of attacks.

RIP provides both simple password and MD5 authentication to validate RIP packets
received from neighbors. All RIP packets received on the interface that are not
authenticated are discarded. By default, there is no authentication enabled on any
RIP interface.

MD5 authentication requires that the same key be used for both the sending and
receiving RIP routers. You can specify more than one MD5 key on the security
device; each key is paired with a key identifier. If you configure multiple MD5 keys
on the security device, you can then select the key identifier of the key that is to be
used for authenticating communications with the neighbor router. This allows MD5
keys on pairs of routers to be changed periodically with minimal risk of packets
being dropped.

Security Configuration  85
 Concepts & Examples ScreenOS Reference Guide

In the following example, you set the two different MD5 keys on interface ethernet1
and select one of the keys to be the active key. The default key-id is 0 so you do not
have to specify the key-id for the first MD5 key you enter.

WebUI
Network > Interfaces > Edit (for ethernet1) > RIP: Enter the following, then
click Apply:

MD5 Keys: (select)

1234567890123456 (first key field)
9876543210987654 (second key field)
Key ID: 1
Preferred: (select)

CLI
set interface ethernet1 protocol rip authentication md5 1234567890123456
set interface ethernet1 protocol rip authentication md5 9876543210987654
key-id 1
set interface ethernet1 protocol rip authentication md5 active-md5-key-id 1
save

Configuring Trusted Neighbors

Multi-access environments can allow devices, including routers, to be connected
into a network relatively easily. This can cause stability or performance issues if the
connected device is not reliable. To prevent this problem, you can use an access list
to filter the devices that are allowed to become RIP neighbors. By default, RIP
neighbors are limited to devices that are on the same subnet as the virtual router
(VR).

In this example, you configure the following global parameters for the RIP routing
instance running in the trust-vr:

 Maximum number of RIP neighbors is 1.

 The IP address of the trusted neighbor, 10.1.1.1, is specified in an access-list.

WebUI
Network > Routing > Virtual Router (trust-vr) > Access List > New: Enter the
following, then click OK:

Access List ID: 10

Sequence No.: 1
IP/Netmask: 10.1.1.1/32
Action: Permit (select)

Network > Routing > Virtual Router (trust-vr) > Edit > Edit RIP Instance:
Enter the following, then click OK:

Trusted Neighbors: (select), 10

Maximum Neighbors: 1

86  Security Configuration
 Chapter 4: Routing Information Protocol

CLI
set vrouter trust-vr
device(trust-vr)-> set access-list 10 permit ip 10.1.1.1/32 1
device(trust-vr)-> set protocol rip
device(trust-vr/rip)-> set max-neighbor-count 1
device(trust-vr/rip)-> set trusted-neighbors 10
device(trust-vr/rip)-> exit
device(trust-vr)-> exit
save

Rejecting Default Routes

In a Route Detour Attack, a router injects a default route (0.0.0.0/0) into the routing
domain in order to detour packets to itself. The router can then either drop the
packets, causing service disruption, or it can obtain sensitive information in the
packets before forwarding them. On Juniper Networks security devices, RIP by
default accepts any default routes that are learned in RIP and adds the default route
to the routing table.

In the following example, you configure the RIP routing instance running in trust-vr
to reject any default routes that are learned in RIP.

WebUI
Network > Routing > Virtual Router (trust-vr) > Edit > Edit RIP Instance:
Enter the following, then click OK:

Reject Default Route Learnt by RIP: (select)

CLI
set vrouter trust-vr protocol rip reject-default-route
save

Protecting Against Flooding

A malfunctioning or compromised router can flood its neighbors with RIP routing
update packets. On virtual router (VRs), you can configure the maximum number of
update packets that can be received on a RIP interface within an update interval to
avoid flooding of update packets. All update packets that exceed the configured
update threshold are dropped. If you do not set an update threshold, all update
packets are accepted.

You need to exercise care when configuring an update threshold when neighbors
have large routing tables, as the number of routing updates can be quite high within
a given duration because of flash updates. Update packets that exceed the threshold
are dropped and valid routes may not be learned.

Security Configuration  87
 Concepts & Examples ScreenOS Reference Guide

Configuring an Update Threshold

In this example, you set the maximum number of routing update packets that RIP
can receive on an interface to 4.

WebUI
Network > Routing > Virtual Router (trust-vr) > Edit > Edit RIP Instance:
Enter the following, then click OK:

Maximum Number Packets per Update Time: (select), 4

CLI
set vrouter trust-vr protocol rip threshold-update 4
save

Enabling RIP on Tunnel Interfaces

The following example creates and enables a RIP routing instance in trust-vr, on the
Device-A device. You enable RIP on both the VPN tunnel interface and the Trust
zone interface. Only routes that are in the subnet 10.10.0.0/16 are advertised to the
RIP neighbor on Device-B. This is done by first configuring an access list that
permits only addresses in the subnet 10.10.0.0/16, then specifying a route map
abcd that permits routes that match the access list. You then specify the route map
to filter the routes that are advertised to RIP neighbors.

Figure 13 shows the described network scenario.

Figure 13: Tunnel Interface with RIP Example

Untrust Zone
Trust Zone

10.20.0.0/16 Device-A (RIP) Device-B (RIP) 1.1.1.1/16

Internet

10.10.0.0/16 2.2.2.2/16

VPN Tunnel

RIP Router tunnel.1 RIP Router

WebUI
Network > Routing > Virtual Router > Edit (for trust-vr) > Create RIP
Instance: Select Enable RIP, then click OK.

Network > Routing > Virtual Router > Access List (for trust-vr) > New: Enter
the following, then click OK:

Access List ID: 10

Sequence No.: 10
IP/Netmask: 10.10.0.0/16
Action: Permit

88  Security Configuration
 Chapter 4: Routing Information Protocol

Network > Routing > Virtual Router > Route Map (for trust-vr) > New: Enter
the following, then click OK:

Map Name: abcd

Sequence No.: 10
Action: Permit
Match Properties:
Access List: (select), 10

Network > Routing > Virtual Router > Edit (for trust-vr) > Edit RIP Instance:
Select the following, then click OK:

Outgoing Route Map Filter: abcd

Network > Interfaces > Edit (for tunnel.1) > RIP: Enter the following, then
click Apply:

Enable RIP: (select)

Network > Interfaces > Edit (for trust) > RIP: Enter the following, then click
Apply:

Enable RIP: (select)

CLI
set vrouter trust-vr protocol rip
set vrouter trust-vr protocol rip enable
set interface tunnel.1 protocol rip enable
set interface trust protocol rip enable
set vrouter trust-vr access-list 10 permit ip 10.10.0.0/16 10
set vrouter trust-vr route-map name abcd permit 10
set vrouter trust-vr route-map abcd 10 match ip 10
set vrouter trust-vr protocol rip route-map abcd out
save

Optional RIP Configurations

This section describes various RIP features that you can configure.

Setting the RIP Version

On Juniper Networks security devices, you can configure the Routing Information
Protocol (RIP) version for the virtual router (VR) and for each RIP interface that
sends and receives updates. Per RFC 2453, the VR can run a version of RIP that
differs from the instance of RIP running on a particular interface. You can also
configure different RIP versions for sending updates and for receiving updates on a
RIP interface.

On the VR, you can configure either RIP version 1 or version 2; the default is
version 2. For sending updates on RIP interfaces, you can configure either RIP
version 1, version 2, or version 1-compatible mode (described in RFC 2453). For
receiving updates on RIP interfaces, you can configure either RIP version 1, version
2, or both version 1 and 2.

Optional RIP Configurations  89

 Concepts & Examples ScreenOS Reference Guide

NOTE: Using both versions 1 and 2 at the same time is not recommended. Network
complications can result between versions 1 and 2 of the protocol.

For both sending and receiving updates on RIP interfaces, the default RIP version is
the version that is configured for the VR.

In the following example, you set RIP version 1 in trust-vr. For the interface
ethernet3, you set RIP version 2 for both sending and receiving updates.

WebUI
Network > Routing > Virtual Router > Edit (for trust-vr) > Edit RIP Instance:
Select V1 for Version, then click Apply.

Network > Interfaces > Edit (for ethernet3) > RIP: Select V2 for Sending and
Receiving in Update Version, then click Apply.

CLI
set vrouter trust-vr protocol rip version 1
set interface ethernet3 protocol rip receive-version v2
set interface ethernet3 protocol rip send-version v2
save

To verify the RIP version in the VR and on RIP interfaces, you can enter the get
vrouter trust-vr protocol rip command.

device-> get vrouter trust-vr protocol rip

VR: trust-vr
----------------------------------
State: enabled
Version: 1
Default metric for routes redistributed into RIP: 10
Maximum neighbors per interface: 512
Not validating neighbor in same subnet: disabled
Next RIP update scheduled after: 14 sec
Advertising default route: disabled
Default routes learnt by RIP will be accepted
Incoming routes filter and offset-metric: not configured
Outgoing routes filter and offset-metric: not configured
Update packet threshold is not configured
Total number of RIP interfaces created on vr(trust-vr): 1
Update Invalid Flush (Timers in seconds)
-------------------------------------------------------------
30 180 120
Flags: Split Horizon - S, Split Horizon with Poison Reverse - P, Passive - I
Demand Circuit - D
Interface IP-Prefix Admin State Flags NbrCnt Metric Ver-Rx/Tx
--------------------------------------------------------------------------------
ethernet3 20.20.1.2/24 enabled enabled S 0 1 2/2

In the example above, the security device is running RIP version 1 on the trust-vr;
but RIP version 2 is running on the ethernet3 interface for sending and receiving
updates.

90  Optional RIP Configurations

 Chapter 4: Routing Information Protocol

Enabling and Disabling a Prefix Summary

You can configure a summary route that encompasses a range of route prefixes to
be advertised by RIP. The security device then advertises only one route that
corresponds to a summary range instead of individually advertising each route that
falls within the summary range. This can reduce the number of route entries sent in
RIP updates and reduce the number of entries that RIP neighbors need to store in
their routing tables. You enable route summarization on the RIP interface from
which the device sends. You can choose to summarize routes on one interface and
send routes without summarization on another interface.

NOTE: You cannot selectively enable summarization for a specific summary range; when
you enable summarization on an interface, all configured summary routes appear
on routing updates.

When configuring the summary route, you cannot specify multiple prefix ranges
that overlap. You also cannot specify a prefix range that includes the default route.
You can optionally specify a metric for the summary route. If you do not specify a
metric, the largest metric for all routes that fall within the summary range is used.

Sometimes a summarized route can create opportunities for loops to occur. You can
configure a route to a NULL interface to avoid loops. For more information about
setting a NULL interface, see “Preventing Loops Created by Summarized Routes” on
page 10.

Enabling a Prefix Summary

In the following example, you configure a summary route 10.1.0.0/16, which
encompasses the prefixes 10.1.1.0/24 and 10.1.2.0/24. To allow ethernet3 to send
the summary route in RIP updates, you need to enable summarization on the
interface.

WebUI
Network > Routing > Virtual Routers > Edit (for trust-vr) > Edit RIP Instance
> Summary IP: Enter the following, then click Add:

Summary IP: 10.1.0.0

Netmask: 16
Metric: 1

Network > Interface > Edit (for ethernet3) > RIP: Select Summarization, then
click Apply.

CLI
set vrouter trust-vr protocol rip summary-ip 10.1.0.0/16
set interface ethernet3 protocol rip summary-enable
save

Optional RIP Configurations  91

 Concepts & Examples ScreenOS Reference Guide

Disabling a Prefix Summary

In the following example, you disable a prefix summary route for ethernet3 on the
trust-vr.

WebUI
Network > Interfaces > Edit > RIP: Uncheck Summarization, then click
Apply.

CLI
unset vrouter trust-vr protocol rip summary-ip 10.1.0.0/16
unset interface ethernet3 protocol rip summary-enable
save

Setting Alternate Routes

The security device maintains a RIP database for routes learned by the protocol and
routes that are redistributed into RIP. By default, only the best route for a given
prefix is maintained in the database. You can specify that one, two, or three
alternate RIP routes for the same prefix can exist in the RIP database. If you allow
alternate routes for a prefix in the RIP database, routes to the same prefix with a
different next-hop or RIP source are added to the RIP database. This allows RIP to
support demand circuits and fast failover.

NOTE: We recommend the use of alternate routes with demand circuits. For more
information about demand circuits, see “Demand Circuits on Tunnel Interfaces”
on page 93.

Only the best route in the RIP database for a given prefix is added to the routing
table of a virtual router (VR) and advertised in RIP updates. If the best route is
removed from the routing table of a VR, then RIP adds the next-best route for the
same prefix from the RIP database. If a new route, which is better than the best
existing route in the routing table of a VR, is added to the RIP database, then RIP
updates to use the new better route to the routing table and stops using the old
route. Depending upon the alternate route limit you configured, RIP may or may
not delete the old route from the RIP database.

You can view the RIP database by issuing this CLI command: get vrouter vrouter
protocol rip database. In the following example, the number of alternate routes for
the RIP database is set to a number greater than 0. The RIP database shows two
entries for the prefix 10.10.70.0/24 in the RIP database, one with a cost of 2 and the
other with a cost of 4. The best route for the prefix, the route with the lowest cost, is
included in the routing table of the VR.

92  Optional RIP Configurations

 Chapter 4: Routing Information Protocol

device-> get vrouter trust-vr protocol rip database

VR: trust-vr
--------------------------------------------------------------------------------
Total database entry: 14
Flags: Added in Multipath - M, RIP - R, Redistributed - I
Default (advertised) - D, Permanent - P, Summary - S
Unreachable - U, Hold - H
DBID Prefix Nexthop Interface Cost Flags Source
--------------------------------------------------------------------------------
.
.
.
47 10.10.70.0/24 10.10.90.1 eth4 2 MR 10.10.90.1
46 10.10.70.0/24 10.10.90.5 eth4 4 R 10.10.90.5
.
.

If equal cost multipath (ECMP) routing is enabled (see “Configuring Equal Cost
Multipath Routing” on page 35) and multiple routes of equal cost exist in the RIP
database for a given prefix, then RIP adds multiple routes for the prefix into the
routing table of the VR up to the ECMP limit. In some cases, the alternate route limit
in the RIP database may result in RIP routes not being added to the routing table of
the VR. If the ECMP limit is less than or equal to the alternate route limit in the RIP
database, RIP routes that are not added to the routing table for the VR remain in the
RIP database; these routes are added into the routing table for the VR only if a
previously added route is either deleted or is no longer the “best” RIP route for the
network prefix.

For example, if the ECMP limit is 2 and the alternate route limit in the RIP database
is 3, there can be only two RIP routes for the same prefix with the same cost in the
routing table for the VR. Additional same prefix/same cost routes in the RIP
database can exist, but only two routes are added into the routing table for the VR.

In the following example, you set the number of alternate routes allowed for a
prefix in the RIP database to 1 in trust-vr. This allows one “best” route and one
alternate route for any given prefix in the RIP database in the VR.

WebUI
Network > Routing > Virtual Routers > Edit (for trust-vr) > Edit RIP Instance:
Enter 1 in the Maximum Alternative Route field, then click Apply.

CLI
set vrouter trust-vr protocol rip alt-route 1
save

Demand Circuits on Tunnel Interfaces

A demand circuit is a point-to-point connection between two tunnel interfaces.
Minimal network overhead in terms of messages pass between the demand circuit
end points. Demand circuits for RIP, defined by RFC 2091 for wide area networks,
support large numbers of RIP neighbors on VPN tunnels on Juniper Networks
security devices.

Optional RIP Configurations  93

 Concepts & Examples ScreenOS Reference Guide

Demand circuits for RIP eliminate the periodic transmission of RIP packets over the
tunnel interface. To save overhead, the security device sends RIP information only
when changes occur in the routing database. The security device also retransmits
updates and requests until valid acknowledgements are received. The security
device learns RIP neighbors through the configuration of static neighbors; and if the
VPN tunnel goes down, RIP flushes routes learned from the neighbor’s IP address.

Routes learned from demand circuits do not age with RIP timers because demand
circuits are in a permanent state. Routes in permanent state are only removed
under the following conditions:

 A formerly reachable route changes to unreachable in an incoming response

 The VPN tunnel goes down or the demand circuit is down due to an excessive
number of unacknowledged retransmissions

On the security device, you can also configure a point-to-point or a

point-to-multipoint tunnel interface as a demand circuit. You must disable
route-deny (if configured) on a point-to-multipoint tunnel so that all routes can
reach remote sites. Although not required, you can also disable split horizon on the
point-to-multipoint interface with demand circuits. If you disable split horizon, the
end points can learn about each other.

You must configure VPN monitoring with rekey on VPN tunnels in order to learn
tunnel status.

After you configure the demand circuit and the static neighbor(s), you can set the
RIP retransmit-timer, poll-timer, and hold-down-timer to conform to your network
requirements.

Examples of how to configure a demand circuit and a static neighbor follow this
section. A RIP network configuration example with demand circuits over
point-to-multipoint tunnel interfaces begins on page 96.

In the following example, you configure tunnel.1 interface to be a demand circuit

and save the configuration.

WebUI
Network > Interfaces > (Edit) RIP: Select Demand Circuit, then click Apply.

CLI
set interface tunnel.1 protocol rip demand-circuit
save

After enabling a demand circuit, you can check its status and timers with the get
vrouter vrouter protocol rip database command. Table 12 lists suggestions for
troubleshooting performance issues influenced by timer settings.

94  Optional RIP Configurations

 Chapter 4: Routing Information Protocol

Table 12: Troubleshooting the Demand Circuit Retransmit Timer

Demand Circuit Performance Suggestion

Relatively slow You can reconfigure the retransmit timer to a higher value
to reduce the number of retransmits.
Loss free You can reconfigure the retransmit timer to lower retry
count.
Congested and lossy You can reconfigure the retransmit timer to a higher retry
count to give the static neighbor more time to respond
before forcing the static neighbor into a POLL state.

Configuring a Static Neighbor

A point-to-multipoint interface that is running RIP requires statically configured
neighbors. For demand circuits manual configuration is the only way for a security
device to learn neighbor addresses on point-to-multipoint interfaces. To configure a
RIP static neighbor you enter the interface name and the IP address of the RIP
neighbor.

In the following example you configure the RIP neighbor at IP address 10.10.10.2 of
the tunnel.1 interface.

WebUI
Network > Interfaces > (Edit) RIP: Click Static Neighbor IP button to advance
to the Static Neighbor IP table. Enter the IP address of the static neighbor, then
click Add.

CLI
set interface tunnel.1 protocol rip neighbor 10.10.10.2
unset interface tunnel.1 protocol rip neighbor 10.10.10.2
save

Configuring a Point-to-Multipoint Tunnel Interface

RIP point-to-multipoint is supported on numbered tunnel interfaces for RIP versions
1 and 2.

CAUTION: RIP is not supported over unnumbered tunnel interfaces. All interfaces
that use RIP protocol must be numbered. Any attempt to configure and run an
unnumbered interface using RIP may lead to unpredictable routing failure.

You must disable split horizon on a point-to-multipoint interface tunnel that you
configure with demand circuits so that messages reach all remote sites. For a
point-to-multipoint tunnel interface without demand circuits, you can leave split
horizon enabled (default). RIP dynamically learns about neighbors. RIP sends all
transmitted messages to the multicast address 224.0.0.9 and reduplicates them to
all tunnels as appropriate.

If you want to set up RIP as a point-to-multipoint tunnel with demand circuits, you
must design your network in a hub-and-spoke configuration.

Configuring a Point-to-Multipoint Tunnel Interface  95

 Concepts & Examples ScreenOS Reference Guide

NOTE: In this example, we only reference the command line interfaces, and we do not
discuss zones and other necessary configuration steps.

The network in this example is a medium-sized enterprise that has a central office
(CO) in San Francisco and remote sites in Chicago, Los Angeles, Montreal, and New
York. Each office has a single security device. See Figure 14 on page 97.

The following are the configuration requirements particular to the security device in
the CO:

1. Configure the VR to run an instance of RIP, enable RIP, and then configure
tunnel.1 interface.

2. Configure the four VPNs and bind them to tunnel.1 interface.

3. Configure RIP static neighbors on the CO security device.

4. Do not change the default timer values in this example.

The following are the configuration requirements particular to the remote Juniper
Networks security devices:

1. Configure the VR to run an instance of RIP and enable RIP and then configure
tunnel.1 interface.

2. Configure the VPN and bind it to tunnel.1 interface.

3. Do not configure static neighbors on the remote office security devices. The
remote office devices only have one neighboring device that will be discovered
by initial multicast requests.

NOTE: It is not necessary to change the default timer values in this example.

96  Configuring a Point-to-Multipoint Tunnel Interface

 Chapter 4: Routing Information Protocol

Figure 14: Point-to-MultiPoint with Tunnel Interface Network Example

Los Angeles Montreal

tunnel.1 10.0.0.3 tunnel.1 10.0.0.4

Untrust 1.1.1.3 Untrust 1.1.1.4

New York Chicago

tunnel.1 10.0.0.2 tunnel.1 10.0.0.5 Untrust 1.1.1.5

Untrust 1.1.1.2

VPN 2 VPN 3
Internet
VPN 1 VPN 4

San Francisco (CO)

ethernet3 1.1.1.1
tunnel.1 10.0.0.1
4 VPNs bound to tunnel.1

In the network diagram shown in Figure 14, four VPNs originate from the San
Francisco security device and radiate out to remote offices in New York, Los
Angeles, Montreal, and Chicago.

In this example, you configure the following settings on the CO security device:

1. Security Zone and Interfaces

2. VPN

3. Routes and RIP

4. Static Neighbors

5. Summary Route

To be able to check the circuit status on the device in the CO, you must enable VPN
monitoring.

To complete the network configuration, you configure the following settings on

each of the four remote office security devices:

1. Security Zone and Interfaces

2. VPN

3. Routes and RIP

4. Static Neighbors

5. Summary Route

Configuring a Point-to-Multipoint Tunnel Interface  97

 Concepts & Examples ScreenOS Reference Guide

NOTE: The WebUI procedures are abbreviated due to the length of the example. The CLI
portion of the example is complete. You can refer ahead to the CLI portion for the
exact settings and values to use.

WebUI (Central Office Device)

1. Security Zones and Interfaces
Network > Interfaces > Click New Tunnel IF and continue to the
Configuration page.

Network > Interfaces > Edit (for ethernet3)

2. VPN
VPNs > AutoKey Advanced > Gateway

3. Routes and RIP

Network > Routing > Virtual Routers > Click Edit for the virtual router and
click Create RIP Instance, then enable RIP on the virtual router.

Network > Interfaces > Edit > Click Edit and then click RIP, then enable RIP
on the interface.

4. Static Neighbors
Network > Interfaces > Edit > RIP > Static Neighbor IP and then Add
Neighbor IP Address.

5. Summary Route
Network > Routing > Virtual Router Edit (RIP) > Click Summary IP and
configure the summary IP address.

CLI (Central Office Device)

1. Security Zones and Interfaces
set interface ethernet3 zone untrust
set interface ethernet3 ip 1.1.1.1/24
set interface tunnel.1 zone untrust
set interface tunnel.1 ip 10.0.0.1/24
2. VPN
set ike gateway gw1 address 1.1.1.2 main outgoing-interface ethernet3 preshare
ripdc proposal pre-g2-3des-sha
set ike gateway gw2 address 1.1.1.3 main outgoing-interface ethernet3 preshare
ripdc proposal pre-g2-3des-sha
set ike gateway gw3 address 1.1.1.4 main outgoing-interface ethernet3 preshare
ripdc proposal pre-g2-3des-sha
set ike gateway gw4 address 1.1.1.5 main outgoing-interface ethernet3 preshare
ripdc proposal pre-g2-3des-sha

set vpn vpn1 gateway gw1 no-replay tunnel idletime 0 proposal g2-esp-3des-sha
set vpn vpn1 monitor rekey
set vpn vpn1 bind interface tunnel.1
set vpn vpn2 gateway gw2 no-replay tunnel idletime 0 proposal g2-esp-3des-sha
set vpn vpn2 monitor rekey
set vpn vpn2 bind interface tunnel.1

98  Configuring a Point-to-Multipoint Tunnel Interface

 Chapter 4: Routing Information Protocol

set vpn vpn3 gateway gw3 no-replay tunnel idletime 0 proposal g2-esp-3des-sha
set vpn vpn3 monitor rekey
set vpn vpn3 bind interface tunnel.1

set vpn vpn4 gateway gw4 no-replay tunnel idletime 0 proposal g2-esp-3des-sha
set vpn vpn4 monitor rekey
set vpn vpn4 bind interface tunnel.1
3. Routes and RIP
set vrouter trust protocol rip
set vrouter trust protocol rip enable
set vrouter protocol rip summary-ip 100.10.0.0/16

set interface tunnel.1 protocol rip

set interface tunnel.1 protocol rip enable
set interface tunnel.1 protocol rip demand-circuit
4. Static Neighbors
set interface tunnel.1 protocol rip neighbor 10.0.0.2
set interface tunnel.1 protocol rip neighbor 10.0.0.3
set interface tunnel.1 protocol rip neighbor 10.0.0.4
set interface tunnel.1 protocol rip neighbor 10.0.0.5
5. Summary Route
set interface tunnel.1 protocol rip summary-enable
save

You can follow these steps to configure the remote office security device. When
setting up the remote office, you do not need to configure static neighbors. In a
demand circuit environment only one neighbor exists for the remote device, and
the remote devices learns this neighbor’s information when it sends a multicast
message at startup.

To complete the configuration shown in the diagram on page 97, you must repeat
this section for each remote device and change the IP addresses, gateway names
and VPN names to match the network needs. For each remote site, the trust and
untrust zones change.

NOTE: The WebUI procedures are abbreviated due to the length of the example. The CLI
portion of the example is complete. You can refer ahead to the CLI portion for the
exact settings and values to use.

WebUI (Remote Office Device)

1. Security Zones and Interfaces
Network > Interfaces > Click New Tunnel IF and continue to the Configuration
page.

Network > Interfaces > Edit (for ethernet3)

2. VPN
VPNs > AutoKey Advanced > Gateway

3. Routes and RIP

Network > Routing > Virtual Routers > Click Edit for the virtual router and
click Create RIP Instance, then enable RIP on the virtual router.

Configuring a Point-to-Multipoint Tunnel Interface  99

 Concepts & Examples ScreenOS Reference Guide

Network > Interfaces > Edit > Click Edit and then click RIP, then enable RIP
on the interface.

4. Policy (configure as required)

Policies (from All zones to All zones) > Click New.

CLI (Remote Office Device)

1. Interface and routing protocol
set vrouter trust-vr protocol rip
set vrouter trust-vr protocol rip enable
set interface untrust ip 1.1.1.1/24
set interface tunnel.1 zone untrust
set interface tunnel.1 ip 10.0.0.2/24
2. VPN
set ike gateway gw1 address 1.1.1.1/24 main outgoing-interface untrust preshare
ripdc proposal pre-g2-3des-sha
set vpn vpn1 gateway gw1 no-replay tunnel idletime 0 proposal g2-esp-3des-sha
set vpn vpn1 monitor rekey
set vpn vpn1 id 1 bind interface tunnel.1
3. Routes and RIP
set interface tunnel.1 protocol rip
set interface tunnel.1 protocol rip demand-circuit
set interface tunnel.1 protocol rip enable
4. Policy (configure as required)
set policy id 1 from trust to untrust any any any permit
set policy id 2 from untrust to trust any any any permit
save

You can view the new changes with the get vrouter vrouter protocol rip neighbors
command. Neighbors for a demand circuit appear in the neighbor table; neighbor
information does not age or expire. You can view the RIP database with the get
vrouter vrouter protocol rip database command. P for permanent appears next to
demand circuit entries.

100  Configuring a Point-to-Multipoint Tunnel Interface

Chapter 5
Border Gateway Protocol

This chapter describes the Border Gateway Protocol (BGP) on Juniper Networks
security devices. It contains the following sections:

 “Overview” on page 102

 “Types of BGP Messages” on page 102

 “Path Attributes” on page 103

 “External and Internal BGP” on page 103

 “Basic BGP Configuration” on page 104

 “Creating and Enabling a BGP Instance” on page 105

 “Enabling and Disabling BGP on Interfaces” on page 106

 “Configuring BGP Peers and Peer Groups” on page 107

 “Verifying the BGP Configuration” on page 110

 “Security Configuration” on page 111

 “Authenticating BGP Neighbors” on page 111

 “Rejecting Default Routes” on page 112

 “Redistributing Routes into BGP” on page 114

 “Configuring an AS-Path Access List” on page 114

 “Adding Routes to BGP” on page 115

 “Route-Refresh Capability” on page 117

 “Configuring Route Reflection” on page 118

 “Configuring a Confederation” on page 120

 “BGP Communities” on page 122

 “Route Aggregation” on page 123

 101
 Concepts & Examples ScreenOS Reference Guide

Overview
The Border Gateway Protocol (BGP) is a path vector protocol that is used to carry
routing information between Autonomous Systems (ASs). An AS is a set of routers
that are in the same administrative domain.

The BGP routing information includes the sequence of AS numbers that a network
prefix (a route) has traversed. The path information that is associated with the
prefix is used to enable loop prevention and enforce routing policies. ScreenOS
supports BGP version 4 (BGP-4), as defined in RFC 1771.

Two BGP peers establish a BGP session in order to exchange routing information. A
BGP router can participate in BGP sessions with different peers. BGP peers must
first establish a TCP connection between themselves to open a BGP session. Upon
forming the initial connection, peers exchange entire routing tables. As routing table
changes occur, BGP routers exchange update messages with peers. A BGP router
maintains current versions of the routing tables of all the peers with which it has
sessions, periodically sending keepalive messages to peers to verify the
connections.

A BGP peer only advertises those routes that it is actively using. When a BGP peer
advertises a route to its neighbor, it also includes path attributes that describe the
characteristics of the route. A BGP router compares the path attributes and prefix to
select the best route from all paths that are available to a given destination.

Types of BGP Messages

BGP uses four different types of messages to communicate with peers:

 Open messages identify BGP peers to each other to initiate the BGP session.
These messages are sent after the peers establish a TCP session. During the
exchange of open messages, BGP peers specify their protocol version, AS
number, hold time and BGP identifier.

 Update messages announce routes to the peer and withdraw previously

advertised routes.

 Notification messages indicate errors. The BGP session is terminated and then
the TCP session is closed.

NOTE: The security device does not send a Notification message to a peer if, during the
exchange of open messages, the peer indicates that it supports protocol
capabilities that the security device does not support.

 Keepalive messages are used to maintain the BGP session. By default, the
security device sends keepalive messages to peers at 60-second intervals. This
interval is configurable.

102  Overview
 Chapter 5: Border Gateway Protocol

Path Attributes
BGP path attributes are a set of parameters that describe the characteristics of a
route. BGP couples the attributes with the route they describe, then compares all
paths available to a destination to select the best route to use to reach the
destination. The well-known mandatory path attributes are:

 Origin describes where the route was learned—it can be IGP, EGP, or
incomplete.

 AS-Path contains a list of autonomous systems through which the route

advertisement has passed.

 Next-Hop is the IP address of the router to which traffic for the route is sent.

The optional path attributes are:

 Multi-Exit Discriminator (MED) is a metric for a path where there are multiple
links between ASs (the MED is set by one AS and used by another AS to choose
a path).

 Local-Pref is a metric used to inform BGP peers of the local router’s preference
for the route.

 Atomic-Aggregate informs BGP peers that the local router selected a

less-specific route from a set of overlapping routes received from a peer.

 Aggregator specifies the AS and router that performed aggregation of the route.

 Communities specifies one or more communities to which this route belongs

 Cluster List contains a list of the reflector clusters through which the route has
passed

A BGP router can choose to add or modify the optional path attributes before
advertising the route to peers.

External and Internal BGP

External BGP (EBGP) is used between autonomous systems, as when different ISP
networks connect to each other or an enterprise network connects to an ISP
network. Internal BGP (IBGP) is used within an AS, such as within an enterprise
network. The main goal of IBGP is to distribute the routes learned from EBGP to
routers in the AS. An IBGP router can readvertise routes that it learns from its EBGP
peers to its IBGP peers, but it cannot advertise routes learned from IBGP peers to
other IBGP peers. This restriction prevents route advertisement loops within the
network, but means that an IBGP network must be fully meshed (that is, every BGP
router in the network must have a session with every other router in the network).

Some path attributes are only applicable to EBGP or IBGP. For example, the MED
attribute is only used for EBGP messages, while the LOCAL-PREF attribute is only
present in IBGP messages.

Overview  103
 Concepts & Examples ScreenOS Reference Guide

Basic BGP Configuration

You create a BGP instance on a per-virtual router (VR) basis on a security device. If
you have multiple VRs on a device, you can enable multiple instances of BGP—one
instance for each VR.

NOTE: Before you configure a dynamic routing protocol on the security device, you
should assign a virtual router ID, as described in “Routing” on page 13.

The five basic steps to configure BGP in a VR on a security device are:

1. Create and enable the BGP routing instance in a VR by first assigning an

autonomous system number to the BGP instance, then enabling the instance.

2. Enable BGP on the interface that is connected to the peer.

3. Enable each BGP peer.

4. Configure one or more remote BGP peers.

5. Verify that BGP is properly configured and operating.

This section describes how to perform each of these tasks using either the CLI or
the WebUI for the following example. Figure 15 shows the security device as a BGP
peer in AS 65000. You need to configure the security device so that it can establish
a BGP session with the peer in AS 65500.

Figure 15: BGP Configuration Example

Autonomous Autonomous
System System
Number Number
Autonomous Systems

AS 65000 AS 65500

Local Security Device

Remote Router

Interface IP Address Router ID

Router ID Interface IP Address 2.2.2.2/24 2.2.2.250
1.1.1.250 1.1.1.1/24 BGP Enabled
BGP Enabled

BGP Peers

104  Basic BGP Configuration

 Chapter 5: Border Gateway Protocol

Creating and Enabling a BGP Instance

You create and enable a BGP routing instance on a specific virtual router (VR) on a
security device. To create a BGP routing instance, you need to first specify the
autonomous system number in which the VR resides. If the VR is an IBGP router,
the autonomous system number must be the same as other IBGP routers in the
network. When you enable the BGP routing instance on a VR, the BGP routing
instance will be able to contact and establish a session with the BGP peers that you
configure.

NOTE: Autonomous System (AS) numbers are globally unique numbers that are used to
exchange EBGP routing information and to identify the AS. The following entities
allocate AS numbers: the American Registry for Internet Numbers (ARIN),
Réseaux IP Européens (RIPE), and Asia Pacific Network Information Center
(APNIC). The numbers 64512 through 65535 are for private use and not to be
advertised on the global Internet.

Creating a BGP Routing Instance

In the following example, you first assign 0.0.0.10 as the router ID for the trust-vr.
You then create and enable a BGP routing instance on the trust-vr, which resides on
the security device in AS 65000. (For more information about virtual routers and
configuring a virtual router on security devices, see “Routing” on page 13.)

WebUI
1. Router ID
Network > Routing > Virtual Router (trust-vr) > Edit: Enter the following, then
click OK:

Virtual Router ID: Custom (select)

In the text box, enter 0.0.0.10
2. BGP Routing Instance
Network > Routing > Virtual Routers > Edit (for trust-vr) > Create BGP
Instance: Enter the following, then click OK:

AS Number (required): 65000

BGP Enabled: (select)

CLI
1. Router ID
set vrouter trust-vr router-id 10
2. BGP Routing Instance
set vrouter trust-vr protocol bgp 65000
set vrouter trust-vr protocol bgp enable
save

Basic BGP Configuration  105

 Concepts & Examples ScreenOS Reference Guide

Removing a BGP Instance

In this example, you disable and remove the BGP routing instance in the trust-vr.
BGP stops sessions with all peers.

WebUI
Network > Routing > Virtual Routers (trust-vr) > Edit > Edit BGP Instance:
Deselect BGP Enabled, then click OK.

Network > Routing > Virtual Routers (trust-vr) > Edit: Select Delete BGP
Instance, then click OK at the confirmation prompt.

CLI
unset vrouter trust-vr protocol bgp enable
unset vrouter trust-vr protocol bgp 65000
save

Enabling and Disabling BGP on Interfaces

You must enable BGP on the interface on which the peer resides. (By default,
interfaces on the security device are not bound to any routing protocol.)

Enabling BGP on Interfaces

In this example, you enable BGP on the interface ethernet4.

WebUI
Network > Interfaces > Edit> BGP: Check Protocol BGP enable, then click
OK.

CLI
set interface ethernet4 protocol bgp
save

Disabling BGP on Interfaces

In this example, you disable BGP on the interface ethernet4. Other interfaces on
which you have enabled BGP are still able to transmit and process BGP packets.

WebUI
Network > Interfaces > Configure (for ethernet4): Uncheck Protocol BGP
enable, then click OK.

CLI
unset interface ethernet4 protocol bgp
save

106  Basic BGP Configuration

 Chapter 5: Border Gateway Protocol

Configuring BGP Peers and Peer Groups

Before two BGP devices can communicate and exchange routes, they need to
identify each other so they can start a BGP session. You need to specify the IP
addresses of the BGP peers and, optionally, configure parameters for establishing
and maintaining the session. Peers can be either internal (IBGP) or external (EBGP)
peers. For an EBGP peer, you need to specify the autonomous system in which the
peer resides.

All BGP sessions are authenticated by checking the BGP peer identifier and the AS
number advertised by the peers. A successful connection with a peer is logged. If
anything goes wrong with the peer connection, a BGP notification message will
either be sent to or received from the peer, which causes the connection to fail or
close.

You can configure parameters for individual peer addresses. You can also assign
peers to a peer-group, which then allows you to configure parameters for the
peer-group as a whole.

NOTE: You cannot assign IBGP and EBGP peers to the same peer group.

Table 13 lists parameters you can configure for BGP peers and the default values. An
“X” in the Peer column indicates a parameter you can configure for an individual
peer IP address while an “X” in the Peer Group column indicates a parameter you
can configure for a peer-group.

Table 13: BGP Peer and Peer Group Parameters and Default Values

Peer
BGP Parameter Peer Group Description Default Value
Advertise default X Advertises the default route in the virtual route to BGP Default route is not
route peers. advertised
EBGP multihop X X Number of nodes between local BGP and neighbor. 0 (disabled)
Force connect X X Causes the BGP instance to drop an existing BGP N/A
connection with the specified peer and accept a new
connection. This parameter is useful when connecting to
a router that goes down, then comes back up and tries
to re-establish BGP peering as it allows faster
re-establishment of the peer connection.1
Hold time X X Time elapsed without a message from a peer before the 180 seconds
peer is considered down.
Keepalive X X Time between keepalive transmissions. 1/3 of hold-time
MD5 X X Configures MD-5 authentication. Only peer identifier and
authentication AS number checked
MED X Configures MED attribute value. 0
Next-hop self X X For routes sent to the peer, the next hop path attribute is Next hop attribute
set to the IP address of the interface of the local virtual unchanged
router.
Reflector client X X Peer is a reflector client when the local BGP is set as the None
route reflector.
Reject default X Ignores default route advertisements from BGP peers. Default routes from peers
route are added to routing table

Basic BGP Configuration  107

 Concepts & Examples ScreenOS Reference Guide

Peer
BGP Parameter Peer Group Description Default Value
Retry time X X Time after a failed session attempt that the BGP session 120 seconds
is reattempted.
Send X X Transmits community attribute to peer. Community attribute not
community sent to peers
Weight X X Priority of path between local BGP and peer. 100

1.You can use the exec neighbor disconnect command to cause the BGP instance to drop an existing BGP connection with the
specified peer and accept a new connection. Using this exec command does not change the configuration of the BGP peer. For
example, you can use this exec command if you change the configuration of the route map that is applied to the peer.

You can configure some parameters at both the peer level and the protocol level
(see “Configuring a Confederation” on page 120). For example, you can configure
the hold-time value for a specific peer at 210 seconds, while the default hold-time
value at the protocol level is 180 seconds; the peer configuration takes precedence.
You can set different MED values at the protocol level and at the peer level; the MED
value you set at the peer level applies only to routes that are advertised to those
peers.

Configuring a BGP Peer

In the following example, you configure and enable a BGP peer. This peer has the
following attributes:

 IP address 1.1.1.250

 Resides in AS 65500

NOTE: You must enable each peer connection that you configure.

WebUI
Network > Routing > Virtual Routers > Edit (for trust-vr) > Edit BGP Instance
> Neighbors: Enter the following, then click Add:

AS Number: 65500
Remote IP: 1.1.1.250

Network > Routing > Virtual Routers > Edit (for trust-vr) > Edit BGP Instance
> Neighbors > Configure (for the peer you just added): Select Peer Enabled,
then click OK.

CLI
set vrouter trust-vr protocol bgp neighbor 1.1.1.250 remote-as 65500
set vrouter trust-vr protocol bgp neighbor 1.1.1.250 enable
save

Configuring an IBGP Peer Group

In the following example, you configure an IBGP peer group called ibgp that
contains the following IP addresses: 10.1.2.250 and 10.1.3.250. Once you have
defined a peer group, you can configure parameters (such as MD5 authentication)
that apply to all members of the peer group.

108  Basic BGP Configuration

 Chapter 5: Border Gateway Protocol

NOTE: You must enable each peer connection that you configure. If you configure peers
as part of a peer group, you still need to enable the peer connections one by one.

WebUI
Network > Routing > Virtual Routers > Edit (for trust-vr) > Edit BGP Instance
> Peer Group: Enter ibgp for Group Name, then click Add.

> Configure (for ibgp): In the Peer authentication field, enter verify03,
then click OK.

Network > Routing > Virtual Routers > Edit (for trust-vr) > Edit BGP Instance
> Neighbors: Enter the following, then click Add:

AS Number: 65000
Remote IP: 10.1.2.250
Peer Group: ibgp (select)

Enter the following, then click Add:

AS Number: 65000
Remote IP: 10.1.3.250
Peer Group: ibgp (select)

Network > Routing > Virtual Routers > Edit (for trust-vr) > Edit BGP Instance
> Neighbors > Configure (for 10.1.2.250): Select Peer Enabled, then click OK.

Network > Routing > Virtual Routers > Edit (for trust-vr) > Edit BGP Instance
> Neighbors > Configure (for 10.1.3.250): Select Peer Enabled, then click OK.

CLI
set vrouter trust-vr protocol bgp neighbor peer-group ibgp
set vrouter trust-vr protocol bgp neighbor peer-group ibgp remote-as 65000
set vrouter trust-vr protocol bgp neighbor peer-group ibgp md5-authentication
verify03
set vrouter trust-vr protocol bgp neighbor 10.1.2.250 remote-as 65000
set vrouter trust-vr protocol bgp neighbor 10.1.2.250 peer-group ibgp
set vrouter trust-vr protocol bgp neighbor 10.1.3.250 remote-as 65000
set vrouter trust-vr protocol bgp neighbor 10.1.3.250 peer-group ibgp
set vrouter trust-vr protocol bgp neighbor 10.1.2.250 enable
set vrouter trust-vr protocol bgp neighbor 10.1.3.250 enable
save

Basic BGP Configuration  109

 Concepts & Examples ScreenOS Reference Guide

Verifying the BGP Configuration

You can review the configuration you entered through the WebUI or the CLI with the
get vrouter vrouter protocol bgp config command.

device-> get vrouter trust-vr protocol bgp config

set protocol bgp 65000
set enable
set neighbor peer-group "ibgp"
set neighbor peer-group "ibgp" md5-authentication "cq1tu6gVNU5gvfsO60CsvxVPNnntO
PwY/g=="
set neighbor 10.1.2.250 remote-as 65000

output continues...

exit

You can verify that BGP is running on the virtual router by executing the get vrouter
vrouter protocol bgp command.

device-> get vrouter trust-vr protocol bgp

Admin State: enable
Local Router ID: 10.1.1.250
Local AS number: 65000
Hold time: 180
Keepalive interval: 60 = 1/3 hold time, default
Local MED is: 0
Always compare MED: disable
Local preference: 100
Route Flap Damping: disable
IGP synchronization: disable
Route reflector: disable
Cluster ID: not set (ID = 0)
Confederation based on RFC 1965
Confederation: disable (confederation ID = 0)
Member AS: none
Origin default route: disable
Ignore default route: disable

You can view the administrative state of the virtual router (VR) and the router ID, as
well as all other configured parameters particular to BGP.

NOTE: We recommend that you explicitly assign a router ID rather than use the default.
For information on setting a router ID, see “Routing” on page 13.

You can verify that a BGP peer or peer group is enabled and see the state of the BGP
session by executing the get vrouter vrouter protocol bgp neighbor command.

device-> get vrouter trust-vr protocol bgp neighbor

Peer AS Remote IP Local IP Wt Status State ConnID
65500 1.1.1.250 0.0.0.0 100 Enabled ACTIVE up
Total 1 BGP peers shown

In this example you can verify that the BGP peer is enabled and the session is
active.

110  Basic BGP Configuration

 Chapter 5: Border Gateway Protocol

The state can be one of the following:

 Idle - The first state of the connection

 Connect - BGP is waiting for successful TCP transport connection

 Active - BGP is initiating a transport connection

 OpenSent - BGP is waiting for an OPEN message from the peer

 OpenConfirm - BGP is waiting for a KEEPALIVE or NOTIFICATION message

from the peer

 Established - BGP is exchanging UPDATE packets with the peer

NOTE: A session state that continually changes between the Active and Connect may
indicate a problem with the connection between the peers.

Security Configuration
This section describes possible security problems in the BGP routing domain and
methods of preventing attacks.

NOTE: To make BGP more secure, you should configure all routers in the BGP domain to
be at the same security level. Otherwise, a compromised BGP router can bring
down the entire BGP routing domain.

Authenticating BGP Neighbors

A BGP router can be easily spoofed, since BGP packets are not encrypted and most
protocol analyzers provide decapsulation of BGP packets. Authenticating BGP peers
is the best way to fend off these types of attacks.

BGP provides MD5 authentication to validate BGP packets received from peer. MD5
authentication requires that the same key be used for both the sending and
receiving BGP routers. All BGP packets received from the specified peer that are not
authenticated are discarded. By default, only the peer identifier and AS number are
checked for a BGP peer.

In the following example, you first configure a BGP peer with the remote IP address
1.1.1.250 in AS 65500. You then configure the peer for MD5 authentication using
the key 1234567890123456.

Security Configuration  111

 Concepts & Examples ScreenOS Reference Guide

WebUI
Network > Routing > Virtual Routers > Edit (for trust-vr) > Edit BGP Instance
> Neighbors: Enter the following, then click Add:

AS Number: 65500
Remote IP: 1.1.1.250

> Configure (for Remote IP 1.1.1.250): Enter the following, then click OK:

Peer Authentication: Enable (select)

MD5 password: 1234567890123456
Peer Enabled: (select)

CLI
set vrouter trust-vr
(trust-vr)-> set protocol bgp
(trust-vr/bgp)-> set neighbor 1.1.1.250 remote-as 65500
(trust-vr/bgp)-> set neighbor 1.1.1.250 md5-authentication 1234567890123456
(trust-vr/bgp)-> set neighbor 1.1.1.250 enable
(trust-vr/bgp)-> exit
(trust-vr)-> exit
save

Rejecting Default Routes

In a Route Detour Attack, a router injects a default route (0.0.0.0/0) into the routing
domain in order to detour packets to itself. The router can then either drop the
packets, causing service disruption, or it can remove sensitive information in the
packets before forwarding them. On security devices, BGP by default accepts any
default routes that are sent from BGP peers and adds the default route to the routing
table.

In this example, you configure the BGP routing instance running in the trust-vr to
ignore any default routes that are sent from BGP peers.

WebUI
Network > Routing > Virtual Router (trust-vr) > Edit > Edit BGP Instance:
Enter the following, then click OK:

Ignore default route from peer: (select)

CLI
set vrouter trust-vr protocol bgp reject-default-route
save

112  Security Configuration

 Chapter 5: Border Gateway Protocol

Optional BGP Configurations

This section describes the parameters you can configure for the BGP routing
protocol in the virtual router. You can configure these parameters with either the CLI
BGP context commands or the WebUI. This section explains some of the more
complex parameter configurations. Table 14 describes BGP parameters and their
default values.

Table 14: Optional BGP Parameters and Default Values

BGP Protocol Parameter Description Default Value

Advertise default route Advertise the default route in the virtual Default route not
router to BGP peers. advertised
Aggregate Create aggregated routes. See “Route Disabled
Aggregation” on page 123.
Always compare MED Compare MED values in routes. Disabled
AS path access list Create an AS path access list to permit or —
deny routes.
Community list Create community lists. See “BGP —
Communities” on page 122.
AS confederation Create confederations. See “Configuring a —
Confederation” on page 120.
Equal cost multipath Equal cost multiple routes can be added Disabled (default = 1)
(ECMP) to provide load-balancing capabilities. See
“Configuring Equal Cost Multipath
Routing” on page 35.
Flap damping Block advertisement of a route until it Disabled
becomes stable.
Hold time Time elapsed without a message from a 180 seconds
peer before the peer is considered down.
Keepalive Time between keepalive transmissions. 1/3 of hold-time
Local preference Configure LOCAL_PREF metric. 100
MED Configure MED attribute value. 0
Network Add static network and subnetwork —
entries into BGP. BGP advertises these
static routes to all BGP peers. See “Adding
Routes to BGP” on page 115.
Route redistribution Import routes into BGP from other —
routing protocols.
Reflector Configure the local BGP instance as a Disabled
route reflector to clients. See “Configuring
Route Reflection” on page 118.
Reject default route Ignore default route advertisements from Default routes from
BGP peers. peers are added to
routing table
Retry time Time after an unsuccessful BGP session 12 seconds
establishment with a peer that session
establishment is retried.
Synchronization Enable synchronization with an IGP, such Disabled
as OSPF or RIP.

Optional BGP Configurations  113

 Concepts & Examples ScreenOS Reference Guide

Redistributing Routes into BGP

Route redistribution is the exchange of route information between routing
protocols. For example, you can redistribute the following types of routes into the
BGP routing instance in the same virtual router:

 Routes learned from OSPF or RIP

 Directly connected routes

 Imported routes

 Statically configured routes

When you configure route redistribution, you must first specify a route map to filter
the routes that are redistributed. For more information about creating route maps
for route redistribution, see “Routing” on page 13.

In the following example, you redistribute a route that originated from an OSPF
routing domain into the current BGP routing domain. Both the CLI and WebUI
examples assume that you previously created a route map called add-ospf.

WebUI
Network > Routing > Virtual Routers > Edit (for trust-vr) > Edit BGP Instance
> Redist. Rules: Enter the following, then click Add:

Route Map: add-ospf

Protocol: OSPF

CLI
set vrouter trust-vr protocol bgp redistribute route-map add-ospf protocol ospf
save

Configuring an AS-Path Access List

The AS-path attribute contains a list of the ASs through which a route has traversed.
BGP prepends the local AS number to the AS-path attribute when a route passes
through the AS. You can use an AS-path access list to filter routes based on the
AS-path information. An AS-path access list consists of a set of regular expressions
that define AS-path information and whether the routes that match the information
are permitted or denied. For example, you can use an AS-path access list to filter
routes that have passed through a particular AS or routes that originated in a
particular AS.

Regular expressions are a way to define a search for specific pattern in the AS-path
attribute. You can use special symbols and characters in constructing a regular
expression. For example, to match routes that have passed through AS 65000, use
the regular expression _65000_ (the underscores match any characters before or
after 65000). You can use the regular expression “65000$” to match routes that
originated in AS 65000 (the dollar sign matches the end of the AS-path attribute,
which would be the AS where the route originated).

The following example configures an AS-path access list for the trust-vr that allows
routes that have passed through AS 65000 but does not allow routes that originated
in AS 65000.

114  Optional BGP Configurations

 Chapter 5: Border Gateway Protocol

WebUI
Network > Routing > Virtual Routers > Edit (for trust-vr) > Edit BGP Instance
> AS Path: Enter the following, then click Add:

AS Path Access List ID: 2

Deny: (select)
AS Path String: 65000$

Network > Routing > Virtual Routers > Edit (for trust-vr) > Edit BGP Instance
> AS Path: Enter the following, then click Add:

AS Path Access List ID: 2

Permit: (select)
AS Path String: _65000_

CLI
set vrouter trust-vr protocol bgp as-path-access-list 2 deny 65000$
set vrouter trust-vr protocol bgp as-path-access-list 2 permit _65000_
save

Adding Routes to BGP

To allow BGP to advertise network routes, you need to redistribute the routes from
the source protocol into the advertising protocol (BGP) in the same virtual router
(VR). You can also add static routes directly into BGP. If the network prefix is
reachable from the VR, BGP advertises this route to peers without requiring that the
route be redistributed into BGP. When you add a network prefix into BGP, you can
specify several options:

 By selecting “Yes” to the check reachability option, you can specify whether a
different network prefix must be reachable from the VR before BGP advertises
the route to peers. For example, if the prefix you want BGP to advertise must be
reached through a specific router interface, you want to ensure that the router
interface is reachable before BGP advertises the network to peers. If the router
interface you specify is reachable, BGP advertises the route to its peers. If the
router interface you specify is not reachable, the route is not added to BGP and
is consequentially not advertised to BGP peers. If the router interface you
specify becomes unreachable, BGP withdraws the route from its peers.

 By selecting “No” to the check reachability option, you can specify that the
network prefix always be advertised whether reachable from the VR or not. By
default, the network prefix must be reachable from the VR before BGP
advertises the route to peers. If you enable check reachability, the route can be
connected.

 You can assign a weight value to the network prefix. The weight is an attribute
that you can assign locally to a route; it is not advertised to peers. If there is
more than one route to a destination, the route with the highest weight value is
preferred.

 You can set the attributes of the route to those specified in a route map (see
“Configuring a Route Map” on page 38). BGP advertises the route with the route
attributes specified in the route map.

Optional BGP Configurations  115

 Concepts & Examples ScreenOS Reference Guide

Conditional Route Advertisement

In the following example, you add a static route to the network 4.4.4.0/24. You
specify that the router interface 5.5.5.0/24 must be reachable from the virtual
router in order for BGP to advertise the 4.4.4.0/24 route to peers. If the 5.5.5.0/24
network is not reachable, BGP does not advertise the 4.4.4.0/24 network. See
Figure 16.

Figure 16: Conditional BGP Route Advertisement Example

4.4.4.0/24

5.5.5.0/24

Internet

Route to 4.4.4.0/24 is only advertised

if 5.5.5.0/24 is reachable.

WebUI
Network > Routing > Virtual Routers > Edit (for trust-vr) > Edit BGP Instance
> Networks: Enter the following, then click Add:

IP/Netmask: 4.4.4.0/24
Check Reachability:
Yes: (select), 5.5.5.0/24

CLI
set vrouter trust-vr protocol bgp network 4.4.4.0/24 check 5.5.5.0/24
save

Setting the Route Weight

In the following example, you set a weight value of 100 for the route 4.4.4.0/24.
(You can specify a weight value between 0 and 65535.)

WebUI
Network > Routing > Virtual Routers > Edit (for trust-vr) > Edit BGP Instance
> Networks: Enter the following, then click Add:

IP/Netmask: 4.4.4.0/24
Weight: 100

CLI
set vrouter trust-vr protocol bgp network 4.4.4.0/24 weight 100
save

116  Optional BGP Configurations

 Chapter 5: Border Gateway Protocol

Setting Route Attributes

In the following example, you configure a route map setattr that sets the metric for
the route to 100. You then configure a static route in BGP that uses the route map
setattr. (You do not need to set the route map to match the network prefix of the
route entry.)

WebUI
Network > Routing > Virtual Router > Route Map (for trust-vr) > New: Enter
the following, then click OK:

Map Name: setattr

Sequence No.: 1
Action: Permit (select)
Set Properties:
Metric: (select), 100

Network > Routing > Virtual Routers > Edit (for trust-vr) > Edit BGP Instance
> Networks: Enter the following, then click Add:

IP/Netmask: 4.4.4.0/24
Route Map: setattr (select)

CLI
set vrouter trust-vr route-map name setattr permit 1
set vrouter trust-vr route-map setattr 1 metric 100
set vrouter trust-vr protocol bgp network 4.4.4.0/24 route-map setattr
save

Route-Refresh Capability
The BGP route-refresh feature as defined in RFC 2918 provides a soft reset
mechanism that allows the dynamic exchange of route refresh requests and routing
information between BGP peers and the subsequent re-advertisement of the
outbound or inbound routing table.

Routing policies for a BGP peer using route-maps might impact inbound or
outbound routing table updates because whenever a route policy change occurs, the
new policy takes effect only after the BGP session is reset. A BGP session can be
cleared through a hard or soft reset.

NOTE: A hard reset is disruptive because active BGP sessions are torn down and brought
back up.

A soft reset allows the application of a new or changed policy without clearing an
active BGP session. The route-refresh feature allows a soft reset to occur on a
per-neighbor basis and does not require preconfiguration or extra memory.

A dynamic inbound soft reset is used to generate inbound updates from a neighbor.
An outbound soft reset is used to send a new set of updates to a neighbor.
Outbound resets don't require preconfiguration or routing table update storage.

Optional BGP Configurations  117

 Concepts & Examples ScreenOS Reference Guide

The route refresh feature requires that both BGP peers advertise route-refresh
feature support in the OPEN message. If the route-refresh method is successfully
negotiated, either BGP peer can use the route-refresh feature to request full routing
information from the other end.

NOTE: Use the get neighbor ip_addr command, an administrator can check whether the
route-refresh capability is negotiated. The command also displays counters, such
as the number of times the route-refresh request is sent or received.

Requesting an Inbound Routing Table Update

In this example, you request the inbound routing table of the neighboring peer at
10.10.10.10 to be sent to the trust-vr of the local BGP peer by using the soft-in
command.

NOTE: If the route refresh feature is not available, the command throws an exception
when the administrator tries to use it.

WebUI
This feature is not available in the WebUI.

CLI
clear vrouter trust-vr protocol bgp neighbor 10.10.10.10 soft-in

Requesting an Outbound Routing Table Update

In this example, you send the full routing table for the trust-vr through updates from
the local BGP peer to the neighboring peer at 10.10.10.10 by using the soft-out
command.

WebUI
This feature is not available in the WebUI.

CLI
clear vrouter trust-vr protocol bgp neighbor 10.10.10.10 soft-out

Configuring Route Reflection

Because an IBGP router cannot readvertise routes learned from one IBGP peer to
another IBGP peer (see “External and Internal BGP” on page 103), a full mesh of
IBGP sessions is required where each router in a BGP AS is a peer to every other
router in the AS.

NOTE: Having a full mesh does not mean each pair of routers needs to be directly
connected, but each router needs to be able to establish and maintain an IBGP
session with every other router.

A full-mesh configuration of IBGP sessions does not scale well. For example, in an
AS with 8 routers, each of the 8 routers would need to peer with the 7 other routers,
which can be calculated with this formula:

118  Optional BGP Configurations

 Chapter 5: Border Gateway Protocol

x x–1 2
For an AS containing 8 routers, the number of full-mesh IBGP sessions would be 28.

Route reflection is a method for solving the IBGP scalability problem (described in
RFC 1966). A route reflector is a router that passes IBGP learned routes to specified
IBGP neighbors (clients), thus eliminating the need for full-mesh sessions. The route
reflector and its clients make up a cluster, which you can further identify with a
cluster ID. Routers outside of the cluster treat the entire cluster as a single entity,
instead of interfacing with each individual router in full mesh. This arrangement
greatly reduces overhead. The clients exchange routes with the route reflector, while
the route reflector reflects routes between clients.

The local virtual router (VR) of the security device can act as a route reflector and
can be assigned a cluster ID. If you specify a cluster ID, the BGP routing instance
appends the cluster ID to the Cluster-List attribute of a route. The cluster ID helps
prevent routing loops as the local BGP routing instance drops a route when its
cluster ID appears in the route’s cluster list.

NOTE: Before you can configure a cluster ID, the BGP routing instance must be disabled.

After you set up a route reflector on the local VR, you then define the route
reflector’s clients. You can specify individual IP addresses or a peer-group for the
clients. You do not need to configure anything on the clients.

In the following example, the EBGP router advertises the 5.5.5.0/24 prefix to Client
3. Without route reflection, Client 3 advertises the route to Device-A, but Device-A
does not readvertise that route to Clients 1 and 2. If you configure Device-A as the
route reflector with Clients 1, 2, and 3 as its clients, Device-A readvertises routes
received from Client 3 to Clients 1 and 2. See Figure 17.

Figure 17: BGP Route Reflection Example

Autonomous Autonomous
System System
Number Autonomous Systems Number

AS 65000 AS 65500

Router ID
Client 1 2.2.2.250
Router ID
1.1.3.250

Device-A Client 3 EBGP Peer

Route Reflector Router ID advertising route
Client 2 Router ID 1.1.1.250 to 5.5.5.0/24
Router ID 1.1.1.250
1.1.4.250

Optional BGP Configurations  119

 Concepts & Examples ScreenOS Reference Guide

WebUI
Network > Routing > Virtual Routers > Edit (for trust-vr) > Edit BGP
Instance: Enter the following, then click Apply:

Route reflector: Enable

Cluster ID: 99

> Neighbors: Enter the following, then click Add:

AS Number: 65000
Remote IP: 1.1.2.250

Enter the following, then click Add:

AS Number: 65000
Remote IP: 1.1.3.250

Enter the following, then click Add:

AS Number: 65000
Remote IP: 1.1.4.250

> Configure (for Remote IP 1.1.2.250): Select Reflector Client, then click
OK.

> Configure (for Remote IP 1.1.3.250): Select Reflector Client, then click
OK.

> Configure (for Remote IP 1.1.4.250): Select Reflector Client, then click
OK.

CLI
set vrouter trust-vr protocol bgp reflector
set vrouter trust-vr protocol bgp reflector cluster-id 99
set vrouter trust-vr protocol bgp neighbor 1.1.2.250 remote-as 65000
set vrouter trust-vr protocol bgp neighbor 1.1.2.250 reflector-client
set vrouter trust-vr protocol bgp neighbor 1.1.3.250 remote-as 65000
set vrouter trust-vr protocol bgp neighbor 1.1.3.250 reflector-client
set vrouter trust-vr protocol bgp neighbor 1.1.4.250 remote-as 65000
set vrouter trust-vr protocol bgp neighbor 1.1.4.250 reflector-client
save

Configuring a Confederation
Like route reflection (see “Configuring Route Reflection” on page 118),
confederations are another approach to solving the problem of full-mesh scaling in
an IBGP environment and are described in RFC 1965. A confederation splits an
autonomous system into several smaller ASs, with each sub-AS a fully meshed IBGP
network. A router outside the confederation sees the entire confederation as a
single autonomous system with a single identifier; the sub-AS networks are not
visible outside the confederation. Sessions between routers in two different sub-ASs
in the same confederation, known as EIBGP sessions, are essentially EBGP sessions
between autonomous systems, but the routers also exchange routing information as
if they were IBGP peers. Figure 18 illustrates BGP confederations.

120  Optional BGP Configurations

 Chapter 5: Border Gateway Protocol

Figure 18: BGP Confederations

Autonomous Systems

AS 65000 (Confederation)

Sub-AS 65001 Sub-AS 65003 AS 65500

Sub-AS 65002
EBGP EBGP EBGP

IBGP IBGP IBGP

Sub-Autonomous Systems

For each router in a confederation, you need to specify the following:

 The sub-AS number (this is the AS number that you specify when you create the
BGP routing instance)

 The confederation to which the sub-AS belongs (this is the AS number that is
visible to BGP routers outside the confederation)

 The peer sub-AS numbers in the confederation

 Whether the confederation supports RFC 1965 (the default) or RFC 3065

NOTE: The AS-Path attribute (see “Path Attributes” on page 103) is normally composed of
a sequence. ASs traversed by the routing update. RFC 3065 allows for the AS-Path
attribute to include the member ASs in the local confederation traversed by the
routing update.

Figure 19 shows the security device as a BGP router in sub-AS 65003 that belongs to
the confederation 65000. The peer sub-ASs in confederation 65000 are 65002 and
65003.

Figure 19: BGP Confederation Configuration Example

AS 65000 (Confederation)

Sub-AS 65001 Sub-AS 65002 Sub-AS 65003

Security Device

Sub-Autonomous Systems

Optional BGP Configurations  121

 Concepts & Examples ScreenOS Reference Guide

WebUI
Network > Routing > Virtual Routers > Edit (for trust-vr) > Create BGP
Instance: Enter the following, then click Apply:

AS Number (required): 65003

> Confederation: Enter the following, then click Apply:

Enable: (select)
ID: 65000
Supported RFC: RFC 1965 (select)

Enter the following, then click Add:

Peer member area ID: 65001

Enter the following, then click Add:

Peer member area ID: 65002

> Parameters: Select BGP Enable

CLI
set vrouter trust-vr protocol bgp 65003
set vrouter trust-vr protocol bgp confederation id 65000
set vrouter trust-vr protocol bgp confederation peer 65001
set vrouter trust-vr protocol bgp confederation peer 65002
set vrouter trust-vr protocol bgp enable
save

BGP Communities
The communities path attribute provides a way of grouping destinations (called
communities), which a BGP router can then use to control the routes it accepts,
prefers, or redistributes to peers. A BGP router can either append communities to a
route (if the route does not have a communities path attribute) or modify the
communities in a route (if the route contains a communities path attribute). The
communities path attribute provides an alternative to distributing route information
based on IP address prefixes or AS path attribute. You can use the communities
path attribute in many ways, but its primary purpose is to simplify configuration of
routing policies in complex networking environments.

RFC 1997 describes the operation of BGP communities. An AS administrator can

assign the same community to a set of routes that require the same routing
decisions; this is sometimes called route coloring. For example, you can assign one
community value to routes that receive access to the Internet and a different
community value to routes that do not.

122  Optional BGP Configurations

 Chapter 5: Border Gateway Protocol

There are two forms of communities:

 A specific community consists of the AS identifier and a community identifier.

The community identifier is defined by the AS administrator.

 A well-known community signifies special handling for routes that contain these
community values. The following are well-known community values that you
can specify for BGP routes on the security device:

 no-export: Routes with this communities path attribute are not advertised
outside a BGP confederation.

 no-advertise: Routes with this communities path attribute are not

advertised to other BGP peers.

 no-export-subconfed: Routes with this communities path attribute are not

advertised to EBGP peers.

You can use a route map to filter routes that match a specified community list,
remove or set the communities path attributes in routes, or add or delete
communities from the route.

For example, if an ISP provides Internet connectivity to its customers, then all
routes from those customers can be assigned a specific community number. Those
customer routes are then advertised to peer ISPs. Routes from other ISPs are
assigned different community numbers and are not advertised to peer ISPs.

Route Aggregation
Aggregation is a technique for summarizing ranges of routing addresses (known as
contributing routes) into a single route entry. There are various optional parameters
you can set when configuring an aggregated route. This section presents examples
of aggregate route configuration.

Aggregating Routes with Different AS-Paths

When you configure an aggregate route, you can specify that the AS-Set field in the
BGP AS-Path path attribute includes the AS paths of all contributing routes. To
specify this, use the AS-Set option in the aggregate route configuration.

NOTE: If you use the AS-Set option with an aggregated route, a change in a contributing
route can cause the path attribute in the aggregated route to also change. This
causes BGP to readvertise the aggregated route with the changed path attribute.

WebUI
Network > Routing > Virtual Routers > Edit (for trust-vr) > Edit BGP Instance
> Aggregate Address: Enter the following, then click Apply:

Aggregate State: Enable (select)

IP/Netmask: 1.0.0.0/8
AS-Set: (select)

Optional BGP Configurations  123

 Concepts & Examples ScreenOS Reference Guide

CLI
set vrouter trust protocol bgp
set vrouter trust protocol bgp aggregate
set vrouter trust protocol bgp aggregate 1.0.0.0/8 as-set
set vrouter trust protocol bgp enable
save

NOTE: You must enable BGP aggregation before enabling BGP.

Suppressing More-Specific Routes in Updates

When you configure an aggregate route, you can specify that more-specific routes
be filtered out from routing updates. (A BGP peer prefers a more-specific route, if
advertised, to an aggregate route.) You can suppress more-specific routes in one of
two ways:

 Use the Summary-Only option in the aggregate route configuration to suppress

all more-specific routes.

 Use the Suppress-Map option in the aggregate route configuration to suppress

routes that are specified by a route map.

In the following example, BGP advertises the aggregate route 1.0.0.0/8, but
more-specific routes are filtered out from outgoing route updates.

WebUI
Network > Routing > Virtual Routers > Edit (for trust-vr) > Edit BGP Instance
> Aggregate Address: Enter the following, then click Apply:

Aggregate State: Enable (select)

IP/Netmask: 1.0.0.0/8
Suppress Option: Summary-Only (select)

CLI
set vrouter trust protocol bgp aggregate 1.0.0.0/8 summary-only
save

In the next example, you want routes in the 1.2.3.0/24 range to be filtered out from
updates that include the aggregate route 1.0.0.0/8. To do this, you first configure an
access list that specifies the routes to be filtered out (1.2.3.0/24). You then configure
a route map ‘noadvert’ to permit routes 1.2.3.0/24. You then configure an aggregate
route 1.0.0.0/8 and specify the route map ‘noadvert’ as a suppress option for
outgoing updates.

WebUI
Network > Routing > Virtual Router > Access List (for trust-vr) > New: Enter
the following, then click OK:

Access List ID: 1

Sequence No.: 777
IP/Netmask: 1.2.3.0/24
Action: Permit (select)

124  Optional BGP Configurations

 Chapter 5: Border Gateway Protocol

Network > Routing > Virtual Router > Route Map (for trust-vr) > New: Enter
the following, then click OK:

Map Name: noadvert

Sequence No.: 2
Action: Permit (select)
Match Properties:
Access List (select), 1 (select)

Network > Routing > Virtual Routers > Edit (for trust-vr) > Edit BGP Instance
> Aggregate Address: Enter the following, then click Apply:

Aggregate State: Enable (select)

IP/Netmask: 1.0.0.0/8
Suppress Option: Route-Map (select), noadvert (select)

CLI
set vrouter trust-vr access-list 1 permit ip 1.2.3.0/24 777
set vrouter trust-vr route-map name noadvert permit 2
set vrouter trust-vr route-map noadvert 2 match ip 1
set vrouter trust protocol bgp aggregate 1.0.0.0/8 suppress-map noadvert
save

Selecting Routes for Path Attribute

When you configure an aggregated route, you can specify which routes should or
should not be used to build the BGP AS-Path path attribute of the aggregated route.
Use the Advertise-Map option in the aggregate route configuration to select the
routes. You can use this option with the AS-Set option to select routes that are
advertised with the AS-Set attribute.

In the following example, you configure an aggregate route 1.0.0.0/8 to be

advertised with the AS-Set attribute. The advertised AS-Set attribute consists of all
more-specific routes that fall into the prefix range 1.5.0.0/16, but not the routes that
fall into the prefix range 1.5.6.0/24; you configure the prefix ranges to be included
and excluded in the route map “advertset.”

WebUI
Network > Routing > Virtual Router > Access List (for trust-vr) > New: Enter
the following, then click OK:

Access List ID: 3

Sequence No.: 888
IP/Netmask: 1.5.6.0/24
Action: Deny (select)

Network > Routing > Virtual Router > Access List (for trust-vr) > New: Enter
the following, then click OK:

Access List ID: 3

Sequence No.: 999
IP/Netmask: 1.5.0.0/16
Action: Permit (select)

Optional BGP Configurations  125

 Concepts & Examples ScreenOS Reference Guide

Network > Routing > Virtual Router > Route Map (for trust-vr) > New: Enter
the following, then click OK:

Map Name: advertset

Sequence No.: 4
Action: Permit (select)
Match Properties:
Access List (select), 3 (select)

Network > Routing > Virtual Routers > Edit (for trust-vr) > Edit BGP Instance
> Aggregate Address: Enter the following, then click Apply:

Aggregate State: Enable (select)

IP/Netmask: 1.0.0.0/8
Advertise Map: advertset (select)

CLI
set vrouter trust-vr access-list 3 deny ip 1.5.6.0/24 888
set vrouter trust-vr access-list 3 permit ip 1.5.0.0/16 999
set vrouter trust-vr route-map name advertset permit 4
set vrouter trust-vr route-map advertset 4 match ip 3
set vrouter trust protocol bgp aggregate 1.0.0.0/8 advertise-map advertset
save

Changing Attributes of an Aggregated Route

When you configure an aggregated route, you can set the attributes of the
aggregated route based upon a specified route map. In the following example, you
configure an aggregated route 1.0.0.0/8 that is advertised with the metric 1111 in
outgoing updates.

WebUI
Network > Routing > Virtual Router > Route Map (for trust-vr) > New: Enter
the following, then click OK:

Map Name: aggmetric

Sequence No.: 5
Action: Permit (select)
Set Properties: (select)
Metric: 1111

Network > Routing > Virtual Routers > Edit (for trust-vr) > Edit BGP Instance
> Aggregate Address: Enter the following, then click Apply:

Aggregate State: Enable (select)

IP/Netmask: 1.0.0.0/8
Attribute Map: aggmetric (select)

CLI
set vrouter trust-vr route-map name aggmetric permit 5
set vrouter trust-vr route-map aggmetric 5 metric 1111
set vrouter trust protocol bgp aggregate 1.0.0.0/8 attribute-map aggmetric
save

126  Optional BGP Configurations

Chapter 6
Policy-Based Routing

This chapter describes policy based routing (PBR). PBR provides a flexible routing
mechanism for data forwarding over networks that rely on Application Layer
support such as for antivirus (AV), deep inspection (DI), or Web filtering.

This chapter contains the following sections:

 “Policy Based Routing Overview” on page 128

 “Extended Access-Lists” on page 128

 “Match Groups” on page 128

 “Action Groups” on page 129

 “Route Lookup with PBR” on page 130

 “Configuring PBR” on page 130

 “Configuring an Extended Access List” on page 131

 “Configuring a Match Group” on page 132

 “Configuring an Action Group” on page 133

 “Configuring a PBR Policy” on page 134

 “Binding a PBR Policy” on page 134

 “Viewing PBR Output” on page 135

 “Viewing an Extended Access List” on page 135

 “Viewing a Match Group” on page 136

 “Viewing an Action Group” on page 136

 “Viewing a PBR Policy Configuration” on page 137

 “Viewing a Complete PBR Configuration” on page 137

 “Advanced PBR Example” on page 138

 127
 Concepts & Examples ScreenOS Reference Guide

 “Advanced PBR with High Availability and Scalability” on page 142

Policy Based Routing Overview

PBR enables you to implement policies that selectively cause packets to take
different paths. PBR provides a routing mechanism for networks that rely on
Application Layer support, such as antivirus (AV), deep inspection (DI), or
anti-spam, Web filtering, and/or that require an automatic way to specific
applications.

When a packet enters the security device, ScreenOS checks for PBR as the first part
of the route-lookup process, and the PBR check is transparent to all non-PBR traffic.
PBR is enabled at the interface level and configured within a virtual router context;
but you can choose to bind PBR policies to an interface, a zone, a virtual router (VR),
or a combination of interface, zone, or VRs.

You use the following three building blocks to create a PBR policy:

 Extended access lists

 Match groups

 Action groups

Extended Access-Lists
Extended access-lists list the match criteria you define for PBR policies. PBR match
criteria determine the path of a particular data traffic flow. Match criteria include
the following:

 Source IP address

 Destination IP address

 Source port

 Destination port

 Protocol, such as HTTP

 Quality of Service (QoS) priority (optional)

Match Groups
Match groups provide a way to organize (by group, name and priority) extended
access lists. Match groups associate an extended access-list ID number with a
unique match group name and a match-group ID number. This match-group ID
number defines the order in which you want the security device to process the
extended ACL lists. You can assign multiple extended access-lists to the same
match-group.

128  Policy Based Routing Overview

 Chapter 6: Policy-Based Routing

Action Groups
Action groups specify the route that you want a packet to take. You specify the
“action” for the route by defining the next interface, the next-hop, or both.

Each configured action entry is monitored for reachability as follows:

NOTE: Monitoring reachability does not refer to Layer 3 tracking or Layer 2 Address
Resolution Protocol (ARP) lookups.

 Next-Interface Only Reachability

If you associate the action entry with only a next-interface, link state
determines reachability.

If the next-interface is up, the action entry is reachable. Any interface including
all the logical interfaces, such as tunnel, aggregate, or redundant, that are
visible in the VR in which the policy resides are candidates for next-interface.

For example, if you configure the action entry with a NULL interface, the action
entry is reachable all the time. With a NULL interface as the next interface, PBR
lookup always succeeds; so, ScreenOS stops the route lookup and discards the
packet(s).

 Next-Hop Only Reachability

If you associate the action group with a next-hop only, that next-hop must be
reachable through a route entry in the destination routes routing table. The
configured next-hop is reachable as long as a valid route exists in the
destination routes routing table to resolve the next-hop.

 Next-Interface and Next-Hop Reachability

If you configure both next-interface and next-hop reachability, the configured

next-hop must be reachable through the configured next-interface.

If the next-hop is reachable through the next-interface, the action entry is

reachable. Any interface including all the logical interfaces, such as tunnel,
aggregate, or redundant, that are visible in the VR in which the policy resides
are candidates to be a next-interface.

If the next hop is reachable but the next interface is a NULL interface, ScreenOS
drops the packet. If you configure the action entry with a NULL interface as the
next interface and the next hop as a static route, ScreenOS passes the packet(s)
to the static route.

At the time of configuration, you also assign a sequence number to specify the
order in which you want the action group entry processed.

Policy Based Routing Overview  129

 Concepts & Examples ScreenOS Reference Guide

Route Lookup with PBR

When you enable PBR on an interface, ScreenOS checks all traffic sent to that
interface for PBR. When a packet enters the security device, ScreenOS checks the
in-interface for a PBR policy configuration. If PBR is enabled on that in-interface, the
following actions are applied to the packet:

1. ScreenOS applies the PBR policy bound to the in-interface to the packet.

2. If no interface-level PBR policy exists, then ScreenOS applies the PBR policy
bound to the zone associated with the in-interface to the packet.

3. If no zone-level PBR policy exists, then ScreenOS applies the PBR policy bound
to the VR associated with the in-interface to the packet.

ScreenOS locates the match group and then processes the action group entries. The
first reachable action entry from the action-group with a valid route is used to
forward the packet. If no reachable route exists among the action entries, then a
regular route lookup is performed.

If the action entry is reachable, ScreenOS performs a route lookup with the
preferred interface as the next-interface (if specified) and the next-hop as the IP
address (if specified) instead of using the destination IP. If a route matches the
indicated next-interface and next-hop, ScreenOS forwards the packet. Otherwise,
ScreenOS uses the destination IP address.

NOTE: For more information about route lookup, see Volume 2: Fundamentals.

Configuring PBR
Figure 20 shows one way PBR differentiates service-traffic paths by sending HTTP
traffic along one path and HTTPS traffic along another. Figure 20 shows two nodes,
one at 172.18.1.10 and another at 172.18.2.10. When the security device receives
HTTP traffic, ScreenOS routes the traffic through the 172.24.76.1 router; and when
the security device receives HTTPS traffic, ScreenOS routes the traffic through the
172.24.76.2 router.

The opposite is true for the 172.18.2.10 node. HTTP traffic from the 172.18.2.10
node flows to the 172.24.76.2 router, and HTTPS traffic flows to the 172.24.76.1
router.

130  Route Lookup with PBR

 Chapter 6: Policy-Based Routing

Figure 20: Routing HTTP and HTTPS Traffic with Policy Based Routing
172.24.76.1 172.24.76.2
Left Router Right Router

172.24.76.71/22
HTTP traffic flows from 172.18.2.10/24 to the 172.24.76.2 router
HTTPS traffic flows from 172.18.1.10/24 to the 172.24.76.1 router

10.25.10.0/24

172.18.1.10/24 172.18.2.10.24

Configuring an Extended Access List

You can configure an extended access list with the web user interface (WebUI) or
the command line interface (CLI) from within a virtual router context. First, you
configure the extended access list on the ingress virtual router (VR).

In this example on page 131, the ingress VR is the trust-vr. If you are using the CLI,
you need to enter the virtual router context. This example requires two access lists:
10 and 20. The access sequence number is a number from 1 to 99. Entries 1 and 2
are required for each extended access list.

NOTE: Optionally, you can also add a type of service (TOS) number, which is a number
from 1 to 255. A TOS number is not required in this example.

Access list 10 defines the source IP address as 172.18.1.10, the destination port as
80, and the protocol as TCP. The destination point for access list 10 defines the
destination IP address as 172.18.2.10, the destination port as 443, and the protocol
as TCP.

Access list 20 defines the source IP address as 172.18.2.10, the destination port as
443, and the protocol as TCP. The destination point for access list 10 defines the
destination IP address as 172.18.1.10, the destination port as 80, and the protocol
as TCP.

In the CLI after configuring the extended access list, you exit the virtual router
context. The WebUI example only shows the creation of access list 10.

Configuring PBR  131

 Concepts & Examples ScreenOS Reference Guide

WebUI
Network > Routing > PBR > Extended ACL List: Select the virtual router from
the drop-down list, then click New to view the Configuration page.

Enter the following information to create access list 10 entries:

Creating Access List 10

Extended ACL ID: 10
Sequence No.: 1
Source IP Address/Netmask: 172.18.1.10/32
Destination Port: 80-80
Protocol: TCP

Click OK. ScreenOS returns you to a list of access lists.

Click New to configure a second entry for access list 10 and enter the following
information:

Creating Access List 10

Extended ACL ID : 10
Sequence No.: 2
Source IP Address/Netmask: 172.18.2.10/32
Destination Port: 443-443
Protocol: TCP

Click OK. ScreenOS returns you to a list of access lists.

CLI
set vrouter trust-vr
set access-list extended 10 src-ip 172.18.1.10/32 dest-port 80-80 protocol tcp
entry 1
set access-list extended 10 src-ip 172.18.2.10/32 dest-port 443-443 protocol tcp
entry 2
set access-list extended 20 src-ip 172.18.2.10/32 dest-port 80-80 protocol tcp
entry 1
set access-list extended 20 src-ip 172.18.1.10/32 dest-port 443-443 protocol tcp
entry 2
exit

Configuring a Match Group

You can configure a match group from within a virtual router context.

In the example on page 131, you need to configure two match-groups: Left Router
and Right Router. You bind extended access list 10 to Left Router and extended
access list 20 to Right Router. A match group name is a unique identifier of no more
than 31 alphanumeric characters.

The ingress VR is the trust-vr. If you are using the CLI, you need to enter the virtual
router context. In the CLI after configuring the extended access list, you exit the
virtual router context.

The WebUI example only shows the creation of a match group for Left Router.

132  Configuring PBR

 Chapter 6: Policy-Based Routing

WebUI
Network > Routing > PBR > Match Group > Select the correct virtual router
from the drop-down list, then click New to view the Match Group Configuration
page. Enter the following information to configure Left Router:

Match Group Name: left_router

Sequence No.: 1
Extended ACL: Select 10 from the drop-down list.

CLI
set vrouter trust-vr
set match-group name left_router
set match-group left ext-acl 10 match-entry 1
set match-group name right_router
set match-group right ext-acl 20 match-entry 1
exit

Configuring an Action Group

You can configure an action group within a virtual routing context.

In the example on page 131 two different action groups are possible: the security
device can forward to traffic to the left router or the right router. For this reason, you
need to configure two different action groups.

To configure these two action-groups, you perform the following tasks:

1. Enter the virtual routing context. In this example, the virtual router is the
trust-vr.

2. Name the action-group with a meaningful, unique name. In this example, the
names action-right and action-left are descriptive of the possible traffic flows.

3. Configure the action-group details. In this example, you set the next-hop
address for each action-group and then assign a number to indicate the
processing priority. In this example, the priority of each action-group is 1.

WebUI
Network > Routing > PBR > Action Group > Click New to view the
Configuration page

CLI
set vrouter trust-vr
set action-group name action-right
set action-group action-right next-hop 172.24.76.2 action-entry 1
set action-group name action-left
set action-group action-left next-hop 172.24.76.1 action-entry 1
exit

Configuring PBR  133

 Concepts & Examples ScreenOS Reference Guide

Configuring a PBR Policy

You can configure a PBR policy from within a virtual router context.

Each PBR policy needs to have a unique name. In this example, the policy is named
redirect-policy.

A PBR policy can contain a match group name and action group name. In this
example, traffic can flow two different ways, so two different statements are
required: action-left with sequence number 1 and action-right with sequence
number 2. The policy statement with sequence number 1 is processed first.

WebUI
Network > Routing > PBR > Policy > Click New to view the Configuration
page

CLI
set vrouter trust-vr
set pbr policy name redirect-policy
set pbr policy redirect-policy match-group left action-group action-left 1
set pbr policy redirect-policy match-group right action-group action-right 2
exit

Binding a PBR Policy

You can bind a PBR policy to an interface, a zone, or a virtual router from within a
virtual router context.

Binding a PBR Policy to an Interface

You can bind the PBR policy redirect-policy to the ingress interface. In this
example, the interface is the trust interface.

WebUI
Network > Routing > PBR > Policy Binding

CLI
set interface trust pbr redirect-policy

Binding a PBR Policy to a Zone

You can bind the PBR policy redirect-policy to a zone. In this example, the zone is
the Trust zone.

WebUI
Network > Routing > PBR > Policy Binding

CLI
set zone trust pbr redirect-policy

134  Configuring PBR

 Chapter 6: Policy-Based Routing

Binding a PBR Policy to a Virtual Router

You can bind the PBR policy redirect-policy to a virtual router. In this example, the
virtual router is the trust-vr.

WebUI
Network > Routing > PBR > Policy Binding

CLI
set vrouter trust-vr pbr redirect-policy

Viewing PBR Output

You can view PBR-related information with the WebUI or the CLI.

Viewing an Extended Access List

You can view the entire list of extended access lists from the WebUI or the CLI.

In the CLI you can specify to view one particular extended access list. In the second
CLI example, the sample output shows that two extended access lists exist in the
trust-vr, but the user indicated extended access list 2. As specified, ScreenOS
returned two access-list entries, 10 and 20, for the second extended access list only.

WebUI
Network > Routing > PBR > Access List Ext

CLI 1
get vrouter trust-vr pbr access-list configuration

Sample output:

set access-list extended 1 src-ip 172.16.10.10/32 dest-ip 192.169.10.10/32

dest-port 80-80 protocol tcp entry 1
set access-list extended 1 src-port 200-300 entry 2
set access-list extended 2 dest-port 500-600 protocol udp entry 10
set access-list extended 2 dest-ip 50.50.50.0/24 protocol udp entry 20

CLI 2
get vrouter trust-vr pbr access-list 2

Sample output:

PBR access-list: 2 in vr: trust-vr, number of entries: 2

------------------------------------------------
PBR access-list entry: 10
------------------------
dest port range 500-600
protocols: udp
PBR access-list entry: 20
------------------------
dest ip-address 50.50.50.0/24
protocols: udp

Viewing PBR Output  135

 Concepts & Examples ScreenOS Reference Guide

Viewing a Match Group

You can view match group details from the WebUI or the CLI.

WebUI
Network > Routing > PBR > Match Group

CLI
get vrouter trust-vr pbr match-group config

Sample output:

set match-group name pbr1_mg

set match-group pbr1_mg ext-acl 1 match-entry 1
set match-group name pbr1_mg2
set match-group pbr1_mg2 ext-acl 2 match-entry 10

Viewing an Action Group

You can view action group details from the WebUI or the CLI.

WebUI
Network > Routing > PBR > Action Group

CLI 1
get vrouter trust-vr pbr action-group configuration

Sample output:

set action-group name pbr1_ag

set action-group pbr1_ag next-interface ethernet2 next-hop 10.10.10.2
action-entry 1
set action-group name pbr1_ag2
set action-group pbr1_ag2 next-hop 30.30.30.30 action-entry 10
set action-group pbr1_ag2 next-interface ethernet3 action-entry 20
set action-group pbr1_ag2 next-interface ethernet3 next-hop 60.60.60.60
action-entry 30

CLI 2
get vrouter trust-vr pbr match-group name pbr1_ag2

Sample output:

device-> get vr tr pbr action-group name pbr1_ag2

PBR action-group: pbr1_ag2 in vr: trust-vr number of entries: 3
------------------------------------------------
PBR action-group entry: 10
next-interface: N/A, next-hop: 30.30.30.30
------------------------
PBR action-group entry: 20
next-interface: ethernet3, next-hop: 0.0.0.0
------------------------
PBR action-group entry: 30
next-interface: ethernet3, next-hop: 60.60.60.60
------------------------

136  Viewing PBR Output

 Chapter 6: Policy-Based Routing

Viewing a PBR Policy Configuration

You can view PBR policy configuration details from the WebUI or the CLI. In the CLI
you can choose to view the configuration or you can enter the policy name to view
a single policy configuration.

WebUI
Network > Routing > PBR > Policy

CLI
get vrouter trust-vr pbr policy config

Sample output:

set pbr policy name pbr1_policy

set pbr policy pbr1_policy match-group pbr1_mg2 action-group pbr1_ag2 50
set pbr policy pbr1_policy match-group pbr1_mg action-group pbr1_ag 256

CLI
get vrouter trust-vr pbr policy name pbr1_policy

Sample output:

PBR policy: pbr1_policy in vr: trust-vr number of entries: 2

------------------------------------------------
PBR policy entry: 50
match-group: pbr1_mg2, action-group: pbr1_ag2
------------------------
PBR policy entry: 256
match-group: pbr1_mg, action-group: pbr1_ag
------------------------

Viewing a Complete PBR Configuration

You can view a PBR configuration from the WebUI or the CLI.

WebUI
Network > Routing > PBR > Access List Ext
Network > Routing > PBR > Match Group
Network > Routing > PBR > Action Group
Network > Routing > PBR > Policy

CLI
get vrouter trust-vr pbr configuration

Sample output:

set access-list extended 1 src-ip 172.16.10.10/32 dest-ip 192.169.10.10/32

dest-port 80-80 protocol tcp entry 1
set access-list extended 1 src-port 200-300 entry 2
set access-list extended 2 dest-port 500-600 protocol udp entry 10
set access-list extended 2 dest-ip 50.50.50.0/24 protocol udp entry 20
set match-group name pbr1_mg
set match-group pbr1_mg ext-acl 1 match-entry 1
set match-group name pbr1_mg2
set match-group pbr1_mg2 ext-acl 2 match-entry 10
set action-group name pbr1_ag

Viewing PBR Output  137

 Concepts & Examples ScreenOS Reference Guide

set action-group pbr1_ag next-interface ethernet2 next-hop 10.10.10.2

action-entry 1
set action-group name pbr1_ag2
set action-group pbr1_ag2 next-hop 30.30.30.30 action-entry 10
set action-group pbr1_ag2 next-interface ethernet3 action-entry 20
set action-group pbr1_ag2 next-interface ethernet3 next-hop 60.60.60.60
action-entry 30
set pbr policy name pbr1_policy
set pbr policy pbr1_policy match-group pbr1_mg2 action-group pbr1_ag2 50
set pbr policy pbr1_policy match-group pbr1_mg action-group pbr1_ag 256

Advanced PBR Example

PBR allows you to define and offload only the types of traffic that ScreenOS needs
to process. In processing specific types of traffic, such as traffic requiring antivirus
(AV) scanning, the network does not get bottlenecked by scanning packet types that
do not need to be scanned for viruses.

NOTE: You could also configure PBR to send traffic specific for anti-spam, deep
inspection (DI), intrusion detection and prevention (IDP), Web filtering, or
caching.

You can combine several types of Juniper Networks security devices to work
together to provide services while keeping network processing speed fast and AV
scanning manageable. Figure 21 shows a security device running PBR to segregate
AV traffic from all other traffic (right).

Figure 21: Selective Routing by Traffic Type

TCP Traffic

Security Device with PBR Configured

AV Scanner

PBR policies send HTTP, SMTP,

and POP3 traffic to an AV scanner.

For example, if you want use PBR to offload only HTTP, SMTP, and POP3 traffic for
AV processing, at a minimum you need to use at least one security device with four
available 10/100 interfaces to provide routing and one security device to provide the
application (AV) support.

NOTE: If you have only three 10/100 interfaces available, you can place a switch between
the two security devices and use VLAN tagging (802.1q) to set up the same paths
for the traffic.

138  Advanced PBR Example

 Chapter 6: Policy-Based Routing

In the following example, you perform the following steps to set up the security
device that provides the routing paths:

1. Configure routing.

2. Configure policy based routing.

3. Bind the PBR policies to the appropriate interfaces.

The next sections explain each of these steps. The examples show only CLI
commands and output.

For information about configuring AV, see Volume 4: Attack Detection

and Defense Mechanisms.

Routing
In this example, you need to create two custom zones:

 av-dmz-1 for the trust-vr

 av-dmz-2 for the untrust-vr

To set up the zones, enter the following commands:

set zone name av-dmz-1

set zone name av-dmz-2

Using the information shown in Table 15, you set up four 10/100 Ethernet
interfaces.

Table 15: Interface Configuration for Routing

Interface Name Zone Virtual Router IPv4 Address

E1 trust trust-vr 10.251.10.0/24
E2 av-dmz-1 trust-vr 192.168.100.1/24
E3 av-dmz-2 untrust-vr 192.168.101.1/24
E4 untrust untrust-vr 172.24.76.127/24

To set up the interfaces, enter the following commands:

set interface e1 zone trust vrouter trust-vr ip 10.251.10.0/24

set interface e2 zone av-dmz-1 vrouter trust-vr ip 192.168.100.1/24
set interface e3 zone av-dmz-2 vrouter untrust-vr ip 192.168.101.1/24
set interface e4 zone untrust vrouter untrust-vr ip 172.24.76.127/24

After setting up the zones, interfaces and routes, you need to perform the following
two tasks:

1. Configure a static route from the untrust-vr to the trust-vr. Assign a gateway IP
address of 10.251.10.0/24 and a preference value of 20 to the entry:

set vrouter "untrust-vr"

set route 10.251.10.0/24 vrouter "trust-vr" preference 20
exit

Advanced PBR Example  139

 Concepts & Examples ScreenOS Reference Guide

2. Configure the NULL interface with a preference value greater than zero (0) from
the Trust interface to the Untrust interface:

set vrouter "trust-vr"

set route 0.0.0.0/0 vrouter "untrust-vr" preference 20
exit

You can verify the changes with the get route command:

Routing Table:
IPv4 Dest-Routes for <untrust-vr> (6 entries)
----------------------------------------------------------------------------
ID IP-Prefix Interface Gateway P Pref Mtr Vsys
----------------------------------------------------------------------------
* 6 0.0.0.0/0 eth4 172.24.76.1 C 0 1 Root
* 3 10.251.10.0/24 n/a trust-vr S 20 0 Root
* 4 172.24.76.0/22 eth4 0.0.0.0 C 0 0 Root
* 2 192.168.101.1/32 eth3 0.0.0.0 H 0 0 Root
* 5 172.24.76.127/32 eth4 0.0.0.0 H 0 0 Root
* 1 192.168.101.0/24 eth3 0.0.0.0 C 0 0 Root

IPv4 Dest-Routes for <trust-vr> (5 entries)

------------------------------------------------------------
ID IP-Prefix Interface Gateway P Pref Mtr Vsys
------------------------------------------------------------
* 5 0.0.0.0/0 n/a untrust-vr S 20 0 Root
* 1 10.251.10.0/24 eth1 0.0.0.0 C 0 0 Root
* 4 192.168.100.1/32 eth2 0.0.0.0 H 0 0 Root
* 3 192.168.100.0/24 eth2 0.0.0.0 C 0 0 Root
* 2 10.251.10.1/32 eth1 0.0.0.0 H 0 0 Root

You are now ready to configure PBR.

PBR Elements
After you configure the interfaces and routes, you configure PBR. For PBR to work
correctly, you must configure the following items for the trust-vr:

 Extended access list

 Match group

 Action group

 PBR policy

Extended Access Lists

For this example, you determine that you want to send HTTP (port 80), SMTP (port
110), and POP3 (port 25) traffic for AV processing. To send these three types of
packets to a security device, you set up an extended access list in the trust-vr.

NOTE: You do not need to set up an extended access list for the return traffic because the
security device performs a session lookup before a route lookup and then applies a
PBR policy as necessary. Return traffic has an existing session.

140  Advanced PBR Example

 Chapter 6: Policy-Based Routing

When any client in the 10.251.10.0/24 subnet initiates traffic that uses TCP to
port 80, 110, or 25, you want ScreenOS to match that traffic to extended access list
criteria and to perform the action associated with the access list. The action forces
ScreenOS to route the traffic as you indicate and not like other traffic. Each access
list needs three entries, one for each kind of TCP traffic that you are targeting.

To configure the extended access list for the trust-vr, enter the following commands:

set vrouter "trust-vr"

set access-list extended 10 src-ip 10.251.10.0/24 dest-port 80-80 protocol tcp
entry 1
set access-list extended 10 src-ip 10.251.10.0/24 dest-port 110-110 protocol
tcp entry 2
set access-list extended 10 src-ip 10.251.10.0/24 dest-port 25-25 protocol tcp
entry 3
exit

Match Groups
A match group associates an extended access list with a meaningful name that gets
referenced in the PBR policy. You first enter a virtual router context, then create a
match group, and finally add an entry that associates the newly created match
group name with an access list and entry number.

To create match groups in the trust-vr, enter the following commands:

set vrouter trust-vr

set match-group name av-match-trust-vr
set match-group av-match-trust-vr ext-acl 10 match-entry 1
exit

Action Group
Next, you create an action-group, which indicates where to send the packet. For this
example, you create an action group for the trust-vr with the action set to send the
traffic to the next hop.

CAUTION: If the action is to send traffic to the next interface, the link-state change
will activate/deactivate the routing policy.

With next hop, the action resolves with Address Resolution Protocol (ARP).

For the trust-vr, you redirect traffic with the next hop statement through
192.168.100.254 by entering the following commands:

set vrouter trust-vr

set action-group name av-action-redirect-trust-vr set action-group
av-action-redirect-trust-vr next-hop 192.168.100.254 action-entry 1
exit

Advanced PBR Example  141

 Concepts & Examples ScreenOS Reference Guide

PBR Policies
Next, you define the PBR policy, which requires the following elements:

 PBR policy name

 Match group name

 Action group name

To configure the PBR policy, enter the following commands:

set vrouter trust-vr

set pbr policy name av-redirect-policy-trust-vr
set pbr policy av-redirect-policy-trust-vr match-group av-match-trust-vr
action-group av-action-redirect-trust-vr 1
exit

Interface Binding
Finally, you bind the PBR policy to the ingress interface, e1.

To bind the PBR policy to its ingress interface, enter the following commands:

set interface e1 pbr av-redirect-policy-trust-vr

Advanced PBR with High Availability and Scalability

Using the previous PBR example as a foundation, you can add resilience to your
network with high availability (HA) and/or scalability.

Resilient PBR Solution

A robust PBR solution might include the following device configurations:

 Two security devices that provide networking

 Two other security devices that provide AV scanning

Each pair of devices runs NetScreen Redundancy Protocol (NSRP) in an

Active/Passive configuration to provide failover protection. For the two security
devices that are performing routing, one device takes over the routing function if a
hardware failure occurs. In the case of the pair that is providing the AV scanning, if a
failure occurs in one of the devices, the other device takes over the scanning
function.

NOTE: For more information, see Volume 11: High Availability.

142  Advanced PBR with High Availability and Scalability

 Chapter 6: Policy-Based Routing

Scalable PBR Solution

PBR solutions scale well. If you need more capacity, you can add more security
devices. By dividing the /24 subnet into two /25 subnets, you can configure one
extended access list for the lower /25 subnet and another extended access list for
the higher /25 subnet, then add two security devices to provide scanning services in
the DMZ.

You can also implement load balancing if you create an active/active NSRP
configuration. One device could process traffic from the lower /25 subnet, and the
other device could process traffic from the higher /25 subnet. Each device backs up
the other.

Advanced PBR with High Availability and Scalability  143

 Concepts & Examples ScreenOS Reference Guide

144  Advanced PBR with High Availability and Scalability

Chapter 7
Multicast Routing

This chapter introduces basic multicast routing concepts. It contains the following
sections:

 “Overview” on page 145

 “Multicast Addresses” on page 146

 “Reverse Path Forwarding” on page 146

 “Multicast Routing on Security Devices” on page 147

 “Multicast Routing Table” on page 147

 “Configuring a Static Multicast Route” on page 148

 “Access Lists” on page 149

 “Configuring Generic Routing Encapsulation on Tunnel Interfaces” on

page 149

 “Multicast Policies” on page 151

Overview
Enterprises use multicast routing to transmit traffic, such as data or video streams,
from one source to a group of receivers simultaneously. Any host can be a source,
and the receivers can be anywhere on the Internet.

IP multicast routing provides an efficient method for forwarding traffic to multiple

hosts because multicast-enabled routers transmit multicast traffic only to hosts that
want to receive the traffic. Hosts must signal their interest in receiving multicast
data, and they must join a multicast group in order to receive the data.
Multicast-enabled routers forward multicast traffic only to receivers interested in
receiving the traffic.

Overview  145
 Concepts & Examples ScreenOS Reference Guide

Multicast routing environments require the following elements to forward multicast

information:

 A mechanism between hosts and routers to communicate multicast group

membership information. Security devices support Internet Group
Management Protocol (IGMP) versions 1, 2, and 3. Routers and hosts use IGMP
to transmit membership information only, not to forward or route multicast
traffic. (For information about IGMP, see “Internet Group Management
Protocol” on page 153.)

 A multicast routing protocol to populate the multicast route table and forward
data to hosts throughout the network. Juniper Networks security devices
support Protocol Independent Multicast - Sparse-Mode (PIM-SM) and Protocol
Independent Multicast - Source-Specific Mode (PIM-SSM). (For information
about PIM-SM and PIM-SSM, see “Protocol Independent Multicast” on
page 179.)

Alternatively, you can use the IGMP Proxy feature to forward multicast traffic
without the CPU overhead of running a multicast routing protocol. (For more
information, see “IGMP Proxy” on page 161.)

The following sections introduce basic concepts used in multicast routing.

Multicast Addresses
When a source sends multicast traffic, the destination address is a multicast group
address. Multicast group addresses are Class D addresses from 224.0.0.0 to
239.255.255.255.

Reverse Path Forwarding

When a multicast router receives multicast packets, it uses a process called reverse
path forwarding (RPF) to check the validity of the packets. Before creating a
multicast route, the router performs a route lookup on the unicast route table to
check if the interface on which it received the packet (ingress interface) is the same
interface it must use to send packets back to the sender. If it is, the router creates
the multicast route entry and forwards the packet to the next hop router. If it is not,
the router drops the packet. Multicast routers do not perform this RPF check for
static routes. Figure 22 shows the security device and the multicast packet
processing flow.

146  Overview
 Chapter 7: Multicast Routing

Figure 22: Reverse Path Forwarding

Multicast packet
from 1.1.1.250 ethernet3
arrives at ethernet1. 10.1.1.1

Source external router ethernet1 Security device checks

3.3.3.6 1.1.1.250 1.1.1.1 if the ingress interface 3a. If yes, send multicast
is the same as egress packets to the destination.
interface for packets to
the sender.

3b. If no, drop the packet.

Route Table Lookup

DST IF GATE
0.0.0.0.eth1 ---
10.1.1.0 eth3 ----
1.1.1.0 eth1 ---

Multicast Routing on Security Devices

Juniper Networks security devices have two predefined virtual routers (VRs): a
trust-vr and an untrust-vr. Each virtual router is a separate routing component with
its own unicast and multicast route tables. (For information about unicast route
tables, see “Static Routing” on page 1.) When the security device receives an
incoming multicast packet, it does a route lookup using the routes in the multicast
route table.

Multicast Routing Table

The multicast route table is populated by multicast static routes or routes learned
through a multicast routing protocol. The security device uses the information from
the multicast route table to forward multicast traffic. Security devices maintain a
multicast routing table for each routing protocol in a virtual router.

The multicast routing table contains information specific to the routing protocol plus
the following information:

 Each entry starts with the forwarding state. The forwarding state can be in one
of the following formats: (*, G) or (S, G). The (*, G) format is called a “star
comma G” entry where the * indicates any source and G is a specific multicast
group address. The (S, G) format is called an “S comma G” entry, where S is the
source IP address and G is the multicast group address.

 The upstream and downstream interfaces.

 The reverse path forwarding (RPF) neighbor.

Multicast Routing on Security Devices  147

 Concepts & Examples ScreenOS Reference Guide

Following is an example of a PIM-SM multicast routing table in the trust-vr virtual

router:

trust-vr - PIM-SM routing table

-----------------------------------------------------------------------------
Register - R, Connected members - C, Pruned - P, Pending SPT Alert - G
Forward - F, Null - N, Negative Cache - E, Local Receivers - L
SPT - T, Proxy-Register - X, Imported - I, SGRpt state - Y, SSM Range Group - S
Turnaround Router - K
-----------------------------------------------------------------------------
Total PIM-SM mroutes: 2
(*, 236.1.1.1) RP 20.20.20.10 00:06:24/- Flags: LF
Zone : Untrust
Upstream : ethernet1/2 State : Joined
RPF Neighbor : local Expires : -
Downstream :
ethernet1/2 00:06:24/00:02:57 Join 0.0.0.0 FC
(20.20.20.200/24, 236.1.1.1) 00:06:24/00:00:36 Flags: TXLF Register Prune
Zone : Untrust
Proxy register : (10.10.10.1, 238.1.1.1) of zone Trust
Upstream : ethernet1/1 State : Joined
RPF Neighbor : local Expires : -
Downstream :
ethernet1/2 00:06:24/- Join 236.1.1.1 20.20.20.200 FC

Configuring a Static Multicast Route

You can define a static multicast route from a source to a multicast group (S, G) or
wildcard either the source or multicast group, or both. Static multicast routes are
typically used to support multicast data forwarding from the hosts on interfaces in
IGMP router proxy mode to the routers upstream on the interfaces in IGMP host
mode. (For more information, see “IGMP Proxy” on page 161.) You can also use
static multicast routes to support inter-domain multicast forwarding. You can create
a static route for an (S, G) pair with any input and output interface. You can also
create a static route and wildcard either the source or multicast group, or both by
entering 0.0.0.0. When you configure a static route, you can also specify the
original multicast group address and a different multicast group address on the
outgoing interface.

In this example, you configure a static multicast route from a source with IP address
20.20.20.200 to the multicast group 238.1.1.1. Configure the security device to
translate the multicast group from 238.1.1.1 to 238.2.2.1 on the outgoing interface.

WebUI
Network > Routing > MCast Routing > New: Enter the following, then click
OK:

Source IP: 20.20.20.200

MGroup: 238.1.1.1
Incoming Interface: ethernet1(select)
Outgoing Interface: ethernet3(select)
Translated MGroup: 238.2.2.1

148  Multicast Routing on Security Devices

 Chapter 7: Multicast Routing

CLI
set vrouter trust-vr mroute mgroup 238.1.1.1 source 20.20.20.200 iif ethernet1
oif ethernet3 out-group 238.2.2.1
save

Access Lists
An access list is a sequential list of statements against which a route is compared.
Each statement specifies the IP address/netmask of a network prefix and the
forwarding status (permit or deny the route). In multicast routing, a statement can
also contain a multicast group address. In multicast routing, you create access lists
to permit multicast traffic for specified multicast groups or hosts. Therefore, the
action or forwarding status is always Permit. You cannot create access lists to deny
certain groups or hosts. (For additional information about access lists, see
“Configuring an Access List” on page 40.)

Configuring Generic Routing Encapsulation on Tunnel Interfaces

Encapsulating multicast packets in unicast packets is a common method for
transmitting multicast packets across a non-multicast-aware network and through
IPSec tunnels. Generic Routing Encapsulation (GRE) version 1 is a mechanism that
encapsulates any type of packet within IPv4 unicast packets. Juniper Networks
security devices support GREv1 for encapsulating IP packets in IPv4 unicast
packets. For additional information about GRE, refer to RFC 1701, Generic Routing
Encapsulation (GRE).

On security devices, you enable GRE encapsulation on tunnel interfaces.

NOTE: You can enable GRE on a tunnel interface that is bound to a loopback interface as
long as the loopback interface is on the same zone as the outgoing interface. For
information about loopback interfaces, see “Loopback Interfaces” on page 2-58.

You must enable GRE when you transmit multicast packets through an IPSec VPN
tunnel between a Juniper Networks security device and a third-party device or
router.

Security devices have platform-specific limitations on the number of outgoing

interfaces through which they can transmit multicast packets. In large
hub-and-spoke VPN environments where the security device is the hub, you can
avoid this limitation by creating a GRE tunnel between the router upstream of the
hub-site security device to security devices at the spokes.

In Figure 23, Router-A is upstream of Device-A. Router-A has two GRE tunnels
which terminate at Device-1 and Device-2. Device-A is connected to Device-1 and
Device-2 through VPN tunnels. Before Router-A transmits multicast packets, it first
encapsulates them in IPv4 unicast packets. Device-A receives these packets as
unicast packets and sends them through to Device-1 and Device-2.

Multicast Routing on Security Devices  149

 Concepts & Examples ScreenOS Reference Guide

Figure 23: GRE on Tunnel Interfaces

Source

Internet

Router-A

GRE Tunnels

VPN Tunnels
with GRE
Device-1 Device-2

Receivers Receivers

In this example, you configure the tunnel interface on Device-1. You perform the
following steps:

1. Create the tunnel.1 interface and bind it to ethernet3 and to the Untrust zone
on the trust-vr.

2. Enable GRE encapsulation on tunnel.1.

3. Specify the local and remote endpoints of the GRE tunnel.

This example shows the GRE configuration for the security device only. (For
information about VPNs, see Volume 5: Virtual Private Networks.)

WebUI
Network > Interfaces > New Tunnel IF: Enter the following, then click Apply:

Tunnel Interface Name: tunnel.1

Zone (VR): Untrust (trust-vr)
Unnumbered: (select)
Interface: ethernet3 (trust-vr)

150  Multicast Routing on Security Devices

 Chapter 7: Multicast Routing

Network > Interfaces > Tunnel (tunnel.1): Enter the following, then click
Apply:

Encap: GRE (select)

Local Interface: ethernet3
Destination IP: 3.3.3.1

CLI
set interface tunnel.1 zone untrust
set interface tunnel.1 ip unnumbered interface ethernet3
set interface tunnel.1 tunnel encap gre
set interface tunnel.1 tunnel local-if ethernet3 dst-ip 3.3.3.1
save

Multicast Policies
By default, Juniper Networks security devices do not permit multicast control traffic,
such as IGMP or PIM messages, to cross security devices. To permit multicast
control traffic between zones, you must configure a multicast policy that specifies
the following:

 Source—The zone from which traffic initiates

 Destination—The zone to which traffic is sent

 Multicast group—The multicast group for which you want the security device
to permit multicast control traffic. You can specify one of the following:

 The multicast group IP address

 An access list that defines the multicast group(s) that hosts can join

 The keyword any, to allow multicast control traffic for any multicast group

 Multicast control traffic—The type of multicast control message: IGMP

messages or PIM messages. (For information about IGMP, see “Internet Group
Management Protocol” on page 153. For information about PIM, see “Protocol
Independent Multicast” on page 179.)

In addition, you can specify the following:

 Translated multicast address—The security device can translate a multicast

group address in an internal zone to a different address on the egress interface.
To translate a group address, you must specify both the original multicast
address and the translated multicast group address in the multicast policy.

 Bi-directional—You can create a bidirectional policy to apply it to both

directions of traffic.

NOTE: Multicast policies control the flow of multicast control traffic only. To allow data
traffic (both unicast and multicast) to pass between zones, you must configure
firewall policies. (For information about policies, see Volume 2: Fundamentals.)

Multicast Policies  151

 Concepts & Examples ScreenOS Reference Guide

You do not sequence multicast policies, as you would firewall policies. Thus, the
latest multicast policy does not overwrite an earlier one, should there be a conflict.
Instead, the security device selects the longest match to resolve any conflict, as
used by other routing protocols. When it finds a smaller subnet to match the
request, it uses that policy.

NOTE: For an example of how to configure a multicast policy for IGMP messages, see
“Creating a Multicast Group Policy for IGMP” on page 165. For an example of how
to configure a multicast policy for PIM messages, see “Defining a Multicast Group
Policy for PIM-SM” on page 189.

152  Multicast Policies

Chapter 8
Internet Group Management Protocol

This chapter describes the Internet Group Management Protocol (IGMP) multicast
protocol on Juniper Networks security devices. It contains the following sections:

 “Overview” on page 154

 “Hosts” on page 154

 “Multicast Routers” on page 155

 “IGMP on Security Devices” on page 155

 “Enabling and Disabling IGMP on Interfaces” on page 155

 “Configuring an Access List for Accepted Groups” on page 156

 “Configuring IGMP” on page 157

 “Verifying an IGMP Configuration” on page 159

 “IGMP Operational Parameters” on page 160

 “IGMP Proxy” on page 161

 “Configuring IGMP Proxy” on page 163

 “Configuring IGMP Proxy on an Interface” on page 164

 “Multicast Policies for IGMP and IGMP Proxy Configurations” on page 165

 “Setting Up an IGMP Sender Proxy” on page 172

 153
 Concepts & Examples ScreenOS Reference Guide

Overview
The Internet Group Management Protocol (IGMP) multicast protocol is used
between hosts and routers to establish and maintain multicast group memberships
in a network. security devices support the following versions of IGMP:

 IGMPv1, as defined in RFC 1112, Host Extensions for IP Multicasting, defines the
basic operations for multicast group memberships.

 IGMPv2, as defined in RFC 2236, Internet Group Management Protocol,

Version 2, expands on the functionality of IGMPv1.

 IGMPv3, as defined in RFC 3376, Internet Group Management Protocol,

Version 3, adds support for source filtering. Hosts running IGMPv3 indicate
which multicast groups they want to join and the sources from which they
expect to receive multicast traffic. IGMPv3 is required when you run Protocol
Independent Multicast in Source-Specific Multicast (PIM-SSM) mode. (For more
information, see “PIM-SSM” on page 186.)

IGMP provides a mechanism for hosts and routers to maintain multicast group
memberships. Multicast routing protocols, such as PIM, then process the
membership information from IGMP, create entries in the multicast routing table
and forward multicast traffic to hosts throughout the network.

The following sections explain the different types of IGMP messages that hosts and
routers exchange to maintain group membership information throughout the
network. Hosts and routers running newer versions of IGMP can operate with those
running older IGMP versions.

Hosts
Hosts send IGMP messages to join multicast groups and maintain their
memberships in those groups. Routers learn which hosts are members of multicast
groups by listening to these IGMP messages on their local networks. Table 16 lists
the IGMP messages that hosts send and the destination of the messages.

Table 16: IGMP Host Messages

IGMP Version IGMP Message Destination

IGMPv1 and v2 A host sends a membership report when it first joins a multicast group and IP address of the
periodically, once it is a member of the group. The membership report indicates multicast group the host
which multicast group the host wants to join. wants to join
IGMPv3 A host sends a membership report when it first joins a multicast group and 224.0.0.22
periodically, once it is a member of the group. The membership report contains
the multicast group address, the filter-mode, which is either include or exclude,
and a list of sources. If the filter-mode is include, then packets from the addresses
in the source list are accepted. If the filter mode is exclude, then packets from
sources other than those in the source list are accepted.
IGMPv2 A host sends a Leave Group message when it wants to leave the multicast group “all routers group”
and stop receiving data for that group. (224.0.0.2)

154  Overview
 Chapter 8: Internet Group Management Protocol

Multicast Routers
Routers use IGMP to learn which multicast groups have members on their local
network. Each network selects a designated router, called the querier. There is
usually one querier for each network. The querier sends IGMP messages to all hosts
in the network to solicit group membership information. When the hosts respond
with their membership reports, the routers take the information from these
messages and update their list of group memberships on a per-interface basis.
IGMPv3 routers maintain a list which includes the multicast group address,
filter-mode (either include or exclude), and the source list.

NOTE: With IGMPv1, each multicast routing protocol determines the querier for a
network. With IGMPv2 and v3, the router interface with the lowest IP address in
the network is the querier.

Table 17 describes the messages that a querier sends and destinations.

Table 17: IGMP Querier Messages

IGMP Version IGMP Message Destination

IGMPv1, v2 The querier periodically sends general queries to solicit group membership “all hosts” group (224.0.0.1)
and v3 information.
IGMPv2 and The querier sends a group-specific query when it receives an IGMPv2 The multicast group that the host
v3 Leave Group message or an IGMPv3 membership report that indicates a is leaving
change in group membership. If the querier does not receive a response
within a specified interval, then it assumes there are no more members for
that group on its local network and stops forwarding multicast traffic for
that group.
IGMPv3 The querier sends a group-and-source-specific query to verify whether The multicast group that the host
there are any receivers for that particular group and source. is leaving

IGMP on Security Devices

On some routers, IGMP is automatically enabled when you enable a multicast
routing protocol. On Juniper Networks security devices, you must explicitly enable
IGMP and a multicast routing protocol.

Enabling and Disabling IGMP on Interfaces

IGMP is disabled by default on all interfaces. You must enable IGMP in router mode
on all interfaces that are connected to hosts. When in router mode, the security
device runs IGMPv2 by default. You can change the default and run IGMPv1,
IGMPv2 and v3, or only IGMPv3.

Enabling IGMP on an Interface

In this example, you enable IGMP in router mode on the ethernet1 interface, which
is connected to a host.

IGMP on Security Devices  155

 Concepts & Examples ScreenOS Reference Guide

WebUI
Network > Interfaces > Edit (for ethernet1) > IGMP: Enter the following, then
click Apply:

IGMP Mode: Router (select)

Protocol IGMP: Enable (select)

CLI
set interface ethernet1 protocol igmp router
set interface ethernet1 protocol igmp enable
save

Disabling IGMP on an Interface

In this example, you disable IGMP on the ethernet1 interface. The security device
maintains the IGMP configuration, but disables it.

WebUI
Network > Interfaces > Edit (for ethernet1) > IGMP: Clear Protocol IGMP
Enable, then click Apply.

CLI
unset interface ethernet1 protocol igmp enable
save

To delete the IGMP configuration, enter the unset interface interface protocol igmp
router command.

Configuring an Access List for Accepted Groups

There are some security issues you must consider when running IGMP. Malicious
users can forge IGMP queries, membership reports, and leave messages. On
security devices, you can restrict multicast traffic to known hosts and multicast
groups only. In addition, you can also specify the allowed queriers in your network.
You set these restrictions by creating access lists and then applying them to an
interface.

An access list is a sequential list of statements that specifies an IP address and a

forwarding status (permit or deny). In IGMP, access lists must always have a
forwarding status of permit and must specify one of the following:

 Multicast groups that hosts can join

 Hosts from which the IGMP router interface can receive IGMP messages

 Queriers from which the IGMP router interface can receive IGMP messages

After you create an access list, you apply it to an interface. Once you apply an
access list to an interface, that interface accepts traffic only from those specified in
the access list. Therefore, to deny traffic from a particular multicast group, host or
querier, simply exclude it from the access list. (For additional information about
access lists, see “Configuring an Access List” on page 40.)

156  IGMP on Security Devices

 Chapter 8: Internet Group Management Protocol

In this example, you create an access list on the trust-vr. The access list specifies the
following:

 Access list ID is 1.

 Permit traffic for multicast group 224.4.4.1/32.

 Sequence Number of this statement is 1.

After you create the access list, allow the hosts on ethernet1 to join the multicast
group specified in the access list.

WebUI
Network > Routing > Virtual Routers > Access List: > New (for trust-vr):
Enter the following, then click OK:

Access List ID: 1

Sequence No: 1
IP/Netmask: 224.4.4.1/32
Action: Permit (select)

Network > Interfaces > Edit (for ethernet1) > IGMP: Enter the following, then
click OK:

Accept Group’s Access List ID: 1

CLI
set vrouter trust-vr access-list 1 permit ip 224.4.4.1/32 1
set interface ethernet1 protocol igmp accept groups 1
save

Configuring IGMP
To run IGMP on a Juniper Networks security device, you simply enable it in Router
mode on the interfaces that are directly connected to hosts. To ensure the security
of your network, use access lists to limit multicast traffic to known multicast groups,
hosts, and routers.

In Figure 24, the hosts in the Trust zone protected by the security device NS1 are
potential receivers of the multicast stream from the source in the Untrust zone. The
interfaces ethernet1 and ethernet2 are connected to the hosts. The multicast source
is transmitting data to the multicast group 224.4.4.1. Perform the following steps to
configure IGMP on the interfaces that are connected to the hosts:

1. Assign IP addresses to the interfaces and bind them to zones.

2. Create an access list that specifies the multicast group 224.4.4.1/32.

3. Enable IGMP in router mode on ethernet1 and ethernet2.

4. Restrict the interfaces (ethernet1 and ethernet2) to receiving IGMP messages

for the multicast group 224.4.4.1/32.

IGMP on Security Devices  157

 Concepts & Examples ScreenOS Reference Guide

Figure 24: IGMP Configuration Example

ethernet1
10.1.1.1/24

Source

NS1
Source ethernet3
Designated 1.1.1.1/24
Router ethernet 2
10.1.2.1/24

Untrust Zone Trust Zone

WebUI
1. Zones and Interfaces
Network > Interfaces > Edit (for ethernet1): Enter the following, then click
OK:

Zone Name: Trust

IP Address/Netmask: 10.1.1.1/24

Network > Interfaces > Edit (for ethernet2): Enter the following, then click
OK:

Zone Name: Trust

IP Address/Netmask: 10.1.2.1/24

Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:

Zone Name: Untrust

IP Address/Netmask: 1.1.1.1/24
2. Access List
Network > Routing > Virtual Routers > Access List: > New (for trust-vr):
Enter the following, then click OK:

Access List ID: 1

Sequence No: 1
IP/Netmask: 224.4.4.1/32
Action: Permit
3. IGMP
Network > Interfaces > Edit (for ethernet1) > IGMP: Enter the following, then
click Apply:

IGMP Mode: Router (select)

Protocol IGMP: Enable (select)
Accept Group’s Access List ID: 1

158  IGMP on Security Devices

 Chapter 8: Internet Group Management Protocol

Network > Interfaces > Edit (for ethernet2) > IGMP: Enter the following, then
click Apply:

IGMP Mode: Router (select)

Protocol IGMP: Enable (select)
Accept Group’s Access List ID: 1

CLI
1. Zones and Interfaces
set interface ethernet1 zone trust
set interface ethernet1 ip 10.1.1.1/24
set interface ethernet2 zone trust
set interface ethernet2 ip 10.2.1.1/24
2. Access List
set vrouter trust access-list 1 permit ip 224.4.4.1/32 1
3. IGMP
set interface ethernet1 protocol igmp router
set interface ethernet1 protocol igmp accept groups 1
set interface ethernet1 protocol igmp enable
set interface ethernet2 protocol igmp router
set interface ethernet2 protocol igmp accept groups 1
set interface ethernet2 protocol igmp enable
save

After you configure IGMP on ethernet1 and ethernet2, you must configure a
multicast routing protocol, such as PIM, to forward multicast traffic. (For
information about PIM, see “Protocol Independent Multicast” on page 179.)

Verifying an IGMP Configuration

To verify connectivity and ensure that IGMP is running properly, there are a number
of exec and get commands that you can use.

 To send either general queries or group-specific queries on a particular

interface, use the exec igmp interface interface query command. For example,
to send a general query from ethernet2, enter the following command:

exec igmp interface ethernet2 query

To send a group-specific query from ethernet2 to the multicast group 224.4.4.1,

enter the following command:

exec igmp interface ethernet2 query 224.4.4.1

 To send a membership report on a particular interface, use the exec igmp

interface interface report command. For example, to send a membership
report from ethernet2, enter the following command:

exec igmp interface ethernet2 report 224.4.4.1

IGMP on Security Devices  159

 Concepts & Examples ScreenOS Reference Guide

You can review the IGMP parameters of an interface by entering the following
command:

device-> get igmp interface

Interface trust support IGMP version 2 router. It is enabled.
IGMP proxy is disabled.
Querier IP is 10.1.1.90, it has up 23 seconds. I am the querier.
There are 0 multicast groups active.
Inbound Router access list number: not set
Inbound Host access list number: not set
Inbound Group access list number: not set
query-interval: 125 seconds
query-max-response-time 10 seconds
leave-interval 1 seconds
last-member-query-interval 1 seconds

This output lists the following information:

 IGMP version (2)

 Querier status (I am the querier.)

 Set and unset parameters

To display information about multicast groups, enter the following CLI command:

device-> get igmp group

total groups matched: 1

multicast group interface last reporter expire ver
*224.4.4.1 trust 0.0.0.0 ------ v2

IGMP Operational Parameters

When you enable IGMP in router mode on an interface, the interface starts up as a
querier. As the querier, the interface uses certain defaults which you can change.
When you set parameters on this level, it affects only the interface that you specify.
Table 18 lists the IGMP querier interface parameters and their defaults.

Table 18: IGMP Querier Interface Parameters and Default Values

IGMP Interface
Parameters Description Default Value
General query interval The interval at which the querier interface sends general queries to the “all 125 seconds
hosts” group (224.0.0.1).
Maximum response The maximum time between a general query and a response from the host. 10 seconds
time
Last Member Query The interval at which the interface sends a Group-Specific query. If it does not 1 second
Interval receive a response after the second Group-Specific query, then it assumes
there are no more members for that group on its local network.

160  IGMP on Security Devices

 Chapter 8: Internet Group Management Protocol

By default, an IGMPv2/v3-enabled router accepts only IGMP packets with a

router-alert IP option, and drops packets that do not have this option. IGMPv1
packets do not have this option and consequently, a security device running
IGMPv2/v3 drops IGMPv1 packets by default. You can configure the security device
to stop checking IGMP packets for the router-alert IP option and accept all IGMP
packets, allowing backward compatibility with IGMPv1 routers. For example, to
allow the ethernet1 interface to accept all IGMP packets:

WebUI
Network > Interfaces > Edit (for ethernet1) > IGMP: Select the following, then
click OK:

Packet Without Router Alert Option: Permit (select)

CLI
set interface ethernet1 protocol igmp no-check-router-alert
save

IGMP Proxy
Routers listen for and send IGMP messages to their connected hosts only; they do
not forward IGMP messages beyond their local network. You can allow interfaces on
a Juniper Networks security device to forward IGMP messages one hop beyond its
local network by enabling IGMP proxy. IGMP proxy enables interfaces to forward
IGMP messages upstream toward the source without the CPU overhead of a
multicast routing protocol.

When you run IGMP proxy on a security device, interfaces connected to hosts
function as routers and those connected to upstream routers function as hosts. The
host and router interfaces are typically in different zones. To allow IGMP messages
to pass between zones, you must configure a multicast policy. Then, to allow
multicast data traffic to pass between zones, you must also configure a firewall
policy.

On devices that support multiple virtual systems, you must configure one interface
in the root virtual system (vsys) and the other interface in a separate vsys. Then,
create a multicast policy to allow multicast control traffic between the two virtual
systems. (For information about virtual systems, see Volume 10: Virtual Systems.)

As the interfaces forward IGMP membership information, they create entries in the
multicast route table of the virtual router to which the interfaces are bound, building
a multicast distribution tree from the receivers to the source. The following sections
describe how the IGMP host and router interfaces forward IGMP membership
information upstream toward the source, and how they forward multicast data
downstream from the source to the receiver.

IGMP Proxy  161

 Concepts & Examples ScreenOS Reference Guide

Membership Reports Upstream to the Source

When a host connected to a router interface on a security device joins a multicast
group, it sends a membership report to the multicast group. When the router
interface receives the membership report from the attached host, it checks if it has
an entry for the multicast group. The security device then takes one of the following
actions:

 If the router interface has an entry for the multicast group, it ignores the
membership report.

 If the router interface does not have an entry for the multicast group, it checks
if there is a multicast policy for the group that specifies to which zone(s) the
router interface should send the report.

 If there is no multicast policy for the group, the router interface does not
forward the report.

 If there is a multicast policy for the group, the router interface creates an
entry for the multicast group and forwards the membership report to the
proxy host interface in the zone specified in the multicast policy.

When a proxy host interface receives the membership report, it checks if it has a (*,
G) entry for that multicast group.

 If it has a (*, G) entry for the group, the host interface adds the router interface
to the list of egress interfaces for that entry.

 If it does not have a (*, G) entry for that group, it creates such an entry; the
ingress interface is the proxy host interface and the egress interface is the
router interface. Then, the proxy host interface forwards the report to its
upstream router.

Multicast Data Downstream to Receivers

When the host interface on the security device receives multicast data for a
multicast group, it checks if there is an existing session for that group.

 If there is a session for the group, the interface forwards the multicast data
based on the session information.

 If there is no session for the group, the interface checks if the group has an (S,
G) entry in the multicast route table.

 If there is an (S, G) entry, the interface forwards the multicast data

accordingly.

 If there is no (S, G) entry, the interface checks if there is a (*, G) entry for
the group.

 If there is no (*, G) entry for the group, the interface drops the packet.

 If there is a (*, G) entry for the group, the interface creates an (S, G) entry.
When the interface receives subsequent multicast packets for that group, it
forwards the traffic to the router interface (the egress interface), which in
turn forwards the traffic to its connected host.

162  IGMP Proxy

 Chapter 8: Internet Group Management Protocol

Figure 25 shows an example of an IGMP proxy host configuration.

Figure 25: IGMP Proxy Host Configuration

Source 4. Source sends multicast data

downstream toward receiver.
3. IGMP proxy host interface checks if it
has (*,G) entry for multicast group: Source 5. IGMP proxy host interface checks for
Designated an existing session for the group:
• If yes, adds router interface to outgoing Router
interfaces in multicast route table entry. • If yes, forwards multicast data.

• If no, creates entry and forwards • If no, checks for (S,G) entry for the
membership report to upstream router. Internet group:

• If yes, forwards multicast data.

• If no, checks for (*,G) entry:
IGMP Proxy
Untrust Host Interface
2. IGMP proxy router interface checks for Zone • If no, drops the data.
an entry for the multicast group:
• If yes, creates an (S,G) entry and
• If yes, ignores the membership report. forwards the data, using the
existing incoming and outgoing
• If no, and if no multicast policy for the Trust interface from the (*,G) entry.
group, drops the membership report. Zone IGMP Proxy
Router Interface
• If no, but if there is a multicast policy for
the group, creates a (*,G) entry in the
multicast route table with the host as 6. IGMP proxy router interface forwards
the iif and the router as the oif. data to the receivers.
Forwards the report upstream to the
host interface on the zone specified in
the multicast policy.

1. Hosts send membership reports

upstream.

Receivers

Configuring IGMP Proxy

This section describes the basic steps required to configure IGMP proxy on a Juniper
Networks security device:

1. Enable IGMP in host mode on upstream interfaces. IGMP proxy is enabled by

default on host interfaces.

2. Enable IGMP in router mode on downstream interfaces.

3. Enable IGMP proxy on router interfaces.

4. Configure a multicast policy that allows multicast control traffic to pass between
zones.

5. Configure a policy to pass data traffic between zones.

IGMP Proxy  163

 Concepts & Examples ScreenOS Reference Guide

Configuring IGMP Proxy on an Interface

When you run IGMP proxy on a security device, you configure the downstream
interface in router mode and the upstream interface in host mode. (Note that an
interface can either be in host mode or router mode, not both.) Additionally, for a
router interface to forward multicast traffic, it must be the querier in the local
network. To allow a non-querier interface to forward multicast traffic, you must
specify the keyword always when you enable IGMP on the interface.

By default, an IGMP interface accepts IGMP messages from its own subnet only. It
ignores IGMP messages from external sources. You must enable the security device
to accept IGMP messages from sources in other subnets when you run IGMP proxy.

In this example, the interface ethernet1 has an IP address of 10.1.2.1/24 and is

connected to the upstream router. You configure the following on ethernet1:

 Enable IGMP in Host mode.

 Allow it to accept IGMP messages from all sources, regardless of subnet.

The interface ethernet3 has an IP address of 10.1.1.1/24 and is connected to the

hosts. You configure the following on ethernet3:

 Enable IGMP in Router mode.

 Allow it to forward multicast traffic even if it is a non-querier.

 Allow it to accept IGMP messages from sources on other subnets.

WebUI
1. Zones and Interfaces
Network > Interfaces > Edit (for ethernet1): Enter the following, then click
OK:

Zone Name: Trust

IP Address/Netmask: 10.1.2.1/24

Network > Interfaces > Edit (for ethernet3): Enter the following, then click
Apply:

Zone Name: Trust

IP Address/Netmask: 10.1.1.1/24
2. IGMP
Network > Interfaces > Edit (for ethernet1) > IGMP: Enter the following, then
click Apply:

IGMP Mode: Host (select)

Protocol IGMP: Enable (select)
Packet From Different Subnet: Permit (select)

164  IGMP Proxy

 Chapter 8: Internet Group Management Protocol

Network > Interfaces > Edit (for ethernet3) > IGMP: Enter the following, then
click OK:

IGMP Mode: Router (select)

Protocol IGMP: Enable (select)
Packet From Different Subnet: Permit (select)
Proxy: (select)
Always (select)

CLI
1. Zones and Interfaces
set interface ethernet1 zone trust
set interface ethernet1 ip 10.1.2.1/24
set interface ethernet3 zone trust
set interface ethernet1 ip 10.1.1.1/24
2. IGMP
set interface ethernet1 protocol igmp host
set interface ethernet1 protocol igmp enable
set interface ethernet1 protocol igmp no-check-subnet
set interface ethernet3 protocol igmp router
set interface ethernet3 protocol igmp proxy
set interface ethernet3 protocol igmp proxy always
set interface ethernet3 protocol igmp enable
set interface ethernet3 protocol igmp no-check-subnet
save

Multicast Policies for IGMP and IGMP Proxy Configurations

Normally, a security device exchanges IGMP messages with its connected hosts
only. With IGMP Proxy, security devices might need to send IGMP messages to a
host or router in another zone. To allow IGMP messages across zones, you must
configure a multicast policy that specifically allows this. When you create a
multicast policy, you must specify the following:

 Source—The zone from which traffic is initiated

 Destination—The zone to which traffic is sent

 Multicast group—Can be a multicast group, an access list that specifies

multicast groups, or “any”

In addition, you can specify that the policy is bidirectional to apply the policy to
both directions of traffic.

Creating a Multicast Group Policy for IGMP

In this example, the router interface is on the Trust zone and the host interface is in
the Untrust zone. You define a multicast policy that allows IGMP messages for the
multicast group 224.2.202.99/32 to pass between the Trust and Untrust zones. You
use the keyword bi-directional to allow traffic in both directions.

IGMP Proxy  165

 Concepts & Examples ScreenOS Reference Guide

WebUI
MCast Policies (From: Trust, To: Untrust) > New: Enter the following, then click
OK:

MGroup Address: IP/Netmask (select) 224.2.202.99/32

Bidirectional: (select)
IGMP Message: (select)

CLI
set multicast-group-policy from trust mgroup 224.2.202.99/32 to untrust
igmp-message bi-directional
save

Creating an IGMP Proxy Configuration

As shown in Figure 26, you configure IGMP proxy on the security devices NS1 and
NS2. They are connected to each other through a VPN tunnel. Perform the following
steps on the security devices at both locations:

1. Assign IP addresses to the physical interfaces bound to the security zones.

2. Create the address objects.

3. Enable IGMP on the host and router interfaces, and enable IGMP proxy on the
router interface. (IGMP proxy is enabled by default on host interfaces.)

a. Specify the keyword always on ethernet1 of NS1 to enable it to forward

multicast traffic even if it is a non-querier.

b. By default, an IGMP interface accepts IGMP packets from its own subnet
only. In the example, the interfaces are on different subnets. When you
enable IGMP, allow the interfaces to accept IGMP packets (queries,
membership reports, and leave messages) from any subnet.

4. Set up routes.

5. Configure the VPN tunnel.

6. Configure a firewall policy to pass data traffic between zones.

7. Configure a multicast policy to pass IGMP messages between zones. In this

example, you restrict multicast traffic to one multicast group (224.4.4.1/32).

166  IGMP Proxy

 Chapter 8: Internet Group Management Protocol

Figure 26: IGMP Proxy Configuration Between Two Devices

NSI-Related Items

Trust Zone Untrust Zone

ethernet3
ethernet1 2.2.2.2/24
10.2.2.1/24
Tunnel Interface
Designated tunnel.1 Receivers
Router NS1 Internet
Source
NS2
Tunnel Interface ethernet1
VPN Tunnel tunnel.1 10.3.1.1/24
ethernet3
3.1.1.1/24
Untrust Zone
Trust Zone
NS2-Related Items

WebUI (NS1)
1. Interfaces
Network > Interfaces > Edit (for ethernet1): Enter the following, then click
Apply:

Zone Name: Trust

Static IP: (select this option when present)
IP Address/Netmask: 10.2.2.1/24
Select the following, then click OK:
Interface Mode: NAT

Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:

Zone Name: Untrust

IP Address/Netmask: 2.2.2.2/24

Network > Interfaces > New Tunnel IF: Enter the following, then click OK:

Tunnel Interface Name: tunnel.1

Zone (VR): Untrust (trust-vr)
Unnumbered: (select)
Interface: ethernet3 (trust-vr)
2. Addresses
Policy > Policy Elements > Addresses > List > New: Enter the following
information, then click OK:

Address Name: branch

IP Address/Domain Name:
IP/Netmask: (select), 10.3.1.0/24
Zone: Untrust

IGMP Proxy  167

 Concepts & Examples ScreenOS Reference Guide

3. IGMP
Network > Interfaces > Edit (for ethernet1) > IGMP: Enter the following, then
click Apply:

IGMP Mode: Host (select)

Protocol IGMP: Enable (select)
Packet From Different Subnet: Permit (select)

Network > Interfaces > Edit (for tunnel.1) > IGMP: Enter the following, then
click Apply:

IGMP Mode: Router (select)

Protocol IGMP: Enable (select)
Packet From Different Subnet: Permit (select)
Proxy (select): Always (select)
4. Routes
Network > Routing > Routing Entries > New: Enter the following, then click
OK:

Network Address / Netmask: 10.3.1.0 / 24

Gateway (select):
Interface: tunnel.1 (select)
5. VPN
VPN > AutoKey Advanced > Gateway > New: Enter the following, then click
OK.

Gateway Name: To_Branch

Security Level: Compatible
Remote Gateway Type:
Static IP Address: (select), IP Address/Hostname: 3.1.1.1
Preshared Key: fg2g4h5j
Outgoing Interface: ethernet3

>> Advanced: Enter the following advanced settings, then click Return to
return to the basic Gateway configuration page:

Security Level: Compatible

Phase 1 Proposal (For Compatible Security Level): pre-g2-3des-sha
Mode (Initiator): Main (ID Protection)
6. Policy
Policies > (From: Untrust, To: Trust) > New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), branch
Destination Address:
Address Book Entry: (select), any (select)
Service: any
Action: Permit

168  IGMP Proxy

 Chapter 8: Internet Group Management Protocol

7. Multicast Policy
MCast Policies > (From: Trust, To: Untrust) > New: Enter the following, then
click OK:

Mgroup Address: IP/Netmask (select): 224.4.4.1/32

Bidirectional: (select)
IGMP Message: (select)

WebUI (NS2)
1. Interfaces
Network > Interfaces > Edit (for ethernet1): Enter the following, then click
OK:

Zone Name: Trust

IP Address/Netmask: 10.3.1.1/24

Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:

Zone Name: Untrust

IP Address/Netmask: 3.1.1.1/24

Network > Interfaces > New Tunnel IF: Enter the following, then click Apply:

Tunnel Interface Name: tunnel.1

Zone (VR): Untrust (trust-vr)
Unnumbered: (select)
Interface: ethernet3 (trust-vr)
2. Addresses
Policy > Policy Elements > Addresses > List > New: Enter the following
information, then click OK:

Address Name: mgroup1

IP Address/Domain Name:
IP/Netmask: (select), 224.4.4.1/32
Zone: Trust

Policy > Policy Elements > Addresses > List > New: Enter the following
information, then click OK:

Address Name: source-dr

IP Address/Domain Name:
IP/Netmask: (select), 10.2.2.1/24
Zone: Untrust
3. IGMP
Network > Interfaces > Edit (for ethernet1) > IGMP: Enter the following, then
click Apply:

IGMP Mode: Router (select)

Protocol IGMP: Enable (select)
Proxy (select): Always (select)

IGMP Proxy  169

 Concepts & Examples ScreenOS Reference Guide

Network > Interfaces > Edit (for tunnel.1) > IGMP: Enter the following, then
click Apply:

IGMP Mode: Host (select)

Protocol IGMP: Enable (select)
Packet From Different Subnet: Permit (select)
4. Routes
Network > Routing > Routing Entries > New (trust-vr): Enter the following,
then click OK:

Network Address / Netmask: 10.2.2.0 / 24

Gateway (select):
Interface: tunnel.1 (select)
5. VPN
VPN > AutoKey Advanced > Gateway > New: Enter the following, then click
OK:

Gateway Name: To_Corp

Security Level: Compatible
Remote Gateway Type:
Static IP Address: (select), IP Address/Hostname: 1.1.1.1
Preshared Key: fg2g4hvj
Outgoing Interface: ethernet3

> Advanced: Enter the following advanced settings, then click Return to
return to the basic Gateway configuration page:

Security Level: Compatible

Phase 1 Proposal (For Compatible Security Level): pre-g2-3des-sha
Mode (Initiator): Main (ID Protection)
6. Policy
Policies > (From: Untrust, To: Trust) > New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), source-dr
Destination Address:
Address Book Entry: (select), mgroup1
Service: ANY
Action: Permit
7. Multicast Policy
MCast Policies > (From: Untrust, To: Trust) > New: Enter the following, then
click OK:

Mgroup Address: IP/Netmask (select): 224.4.4.1/32

Bidirectional: (select)
IGMP Message: (select)

CLI (NS1)
1. Interfaces
Set interface ethernet1 zone trust
set interface ethernet1 ip 10.2.2.1/24
set interface ethernet3 zone untrust
set interface ethernet3 ip 2.2.2.2/24

170  IGMP Proxy

 Chapter 8: Internet Group Management Protocol

set interface tunnel.1 zone untrust

set interface tunnel.1 ip unnumbered interface ethernet3
2. Addresses
set address untrust branch1 10.3.1.0/24
3. IGMP
set interface ethernet1 protocol igmp host
set interface ethernet1 protocol igmp enable
set interface ethernet1 protocol igmp no-check-subnet
set interface tunnel.1 protocol igmp router
set interface tunnel.1 protocol igmp proxy
set interface tunnel.1 protocol igmp proxy always
set interface tunnel.1 protocol igmp enable
set interface tunnel.1 protocol igmp no-check-subnet
4. Routes
set route 10.3.1.0/24 interface tunnel.1
5. VPN Tunnel
set ike gateway To_Branch address 3.1.1.1 main outgoing-interface ethernet3
preshare fg2g4h5j proposal pre-g2-3des-sha
set vpn Corp_Branch gateway To_Branch sec-level compatible
set vpn Corp_Branch bind interface tunnel.1
set vpn Corp_Branch proxy-id local-ip 10.2.2.0/24 remote-ip 10.3.1.0/24 any
6. Policies
set policy name To_Branch from untrust to trust branch1 any any permit
7. Multicast Policies
set multicast-group-policy from trust mgroup 224.4.4.1/32 to untrust
igmp-message bi-directional
save

CLI (NS2)
1. Interfaces
Set interface ethernet1 zone trust
set interface ethernet1 ip 10.3.1.1/24
set interface ethernet3 zone untrust
set interface ethernet3 ip 3.1.1.1/24
set interface tunnel.1 zone untrust
set interface tunnel.1 ip unnumbered interface ethernet3
2. Addresses
set address trust mgroup1 224.4.4.1/32
set address untrust source-dr 10.2.2.1/24
3. IGMP
set interface ethernet1 protocol igmp router
set interface ethernet1 protocol igmp proxy
set interface ethernet1 protocol igmp proxy always
set interface ethernet1 protocol igmp enable
set interface tunnel.1 protocol igmp host
set interface tunnel.1 protocol igmp enable
set interface tunnel.1 protocol igmp no-check-subnet

IGMP Proxy  171

 Concepts & Examples ScreenOS Reference Guide

4. Routes
set route 10.2.2.0/24 interface tunnel.1
5. VPN Tunnel
set ike gateway To_Corp address 2.2.2.2 main outgoing-interface ethernet3
preshare fg2g4hvj proposal pre-g2-3des-sha
set vpn Branch_Corp gateway To_Corp sec-level compatible
set vpn Branch_Corp bind interface tunnel.1
set vpn Branch_Corp proxy-id local-ip 10.3.1.0/24 remote-ip 10.2.2.0/24 any
6. Policy
set policy from untrust to trust source-dr mgroup1 any permit
7. Multicast Policy
set multicast-group-policy from untrust mgroup 224.4.4.1/32 to trust
igmp-message bi-directional
save

Setting Up an IGMP Sender Proxy

In IGMP proxy, the multicast traffic usually travels downstream from the host
interface to the router interface. In certain situations, the source can be in the same
network as the router interface. When a source connected to an interface that is on
the same network as the IGMP router proxy interface sends multicast traffic, the
security device checks for the following:

 A multicast group policy allowing traffic from the source zone to the zone of the
IGMP proxy host interface

 An access list for acceptable sources

If there is no multicast policy between the source zone and the zone of the proxy
IGMP interface or if the source is not on the list of acceptable sources, the security
device drops the traffic. If there is a multicast policy between the source zone and
the zone of the proxy IGMP interface, and the source is on the list of acceptable
sources, then the device creates an (S,G) entry for that interface in the multicast
route table; the incoming interface is the interface to which the source is connected
and the outgoing interface is the IGMP proxy host interface. The security device
then sends the data upstream to the IGMP proxy host interface which sends the
data to all its connected proxy router interfaces, except to the interface connected
to the source.

172  IGMP Proxy

 Chapter 8: Internet Group Management Protocol

Figure 27 shows an example of IGMP sender proxy.

Figure 27: IGMP Sender Proxy

ethernet proxy IGMP interface
sends multicast traffic to all
proxy router interfaces

ethernet1
Receivers Internet
ethernet2
Receivers

multicast traffic

Multicast Route Table

iff = ehternet2
oif = thernet3
Source

In Figure 28, the source is connected to the ethernet2 interface, which is bound to
the DMZ zone on NS2. It is sending multicast traffic to the multicast group
224.4.4.1/32. There are receivers connected to the ethernet1 interface bound to the
Trust zone on NS2. Both ethernet1 and ethernet2 are IGMP proxy router interfaces.
The ethernet3 interface bound to the Untrust zone of NS2 is an IGMP proxy host
interface. There are also receivers connected to the ethernet1 interface bound to the
Trust zone on NS1. Perform the following steps on NS2:

1. Assign IP addresses to the interfaces bound to the security zones.

2. Create the address objects.

3. On ethernet1 and ethernet2:

a. Enable IGMP in router mode and enable IGMP proxy.

b. Specify the keyword always to enable the interfaces to forward multicast

traffic even if they are not queriers.

4. Enable IGMP in Host mode on ethernet3.

5. Set up the default route.

6. Configure firewall policies between the zones.

7. Configure multicast policies between the zones.

NOTE: This example includes only the configuration for NS2, not the configuration for
NS1.

IGMP Proxy  173

 Concepts & Examples ScreenOS Reference Guide

Figure 28: IGMP Sender Proxy Network Example

ethernet1, 10.2.2.1
ethernet1 ethernet1 ethernet3 Trust Zone IGMP
10.2.2.1/24 1.1.1.1/24 2.2.2.2/24 Router Proxy Receivers
Trust Zone Untrust Zone Untrust Zone
IGMP Host Proxy
Receivers
NS1 NS2

Internet
Source
3.2.2.5
Note: Security zones are not
shown in this illustration.
ethernet2, 3.2.2.1/24
DMZ Zone, IGMP
Router Proxy

WebUI (NS2)
1. Interfaces
Network > Interfaces > Edit (for ethernet1): Enter the following, then click
Apply:

Zone Name: Trust

Static IP: (select this option when present)
IP Address/Netmask: 10.2.2.1/24
Select the following, then click OK:
Interface Mode: NAT

Network > Interfaces > Edit (for ethernet2): Enter the following, then click
OK:

Zone Name: DMZ

Static IP: (select this option when present)
IP Address/Netmask: 3.2.2.1/24

Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:

Zone Name: Untrust

Static IP: (select this option when present)
IP Address/Netmask: 2.2.2.2/24
2. Addresses
Policy > Policy Elements > Addresses > List > New: Enter the following
information, then click OK:

Address Name: mgroup1

IP Address/Domain Name:
IP/Netmask: (select), 224.4.4.1/32
Zone: Trust

174  IGMP Proxy

 Chapter 8: Internet Group Management Protocol

Policy > Policy Elements > Addresses > List > New: Enter the following
information, then click OK:

Address Name: source-dr

IP Address/Domain Name:
IP/Netmask: (select), 3.2.2.5/32
Zone: DMZ

Policy > Policy Elements > Addresses > List > New: Enter the following
information, then click OK:

Address Name: proxy-host

IP Address/Domain Name:
IP/Netmask: (select), 2.2.2.2/32
Zone: Untrust
3. IGMP
Network > Interfaces > Edit (for ethernet1) > IGMP: Enter the following, then
click Apply:

IGMP Mode: Router (select)

Protocol IGMP: Enable (select)
Proxy (select): Always (select)

Network > Interfaces > Edit (for ethernet2) > IGMP: Enter the following, then
click Apply:

IGMP Mode: Router (select)

Protocol IGMP: Enable (select)
Proxy (select): Always (select)

Network > Interfaces > Edit (for ethernet3) > IGMP: Enter the following, then
click Apply:

IGMP Mode: Host (select)

Protocol IGMP: Enable (select)
Packet From Different Subnet: Permit (select)
4. Route
Network > Routing > Routing Entries > trust-vr New: Enter the following,
then click OK:

Network Address/Netmask: 0.0.0.0/0

Gateway: (select)
Interface: ethernet3
Gateway IP Address: 2.2.2.250
5. Policy
Policies > (From: DMZ, To: Trust) > New: Enter the following, then click OK:

Source Address:
Address Book Entry: source-dr
Destination Address:
Address Book Entry: (select), mgroup1
Service: ANY
Action: Permit

IGMP Proxy  175

 Concepts & Examples ScreenOS Reference Guide

Policies > (From: DMZ, To: Untrust) > New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), source-dr
Destination Address:
Address Book Entry: (select), mgroup1
Service: ANY
Action: Permit

Policies > (From: Untrust, To: Trust) > New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), proxy-host
Destination Address:
Address Book Entry: (select), mgroup1
Service: ANY
Action: Permit
6. Multicast Policy
MCast Policies > (From: DMZ, To: Untrust) > New: Enter the following, then
click OK:

Mgroup Address: IP/Netmask (select): 224.4.4.1/32

Bidirectional: (select)
IGMP Message: (select)

MCast Policies > (From: DMZ, To: Trust) > New: Enter the following, then click
OK:

Mgroup Address: IP/Netmask (select): 224.4.4.1/32

Bidirectional: (select)
IGMP Message: (select)

MCast Policies > (From: Untrust, To: Trust) > New: Enter the following, then
click OK:

Mgroup Address: IP/Netmask (select): 224.4.4.1/32

Bidirectional: (select)
IGMP Message: (select)

CLI (NS2)
1. Interfaces
set interface ethernet1 zone trust
set interface ethernet1 ip 10.2.2.1/24
set interface ethernet1 nat
set interface ethernet2 zone dmz
set interface ethernet2 ip 3.2.2.1/24
set interface ethernet3 zone untrust
set interface ethernet3 ip 2.2.2.2/24
2. Addresses
set address trust mgroup1 224.4.4.1/32
set address dmz source-dr 3.2.2.5/32
set address untrust proxy-host 2.2.2.2/32

176  IGMP Proxy

 Chapter 8: Internet Group Management Protocol

3. IGMP
set interface ethernet1 protocol igmp router
set interface ethernet1 protocol igmp proxy always
set interface ethernet1 protocol igmp enable
set interface ethernet2 protocol igmp router
set interface ethernet2 protocol igmp proxy always
set interface ethernet2 protocol igmp enable
set interface ethernet3 protocol igmp host
set interface ethernet3 protocol igmp no-check-subnet
set interface ethernet3 protocol igmp enable
4. Route
set vrouter trust-vr route 0.0.0.0/0 interface ethernet3 gateway 2.2.2.250
5. Policies
set policy from dmz to trust source-dr mgroup1 any permit
set policy from dmz to untrust source-dr mgroup1 any permit
set policy from untrust to trust proxy-host mgroup1 any permit
6. Multicast Policies
set multicast-group-policy from dmz mgroup 224.4.4.1/32 to untrust
igmp-message bi-directional
set multicast-group-policy from dmz mgroup 224.4.4.1/32 to trust igmp-message
bi-directional
set multicast-group-policy from trust mgroup 224.4.4.1/32 to untrust
igmp-message bi-directional
save

IGMP Proxy  177

 Concepts & Examples ScreenOS Reference Guide

178  IGMP Proxy

Chapter 9
Protocol Independent Multicast

This chapter explains how to configure Protocol Independent Multicast - Sparse

Mode (PIM-SM) and Protocol Independent Multicast - Source Specific Multicast
(PIM-SSM) on Juniper Networks security devices. It includes the following sections:

 “Overview” on page 180

 “PIM-SM” on page 182

 “Multicast Distribution Trees” on page 182

 “Designated Router” on page 183

 “Mapping Rendezvous Points to Groups” on page 183

 “Forwarding Traffic on the Distribution Tree” on page 184

 “Configuring PIM-SM on Security Devices” on page 186

 “Enabling and Deleting a PIM-SM Instance for a VR” on page 187

 “Enabling and Disabling PIM-SM on Interfaces” on page 187

 “Multicast Group Policies” on page 188

 “Setting a Basic PIM-SM Configuration” on page 190

 “Verifying the Configuration” on page 194

 “Configuring Rendezvous Points” on page 196

 “Configuring a Static Rendezvous Point” on page 196

 “Configuring a Candidate Rendezvous Point” on page 197

 “Security Considerations” on page 198

 “Restricting Multicast Groups” on page 198

 “Restricting Multicast Sources” on page 199

 179
 Concepts & Examples ScreenOS Reference Guide

 “Restricting Rendezvous Points” on page 200

 “PIM-SM Interface Parameters” on page 201

 “Defining a Neighbor Policy” on page 201

 “Defining a Bootstrap Border” on page 202

 “Configuring a Proxy Rendezvous Point” on page 202

 “PIM-SM and IGMPv3” on page 212

Overview
Protocol Independent Multicast (PIM) is a multicast routing protocol that runs
between routers. Whereas the Internet Group Management Protocol (IGMP) runs
between hosts and routers to exchange multicast group membership information,
PIM runs between routers to forward multicast traffic to multicast group members
throughout the network. (For information about IGMP, see “Internet Group
Management Protocol” on page 153.)

180  Overview
 Chapter 9: Protocol Independent Multicast

Figure 29: IGMP

Source

Multicast routing
protocols, such as
PIM-SM, populate the
multicast route table and
forward data to hosts
Internet throughout the network.

Hosts and routers use

IGMP to exchange
multicast group
membership information.

When you run PIM, you must also configure either static routes or a dynamic
routing protocol. PIM is called protocol independent because it uses the route table of
the underlying unicast routing protocol to perform its RPF (reverse path forwarding)
checks, but does not depend on the functionality of the unicast routing protocol.
(For information about RPF, see “Reverse Path Forwarding” on page 146.)

PIM can operate in the following modes:

 PIM-Dense Mode (PIM-DM) floods multicast traffic throughout the network and
then prunes routes to receivers that do not want to receive the multicast traffic.

 PIM-Sparse Mode (PIM-SM) forwards multicast traffic only to those receivers

that request it. Routers running PIM-SM can use the shared path tree or shortest
path tree (SPT) to forward multicast information. (For more information, see
“Multicast Distribution Trees” on page 182.)

 PIM-Source Specific Multicast Mode (PIM-SSM) is derived from PIM-SM. Like

PIM-SM, it forwards multicast traffic to interested receivers only. Unlike PIM-SM,
it immediately forms an SPT to the source.

Juniper Networks security devices support PIM-SM, as defined in

draft-ietf-pim-sm-v2-new-06; and PIM-SSM as defined in RFC 3569, An Overview
of Source-Specific Multicast (SSM). For information about PIM-SM, see
“PIM-SM.” For information about PIM-SSM, see “PIM-SSM” on page 186.

Overview  181
 Concepts & Examples ScreenOS Reference Guide

PIM-SM
PIM-SM is a multicast routing protocol that forwards multicast traffic to interested
receivers only. It can use either a shared distribution tree or the shortest path tree
(SPT) to forward multicast traffic throughout the network. (For information about
multicast distribution trees, see “Multicast Distribution Trees” on page 182.) By
default, PIM-SM uses the shared distribution tree with a rendezvous point (RP) at
the root of the tree. All sources in a group send their packets to the RP, and the RP
sends data down the shared distribution tree to all receivers in a network. When a
configured threshold is reached, the receivers can form an SPT to the source,
decreasing the time it takes the receivers to receive the multicast data.

NOTE: By default, Juniper Networks security devices switch to the SPT upon receiving the
first byte.

Regardless of which tree is used to distribute traffic, only receivers that explicitly
join a multicast group can receive the traffic for that group. PIM-SM uses the unicast
routing table to perform its reverse path forwarding (RPF) lookups when it receives
multicast control messages, and it uses the multicast routing table to send multicast
data traffic to receivers.

Multicast Distribution Trees

Multicast routers forward multicast traffic downstream from the source to the
receivers through a multicast distribution tree. There are two types of multicast
distribution trees:

 Shortest-Path Tree (SPT) - The source is at the root of the tree and forwards the
multicast data downstream to each receiver. This is also referred to as a
source-specific tree.

 Shared Distribution Tree - The source transmits the multicast traffic to the
rendezvous point (RP), which is typically a router at the core of the network.
The RP then forwards the traffic downstream to receivers on the distribution
tree.

182  Overview
 Chapter 9: Protocol Independent Multicast

Figure 30: PIM

Shortest-Path Tree
Shared Distribution Tree
Shared Distribution Tree

Shortest-Path Tree 2. Source sends multicast traffic downstream

towards the rendezvous point (RP).
1. Source sends multicast traffic
downstream to receivers. 3. RP forwards multicast traffic
downstream to receivers.

RP

Receivers Receivers

Designated Router
When there are multiple multicast routers in a multi-access local area network
(LAN), the routers elect a designated router (DR). The DR on the LAN of the source
is responsible for sending the multicast packets from the source to the RP and to
the receivers that are on the source-specific distribution tree. The DR on the LAN of
the receivers is responsible for forwarding join-prune messages from the receivers
to the RP, and for sending multicast data traffic to the receivers in the LAN.
Receivers send join-prune messages when they want to join or leave a multicast
group.

The DR is selected through an election process. Each PIM-SM router in a LAN has a
DR priority that is user configurable. PIM-SM routers advertise their DR priorities in
hello messages they periodically send their neighbors. When the routers receive the
hello messages, they select the router with the highest DR priority as the DR for the
LAN. If multiple routers have the highest DR priority, then the router with the
highest IP address becomes the DR of the LAN.

Mapping Rendezvous Points to Groups

A rendezvous point (RP) sends multicast packets for specific multicast groups. A
PIM-SM domain is a group of PIM-SM routers that have the same RP-group
mappings. There are two ways to map multicast groups to an RP: statically and
dynamically.

Static RP Mapping
To create a static mapping between an RP and a multicast group, you must
configure the RP for the multicast group on each router in the network. Each time
the address of the RP changes, you must reconfigure the RP address.

Overview  183
 Concepts & Examples ScreenOS Reference Guide

Dynamic RP Mapping
PIM-SM also provides a mechanism for dynamically mapping RPs to multicast
groups. First, you configure candidate rendezvous points (C-RPs) for each multicast
group. Then, the C-RPs send Candidate-RP advertisements to one router in the LAN,
called the bootstrap router (BSR). The advertisements contain the multicast group(s)
for which the router is to be an RP and the priority of the C-RP.

The BSR collects these C-RP advertisements and sends them out in a BSR message
to all routers in the domain. The routers collect these BSR messages and use a
well-known hash algorithm to select one active RP per multicast group. If the
selected RP fails, then the router selects a new RP-group mapping from among the
candidate RPs. For information about the BSR selection process, refer to
draft-ietf-pim-sm-bsr-03.txt.

Forwarding Traffic on the Distribution Tree

This section describes how PIM-SM routers send join messages toward the
rendezvous point (RP) of a multicast group and how the RP sends multicast data to
the receivers in the network. In a multicast networking environment, a security
device can function as an RP, a designated router either in the source network or
the receivers’ network, or an intermediate router.

Source Sends Data to a Group

When a source starts sending multicast packets, it transmits the packets on the
network. When the designated router (DR) on that local area network (LAN)
receives the multicast packets, it looks up the outgoing interface and next-hop IP
address toward the RP in the unicast route table. Then the DR encapsulates the
multicast packets in unicast packets, called register messages, and forwards them to
the next hop IP address. When the RP receives the register messages, it
decapsulates the packets and sends the multicast packets down the distribution tree
toward the receivers.

Figure 31: Source Sending Data

Source
1.Source sends multicast
packets downstream.

2. DR encapsulates packets Rendezvous Point (RP)

and sends register
messages to the RP.

Designated Router (DR)

3. RP decapsulates register
messages and sends multicast
packets to receivers.

Receivers Receivers

184  Overview
 Chapter 9: Protocol Independent Multicast

If the data rate from the source DR reaches a configured threshold, the RP sends a
PIM-SM join message toward the source DR so the RP can receive the native
multicast data, instead of the register messages. When the source DR receives the
join message, it sends the multicast packets and the register messages toward the
RP. When the RP receives the multicast packets from the DR, it sends the DR a
register-stop message. When the DR receives the register-stop message, it stops
sending the register messages and sends the native multicast data, which the RP
then sends downstream to the receivers.

Host Joins a Group

When a host joins a multicast group, it sends an IGMP join message to that
multicast group. When the DR on the LAN of the host receives the IGMP join
message, it looks up the RP for the group. It creates a (*,G) entry in the multicast
route table and sends a PIM-SM join message to its RPF neighbor upstream toward
the RP. When the upstream router receives the PIM-SM join message, it performs
the same RP lookup process and also checks if the join message came from an RPF
neighbor. If it did, then it forwards the PIM-SM join message toward the RP. This
continues until the PIM-SM join message reaches the RP. When the RP receives the
join message, it sends the multicast data downstream toward the receiver.

Figure 32: Host Joining a Group

Source

Designated Router (DR) 2. DR sends IGMP join

messages to the RP.

3. RP sends multicast data

downstream to receivers.
Rendezvous
Point RP
1. Hosts send IGMP join
messages for multicast group.

Hosts/Receivers Hosts/Receivers

Each downstream router performs an RPF check when it receives the multicast
data. Each router checks if it received the multicast packets from the same interface
it uses to send traffic toward the RP. If the RPF check is successful, the router then
looks for a matching (*, G) forwarding entry in the multicast route table. If it finds
the (*, G) entry, it places the source in the entry, which becomes an (S, G) entry, and
forwards the multicast packets downstream. This process continues down the
distribution tree until the host receives the multicast data.

When the traffic rate reaches a configured threshold, the DR on the LAN of the host
can form the shortest-path tree directly to the multicast source. When the DR starts
receiving traffic directly from the source, it sends a source-specific prune message
upstream toward the RP. Each intermediate router “prunes” the link to the host off
the distribution tree, until the prune message reaches the RP, which then stops
sending the multicast traffic down that particular branch of the distribution tree.

Overview  185
 Concepts & Examples ScreenOS Reference Guide

PIM-SSM
In addition to PIM-SM, security devices also support PIM-Source-Specific Multicast
(SSM). PIM-SSM follows the source-specific model (SSM) where multicast traffic is
transmitted to channels, not just multicast groups. A channel consists of a source
and multicast group. A receiver subscribes to a channel with a known source and
multicast group. The receivers provide information about the source through
IGMPv3. The designated router on the LAN sends messages to the source and not to
a rendezvous point (RP).

The IANA has reserved the multicast address range 232/8 for the SSM service in
IPv4. If IGMPv3 is running on a device along with PIM-SM, PIM-SSM operations are
guaranteed within this address range. The security device handles IGMPv3
membership reports for multicast groups within the 232/8 address range as follows:

 If the report contains a filter-mode of include, the device sends the report
directly to the sources in the source list.

 If the report contains a filter mode of exclude, the device drops the report. It
does not process (*,G) reports for multicast groups in the 232/8 address range.

The steps for configuring PIM-SSM on a security device are the same as those for
configuring PIM-SM with the following differences:

 You must configure IGMPv3 on interfaces connected to receivers. (IGMPv2 is

enabled by default on security devices.)

 When you configure a multicast group policy, allow join-prune messages.

(Bootstrap messages are not used.)

 You do not configure an Rendezvous Point.

The next sections explain how to configure PIM-SM on security devices.

Configuring PIM-SM on Security Devices

Juniper Networks security devices have two predefined virtual routers (VRs): a
trust-vr and an untrust-vr. Each virtual router is a separate routing component with
its own route tables. Protocol Independent Multicast - Sparse Mode (PIM-SM) uses
the route table of the virtual router on which it is configured to look up the reverse
path forwarding (RPF) interface and next-hop IP address. Therefore, to run PIM-SM
on a security device, you must first configure either static routes or a dynamic
routing protocol on a virtual router, and then configure PIM-SM on the same virtual
router. (For information about virtual routers, see “Routing” on page 13.) Security
devices support the following dynamic routing protocols:

 Open Shortest Path First (OSPF)—For more information, see “Open Shortest
Path First” on page 45.

 Routing Information Protocol (RIP)—For more information, see “Routing

Information Protocol” on page 73.

 Border Gateway Protocol (BGP)—For more information, see “Border Gateway

Protocol” on page 101.

186  Configuring PIM-SM on Security Devices

 Chapter 9: Protocol Independent Multicast

The following sections describe the basic steps for configuring PIM-SM on a security
device:

 Creating and enabling a PIM-SM instance in a VR

 Enabling PIM-SM on interfaces

 Configuring a multicast policy to allow PIM-SM messages to cross the security

device

Enabling and Deleting a PIM-SM Instance for a VR

You can configure one PIM-SM instance for each VR. PIM-SM uses the unicast route
table of the VR to perform its RPF check. After you create and enable a PIM-SM
routing instance on a VR, you can then enable PIM-SM on the interfaces in the VR.

Enabling PIM-SM Instance

In this example, you create and enable a PIM-SM instance for the trust-vr virtual
router.

WebUI
Network > Routing > Virtual Routers > Edit (for trust-vr) > Create PIM
Instance: Select Protocol PIM: Enable, then click Apply.

CLI
device-> set vrouter trust-vr
device(trust-vr)-> set protocol pim
device(trust.vr/pim)-> set enable
device(trust.vr/pim)-> exit
device(trust-vr)-> exit
save

Deleting a PIM-SM Instance

In this example, you delete the PIM-SM instance in the trust-vr virtual router. When
you delete the PIM-SM instance in a virtual router, the security device disables
PIM-SM on the interfaces and deletes all PIM-SM interface parameters.

WebUI
Network > Routing > Virtual Router (trust-vr) > Edit > Delete PIM Instance,
then click OK at the confirmation prompt.

CLI
unset vrouter trust-vr protocol pim
deleting PIM instance, are you sure? y/[n] y
save

Enabling and Disabling PIM-SM on Interfaces

By default, PIM-SM is disabled on all interfaces. After you create and enable PIM-SM
in a virtual router, you must enable PIM-SM on the interfaces within that virtual
router that transmit multicast traffic. If an interface is connected to a receiver, you
must also configure IGMP in router mode on that interface. (For information about
IGMP, see “Internet Group Management Protocol” on page 153.)

Configuring PIM-SM on Security Devices  187

 Concepts & Examples ScreenOS Reference Guide

When you enable PIM-SM on an interface that is bound to a zone, PIM-SM is

automatically enabled in the zone to which that interface belongs. You can then
configure PIM-SM parameters for that zone. Similarly, when you disable PIM-SM
parameters on interfaces in a zone, then all PIM-SM parameters related to the zone
are automatically deleted.

Enabling PIM-SM on an Interface

In this example, you enable PIM-SM on the ethernet1 interface.

WebUI
Network > Interfaces > Edit (for ethernet1) > PIM: Enter the following, then
click Apply:

PIM Instance: (select)

Protocol PIM: Enable (select)

CLI
set interface ethernet1 protocol pim
set interface ethernet1 protocol pim enable
save

Disabling PIM-SM on an Interface

In this example, you disable PIM-SM on the ethernet1 interface. Note that any other
interfaces on which you have enabled PIM-SM are still transmitting and processing
PIM-SM packets.

WebUI
Network > Interfaces > Edit (for ethernet1) > PIM: Clear Protocol PIM
Enable, then click Apply.

CLI
unset interface ethernet1 protocol pim enable
save

Multicast Group Policies

By default, security devices do not allow multicast control traffic, such as PIM-SM
messages, to pass between zones. You must configure a multicast group policy to
allow PIM-SM messages between zones. Multicast group policies control two types
of PIM-SM messages: static-RP-BSR messages and join-prune messages.

Static-RP-BSR Messages
Static-RP-BSR messages contain information about static rendezvous points (RPs)
and dynamic RP-group mappings. Configuring a multicast policy that allows static
RP mappings and bootstrap (BSR) messages between zones enables the security
device to share RP-group mappings across zones within a virtual router or between
two virtual routers. Routers are able to learn about RP-group mappings from other
zones, so you do not have to configure RPs in all zones.

188  Configuring PIM-SM on Security Devices

 Chapter 9: Protocol Independent Multicast

When the security device receives a BSR message, it verifies that it came from its
reverse path forwarding (RPF) neighbor. Then it checks if there are multicast
policies for the multicast groups in the BSR message. It filters out groups not
allowed in the multicast policy and sends the BSR message for the allowed groups
to all destination zones that are allowed by the policy.

Join-Prune Messages
Multicast group policies also control join-prune messages. When the security device
receives a join-prune message for a source and group or source and RP on its
downstream interface, it looks up the RPF neighbor and interface in the unicast
routing table.

 If the RPF interface is on the same zone as the downstream interface, then
multicast policy validation is not necessary.

 If the RPF interface is on another zone, then the security device checks if there
is a multicast policy that allows join-prune messages for the group between the
zone of the downstream interface and the zone of the RPF interface.

 If there is a multicast policy that allows join-prune messages between the

two zones, the security device forwards the message to the RPF interface.

 If there is no multicast policy that allows join-prune messages between the

two zones, then it drops the join-prune message.

Defining a Multicast Group Policy for PIM-SM

In this example, you define a bi-directional multicast group policy that allows all
PIM-SM messages between the Trust and Untrust zones for group 224.4.4.1.

WebUI
Policies (From: Trust, To: Untrust) > New: Enter the following, then click OK:

MGroup Address: IP/Netmask (select) 224.4.4.1/32

Bidirectional: (select)
PIM Message: (select)
BSR-Static RP: (select)
Join/Prune: (select)

CLI
set multicast-group-policy from trust mgroup 224.4.4.1/32 to untrust
pim-message bsr-static-rp join-prune bi-directional
save

Configuring PIM-SM on Security Devices  189

 Concepts & Examples ScreenOS Reference Guide

Setting a Basic PIM-SM Configuration

A security device can function as a rendezvous point (RP), source designated router
(DR), receiver DR, and intermediate router. It cannot function as a bootstrap router.

You can configure PIM-SM on one virtual router (VR) or across two VRs. Perform the
following steps to configure PIM-SM on one virtual router:

1. Configure zones and interfaces.

2. Configure either static routes or a dynamic routing protocol such as Routing

Information Protocol (RIP), Border Gateway Protocol (BGP) or Open Shortest
Path First (OSPF) on a specific virtual router on the security device.

3. Create a firewall policy to pass unicast and multicast data traffic between zones.

4. Create and enable a PIM-SM routing instance on the same virtual router on
which you configured the static routes or a dynamic routing protocol.

5. Enable PIM-SM on interfaces forwarding traffic upstream toward the source or

RP, and downstream toward the receivers.

6. Enable IGMP on interfaces connected to hosts.

7. Configure a multicast policy to permit PIM-SM messages between zones.

When you configure PIM-SM across two VRs, you must configure the RP in the zone
of the VR in which the RP is located. Then, configure a multicast group policy
allowing join-prune and BSR-static-RP messages between the zones in each VR. You
must also export unicast routes between the two VRs to ensure the accuracy of the
reverse path forwarding (RPF) information. For information about exporting routes,
see “Exporting and Importing Routes Between Virtual Routers” on page 42.

NOTE: If a security device is configured with multiple VRs, all VRs must have the same
PIM-SM options.

Some Juniper Networks security devices support multiple virtual systems. (For
information about virtual systems, see Volume 10: Virtual Systems.) When you
configure PIM-SM in a virtual system, it is the same as configuring PIM-SM in the
root system. When you configure PIM-SM on two virtual routers that are each in a
different virtual system, then you must configure a proxy RP. (For information about
configuring a proxy RP, see “Configuring a Proxy Rendezvous Point” on page 202.)

In this example, you configure PIM-SM in the trust-vr. You want hosts in the Trust
zone to receive multicast traffic for the multicast group 224.4.4.1/32. You configure
RIP as the unicast routing protocol in the trust-vr and create a firewall policy to pass
data traffic between the Trust and Untrust zones. You create a PIM-SM instance in
the trust-vr and enable PIM-SM on ethernet1 and ethernet2 in the Trust zone, and
on ethernet3 in the Untrust zone. All interfaces are in route mode. Then, you
configure IGMP on ethernet1 and ethernet2, which are connected to receivers.
Finally, create a multicast policy that permits static-RP-BSR and join-prune
messages between the zones.

190  Setting a Basic PIM-SM Configuration

 Chapter 9: Protocol Independent Multicast

Figure 33: Basic PIM-SM Configuration

Untrust Zone

Source

Designated
Router
Bootstrap
Router

Rendezvous
Point

ethernet3 Receivers
1.1.1.1/24

ethernet1 Trust Zone ethernet2

10.1.1.1/24 10.1.2.1/24

Receivers

WebUI
1. Zones and Interfaces
Network > Interfaces > Edit (for ethernet1): Enter the following, then click
Apply:

Zone Name: Trust

Static IP: (select this option when present)
IP Address/Netmask: 10.1.1.1/24

Select the following, then click OK:

Interface Mode: NAT

Setting a Basic PIM-SM Configuration  191

 Concepts & Examples ScreenOS Reference Guide

Network > Interfaces > Edit (for ethernet2): Enter the following, then click
OK:

Zone Name: Trust

Static IP: (select this option when present)
IP Address/Netmask: 10.1.2.1/24
Select the following, then click OK:
Interface Mode: NAT

Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:

Zone Name: Untrust

IP Address/Netmask: 1.1.1.1/24
2. Addresses
Policy > Policy Elements > Addresses > List > New: Enter the following
information, then click OK:

Address Name: mgroup1

IP Address/Domain Name:
IP/Netmask: (select), 224.4.4.1/32
Zone: Trust

Policy > Policy Elements > Addresses > List > New: Enter the following
information, then click OK:

Address Name: source-dr

IP Address/Domain Name:
IP/Netmask: (select), 6.6.6.1/24
Zone: Untrust
3. IGMP
Network > Interfaces > Edit (for ethernet1) > IGMP: Enter the following, then
click OK:

IGMP Mode: Router (select)

Protocol IGMP: Enable (select)

Network > Interfaces > Edit (for ethernet2) > IGMP: Enter the following, then
click OK:

IGMP Mode: Router (select)

Protocol IGMP: Enable (select)
4. RIP
Network > Routing > Virtual Router (trust-vr) > Edit > Create RIP Instance:
Select Enable RIP, then click OK.

Network > Interfaces > Edit (for ethernet3) > RIP: Enter the following, then
click Apply:

RIP Instance: (select)

Protocol RIP: Enable (select)

192  Setting a Basic PIM-SM Configuration

 Chapter 9: Protocol Independent Multicast

5. PIM-SM
Network > Routing > Virtual Router (trust-vr) > Edit > Create PIM Instance:
Select the following, then click OK.

Protocol PIM: Enable (select)

Network > Interfaces > Edit (for ethernet1) > PIM: Enter the following, then
click Apply:

PIM Instance: (select)

Protocol PIM: Enable (select)

Network > Interfaces > Edit (for ethernet2) > PIM: Enter the following, then
click Apply:

PIM Instance: (select)

Protocol PIM: Enable (select)

Network > Interfaces > Edit (for ethernet3) > PIM: Enter the following, then
click Apply:

PIM Instance: (select)

Protocol PIM: Enable (select)
6. Policy
Policies > (From: Untrust, To: Trust) > New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), source-dr
Destination Address:
Address Book Entry: (select), mgroup1
Service: any
Action: Permit
7. Multicast Policy
MCast Policies (From: Trust, To: Untrust) > New: Enter the following and click
OK:

MGroup Address: IP/Netmask (select) 224.4.4.1/32

Bidirectional: (select)
PIM Message: (select)
BSR Static RP: (select)
Join/Prune: (select)

CLI
1. Zones and Interfaces
set interface ethernet1 zone trust
set interface ethernet1 ip 10.1.1.1/24
set interface ethernet1 nat
set interface ethernet2 zone trust
set interface ethernet2 ip 10.1.2.1/24
set interface ethernet2 nat
set interface ethernet3 zone untrust
set interface ethernet3 ip 1.1.1.1/24

Setting a Basic PIM-SM Configuration  193

 Concepts & Examples ScreenOS Reference Guide

2. Addresses
set address trust mgroup1 224.4.4.1/32
set address untrust source-dr 6.6.6.1/24
3. IGMP
set interface ethernet1 protocol igmp router
set interface ethernet1 protocol igmp enable
set interface ethernet2 protocol igmp router
set interface ethernet2 protocol igmp enable
4. RIP
set vrouter trust-vr protocol rip
set vrouter trust-vr protocol rip enable
set interface ethernet3 protocol rip enable
5. PIM-SM
set vrouter trust-vr protocol pim
set vrouter trust-vr protocol pim enable
set interface ethernet1 protocol pim
set interface ethernet1 protocol pim enable
set interface ethernet2 protocol pim
set interface ethernet2 protocol pim enable
set interface ethernet3 protocol pim
set interface ethernet3 protocol pim enable
6. Policy
set policy from untrust to trust source-dr mgroup1 any permit
7. Multicast Policy
set multicast-group-policy from trust mgroup 224.4.4.1/32 any to untrust
pim-message bsr-static-rp join bi-directional
save

Verifying the Configuration

To verify the PIM-SM configuration, execute the following command:

device-> get vrouter trust protocol pim

PIM-SM enabled
Number of interfaces : 1
SPT threshold : 1 Bps
PIM-SM Pending Register Entries Count : 0
Multicast group accept policy list: 1
Virtual Router trust-vr - PIM RP policy
--------------------------------------------------
Group Address RP access-list
Virtual Router trust-vr - PIM source policy
--------------------------------------------------
Group Address Source access-list

194  Verifying the Configuration

 Chapter 9: Protocol Independent Multicast

To view the multicast route entries, execute the following command:

device-> get igmp group

total groups matched: 1
multicast group interface last reporter expire ver
*224.4.4.1 trust 0.0.0.0 ------ v2

device->get vrouter trust protocol pim mroute

trust-vr - PIM-SM routing table
-----------------------------------------------------------------------------
Register - R, Connected members - C, Pruned - P, Pending SPT Alert - G
Forward - F, Null - N, Negative Cache - E, Local Receivers - L
SPT - T, Proxy-Register - X, Imported - I, SGRpt state - Y, SSM Range Group - S
Turnaround Router - K
-----------------------------------------------------------------------------
Total PIM-SM mroutes: 2

(*, 236.1.1.1) RP 20.20.20.10 01:54:20/- Flags: LF

Zone : Untrust
Upstream : ethernet1/2 State : Joined
RPF Neighbor : local Expires : -
Downstream :
ethernet1/2 01:54:20/- Join 0.0.0.0 FC

(10.10.10.1/24, 238.1.1.1) 01:56:35/00:00:42 Flags: TLF Register

Prune
Zone : Trust
Upstream : ethernet1/1 State : Joined
RPF Neighbor : local Expires : -
Downstream :
ethernet1/2 01:54:20/- Join 236.1.1.1 20.20.20.200
FC

You can verify the following in each route entry:

 The (S, G) state or (*, G) forwarding state

 If the forwarding state is (*, G), the RP IP address; If the forwarding state is (S,
G), the source IP address

 Zone that owns the route

 The “join” status and the incoming and outgoing interfaces

 Timer values

To view the rendezvous points in each zone, execute the following command:

device-> get vrouter trust protocol pim rp

Flags : I - Imported, A - Always(override BSR mapping)
C - Static Config, P - Static Proxy
-----------------------------------------------------------------------------
Trust
238.1.1.1/32 RP: 10.10.10.10 192 Static - C
Registering : 0
Active Groups : 1
238.1.1.1
Untrust
236.1.1.1/32 RP: 20.20.20.10 192 Static - P
Registering : 0

Verifying the Configuration  195

 Concepts & Examples ScreenOS Reference Guide

Active Groups : 1
236.1.1.1
To verify that there is a Reverse Path Forwarding neighbor, execute the following
command:

device-> get vrouter trust protocol pim rpf

Flags : RP address - R, Source address - S
Address RPF Interface RPF Neighbor Flags
-------------------------------------------------------
10.10.11.51 ethernet3 10.10.11.51 R
10.150.43.133 ethernet3 10.10.11.51 S

To view the status of join-prune messages the security device sends to each
neighbor in a virtual router, execute the following command:

device-> get vrouter untrust protocol pim join

Neighbor Interface J/P Group Source
---------------------------------------------------------------------
1.1.1.1 ethernet4:1 (S,G) J 224.11.1.1 60.60.0.1
(S,G) J 224.11.1.1 60.60.0.1

Configuring Rendezvous Points

You can configure a static rendezvous point (RP) when you want to bind a specific
RP to one or more multicast groups. You can configure multiple static RPs, with
each RP mapped to a different multicast group.

You must configure a static RP when there is no bootstrap router in the network.
Although a security device can receive and process bootstrap messages, it does not
function as a bootstrap router.

You can configure a virtual router as a candidate RP (C-RP) when you want to map
RPs dynamically to multicast groups. You can create one C-RP for each zone.

Configuring a Static Rendezvous Point

When you configure a static RP, you specify the following:

 The zone of the static RP

 IP address of the static RP

 An access list that defines the multicast groups of the static RP (For more
information, see “Access Lists” on page 149.)

To ensure that the multicast groups in the access list always use the same RP,
include the keyword always. If you do not include this keyword, and the security
device discovers another RP dynamically mapped to the same multicast groups, it
uses the dynamic RP.

In this example, you create an access list for the multicast group 224.4.4.1, and
then create a static RP for that group. The IP address of the static RP is 1.1.1.5/24.
You specify the keyword always to ensure that the security device always uses the
same RP for that.

196  Configuring Rendezvous Points

 Chapter 9: Protocol Independent Multicast

WebUI
Network > Routing > Virtual Routers > Access List: > New (for trust-vr):
Enter the following, then click OK:

Access List ID: 2

Sequence No.: 1
IP/Netmask: 224.4.4.1/32
Action: Permit

Network > Routing > Virtual Router (trust-vr) > Edit > Edit PIM Instance >
RP Address > New: Select the following, then click OK:

Zone: Trust (select)

Address: 1.1.1.5
Access List: 2
Always: (select)

CLI
set vrouter trust-vr access-list 2 permit ip 224.4.4.1/32 1
set vrouter trust-vr protocol pim zone trust rp address 1.1.1.5 mgroup-list 2 always
save

Configuring a Candidate Rendezvous Point

When you configure a virtual router as a C-RP, you specify the following:

 The zone in which the C-RP is configured

 IP address of the interface that is advertised as the C-RP

 An access list that defines the multicast groups of the C-RP

 The advertised C-RP priority

In this example, you enable PIM-SM on the ethernet1 interface which is bound to
the Trust zone. You create an access list that defines the multicast groups of the
C-RP. Then you create a C-RP in the Trust zone of the trust-vr. You set the priority of
the C-RP to 200.

WebUI
Network > Interfaces > Edit (for ethernet1) > PIM: Enter the following, then
click Apply:

PIM Instance: (select)

Protocol PIM: Enable (select)

Network > Routing > Virtual Routers > Access List: > New (for trust-vr):
Enter the following, then click OK:

Access List ID: 1

Sequence No.: 1
IP/Netmask: 224.2.2.1/32
Action: Permit

Configuring Rendezvous Points  197

 Concepts & Examples ScreenOS Reference Guide

Select Add Seq No: Enter the following, then click OK:

Sequence No.: 2
IP/Netmask: 224.3.3.1/32
Action: Permit

Network > Routing > Virtual Router (trust-vr) > Edit > Edit PIM Instance >
RP Candidate > Edit (Trust Zone): Select the following, then click OK.

Interface: ethernet1 (select)

Access List: 1 (select)
Priority: 200

CLI
setinterface ethernet1 protocol pim
setinterface ethernet1 protocol pim enable
setvrouter trust-vr access-list 1 permit ip 224.2.2.1/32 1
setvrouter trust-vr access-list 1 permit ip 224.3.3.1/32 2
setvrouter trust-vr protocol pim zone trust rp candidate interface ethernet1
mgroup-list 1 priority 200
save

Security Considerations
When you run PIM-SM, there are certain options that you can set at the virtual
router (VR) level to control traffic to and from the VR. Settings defined at the VR
level affect all PIM-SM-enabled interfaces in the VR.

When an interface receives multicast control traffic (IGMP or PIM-SM messages)

from another zone, the security device first checks if there is a multicast policy that
allows the traffic. If the security device finds a multicast policy that allows the
traffic, it checks the virtual router for any PIM-SM options that apply to the traffic.
For example, if you configure the virtual router to accept join-prune messages from
multicast groups specified in an access list, the security device checks if the traffic is
for a multicast group on the list. If it is, then the device allows the traffic. If it is not,
then the device drops the traffic.

Restricting Multicast Groups

You can restrict a VR to forward PIM-SM join-prune messages for a particular set of
multicast groups only. You specify the allowed multicast groups in an access list.
When you use this feature, the VR drops join-prune messages for groups that are
not in the access list.

In this example, you create an access list with ID number 1 that allows the following
multicast groups: 224.2.2.1/32 and 224.3.3.1/32. Then you configure the trust-vr to
accept join-prune messages from the multicast groups in the access list.

198  Security Considerations

 Chapter 9: Protocol Independent Multicast

WebUI
Network > Routing > Virtual Routers > Access List: > New (for trust-vr):
Enter the following, then click OK:

Access List ID: 1

Sequence No: 1
IP/Netmask: 224.2.2.1/32
Action: Permit

Select Add Seq No: Enter the following, then click OK:

Sequence No: 2
IP/Netmask: 224.3.3.1/32
Action: Permit

Network > Routing > Virtual Router (trust-vr) > Edit > Edit PIM Instance:
Select the following, then click Apply:

Access Group: 1 (select)

CLI
set vrouter trust-vr access-list 1 permit ip 224.2.2.1/32 1
set vrouter trust-vr access-list 1 permit ip 224.3.3.1/32 2
set vrouter trust-vr protocol pim accept-group 1
save

Restricting Multicast Sources

You can control the sources from which a multicast group receives data. You
identify the allowed source(s) in an access list, then link the access list to multicast
groups. This prevents unauthorized sources from sending data into your network.
When you use this feature, the security device drops multicast data from sources
not in the list. If the virtual router is the rendezvous point in the zone, it checks the
access list before accepting a register message from a source. The security device
drops register messages that are not from an allowed source.

In this example, you first create an access list with ID number 5 that specifies the
allowed source, 1.1.1.1/32. Then you configure the trust-vr to accept multicast data
for the multicast group 224.4.4.1/32 from the source specified in the access list.

WebUI
Network > Routing > Virtual Routers > Access List: > New (for trust-vr):
Enter the following, then click OK:

Access List ID: 5

Sequence No: 1
IP/Netmask: 1.1.1.1/32
Action: Permit

Network > Routing > Virtual Router (trust-vr) > Edit > Edit PIM Instance >
MGroup: Select the following, then click Add:

MGroup: 224.4.4.1/32
Accept Source: 5 (select)

Security Considerations  199

 Concepts & Examples ScreenOS Reference Guide

CLI
set vrouter trust-vr access-list 5 permit ip 1.1.1.1/32 1
set vrouter trust-vr protocol pim mgroup 224.4.4.1/32 accept-source 5
save

Restricting Rendezvous Points

You can control which rendezvous points (RPs) are mapped to a multicast group.
You identify the allowed RP(s) in an access list, then link the access list to the
multicast groups. When the virtual router (VR) receives a bootstrap message for a
particular group, it checks its list of allowed RPs for that group. If it does not find a
match, then it does not select an RP for the multicast group.

In this example, you create an access list with ID number 6 that specifies the
allowed RP, 2.1.1.1/32. Then you configure the trust-vr to accept the RPs in the
access list for the multicast group, 224.4.4.1/32.

WebUI
Network > Routing > Virtual Routers > Access List: > New (for trust-vr):
Enter the following, then click OK:

Access List ID: 6

Sequence No: 1
IP/Netmask: 2.1.1.1/32
Action: Permit

Network > Routing > Virtual Router (trust-vr) > Edit > Edit PIM Instance >
MGroup: Select the following, then click Add:

MGroup: 224.4.4.1/32
Accept RP: 6 (select)

CLI
set vrouter trust-vr access-list 6 permit ip 2.1.1.1/32 1
set vrouter trust-vr protocol pim mgroup 224.4.4.1/32 accept-rp 6
save

200  Security Considerations

 Chapter 9: Protocol Independent Multicast

PIM-SM Interface Parameters

You can change certain defaults for each interface on which you enable PIM-SM.
When you set parameters on this level, it affects only the interface that you specify.

Table 19 describes the PIM-SM interface parameters and their defaults.

Table 19: PIM-SIM Parameters

PIM-SIM Interface Parameters Description Default Value

Neighbor policy Controls neighbor adjacencies. For Disabled
additional information, see “Defining a
Neighbor Policy” on page 201.
Hello interval Specifies the interval at which the 30 seconds
interface sends hello messages to its
neighboring routers.
Designates router priority Specifies the priority of the interface for 1
the designated router election.
Join-Prune interval Specifies the interval, in seconds, at 60 seconds
which the interface sends join-prune
messages.
Bootstrap border Specifies that the interface is a bootstrap Disabled
border. For additional information, see
“Defining a Bootstrap Border” on
page 202.

Defining a Neighbor Policy

You can control the neighbors with which an interface can form an adjacency.
PIM-SM routers periodically send hello messages to announce themselves as
PIM-SM routers. If you use this feature, the interface checks its list of allowed or
disallowed neighbors and forms adjacencies with those that are allowed.

In this example, you create an access list that specifies the following:

 ID number is 1.

 The first statement permits 2.1.1.1/24.

 The second statement permits 2.1.1.3/24.

Then you specify that ethernet 1 can form an adjacency with the neighbors in the
access list.

WebUI
Network > Routing > Virtual Routers > Access List: > New (for trust-vr):
Enter the following, then click OK:

Access List ID: 1

Sequence No: 1
IP/Netmask: 2.1.1.1/24
Action: Permit

PIM-SM Interface Parameters  201

 Concepts & Examples ScreenOS Reference Guide

Select Add Seq No: Enter the following and click OK:

Sequence No: 2
IP/Netmask: 2.1.1.3/24
Action: Permit

Network > Interfaces > Edit (for ethernet1) > PIM: Enter the following, then
click Apply:

Accepted Neighbors: 1

CLI
set vrouter trust-vr access-list 1 permit ip 2.1.1.1/24 1
set vrouter trust-vr access-list 1 permit ip 2.1.1.3/24 2
set interface ethernet1 protocol pim neighbor-policy 1
save

Defining a Bootstrap Border

An interface that is a bootstrap (BSR) border receives and processes BSR messages,
but it does not forward these messages to other interfaces even if there is a
multicast group policy allowing BSR messages between zones. This ensures that the
RP-to-group mappings always stay within a zone.

In this example, you configure ethernet1 as a bootstrap border.

WebUI
Network > Interfaces > Edit (for ethernet1) > PIM: Select Bootstrap Border,
then click Apply.

CLI
set interface ethernet1 protocol pim boot-strap-border
save

Configuring a Proxy Rendezvous Point

A PIM-SM domain is a group of PIM-SM routers that have the same rendezvous
point (RP)-group mappings. In a PIM-SM domain with dynamic RP-group mappings,
PIM-SM routers in a domain listen to messages from the same bootstrap router
(BSR) to select their RP-group mappings. In a PIM-SM domain with static RP-group
mappings, you must configure the static RP on each router in the domain. (For
information about RP-group mappings, see “Configuring Rendezvous Points” on
page 196.)

On Juniper Networks security devices, interfaces bound to a Layer-3 zone can run
either in NAT mode or in route mode. To run PIM-SM on a device with interfaces
operating in different modes, each zone must be in a different PIM-SM domain. For
example, if interfaces in the Trust zone are in NAT mode and interfaces in the
Untrust zone are in route mode, each zone must be in a different PIM-SM domain.
In addition, when configuring PIM-SM across two virtual routers that are in two
different virtual systems, each virtual router must be in a separate PIM-SM domain.

202  Configuring a Proxy Rendezvous Point

 Chapter 9: Protocol Independent Multicast

You can advertise multicast groups from one PIM-SM domain to another by
configuring a proxy RP. A proxy RP acts as the RP for multicast groups learned from
other PIM-SM domains either through a static RP or through bootstrap messages
allowed by the multicast group policy. It functions as the root of the shared tree for
receivers in its domain and it can form the shortest path tree to the source.

You can configure one proxy RP per zone in a virtual router. To configure a proxy RP
in a zone, you must configure a candidate-RP (C-RP) in that zone. The security
device then advertises the IP address of the C-RP as the IP address of the proxy RP.
When you configure the C-RP, do not specify any multicast group in the multicast
group list. This enables the C-RP to act as the proxy RP for any group imported from
other zones. If you specify multicast groups, then the C-RP functions as the real RP
for the groups specified in the list.

If there is a BSR in the zone, the proxy RP advertises itself as the RP for the
multicast groups imported from other zones. If there is no BSR in the zone of the
proxy RP, then the proxy RP functions as the static RP for the multicast groups
imported from other zones. You must then configure the IP address of the C-RP as
the static RP on all the other routers in the zone.

Proxy RP supports the use of mapped IP (MIP) addresses for source address
translation. A MIP is a direct one-to-one mapping of one IP address to another. You
can configure a MIP when you want the security device to translate a private
address in a zone whose interfaces are in NAT mode to another address. When a
MIP host in the zone of a proxy RP sends a register message, the security device
translates the source IP address to the MIP address and sends a new register
message to the real RP. When the security device receives a join-prune message for
a MIP address, the device maps the MIP to the original source address and sends it
to the source.

Proxy RP also supports the translation of multicast group addresses between zones.
You can configure a multicast policy that specifies the original multicast group
address and the translated multicast group address. When the security device
receives a join-prune message on an interface in the zone of the proxy RP, it
translates the multicast group, if required, and sends the join message to the real
RP.

Consider the following scenario:

 ethernet1 in the Trust zone is in NAT mode, and ethernet3 in the Untrust zone
is in Route mode.

 There is a MIP for the source in the Trust zone.

 The source in the Trust zone sends multicast traffic to the multicast group
224.4.4.1/32.

 There are receivers in both the Trust and Untrust zones.

 There is a multicast policy that allows PIM-SM messages between the Trust and
Untrust zones.

 The Trust zone is configured as the proxy RP.

 The RP and BSR are in the Untrust zone.

Configuring a Proxy Rendezvous Point  203

 Concepts & Examples ScreenOS Reference Guide

Figure 34: Proxy Rendezvous Point Example

ethernet1 ethernet3
NAT mode Route mode
Trust zone Untrust zone

Rendezvous
Point (RP)

Source Bootstrap
Router
(BSR)

Receivers

Receivers

Following is the data flow:

1. Source sends data to the multicast group 224.4.4.1/32.

2. The designated router (DR) encapsulates the data and sends Register messages
toward the RP.

3. The RP proxy in the Trust zone receives the Register message, and changes the
original source IP address to the IP address of the MIP. It then forwards the
message toward the RP for the multicast group.

4. The proxy RP sends (*, G) joins to the real RP.

5. Receivers in the Trust zone send join messages to the proxy RP.

6. Proxy RP sends multicast packets to receivers in the Trust zone.

To configure a proxy RP, you must do the following:

1. Create a PIM-SM instance on a specific virtual router.

2. Enable PIM-SM on the appropriate interfaces.

3. Configure a candidate RP in the zone of the proxy RP.

4. Configure the proxy RP.

In this example, the security devices NS1 and NS2 are connected through a VPN
tunnel. Both devices are running the dynamic routing protocol, BGP. You configure
PIM-SM on ethernet1 and tunnel.1 on NS1 and on NS2. Then, on NS2, you
configure ethernet1 as a static RP and create a proxy RP in the Trust zone of the
trust-vr.

204  Configuring a Proxy Rendezvous Point

 Chapter 9: Protocol Independent Multicast

Figure 35: Proxy RP Configuration Example

NS2-Related Items

Untrust Zone Trust Zone

Tunnel Interface
tunnel.1 ethernet1
10.4.1.1/24
Source ethernet3 Proxy
4.1.1.1/24 Rendezvous
NS2 Point
VPN

NS1

Bootstrap ethernet3
Router ethernet1 2.2.2.2/24
10.2.2.1/24
Actual Tunnel
Rendezvous Interface
Point tunnel.1
Receivers

Receivers

Trust Zone Untrust Zone

NS1-Related Items

WebUI (NS1)
1. Interfaces
Network > Interfaces > Edit (for ethernet1): Enter the following, then click
OK:

Zone Name: Trust

Static IP: (select this option when present)
IP Address/Netmask: 10.2.2.1/24
Select the following, then click OK:
Interface Mode: NAT

Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:

Zone Name: Untrust

Static IP: (select this option when present)
IP Address/Netmask: 2.2.2.2/24

Network > Interfaces > New Tunnel IF: Enter the following, then click OK:

Tunnel Interface Name: tunnel.1

Zone (VR): Untrust (trust-vr)
Unnumbered: (select)
Interface: ethernet3 (trust-vr)

Configuring a Proxy Rendezvous Point  205

 Concepts & Examples ScreenOS Reference Guide

2. Addresses
Policy > Policy Elements > Addresses > List > New: Enter the following
information, then click OK:

Address Name: mgroup1

IP Address/Domain Name:
IP/Netmask: (select), 224.4.4.1/32
Zone: Trust

Policy > Policy Elements > Addresses > List > New: Enter the following
information, then click OK:

Address Name: branch

IP Address/Domain Name:
IP/Netmask: (select), 10.4.1.0/24
Zone: Untrust
3. PIM-SM
Network > Routing > Virtual Router (trust-vr) > Edit > Create PIM Instance:
Select Protocol PIM: Enable, then click OK.

Network > Interfaces > Edit (for ethernet1) > PIM: Enter the following, then
click Apply:

PIM Instance: (select)

Protocol PIM: Enable (select)

Network > Interfaces > Edit (for tunnel.1) > PIM: Enter the following, then
click Apply:

PIM Instance: (select)

Protocol PIM: Enable (select)
4. VPN
VPN > AutoKey Advanced > Gateway > New: Enter the following, then click
OK.

Gateway Name: To_Branch

Security Level: Compatible
Remote Gateway Type:
Static IP Address: (select), IP Address/Hostname: 4.1.1.1
Preshared Key: fg2g4h5j
Outgoing Interface: ethernet3

> Advanced: Enter the following advanced settings, then click Return to
return to the basic Gateway configuration page:

Security Level: Compatible

Phase 1 Proposal (For Compatible Security Level): pre-g2-3des-sha
Mode (Initiator): Main (ID Protection)
5. BGP
Network > Routing > Virtual Router (trust-vr) > Edit: Enter the following, then
click OK:

Virtual Router ID: Custom (select)

In the text box, enter 0.0.0.10

206  Configuring a Proxy Rendezvous Point

 Chapter 9: Protocol Independent Multicast

Network > Routing > Virtual Router (trust-vr) > Edit: Select Create BGP
Instance.

AS Number (required): 65000

BGP Enabled: (select)

Network > Routing > Virtual Router (trust-vr) > Edit > Edit BGP Instance >
Neighbors: Enter the following, then click Add:

AS Number: 65000
Remote IP: 4.1.1.1
Outgoing Interface: ethernet3

Network > Routing > Virtual Router (trust-vr) > Edit > Edit BGP Instance >
Neighbors > Configure (for the peer you just added): Select Peer Enabled and
then click OK.

Network > Routing > Virtual Router (trust-vr) > Edit > Edit BGP Instance >
Networks: Enter 2.2.2.0/24 in the IP/Netmask field, then click Add. Then enter
10.2.2.0/24 in the IP/Netmask field, and click Add again.

Network > Interfaces > Edit (for ethernet3) > BGP: Enter the following, then
click Apply:

Protocol BGP: Enable (select)

6. Policy
Policies > (From: Untrust, To: Trust) > New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), branch
Destination Address:
Address Book Entry: (select), mgroup1
Service: any
Action: Permit
7. Multicast Policy
MCast Policies (From: Trust, To: Untrust) > New: Enter the following and click
OK:

MGroup Address: IP/Netmask (select) 224.4.4.1/32

Bidirectional: (select)
PIM Message: (select)
BSR Static IP: (select)
Join/Prune: (select)

WebUI (NS2)
1. Interfaces
Network > Interfaces > Edit (for ethernet1): Enter the following, then click
Apply:

Zone Name: Trust

Static IP: (select this option when present)
IP Address/Netmask: 10.4.1.1/24
Select NAT, then click Apply.

> IGMP: Enter the following, then click Apply:

Configuring a Proxy Rendezvous Point  207

 Concepts & Examples ScreenOS Reference Guide

IGMP Mode: Router

Protocol IGMP: Enable (select)

Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:

Zone Name: Untrust

Static IP: (select this option when present)
IP Address/Netmask: 4.1.1.1/24

Network > Interfaces > New Tunnel IF: Enter the following, then click OK:

Tunnel Interface Name: tunnel.1

Zone (VR): Untrust (trust-vr)
Unnumbered: (select)
Interface: ethernet3 (trust-vr)
2. Addresses
Policy > Policy Elements > Addresses > List > New: Enter the following
information, then click OK:

Address Name: mgroup1

IP Address/Domain Name:
IP/Netmask: (select), 224.4.4.1/32
Zone: Trust

Policy > Policy Elements > Addresses > List > New: Enter the following
information, then click OK:

Address Name: corp

IP Address/Domain Name:
IP/Netmask: (select), 2.2.2.0/24
Zone: Untrust
3. PIM-SM
Network > Routing > Virtual Router (trust-vr) > Edit > Create PIM Instance:
Select Protocol PIM: Enable, then click OK.

Network > Interfaces > Edit (for ethernet1) > PIM: Enter the following, then
click Apply:

PIM Instance: (select)

Protocol PIM: Enable (select)
Network > Interfaces > Edit (for tunnel.1) > PIM: Enter the following, then
click Apply:

PIM Instance: (select)

Protocol PIM: Enable (select)

Network > Routing > Virtual Router (trust-vr) > Edit > Edit PIM Instance >
RP Address > New: Select the following, then click OK:

Zone: Trust (select)

Address:10.4.1.1/24
4. VPN
VPN > AutoKey Advanced > Gateway > New: Enter the following, then click
OK:

208  Configuring a Proxy Rendezvous Point

 Chapter 9: Protocol Independent Multicast

Gateway Name: To_Corp

Security Level: Compatible
Remote Gateway Type:
Static IP Address: (select), IP Address/Hostname: 2.2.2.2
Preshared Key: fg2g4h5j
Outgoing Interface: ethernet3

> Advanced: Enter the following advanced settings, then click Return to
return to the basic Gateway configuration page:

Security Level: Compatible

Phase 1 Proposal (For Compatible Security Level): pre-g2-3des-sha
Mode (Initiator): Main (ID Protection)
5. BGP
Network > Routing > Virtual Router (trust-vr) > Edit: Enter the following, then
click OK:

Virtual Router ID: Custom (select)

In the text box, enter 0.0.0.10

Network > Routing > Virtual Router (trust-vr) > Edit: Select Create BGP
Instance.

AS Number (required): 65000

BGP Enabled: (select)

Network > Routing > Virtual Router (trust-vr) > Edit > Edit BGP Instance >
Neighbors: Enter the following, then click Add:

AS Number: 65000
Remote IP: 2.2.2.2
Outgoing Interface: ethernet3

Network > Routing > Virtual Router (trust-vr) > Edit > Edit BGP Instance >
Neighbors > Configure (for the peer you just added): Select Peer Enabled and
then click OK.

Network > Routing > Virtual Router (trust-vr) > Edit > Edit BGP Instance >
Networks:

In the IP/Netmask field, enter 4.1.1.0/24, then click Add.

In the IP/Netmask field, enter 10.4.1.0/24, then click Add.

Network > Interfaces > Edit (for ethernet3) > BGP: Select Protocol BGP:
Enable, then click Apply.

Configuring a Proxy Rendezvous Point  209

 Concepts & Examples ScreenOS Reference Guide

6. Policy
Policies > (From: Untrust, To: Trust) > New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), corp
Destination Address:
Address Book Entry: (select), mgroup1
Service: any
Action: Permit
7. Multicast Policy
MCast Policies (From: Trust, To: Untrust) > New: Enter the following and click
OK:

MGroup Address: IP/Netmask (select) 224.4.4.1/32

Bidirectional: (select)
PIM Message: (select)
BSR Static IP: (select)
Join/Prune: (select)

CLI (NS1)
1. Interfaces
Set interface ethernet1 zone trust
set interface ethernet1 ip 10.2.2.1/24
set interface ethernet3 zone untrust
set interface ethernet3 ip 2.2.2.2/24
set interface tunnel.1 zone untrust
set interface tunnel.1 ip unnumbered interface ethernet3
2. Addresses
set address trust mgroup1 224.4.4.1/32
set address untrust branch 10.4.1.0/24
3. PIM-SM
set vrouter trust-vr
set vrouter trust-vr protocol pim enable
set interface ethernet1 protocol pim
set interface ethernet1 protocol pim enable
set interface tunnel.1 protocol pim
set interface tunnel.1 protocol pim enable
4. VPN Tunnel
set ike gateway To_Branch address 4.1.1.1 main outgoing-interface ethernet3
preshare fg2g4h5j proposal pre-g2-3des-sha
set vpn Corp_Branch gateway To-Branch3 sec-level compatible
set vpn Corp_Branch bind interface tunnel.1
set vpn Corp_Branch proxy-id local-ip 10.2.2.0/24 remote-ip 10.4.1.0/24

210  Configuring a Proxy Rendezvous Point

 Chapter 9: Protocol Independent Multicast

5. BGP
set vrouter trust-vr router-id 10
set vrouter trust-vr protocol bgp 6500
set vrouter trust-vr protocol bgp enable
set vrouter trust-vr protocol bgp neighbor 4.1.1.1
set vrouter trust-vr protocol bgp network 2.2.2.0/24
set vrouter trust-vr protocol bgp network 10.2.2.0/24
set interface ethernet3 protocol bgp enable
set interface ethernet3 protocol bgp neighbor 4.1.1.1
6. Policy
set policy name To-Branch from untrust to trust branch any any permit
7. Multicast Policy
set multicast-group-policy from trust mgroup 224.4.4.1/32 any to untrust
pim-message bsr-static-rp join bi-directional
save

CLI (NS2)
1. Interfaces
set interface ethernet 1 zone trust
set interface ethernet 1 ip 10.4.1.1/24
set interface ethernet 1 protocol igmp router
set interface ethernet 1 protocol igmp enable
set interface ethernet 3 zone untrust
set interface ethernet 3 ip 4.1.1.1/24
set interface tunnel.1 zone untrust
set interface tunnel.1 ip unnumbered interface ethernet3
2. Addresses
set address trust mgroup1 224.4.4.1/32
set address untrust corp 2.2.2.0/24
3. PIM-SM
set vrouter trust protocol pim
set interface ethernet1 protocol pim
set interface ethernet1 protocol pim enable
set interface tunnel.1 protocol pim
set interface tunnel.1 protocol pim enable
set vrouter trust protocol pim zone trust rp proxy
set vrouter trust protocol pim zone trust rp candidate interface ethernet1
set vrouter trust protocol pim enable
4. VPN Tunnel
set ike gateway To_Corp address 2.2.2.2 main outgoing-interface ethernet3
preshare fg2g4h5j proposal pre-g2-3des-sha
set vpn Branch_Corp gateway To_Corp sec-level compatible
set vpn Branch_Corp bind interface tunnel.1
set vpn Branch_Corp proxy-id local-ip 10.4.1.0/24 remote-ip 10.2.2.0/24

Configuring a Proxy Rendezvous Point  211

 Concepts & Examples ScreenOS Reference Guide

5. BGP
set vrouter trust-vr router-id 10
set vrouter trust-vr protocol bgp 6500
set vrouter trust-vr protocol bgp enable
set vrouter trust-vr protocol bgp neighbor 2.2.2.2
set vrouter trust-vr protocol bgp network 4.1.1.0/24
set vrouter trust-vr protocol bgp network 10.4.1.0/24
set interface ethernet3 protocol bgp neighbor 2.2.2.2
6. Policy
set policy name To-Corp from untrust to trust corp any any permit
7. Multicast Policy
set multicast-group-policy from trust mgroup 224.4.4.1/32 any to untrust
pim-message bsr-static-rp join bi-directional
save

PIM-SM and IGMPv3

PIM-SM can operate with interfaces running Internet Group Management Protocol
(IGMP) version 1, 2 or 3. When you run PIM-SM with interfaces running IGMPv1 or
v2, hosts receiving data for a multicast group can receive data from any source that
sends data to the multicast group. IGMPv1 and v2 membership reports only
indicate which multicast groups the hosts wants to join. They do not contain
information about the sources of the multicast traffic. When PIM-SM receives
IGMPv1 and v2 membership reports, it creates (*,G) entries in the multicast route
table, allowing any source to send to the multicast group. This is called the
any-source-multicast model (ASM), where receivers join a multicast group, with no
knowledge of the source that sends data to the group. The network maintains
information about the source.

Hosts running IGMPv3 indicate which multicast groups they want to join and the
sources from which they expect to receive multicast traffic. The IGMPv3
membership reports contain the multicast group address, the filter-mode, which is
either include or exclude, and a list of sources.

If the filter-mode is include, then receivers accept multicast traffic only from the
addresses in the source list. When PIM-SM receives an IGMPv3 membership report
with a source list and a filter mode of include, it creates (S,G) entries in the multicast
route table for all sources in the source list.

If the filter mode is exclude, then receivers do not accept multicast traffic from the
sources in the list; they accept multicast traffic from all other sources. When
PIM-SM receives an IGMPv3 membership report with source list and a filter mode of
exclude, then it creates a (*,G) for the group and sends a prune message for sources
in the source list. In this case, you might need to configure a rendezvous point if the
receivers do not know the address of the source.

212  PIM-SM and IGMPv3

Chapter 10
ICMP Router Discovery Protocol

This chapter explains Internet Control Messages Protocol (ICMP) Router Discovery
Protocol as defined in RFC 1256. It contains the following sections:

 “Overview” on page 213

 “Configuring ICMP Router Discovery Protocol” on page 214

 “Enabling ICMP Router Discovery Protocol” on page 214

 “Configuring ICMP Router Discovery Protocol from the WebUI” on

page 214

 “Configuring ICMP Router Discovery Protocol from the CLI” on page 215

 “Disabling IRDP” on page 217

 “Viewing IRDP Settings” on page 217

Overview
ICMP Router Discovery Protocol (IRDP) is an ICMP message exchange between a
host and a router. The security device is the router and advertises the IP address of
a specified interface periodically or on-demand. If the host is configured to listen,
you can configure the security device to send periodic advertisements. If the host
explicitly sends router solicitations, you can configure the security device to
respond on demand.

NOTE: IRDP is not available on all platforms. Check your datasheet to see if this feature is
available on your security device.

ScreenOS supports IRDP on a per-interface basis. You must assign an IP address

before IRDP becomes available on that interface. By default, this feature is disabled.
You can configure this feature in a high availability (HA) environment with
NetScreen Redundancy Protocol (NSRP).

Overview  213
 Concepts & Examples ScreenOS Reference Guide

Configuring ICMP Router Discovery Protocol

You can enable and disable IRDP and configure or view IRDP settings with the
WebUI or the CLI.

Enabling ICMP Router Discovery Protocol

When you enable IRDP on an interface, ScreenOS initiates an immediate IRDP
advertisement to the network. For information about configuring an interface, see
“Interfaces” on page 2-35.

In the following example, you configure IRDP for the Trust interface.

WebUI
Network > Interfaces (edit) > IRDP: Select the IRDP Enable check box.

CLI
set interface trust protocol irdp enable

Configuring ICMP Router Discovery Protocol from the WebUI

To configure IRDP from the WebUI:

Network > Interface > Edit > IRDP: Enter the desired settings, then click OK.

Table 20 lists the IRDP parameters, default values, and available settings.

Table 20: IRDP WebUI Settings

Parameter Default Settings Alternative Settings

IPv4 address  Primary and secondary IP Advertise—you can add a preference
addresses-advertised value (-1through 2147483647)
 Management and webauth
IP addresses-not advertised
Broadcast-address Disabled Enabled
Init Advertise Interval 16 seconds 1 through 32 seconds
Init Advertise Packet 3 1 through 5
Lifetime three times the Max Advertise Max Advertise Interval value through
Interval value 9000 seconds
Max Advertise Interval 600 seconds 4 through 1800 seconds
Min Advertise Interval 75% of the Max Advertise 3 through Max Advertise Interval
Interval value value
Response Delay 2 seconds 0 through 4 seconds

214  Configuring ICMP Router Discovery Protocol

Configuring ICMP Router Discovery Protocol from the CLI
You can configure various IRDP parameters from the CLI to control how
advertisement and solicitation behavior occurs.

Advertising an Interface
By default, ScreenOS advertises the primary IP address of the security device;
however, the IP address is not advertised for WebAuth and management.

You can also associate a preference status for a security device. The preference
status is a number from -1 through 2147483647. Higher numbers have greater
preference. You can assign different preference values for different security devices.
For example, you can assign a higher preference number for the security device
that primarily handles network traffic. For a backup security device, you can assign
a lower preference number.

To advertise the Untrust interface with an IP address of 10.10.10.10 with a

preference of 250, enter the following commands:

set interface untrust protocol irdp 10.10.10.10 advertise

set interface untrust protocol irdp 10.10.10.10 preference 250
save

Broadcasting the Address

By default, except for the initial broadcast advertisement message when IRDP is
enabled, the interface does not send broadcast advertisements. The default address
is 224.0.0.1 (all hosts on the network).

To configure the default broadcast address for the Untrust interface, enter the
following command:

set interface untrust protocol irdp broadcast-address

Setting a Maximum Advertisement Interval

The maximum advertisement interval is the maximum number of seconds that
passes between ICMP advertisements. This interval can be a value from 4 through
1800 seconds. The default value is 600 seconds.

To set the maximum advertisement interval to be 800 seconds for the Untrust
interface, enter the following commands:

set interface untrust protocol irdp max-adv-interval 800

save

Setting a Minimum Advertisement Interval

The minimum advertisement interval is the lower limit (in seconds) of the
advertisement period, which is calculated to be 75 percent of the maximum
advertisement value. The value range for the minimum advertisement interval is 3
through the maximum advertisement value. When you change the maximum
advertisement value, the minimum advertisement interval value is automatically
calculated.

Configuring ICMP Router Discovery Protocol  215

 Concepts & Examples ScreenOS Reference Guide

When you set the maximum advertisement interval to 800 seconds, ScreenOS
automatically recalculates the minimum advertisement interval to be 600 seconds.

To set the minimum advertisement interval value to 500 seconds for the Untrust
interface, enter the following commands:

set interface untrust protocol irdp min-adv-interval 500

save

Setting an Advertisement Lifetime Value

By default, the advertisement lifetime value is three times the maximum
advertisement interval. You can set the advertisement lifetime value. The value
range is the maximum advertisement interval value (4 through 1800 seconds)
through 9000 seconds.

To set the advertisement lifetime value to 5000 seconds for the Untrust interface,
enter the following commands:

set interface untrust protocol untrust lifetime 5000

save

Setting a Response Delay

By default, the security device waits 0 to 2 seconds before responding to a
client-solicitation request. You can change the response delay setting to no delay
(0 seconds) to up to a four-second response delay. For example, if you configure the
response delay to 4 seconds, the security device waits 0 to 4 seconds before
responding.

To set a delay the response delay value to 4 seconds to the Untrust interface, enter
the following commands:

set interface untrust protocol irdp response-delay 4

save

Setting an Initial Advertisement Interval

The Initial Advertise Interval is the number of seconds during the IRDP startup
period allocated for advertisement. By default, this interval is 16 seconds. The value
range for this interval is 1 through 32 seconds.

To set the Initial Advertise Interval to 24 seconds for the Untrust interface, enter the
following commands:

set interface untrust protocol irdp init-adv-interval

save

Setting a Number of Initial Advertisement Packets

By default. the security device sends out three advertisement packets during the
specified startup period. You can change this setting to be 1 through 5.

216  Configuring ICMP Router Discovery Protocol

 To change the number of initial packets sent to 5, enter the following commands:

set interface untrust protocol irdp init-adv-packet 5

save

Disabling IRDP
You can disable an interface from running IRDP; however, when you do so,
ScreenOS deletes all related memory from the original configuration.

To disable the Trust interface from running IRDP, enter the following command:

unset interface trust protocol irdp enable

Viewing IRDP Settings

You can view IRDP information from the WebUI or the CLI.

To view IRDP settings, enter the get irdp or get irdp interface interface_name
commands.

WebUI
Network > Interface > Edit > IRDP: You can view whether IRDP is enabled.

CLI 1
device> get irdp
Total 1 IRDP instance enabled
----------------------------------------------------------------
interface dest-addr lifetime adv-interval Next-Adv(sec)
----------------------------------------------------------------
untrust 255.255.255.255 6000 450 to 600 358

CLI 2
device-> get irdp interface untrust
IRDP enabled on untrust:
advertisement interval : 450 to 600 sec
next advertisement in : 299 sec
advertisement lifetime : 6000 sec
advertisement address : 255.255.255.255
initial advertise interval : 16 sec
initial advertise packet : 3
solicitation response delay : 4 sec
10.100.37.90 : pref 250, advertise YES

Disabling IRDP  217

 Concepts & Examples ScreenOS Reference Guide

218  Viewing IRDP Settings

Index
A in VRs......................................................................105
access lists on interfaces ..........................................................106
for routes ..................................................................40
IGMP .......................................................................156 D
multicast routing ...................................................149 demand circuits, RIP .....................................................93
PIM-SM ...................................................................198
Autonomous System (AS) numbers ...........................105 E
ECMP .........................................................................36, 58
B
BGP G
AS-path access list .................................................114 Generic Routing Encapsulation (GRE) .......................149
communities ..........................................................122
confederations .......................................................120 I
configurations, security ........................................111 IGMP
configurations, verifying ......................................110 access lists, using ..................................................156
external ..................................................................103 configuration, basic ...............................................157
internal ...................................................................103 configuration, verifying ........................................159
load-balancing .........................................................36 host messages........................................................154
message types .......................................................102 interfaces, enabling on .........................................155
neighbors, authenticating.....................................111 parameters .....................................................159, 160
parameters .............................................................113 policies, multicast ..................................................165
path attributes .......................................................103 querier ....................................................................155
protocol overview .................................................102 IGMP proxies ................................................................161
regular expressions ...............................................114 on interfaces ..........................................................163
virtual router, creating an instance in ................105 sender .....................................................................172
BGP routes interfaces, enabling IGMP on .....................................155
adding .....................................................................115 Internet Group Management Protocol
aggregation ............................................................123 See IGMP
attributes, setting ..................................................117
conditional advertisement ...................................116 L
default, rejecting....................................................112 Link-State Advertisement (LSA) suppression ..............67
redistributing .........................................................114 load-balancing by path cost ....................................36, 58
reflection ................................................................118
suppressing ............................................................124
M
weight, setting .......................................................116 multicast
BGP routes, aggregate addresses ................................................................146
aggregation ............................................................123 distribution trees ...................................................182
AS-Path in...............................................................125 policies ....................................................................151
AS-Set in .................................................................123 policies for IGMP ...................................................165
attributes of ............................................................126 reverse path forwarding .......................................146
BGP, configuring routing tables .........................................................147
peer groups ............................................................107 static routes ............................................................148
peers .......................................................................107 multicast routing
steps ........................................................................104 IGMP .......................................................................153
BGP, enabling PIM ..........................................................................179

Index  IX-I
 Concepts & Examples ScreenOS Reference Guide

N security configurations .........................................198

Null interface, defining routes with ............................. 10 traffic, forwarding .................................................184
PIM-SSM........................................................................186
O point-to-multipoint configuration, OSPF .....................68
Open Shortest Path First policies
See OSPF PBR .........................................................................127
OSPF policies, multicast ........................................................151
broadcast networks ................................................ 48 policy based routing (PBR) .........................................127
configuration steps ................................................. 49 Protocol Independent Multicast
ECMP support .......................................................... 58 See PIM
flooding, protecting against ................................... 66
flooding, reduced LSA ............................................ 67 R
global parameters ................................................... 58 RIP
hello protocol ........................................................... 47 authenticating neighbors ........................................85
interface parameters .............................................. 62 database ...................................................................92
interfaces, assigning to areas ................................ 53 demand circuit configuration ................................93
interfaces, tunnel .................................................... 68 filtering neighbors ...................................................86
link-state advertisements ....................................... 46 flooding, protecting against ...................................87
link-type, setting...................................................... 68 global parameters ...................................................82
load-balancing ......................................................... 36 instances, creating in VR ........................................75
LSA suppression ...................................................... 67 interface parameters ..............................................84
neighbors, authenticating ...................................... 64 interfaces, enabling on ...........................................76
neighbors, filtering .................................................. 65 load-balancing .........................................................36
not so stubby area .................................................. 47 point-to-multipoint ..................................................95
point-to-multipoint .................................................. 68 prefix summary .......................................................91
point-to-point network ........................................... 48 versions ....................................................................89
security configuration ............................................. 64 versions, protocol ....................................................89
stub area .................................................................. 47 RIP routes
virtual links .............................................................. 59 alternate ...................................................................92
OSPF areas ..................................................................... 46 redistributing ...........................................................77
defining .................................................................... 51 rejecting default .......................................................87
interfaces, assigning to ........................................... 53 summary, configuring ............................................91
OSPF routers RIP, configuring
adjacency ................................................................. 47 demand circuits .......................................................94
backup designated .................................................. 47 security .....................................................................85
creating OSPF instance in VR ................................ 50 steps ..........................................................................75
designated ................................................................ 47 RIP, viewing
types ......................................................................... 47 database ...................................................................79
OSPF routes interface details .......................................................81
default, rejecting ..................................................... 66 neighbor information .............................................80
redistributed, summarizing ................................... 57 protocol details ........................................................79
redistributing ........................................................... 56 route lookup
route-deny restriction, disabling ........................... 69 multiple VRs.............................................................34
sequence ..................................................................32
P routes
PIM-SM ......................................................................... 182 exporting ..................................................................42
configuration steps ............................................... 186 filtering .....................................................................39
configuring rendezvous points ............................ 196 importing .................................................................42
designated router .................................................. 183 maps .........................................................................38
IGMPv3 ................................................................... 212 metrics......................................................................31
instances, creating ................................................ 187 preference ................................................................30
interface parameters ............................................ 201 redistributing ...........................................................37
proxy RP ................................................................ 202 selection ...................................................................30
rendezvous points ................................................. 183 Routing Information Protocol

IX-II  Index
 Index

See RIP
routing tables .................................................................15
lookup .......................................................................32
lookup in multiple VRs ...........................................34
multicast .................................................................147
route selection .........................................................30
types .........................................................................15
routing, multicast.........................................................145
routing, policy based ...................................................127

S
source interface-based routing (SIBR) .........................19
source-based routing (SBR) ..........................................17
static routing .........................................................2, 2 to 9
configuring .................................................................5
multicast .................................................................148
Null interface, forwarding on .................................10
using ...........................................................................3

V
virtual routers
See VRs
VRs .........................................................................37 to 42
access lists................................................................40
BGP ..............................................................104 to 111
ECMP ........................................................................36
modifying .................................................................22
on vsys .....................................................................26
OSPF ................................................................49 to 67
RIP....................................................................75 to 89
route metrics ...........................................................31
router IDs .................................................................22
SBR............................................................................17
SIBR ..........................................................................19
using two ..................................................................23
VRs, routes
exporting ..................................................................42
filtering .....................................................................39
importing .................................................................42
maps .........................................................................38
preference ................................................................30
redistribution ...........................................................37
selection ...................................................................30
VRs, routing tables
lookup .......................................................................32
lookup in multiple VRs ...........................................34
maximum entries ....................................................29

Index  IX-III
 Concepts & Examples ScreenOS Reference Guide

IX-IV  Index
Concepts & Examples
ScreenOS Reference Guide

Volume 8:
Address Translation

Release 6.1.0, Rev. 03

Juniper Networks, Inc.

1194 North Mathilda Avenue
Sunnyvale, CA 94089
USA
408-745-2000
www.juniper.net
 Copyright Notice
Copyright © 2009 Juniper Networks, Inc. All rights reserved.

Juniper Networks, the Juniper Networks logo, JUNOS, NetScreen, ScreenOS, and Steel-Belted Radius are registered trademarks of Juniper Networks, Inc.
in the United States and other countries. JUNOSe is a trademark of Juniper Networks, Inc. All other trademarks, service marks, registered trademarks, or
registered service marks are the property of their respective owners.

All specifications are subject to change without notice. Juniper Networks assumes no responsibility for any inaccuracies in this document or for any
obligation to update information in this document. Juniper Networks reserves the right to change, modify, transfer, or otherwise revise this publication
without notice.

FCC Statement
The following information is for FCC compliance of Class A devices: This equipment has been tested and found to comply with the limits for a Class A
digital device, pursuant to part 15 of the FCC rules. These limits are designed to provide reasonable protection against harmful interference when the
equipment is operated in a commercial environment. The equipment generates, uses, and can radiate radio-frequency energy and, if not installed and
used in accordance with the instruction manual, may cause harmful interference to radio communications. Operation of this equipment in a residential
area is likely to cause harmful interference, in which case users will be required to correct the interference at their own expense.

The following information is for FCC compliance of Class B devices: The equipment described in this manual generates and may radiate radio-frequency
energy. If it is not installed in accordance with Juniper Networks’ installation instructions, it may cause interference with radio and television reception.
This equipment has been tested and found to comply with the limits for a Class B digital device in accordance with the specifications in part 15 of the FCC
rules. These specifications are designed to provide reasonable protection against such interference in a residential installation. However, there is no
guarantee that interference will not occur in a particular installation.

If this equipment does cause harmful interference to radio or television reception, which can be determined by turning the equipment off and on, the user
is encouraged to try to correct the interference by one or more of the following measures:

 Reorient or relocate the receiving antenna.

 Increase the separation between the equipment and receiver.

 Consult the dealer or an experienced radio/TV technician for help.

 Connect the equipment to an outlet on a circuit different from that to which the receiver is connected.

Caution: Changes or modifications to this product could void the user's warranty and authority to operate this device.

Disclaimer
THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED
WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED
WARRANTY, CONTACT YOUR JUNIPER NETWORKS REPRESENTATIVE FOR A COPY.

ii 
Table of Contents
About This Volume v
Document Conventions................................................................................... vi
Web User Interface Conventions ............................................................. vi
Command Line Interface Conventions ..................................................... vi
Naming Conventions and Character Types ............................................. vii
Illustration Conventions ......................................................................... viii
Requesting Technical Support ....................................................................... viii
Self-Help Online Tools and Resources....................................................... ix
Opening a Case with JTAC ........................................................................ ix
Document Feedback ....................................................................................... ix

Chapter 1 Address Translation 1

Introduction to Address Translation ................................................................. 1
Source Network Address Translation ......................................................... 1
Destination Network Address Translation.................................................. 3
Policy-Based NAT-Dst.......................................................................... 4
Mapped Internet Protocol.................................................................... 6
Virtual Internet Protocol ...................................................................... 6
Policy-Based Translation Options ..................................................................... 7
Example: NAT-Src from a DIP Pool with PAT............................................. 7
Example: NAT-Src From a DIP Pool Without PAT ...................................... 7
Example: NAT-Src from a DIP Pool with Address Shifting.......................... 8
Example: NAT-Src from the Egress Interface IP Address............................ 8
Example: NAT-Dst to a Single IP Address with Port Mapping..................... 8
Example: NAT-Dst to a Single IP Address Without Port Mapping ............... 9
Example: NAT-Dst from an IP Address Range to a Single IP Address......... 9
Example: NAT-Dst Between IP Address Ranges ....................................... 10
Directional Nature of NAT-Src and NAT-Dst ................................................... 10

Chapter 2 Source Network Address Translation 13

Introduction to NAT-Src ................................................................................. 13
NAT-Src from a DIP Pool with PAT Enabled ................................................... 15
Example: NAT-Src with PAT Enabled....................................................... 15
NAT-Src from a DIP Pool with PAT Disabled .................................................. 18
Example: NAT-Src with PAT Disabled ...................................................... 18
NAT-Src from a DIP Pool with Address Shifting.............................................. 20
Example: NAT-Src with Address Shifting ................................................. 21
NAT-Src from the Egress Interface IP Address................................................ 24
Example: NAT-Src Without DIP ............................................................... 24

Chapter 3 Destination Network Address Translation 27

Introduction to NAT-Dst ................................................................................. 28

Table of Contents  iii

 Concepts & Examples ScreenOS Reference Guide

Packet Flow for NAT-Dst.......................................................................... 29

Routing for NAT-Dst ................................................................................ 32
Example: Addresses Connected to One Interface.............................. 33
Example: Addresses Connected to One Interface
But Separated by a Router .......................................................... 34
Example: Addresses Separated by an Interface................................. 34
NAT-Dst—One-to-One Mapping ..................................................................... 35
Example: One-to-One Destination Translation......................................... 36
Translating from One Address to Multiple Addresses............................... 38
Example: One-to-Many Destination Translation ................................ 38
NAT-Dst—Many-to-One Mapping ................................................................... 41
Example: Many-to-One Destination Translation....................................... 41
NAT-Dst—Many-to-Many Mapping .................................................................44
Example: Many-to-Many Destination Translation .................................... 45
NAT-Dst with Port Mapping............................................................................ 47
Example: NAT-Dst with Port Mapping ..................................................... 47
NAT-Src and NAT-Dst in the Same Policy ....................................................... 50
Example: NAT-Src and NAT-Dst Combined.............................................. 50

Chapter 4 Mapped and Virtual Addresses 63

Mapped IP Addresses..................................................................................... 63
MIP and the Global Zone ......................................................................... 64
Example: MIP on an Untrust Zone Interface...................................... 65
Example: Reaching a MIP from Different Zones................................ 67
Example: Adding a MIP to a Tunnel Interface ................................... 70
MIP-Same-as-Untrust ............................................................................... 70
Example: MIP on the Untrust Interface ............................................. 71
MIP and the Loopback Interface .............................................................. 73
Example: MIP for Two Tunnel Interfaces .......................................... 74
MIP Grouping .......................................................................................... 79
Example: MIP Grouping with Multi-Cell Policy................................... 79
Virtual IP Addresses ....................................................................................... 80
VIP and the Global Zone .......................................................................... 82
Example: Configuring Virtual IP Servers............................................ 82
Example: Editing a VIP Configuration ............................................... 84
Example: Removing a VIP Configuration........................................... 84
Example: VIP with Custom and Multiple-Port Services ...................... 85

Index..........................................................................................................................IX-I

iv  Table of Contents
About This Volume

Volume 8: Address Translation focuses on the various methods available in ScreenOS

to perform address translation. This volume contains the following chapters:

 Chapter 1, “Address Translation,” gives an overview of the various translation

options, which are covered in detail in subsequent chapters.

 Chapter 2, “Source Network Address Translation,” describes NAT-src, the

translation of the source IP address in a packet header, with and without Port
Address Translation (PAT).

 Chapter 3, “Destination Network Address Translation,” describes NAT-dst, the

translation of the destination IP address in a packet header, with and without
destination port address mapping. This section also includes information about
the packet flow when doing NAT-src, routing considerations, and address
shifting.

 Chapter 4, “Mapped and Virtual Addresses,” describes the mapping of one

destination IP address to another based on IP address alone (mapped IP) or
based on destination IP address and destination port number (virtual IP).

NOTE: For coverage of interface-based Source Network Address Translation—referred to

simply as NAT—see “NAT Mode” on page 2 -92.

 v
 Concepts & Examples ScreenOS Reference Guide

Document Conventions
This document uses the conventions described in the following sections:

 “Web User Interface Conventions” on page vi

 “Command Line Interface Conventions” on page vi

 “Naming Conventions and Character Types” on page vii

 “Illustration Conventions” on page viii

Web User Interface Conventions

The Web user interface (WebUI) contains a navigational path and configuration
settings. To enter configuration settings, begin by clicking a menu item in the
navigation tree on the left side of the screen. As you proceed, your navigation path
appears at the top of the screen, with each page separated by angle brackets.

The following example shows the WebUI path and parameters for defining an
address:

Policy > Policy Elements > Addresses > List > New: Enter the following, then
click OK:

Address Name: addr_1

IP Address/Domain Name:
IP/Netmask: (select), 10.2.2.5/32
Zone: Untrust

To open Online Help for configuration settings, click the question mark (?) in the
upper left of the screen.

The navigation tree also provides a Help > Config Guide configuration page to help
you configure security policies and Internet Protocol Security (IPSec). Select an
option from the list, and follow the instructions on the page. Click the ? character in
the upper left for Online Help on the Config Guide.

Command Line Interface Conventions

The following conventions are used to present the syntax of command line
interface (CLI) commands in text and examples.

In text, commands are in boldface type and variables are in italic type.

In examples:

 Variables are in italic type.

 Anything inside square brackets [ ] is optional.

 Anything inside braces { } is required.

vi  Document Conventions
 About This Volume

 If there is more than one choice, each choice is separated by a pipe ( | ). For
example, the following command means “set the management options for the
ethernet1, the ethernet2, or the ethernet3 interface”:

set interface { ethernet1 | ethernet2 | ethernet3 } manage

NOTE: When entering a keyword, you only have to type enough letters to identify the
word uniquely. Typing set adm u whee j12fmt54 will enter the command set
admin user wheezer j12fmt54. However, all the commands documented in this
guide are presented in their entirety.

Naming Conventions and Character Types

ScreenOS employs the following conventions regarding the names of objects—such
as addresses, admin users, auth servers, IKE gateways, virtual systems, VPN
tunnels, and zones—defined in ScreenOS configurations:

 If a name string includes one or more spaces, the entire string must be
enclosed within double quotes; for example:

set address trust “local LAN” 10.1.1.0/24

 Any leading spaces or trailing text within a set of double quotes are trimmed;
for example, “ local LAN ” becomes “local LAN”.

 Multiple consecutive spaces are treated as a single space.

 Name strings are case-sensitive, although many CLI keywords are

case-insensitive. For example, “local LAN” is different from “local lan”.

ScreenOS supports the following character types:

 Single-byte character sets (SBCS) and multiple-byte character sets (MBCS).

Examples of SBCS are ASCII, European, and Hebrew. Examples of MBCS—also
referred to as double-byte character sets (DBCS)—are Chinese, Korean, and
Japanese.

 ASCII characters from 32 (0x20 in hexadecimals) to 255 (0xff), except double

quotes ( “ ), which have special significance as an indicator of the beginning or
end of a name string that includes spaces.

NOTE: A console connection only supports SBCS. The WebUI supports both SBCS and
MBCS, depending on the character sets that your browser supports.

Document Conventions  vii

 Concepts & Examples ScreenOS Reference Guide

Illustration Conventions
Figure 1 shows the basic set of images used in illustrations throughout this volume.

Figure 1: Images in Illustrations

Autonomous System Local Area Network (LAN)
or with a Single Subnet
Virtual Routing Domain or
Security Zone

Dynamic IP (DIP) Pool

Internet

Policy Engine
Security Zone Interfaces:
White = Protected Zone Interface
(example = Trust Zone)
Black = Outside Zone Interface
(example = Untrust Zone)
Generic Network Device

Tunnel Interface

Server

VPN Tunnel

Router

Juniper Networks
Switch Security Devices

Hub

Requesting Technical Support

Technical product support is available through the Juniper Networks Technical
Assistance Center (JTAC). If you are a customer with an active J-Care or JNASC
support contract, or are covered under warranty, and need postsales technical
support, you can access our tools and resources online or open a case with JTAC.

 JTAC policies—For a complete understanding of our JTAC procedures and

policies, review the JTAC User Guide located at
http://www.juniper.net/customers/support/downloads/710059.pdf.

 Product warranties—For product warranty information, visit

http://www.juniper.net/support/warranty/.

 JTAC hours of operation—The JTAC centers have resources available 24 hours a

day, 7 days a week, 365 days a year.

viii  Requesting Technical Support

 About This Volume

Self-Help Online Tools and Resources

For quick and easy problem resolution, Juniper Networks has designed an online
self-service portal called the Customer Support Center (CSC) that provides you with
the following features:

 Find CSC offerings—http://www.juniper.net/customers/support/

 Find product documentation—http://www.juniper.net/techpubs/

 Find solutions and answer questions using our Knowledge Base—

http://kb.juniper.net/

 Download the latest versions of software and review your release notes—
http://www.juniper.net/customers/csc/software/

 Search technical bulletins for relevant hardware and software notifications—

http://www.juniper.net/alerts/

 Join and participate in the Juniper Networks Community Forum—

http://www.juniper.net/company/communities/

 Open a case online in the CSC Case Manager—

http://www.juniper.net/customers/cm/

 To verify service entitlement by product serial number, use our Serial Number
Entitlement (SNE) Tool—
https://tools.juniper.net/SerialNumberEntitlementSearch/

Opening a Case with JTAC

You can open a case with JTAC on the Web or by telephone.

 Use the Case Manager tool in the CSC at http://www.juniper.net/customers/cm/.

 Call 1-888-314-JTAC (1-888-314-5822—toll free in USA, Canada, and Mexico).

For international or direct-dial options in countries without toll-free numbers, visit

us at http://www.juniper.net/customers/support/requesting-support/.

Document Feedback
If you find any errors or omissions in this document, contact Juniper Networks at
[email protected].

Document Feedback  ix
 Concepts & Examples ScreenOS Reference Guide

x  Document Feedback
Chapter 1
Address Translation

ScreenOS provides many methods for performing source and destination IP and
port address translation. This chapter describes the various address translation
methods available and contains the following sections:

 “Introduction to Address Translation” on page 1

 “Source Network Address Translation” on page 1

 “Destination Network Address Translation” on page 3

 “Policy-Based Translation Options” on page 7

 “Directional Nature of NAT-Src and NAT-Dst” on page 10

Introduction to Address Translation

ScreenOS provides several mechanisms for applying Network Address Translation
(NAT). NAT includes the translation of the Internet Protocol (IP) address in an IP
packet header and, optionally, the translation of the port number in the
Transmission Control Protocol (TCP) segment or User Datagram Protocol (UDP)
datagram header. The translation can involve the source address (and, optionally,
the source port number), the destination address (and, optionally, the destination
port number), or a combination of translated elements.

Source Network Address Translation

When performing Source Network Address Translation (NAT-src), the security device
translates the original source IP address to a different address. The translated
address can come from a dynamic IP (DIP) pool or from the egress interface of the
security device. If the security device draws the translated address from a DIP pool,
it can do so either arbitrarily or deterministically; that is, it can draw any address
from the DIP pool at random, or it can consistently draw a specific address in
relation to the original source IP address.

NOTE: Deterministic address translation uses a technique called address shifting, which
is explained later in this chapter. For information about address shifting that
applies to NAT-src, see “NAT-Src from a DIP Pool with Address Shifting” on
page 20. For information about address shifting that applies to NAT-dst, see
“NAT-Src and NAT-Dst in the Same Policy” on page 50.

Introduction to Address Translation  1

 Concepts & Examples ScreenOS Reference Guide

If the translated address comes from the egress interface, the security device
translates the source IP address in all packets to the IP address of that interface. You
can configure the security device to apply NAT-src at either the interface level or at
the policy level. If you configure a policy to apply NAT-src and the ingress interface
is in NAT mode, the policy-based NAT-src settings override the interface-based NAT.
(This chapter focusses on policy-based NAT-src. For details on interface-based
NAT-src—or NAT alone—see “NAT Mode” on page 2-92. For more information about
DIP pools, see “Dynamic IP Pools” on page 2-141.)

NOTE: You can use policy-based NAT-src when the ingress interface is in Route or NAT
mode. If it is in NAT mode, the policy-level NAT-src parameters supersede the
interface-level NAT parameters.

Figure 2: Source IP Address Translation

Original Source IP Addresses Translated Source IP Addresses

SRC IP DST IP SRC IP DST IP

IP Packet 10.1.1.5 2.2.2.2 Payload 1.1.1.5 2.2.2.2 Payload

With policy-based NAT-src, you can optionally choose to have the security device
perform Port Address Translation (PAT) on the original source port number. When
PAT is enabled, the security device can translate up to ~64,500 different IP
addresses to a single IP address with up to ~64,500 different port numbers. The
security device uses the unique, translated port number to maintain session state
information for traffic to and from the same, single IP address. For interface-based
NAT-src—or just NAT—PAT is enabled automatically. Because the security device
translates all original IP addresses to the same translated IP address (that of the
egress interface), the security device uses the translated port number to identify
each session to which a packet belongs. Similarly, if a DIP pool consists of only one
IP address and you want the security device to apply NAT-src to multiple hosts using
that address, then PAT is required for the same reason.

NOTE: With PAT enabled, the security device maintains a pool of free port numbers to
assign along with addresses from the DIP pool. The figure of ~64,500 is derived
by subtracting 1023, the numbers reserved for the well-known ports, from the
maximum number of ports, which is 65,535. Thus, when the security device
performs NAT-src with a DIP pool containing a single IP address and PAT is
enabled, the security device can translate the original IP addresses of up to
~64,500 hosts to a single IP address and translate each original port number to a
unique port number.

2  Introduction to Address Translation

 Chapter 1: Address Translation

Figure 3: Source IP and Source Port Address Translation

Original Source IP and Port Addresses Translated Source IP and Port Addresses

SRC IP DST IP SRC IP DST IP

IP Packet 10.1.1.5 2.2.2.2 Payload 1.1.1.5 2.2.2.2 Payload

TCP Segment or SRC DST SRC DST

UDP Datagram Port Port Port Port
44235 53 Payload 30777 53 Payload

For custom applications that require a specific source port number to operate
properly, performing PAT causes such applications to fail. To provide for such cases,
you can disable PAT.

NOTE: For more information about NAT-src, see “Source Network Address Translation” on
page 13.

Destination Network Address Translation

Screen OS offers the following three mechanisms for performing Destination
Network Address Translation (NAT-dst):

 Policy-based NAT-dst: see “Policy-Based NAT-Dst” on page 4

 MIP: see “Mapped Internet Protocol” on page 6

 VIP: see “Virtual Internet Protocol” on page 6

All three options translate the original destination IP address in an IP packet header
to a different address. WIth policy-based NAT-dst and VIPs, you can optionally
enable port mapping.

NOTE: For information about port mapping, see the “Policy-Based NAT-Dst” on page 4
and “Destination Network Address Translation” on page 27.

ScreenOS does not support the use of policy-based NAT-dst in combination with
MIPs and VIPs. If you have configured a MIP or VIP, the security device applies the
MIP or VIP to any traffic to which a policy-based NAT-dst configuration also
applies. In other words, MIPs and VIPs disable policy-based NAT-dst if the security
device is accidentally configured to apply both to the same traffic.

Introduction to Address Translation  3

 Concepts & Examples ScreenOS Reference Guide

Policy-Based NAT-Dst
You can configure a policy to translate one destination IP address to another
address, one IP address range to a single IP address, or one IP address range to
another IP address range. When a single destination IP address translates to
another IP address or an IP address range translates to a single IP address,
ScreenOS can support NAT-dst with or without port mapping. Port mapping is the
deterministic translation of one original destination port number to another specific
number, unlike PAT, which translates any original source port number randomly
assigned by the initiating host to another number randomly assigned by the
security device.

Figure 4: Destination IP Address Translation

Destination IP Address Translation without Destination Port Mapping
Original Destination and IP Address Translated Destination IP Address

SRC IP DST IP SRC Port DST Port

IP Packet 1.1.1.5 2.2.2.2 Payload 1.1.1.5 10.3.1.6 Payload

Destination IP Address Translation without

Destination IP Address Translation with Destination Port Mapping
Destination Port Mapping
Original Destination and IP and Port Addresses Original Destination and IP and Port Addresses

SRC DST SRC DST

Port Port Port Port

IP Packet 1.1.1.5 2.2.2.2 Payload 1.1.1.5 10.3.1.6 Payload

TCP Segment
or
UDP Datagram 44235 6055 Payload 44235 53 Payload

When you configure a policy to perform NAT-dst to translate an address range to a

single address, the security device translates any destination IP address from within
the user-defined range of original destination addresses to a single address. You can
also enable port mapping.

4  Introduction to Address Translation

 Chapter 1: Address Translation

Figure 5: NAT-Dst from an IP Address Range to a Single IP Address

Destination IP Address Translation from an IP Address Range to a Single IP Address
Original Destination and IP Address Translated Destination IP Address
SRC IP DST IP SRC IP DST IP

1.1.1.5 2.2.2.2 Payload 1.1.1.5 10.3.1.6 Payload

IP Packets

1.1.1.5 2.2.2.3 Payload 1.1.1.5 10.3.1.6 Payload

Destination IP Address Translation from an IP Address Range to a Single IP Address with Destination Port Mapping
Original Destination and IP and Port Addresses Translated Destination IP and Port Addresses

IP Packet 1 1.1.1.5 2.2.2.2 Payload 1.1.1.5 10.3.1.6 Payload

SRC DST SRC DST

Port Port Port Port

TCP Segment 1 44235 8000 Payload 44235 80 Payload

IP Packet 2 1.1.1.5 2.2.2.3 Payload 1.1.1.5 10.3.1.6 Payload

TCP Segment 2
28560 8000 Payload 28560 80 Payload

When you configure a policy to perform NAT-dst for an address range, the security
device uses address shifting to translate a destination IP address from within a
range of original destination addresses to a known address in another range of
addresses.

Figure 6: NAT-Dst with Address Shifting

Original Destination IP Addresses Translated Destination IP Addresses

SRC DST SRC DST

IP IP IP IP

IP Packets 1.1.1.5 2.2.2.2 Payload 1.1.1.5 10.3.1.6 Payload

1.1.1.5 2.2.2.3 Payload 1.1.1.5 10.3.1.7 Payload

1.1.1.5 2.2.2.4 Payload 1.1.1.5 10.3.1.8 Payload

When performing NAT-dst for a range of IP addresses, the security device maintains a mapping of each IP address in
one address range to a corresponding IP address in another address range.

Introduction to Address Translation  5

 Concepts & Examples ScreenOS Reference Guide

NOTE: You can combine NAT-src and NAT-dst within the same policy. Each translation
mechanism operates independently and unidirectionally. That is, if you enable
NAT-dst on traffic from zone1 to zone2, the security device does not perform
NAT-src on traffic originating from zone2 and destined to zone1 unless you
specifically configure it to do so. For more information, see “Directional Nature of
NAT-Src and NAT-Dst” on page 10. For more information about NAT-dst, see
“Destination Network Address Translation” on page 27.

Mapped Internet Protocol

A mapped Internet Protocol (MIP) is a mapping of one IP address to another IP
address. You define one address in the same subnet as an interface IP address. The
other address belongs to the host to which you want to direct traffic. Address
translation for a MIP behaves bidirectionally, so that the security device translates
the destination IP address in all traffic coming to a MIP to the host IP address and
source IP address in all traffic originating from the host IP address to the MIP
address. MIPs do not support port mapping. For more information about MIPs, see
“Mapped IP Addresses” on page 63.

Virtual Internet Protocol

A virtual Internet Protocol (VIP) is a mapping of one IP address to another IP
address based on the destination port number. A single IP address defined in the
same subnet as an interface can host mappings of several services—identified by
various destination port numbers—to as many hosts. VIPs also support port
mapping. Unlike MIPs, address translation for a VIP behaves unidirectional. The
security device translates the destination IP address in all traffic coming to a VIP to
a host IP address. The security device does not translate the original source IP
address in outbound traffic from a VIP host to that of the VIP address. Instead, the
security device applies interface-based or policy-based NAT-src if you have
previously configured it. Otherwise, the security device does not perform any
NAT-src on traffic originating from a VIP host. For more information about VIPs, see
“Virtual IP Addresses” on page 80.

NOTE: You can define a VIP to be the same as an interface IP address. This ability is
convenient when the security device only has one assigned IP address and when
the IP address is assigned dynamically.

Whereas the address translation mechanisms for MIPs and VIPs are bidirectional,
the capabilities provided by policy-based NAT-src and NAT-dst separate address
translation for inbound and outbound traffic, providing better control and security.
For example, if you use a MIP to a webserver, whenever that server initiates
outbound traffic to get an update or patch, its activity is exposed, which might
provide information for a vigilant attacker to exploit. The policy-based address
translation methods allow you to define a different address mapping when the
webserver receives traffic (using NAT-dst) than when it initiates traffic (using
NAT-src). By thus keeping its activities hidden, you can better protect the server
from anyone attempting to gather information in preparation for an attack.
Policy-based NAT-src and NAT-dst offer a single approach that can duplicate and
surpass the functionality of interface-based MIPs and VIPs.

6  Introduction to Address Translation

 Chapter 1: Address Translation

Policy-Based Translation Options

ScreenOS provides the following ways to apply Source Network Address Translation
(NAT-src) and Destination Network Address Translation (NAT-dst). Note that you can
always combine NAT-src with NAT-dst within the same policy.

Example: NAT-Src from a DIP Pool with PAT

The security device translates the original source IP address to an address drawn
from a dynamic IP (DIP) pool. The security device also applies source Port Address
Translation (PAT). For more information, see “NAT-Src from a DIP Pool with PAT
Enabled” on page 15.

Figure 7: NAT-Src with Port Address Translation

DIP Pool ID 5
1.1.1.10 – 1.1.1.40

1.1.1.20
Trust Zone ethernet1 ethernet3 Untrust Zone
10.1.1.1/24 1.1.1.1/24
10.1.1.5:25611 1.1.1.20:41834 2.2.2.2:80

(Virtual Device)
Translated Source Destination
Original Source

NOTE: In Figure 7 and in subsequent figures, a “virtual device” is used to indicate a

translated source or destination address when that address does not belong to an
actual device.

Example: NAT-Src From a DIP Pool Without PAT

The security device translates the original source IP address to an address drawn
from a DIP pool. The security device does not apply source PAT. For more
information, see “NAT-Src from a DIP Pool with PAT Disabled” on page 18.

Figure 8: NAT-Src Without Port Address Translation

DIP Pool ID 5
1.1.1.10 – 1.1.1.40
1.1.1.20
Trust Zone ethernet1 ethernet3 Untrust Zone
10.1.1.1/24 1.1.1.1/24
10.1.1.5:25611 1.1.1.20:25611 2.2.2.2:80

(Virtual Device)

Original Source Translated Source Destination

Policy-Based Translation Options  7

 Concepts & Examples ScreenOS Reference Guide

Example: NAT-Src from a DIP Pool with Address Shifting

The security device translates the original source IP address to an address drawn
from a dynamic IP (DIP) pool, consistently mapping each original address to a
particular translated address. The security device does not apply source Port
Address Translation (PAT). For more information, see “NAT-Src from a DIP Pool with
Address Shifting” on page 20.

Figure 9: NAT-Src with Address Shifting

DIP Pool ID 5
1.1.1.10 – 1.1.1.40

1.1.1.20
Trust Zone ethernet3 1.1.1.21
ethernet1 1.1.1.1/24 Untrust Zone
10.1.1.20:25611 10.1.1.1/24 1.1.1.20:25611
2.2.2.2:80
10.1.1.21:35030
1.1.1.21:35030

10.1.1.20 always translates to 1.1.1.20. (Virtual Devices)

10.1.1.21 always translates to 1.1.1.21. Destination
Original Source Translated Source

Example: NAT-Src from the Egress Interface IP Address

The security device translates the original source IP address to the address of the
egress interface. The security device applies source PAT as well. For more
information, see “NAT-Src from the Egress Interface IP Address” on page 24.

Figure 10: NAT-Src Using the Egress Interface IP Address

Trust Zone ethernet1 ethernet3 Untrust Zone
10.1.1.1/24 1.1.1.1/24
10.1.1.20:25611 1.1.1.1:35030 2.2.2.2:80

1.1.1.1 (Virtual Devices)

Original Source Translated Source Destination

Example: NAT-Dst to a Single IP Address with Port Mapping

The security device performs Destination Network Address Translation (NAT-dst)
and destination port mapping. For more information, see “NAT-Dst with Port
Mapping” on page 47.

Figure 11: NAT-Dst with Port Mapping

2.2.2.8:7777
ethernet3 ethernet1 Trust Zone
Untrust Zone 1.1.1.1/24 10.2.2.1/244
10.2.2.8:80
(Virtual
Devices)

Source Original Translated

Destination Destination

8  Policy-Based Translation Options

 Chapter 1: Address Translation

Example: NAT-Dst to a Single IP Address Without Port Mapping

The security device performs NAT-dst but does not change the original destination
port number. For more information, see “Destination Network Address Translation”
on page 27.

Figure 12: NAT-Dst Without Port Mapping

2.2.2.8:80
ethernet13 ethernet1 Trust Zone
Untrust Zone 1.1.1.1/24 10.2.2.1/24
1.1.1.5 10.2.2.8:80
(Virtual
Devices)

Source Original
Destination Translated
Destination

Example: NAT-Dst from an IP Address Range to a Single IP Address

The security device performs NAT-dst to translate a range of IP addresses to a single
IP address. If you also enable port mapping, the security device translates the
original destination port number to another number. For more information, see
“NAT-Dst—Many-to-One Mapping” on page 41.

Figure 13: NAT-Dst from an Address Range to a Single IP Address

2.2.2.8:80

1.1.1.5:25611 Untrust Zone ethernet3 DMZ Zone

1.1.1.1/24 ethernet2
10.2.2.1/24
10.2.2.8:80
10.2.2.8:80
1.1.1.6:40365 Both 2.2.2.8 and 2.2.2.9 always
translate to 10.2.2.8. Translated
Destination
Sources (Virtual
Devices)
Original
Destinations

Policy-Based Translation Options  9

 Concepts & Examples ScreenOS Reference Guide

Example: NAT-Dst Between IP Address Ranges

When you apply NAT-dst for a range of IP addresses, the security device maintains a
consistent mapping of an original destination address to a translated address within
the specified range using a technique called address shifting. Note that address
shifting does not support port mapping. For more information, see
“NAT-Dst—Many-to-Many Mapping” on page 44.

Figure 14: NAT-Dst Between Address Ranges

2.2.2.8:80 10.2.2.8:80
Untrust Zone ethernet3 ethernet1
1.1.1.1/24 10.2.2.1/24
Trust Zone
1.1.1.5
2.2.2.9:80 10.2.2.9:80

1.1.1.6 2.2.2.8 always translates to 10.2.2.8, and

2.2.2.9 always translates to 10.2.2.9.
Sources
(Virtual Devices) Translated
Original Destinations
Destinations

Directional Nature of NAT-Src and NAT-Dst

The application of NAT-src is separate from that of NAT-dst. You determine their
applications on traffic by the direction indicated in a policy. For example, if the
security device applies a policy requiring NAT-dst for traffic sent from host A to
virtual host B, the security device translates the original destination IP address from
2.2.2.2 to 3.3.3.3. (It also translates the source IP address from 3.3.3.3 to 2.2.2.2 in
responding traffic.)

10  Directional Nature of NAT-Src and NAT-Dst

 Chapter 1: Address Translation

Figure 15: Packet Flow for NAT-Dst

set policy from “zone A” to “zone B” “host A” “virtual host B” any nat dst ip 3.3.3.3 permit set
vrouter trust-vr route 2.2.2.2/32 interface ethernet1.
Host A Virtual Host B
1.1.1.1 2.2.2.2 Host B
3.3.3.3

ethernet3 1.1.1.10/24 ethernet1 3.3.3.10/124

Zone A Zone B
SRC DST
1.1.1.1 2.2.2.2 Payload

The security device translates the destination IP

address from 2.2.2.2 to 3.3.3.3. It stores the IP and
port address information in its session table.

SRC DST Payload

1.1.1.1 3.3.3.3

SRC DST
3.3.3.3 1.1.1.1 Payload

The security device matches the IP and port

information in the packet with the information
stored in its session table. It then translates the
source IP address from 3.3.3.3 to 2.2.2.2.

SRC DST
2.2.2.2 1.1.1.1 Payload

NOTE: You must set a route to 2.2.2.2/32 (virtual host B) so the security device can do a
route lookup to determine the destination zone. For more about NAT-dst routing
issues, see “Routing for NAT-Dst” on page 32.

However, if you only create the above policy specifying NAT-dst from host A to
host B, the security device does not translate the original source IP address of
host B if host B initiates traffic to host A, rather than responding to traffic from
host A. For the security device to do translate the source IP address of host B when
it initiates traffic to host A, you must configure a second policy from host B to
host A specifying NAT-src. (This behavior differs from that of MIPs. See “Mapped IP
Addresses” on page 63.)

NOTE: To retain focus on the IP address translation mechanisms, Port Address Translation
(PAT) is not shown. If you specify fixed port numbers for a DIP pool consisting of a
single IP address, then only one host can use that pool at a time. The policy above
specifies only “host B” as the source address. If “host B” is the only host that uses
DIP pool 7, then it is unnecessary to enable PAT.

Directional Nature of NAT-Src and NAT-Dst  11

 Concepts & Examples ScreenOS Reference Guide

Figure 16: Packet Flow for Source IP Address Translation

set interface ethernet1 dip-id 7 1.1.1.3 1.1.1.3
set policy from “zone B” to “zone A” “host B”
“host A” any nat src dip-id 7 permit

Host A
1.1.1.1 DIP Pool 7 Host B
1.1.1.3 - 1.1.1.3 ethernet3 ethernet1 3.3.3.3
1.1.1.10/24 3.3.3.10/24

Zone A Zone B

SRC DST
3.3.3.3 1.1.1.1 Payload

The security device translates the destination IP

address from 3.3.3.3 to 1.1.1.3. It stores the IP
and port address information in its session table.

SRC DST Payload

1.1.1.3 1.1.1.1

SRC DST
1.1.1.1 1.1.1.3 Payload

The security device matches the IP and port

information in the packet with the information
stored in its session table. It then translates the
destination IP address from 1.1.1.3 to 3.3.3.3.

SRC DST Payload

1.1.1.1 3.3.3.3

12  Directional Nature of NAT-Src and NAT-Dst

Chapter 2
Source Network Address Translation

ScreenOS provides many methods for performing Source Network Address

Translation (NAT-src) and source Port Address Translation (PAT). This chapter
describes the various address translation methods available and is organized into
the following sections:

 “Introduction to NAT-Src” on page 13

 “NAT-Src from a DIP Pool with PAT Enabled” on page 15

 “NAT-Src from a DIP Pool with PAT Disabled” on page 18

 “NAT-Src from a DIP Pool with Address Shifting” on page 20

 “NAT-Src from the Egress Interface IP Address” on page 24

Introduction to NAT-Src
It is sometimes necessary for the security device to translate the original source IP
address in an IP packet header to another address. For example, when hosts with
private IP addresses initiate traffic to a public address space, the security device
must translate the private source IP address to a public one. Also, when sending
traffic from one private address space through a VPN to a site using the same
addresses, the security devices at both ends of the tunnel must translate the source
and destination IP addresses to mutually neutral addresses.

NOTE: For information about public and private IP addresses, see “Public IP Addresses”
on page 2-47 and “Private IP Addresses” on page 2-48.

A dynamic IP (DIP) address pool provides the security device with a supply of
addresses from which to draw when performing Source Network Address
Translation (NAT-src). When a policy requires NAT-src and references a specific DIP
pool, the security device draws addresses from that pool when performing the
translation.

Introduction to NAT-Src  13
 Concepts & Examples ScreenOS Reference Guide

NOTE: The DIP pool must use addresses within the same subnet as the default interface
in the destination zone referenced in the policy. If you want to use a DIP pool with
addresses outside the subnet of the destination zone interface, you must define a
DIP pool on an extended interface. For more information, see “Using DIP in a
Different Subnet” on page 2-145.

The DIP pool can be as small as a single IP address, which, if you enable Port
Address Translation (PAT), can support up to ~64,500 hosts concurrently. Although
all packets receiving a new source IP address from that pool get the same address,
they each get a different port number. By maintaining a session table entry that
matches the original address and port number with the translated address and port
number, the security device can track which packets belong to which session and
which sessions belong to which hosts.

NOTE: When PAT is enabled, the security device also maintains a pool of free port
numbers to assign along with addresses from the DIP pool. The figure of ~64,500
is derived by subtracting 1023, the numbers reserved for the well-known ports,
from the maximum number of ports, which is 65,535.

If you use NAT-src but do not specify a DIP pool in the policy, the security device
translates the source address to that of the egress interface in the destination zone.
In such cases, PAT is required and automatically enabled.

For applications requiring that a particular source port number remain fixed, you
must disable PAT and define a DIP pool with a range of IP addresses large enough
for each concurrently active host to receive a different translated address. For
fixed-port DIP, the security device assigns one translated source address to the
same host for all its concurrent sessions. In contrast, when the DIP pool has PAT
enabled, the security device might assign a single host different addresses for
different concurrent sessions—unless you define the DIP as sticky (see “Sticky DIP
Addresses” on page 2-144).

NOTE: You can add a maximum of three IP address ranges for a fixed-port DIP pool. The
IP address ranges should not overlap. When the first address range is exhausted,
the security device attempts to process the NAT request using the second address
range. When the second address range is exhausted, the security device attempts
to process the NAT request using the third address range. Note that the total range
of all IP addresses defined in the fixed-port DIP pool must not exceed the
permitted address scope of the subnet.

14  Introduction to NAT-Src
 Chapter 2: Source Network Address Translation

NAT-Src from a DIP Pool with PAT Enabled

When applying Source Network Address Translation (NAT-src) with Port Address
Translation (PAT), the security device translates IP addresses and port numbers, and
performs stateful inspection as illustrated in Figure 17 (note that only the elements
in the IP packet and TCP segment headers relevant to NAT-src are shown).

Figure 17: NAT-Src Using a DIP Pool with PAT Enabled

set policy from trust to untrust any http net src dip-ip 5 permit

Security Device DIP Pool ID 5

Local Host 1.1.1.30 - 1.1.1.30
ethernet1 10.1.1.1/24 (PAT enabled) Remote Webserver
10.1.1.5.25611 2.2.2.2:80
ethernet3 1.1.1.1/24
Trust Zone Untrust Zone

SRC IP DST IP SRC PT DST PT PROTO

10.1.1.5 2.2.2.2 25611 80 HTTP

The security device translates the source IP

address from 10.1.1.5 to 1.1.1.30 and the source
port from 25611 to 41834. It stores the IP and
port address information in its session table.

SRC IP DST IP SRC PT DST PT PROTO

1.1.1.30 2.2.2.2 41834 80 HTTP

SRC IP DST IP SRC PT DST PT PROT

2.2.2.2 1.1.1.30 80 41834 HTTP

The security device matches the IP and port

information in the packet with the information
stored in its session table. It then translates the
destination IP address from 1.1.1.30 to 10.1.1.5
and the destination port from 41834 to 25611.

SRC IP DST IP SRC PT DST PT PROTO

2.2.2.2 10.1.1.5 80 25611 HTTP

Example: NAT-Src with PAT Enabled

In this example, you define a DIP pool 5 on ethernet3, an interface bound to the
Untrust zone. The DIP pool contains a single IP address—1.1.1.30—and has PAT
enabled by default.

NOTE: When you define a DIP pool, the security device enables PAT by default. To disable
PAT, you must add the key word fix-port to the end of the CLI command, or clear
the Port Translation option on the DIP configuration page in the WebUI. For
example, set interface ethernet3 dip 5 1.1.1.30 1.1.1.30 fix-port, or Network >
Interfaces > Edit (for ethernet3) > DIP: ID: 5; Start: 1.1.1.30; End: 1.1.1.30; Port
Translation: (clear).

NAT-Src from a DIP Pool with PAT Enabled  15

 Concepts & Examples ScreenOS Reference Guide

You then set a policy that instructs the security device to perform the following
tasks:

 Permit HTTP traffic from any address in the Trust zone to any address in the
Untrust zone

 Translate the source IP address in the IP packet header to 1.1.1.30, which is the
sole entry in DIP pool 5

 Translate the original source port number in the TCP segment header or UDP
datagram header to a new, unique number

 Send HTTP traffic with the translated source IP address and port number out
ethernet3 to the Untrust zone

Figure 18: NAT-Src with PAT Enabled

Source Network Address Translation (NAT-src) DIP Pool ID 5

(Translates source IP address to a one-address 1.1.1.30 – 1.1.1.30
DIP pool—1.1.1.30. PAT is enabled.)

Trust Zone ethernet1 ethernet3 Untrust Zone

10.1.1.1/24 1.1.1.1/24

10.1.1.5:25611 1.1.1.30:41834 2.2.2.2:80

(Virtual Device)

Original Source Translated Source Destination

SRC IP DST IP SRC PT DST PT PROTO SRC IP DST IP SRC PT DST PT PROTO
10.1.1.5 2.2.2.2 25611 80 HTTP 1.1.1.30 2.2.2.2 41834 80 HTTP

WebUI
1. Interfaces
Network > Interfaces > Edit (for ethernet1): Enter the following, then click
Apply:

Zone Name: Trust

Static IP: (select this option when present)
IP Address/Netmask: 10.1.1.1/24

Select the following, then click OK:

Interface Mode: NAT

Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:

Zone Name: Untrust

Static IP: (select this option when present)
IP Address/Netmask: 1.1.1.1/24

16  NAT-Src from a DIP Pool with PAT Enabled

 Chapter 2: Source Network Address Translation

2. DIP
Network > Interfaces > Edit (for ethernet3) > DIP > New: Enter the
following, then click OK:

ID: 5
IP Address Range: (select), 1.1.1.30 ~ 1.1.1.30
Port Translation: (select)
In the same subnet as the interface IP or its secondary IPs: (select)
3. Policy
Policies > (From: Trust, To: Untrust) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), Any
Destination Address:
Address Book Entry: (select), Any
Service: HTTP
Action: Permit

> Advanced: Enter the following, then click Return to set the advanced
options and return to the basic configuration page:

NAT:
Source Translation: (select)
(DIP on): 5 (1.1.1.30 - 1.1.1.30)/X-late

CLI
1. Interfaces
set interface ethernet1 zone trust
set interface ethernet1 ip 10.1.1.1/24
set interface ethernet1 nat
set interface ethernet3 zone untrust
set interface ethernet3 ip 1.1.1.1/24
2. DIP
set interface ethernet3 dip 5 1.1.1.30 1.1.1.30
3. Policy
set policy from trust to untrust any any http nat src dip-id 5 permit
save

NAT-Src from a DIP Pool with PAT Enabled  17

 Concepts & Examples ScreenOS Reference Guide

NAT-Src from a DIP Pool with PAT Disabled

Certain configurations or situations may require you to perform Source Network
Address Translation (NAT-src) for the IP address without performing Port Address
Translation (PAT) for the source port number. For example, a custom application
might require a specific number for the source port address. In such a case, you can
define a policy instructing the security device to perform NAT-src without
performing PAT.

Example: NAT-Src with PAT Disabled

In this example, you define a DIP pool 6 on ethernet3, an interface bound to the
Untrust zone. The DIP pool contains a range of IP addresses from 1.1.1.50 to
1.1.1.150. You disable PAT. You then set a policy that instructs the security device to
perform the following tasks:

 Permit traffic for a user-defined service named “e-stock” from any address in
the Trust zone to any address in the Untrust zone

NOTE: It is assumed that you have previously defined the user-defined service “e-stock.”
This fictional service requires that all e-stock transactions originate from specific
source port numbers. For this reason, you must disable PAT for DIP pool 6.

 Translate the source IP address in the IP packet header to any available address
in DIP pool 6

 Retain the original source port number in the TCP segment header or UDP
datagram header

 Send e-stock traffic with the translated source IP address and original port
number out ethernet3 to the Untrust zone

WebUI
1. Interfaces
Network > Interfaces > Edit (for ethernet1): Enter the following, then click
Apply:

Zone Name: Trust

Static IP: (select this option when present)
IP Address/Netmask: 10.1.1.1/24
Select the following, then click OK:
Interface Mode: NAT

Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:

Zone Name: Untrust

Static IP: (select this option when present)
IP Address/Netmask: 1.1.1.1/24

18  NAT-Src from a DIP Pool with PAT Disabled

 Chapter 2: Source Network Address Translation

2. DIP
Network > Interfaces > Edit (for ethernet3) > DIP > New: Enter the
following, then click OK:

ID: 6
IP Address Range: (select), 1.1.1.50 ~ 1.1.1.150
Port Translation: (clear)
In the same subnet as the interface IP or its secondary IPs: (select)
3. Policy
Policies > (From: Trust, To: Untrust) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), Any
Destination Address:
Address Book Entry: (select), Any
Service: e-stock
Action: Permit

> Advanced: Enter the following, then click Return to set the advanced
options and return to the basic configuration page:

NAT:
Source Translation: (select)
DIP on: (select), 6 (1.1.1.50 - 1.1.1.150)

CLI
1. Interfaces
set interface ethernet1 zone trust
set interface ethernet1 ip 10.1.1.1/24
set interface ethernet1 nat
set interface ethernet3 zone untrust
set interface ethernet3 ip 1.1.1.1/24
2. DIP
set interface ethernet3 dip 6 1.1.1.50 1.1.1.150 fix-port
3. Policy
set policy from trust to untrust any any e-stock nat src dip-id 6 permit
save

NAT-Src from a DIP Pool with PAT Disabled  19

 Concepts & Examples ScreenOS Reference Guide

NAT-Src from a DIP Pool with Address Shifting

You can define a one-to-one mapping from an original source IP address to a
translated source IP address for a range of IP addresses. Such a mapping ensures
that the security device always translates a particular source IP address from within
that range to the same translated address within a DIP pool. There can be any
number of addresses in the range. You can even map one subnet to another subnet,
with a consistent one-to-one mapping of each original address in one subnet to its
translated counterpart in the other subnet.

One possible use for performing NAT-src with address shifting is to provide greater
policy granularity on another security device that receives traffic from the first one.
For example, the admin for Device-A at site A defines a policy that translates the
source addresses of its hosts when communicating with Device-B at site B through a
site-to-site VPN tunnel. If Device-A applies NAT-src using addresses from a DIP pool
without address shifting, the Device-B admin can only configure generic policies
regarding the traffic it can allow from site A. Unless the Device-B admin knows the
specific translated IP addresses, he can only set inbound policies for the range of
source addresses drawn from the Device-A DIP pool. On the other hand, if the
Device-B admin knows what the translated source addresses are (because of
address shifting), the Device-B admin can now be more selective and restrictive
with the policies he sets for inbound traffic from site A.

Note that it is possible to use a DIP pool with address shifting enabled in a policy
that applies to source addresses beyond the range specified in the pool. In such
cases, the security device passes traffic from all source addresses permitted in the
policy, applying NAT-src with address shifting to those addresses that fall within the
DIP pool range but leaving those addresses that fall outside the DIP pool range
unchanged. If you want the security device to apply NAT-src to all source addresses,
make sure that the range of source addresses is smaller or the same size as the
range of the DIP pool.

NOTE: The security device does not support source Port Address Translation (PAT) with
address shifting.

20  NAT-Src from a DIP Pool with Address Shifting

 Chapter 2: Source Network Address Translation

Example: NAT-Src with Address Shifting

In this example, you define DIP pool 10 on ethernet3, an interface bound to the
Untrust zone. You want to translate five addresses between 10.1.1.11 and 10.1.1.15
to five addresses between 1.1.1.101 and 1.1.1.105, and you want the relationship
between each original and translated address to be consistent:

Table 1: NAT-Src with Address Shifting

Original Source IP Address Translated Source IP Address

10.1.1.11 1.1.1.101
10.1.1.12 1.1.1.102
10.1.1.13 1.1.1.103
10.1.1.14 1.1.1.104
10.1.1.15 1.1.1.105

You define addresses for five hosts in the Trust zone and added them to an address
group named “group1”. The addresses for these hosts are 10.1.1.11, 10.1.1.12,
10.1.1.13, 10.1.1.14, and 10.1.1.15. You configure a policy from the Trust zone to
the Untrust zone that references that address group in a policy to which you apply
NAT-src with DIP pool 10. The policy instructs the security device to perform NAT-src
whenever a member of group1 initiates HTTP traffic to an address in the Untrust
zone. Furthermore, the security device always performs NAT-src from a particular IP
address—such as 10.1.1.13—to the same translated IP address—1.1.1.103.

You then set a policy that instructs the security device to perform the following
tasks:

 Permit HTTP traffic from group1 in the Trust zone to any address in the Untrust
zone

 Translate the source IP address in the IP packet header to its corresponding

address in DIP pool 10

 Send HTTP traffic with the translated source IP address and port number out
ethernet3 to the Untrust zone

WebUI
1. Interfaces
Network > Interfaces > Edit (for ethernet1): Enter the following, then click
Apply:

Zone Name: Trust

Static IP: (select this option when present)
IP Address/Netmask: 10.1.1.1/24
Select the following, then click OK:
Interface Mode: NAT

NAT-Src from a DIP Pool with Address Shifting  21

 Concepts & Examples ScreenOS Reference Guide

Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:

Zone Name: Untrust

Static IP: (select this option when present)
IP Address/Netmask: 1.1.1.1/24
2. DIP
Network > Interfaces > Edit (for ethernet3) > DIP > New: Enter the
following, then click OK:

ID: 10
IP Shift: (select)
From: 10.1.1.11
To: 1.1.1.101 ~ 1.1.1.105
In the same subnet as the interface IP or its secondary IPs: (select)
3. Addresses
Policy > Policy Elements> Addresses > List > New: Enter the following
information, then click OK:

Address Name: host1

IP Address/Domain Name:
IP/Netmask: (select), 10.1.1.11/32
Zone: Trust

Policy > Policy Elements> Addresses > List > New: Enter the following
information, then click OK:

Address Name: host2

IP Address/Domain Name:
IP/Netmask: (select), 10.1.1.12/32
Zone: Trust

Policy > Policy Elements> Addresses > List > New: Enter the following
information, then click OK:

Address Name: host3

IP Address/Domain Name:
IP/Netmask: (select), 10.1.1.13/32
Zone: Trust

Policy > Policy Elements> Addresses > List > New: Enter the following
information, then click OK:

Address Name: host4

IP Address/Domain Name:
IP/Netmask: (select), 10.1.1.14/32
Zone: Trust

Policy > Policy Elements> Addresses > List > New: Enter the following
information, then click OK:

Address Name: host5

IP Address/Domain Name:
IP/Netmask: (select), 10.1.1.15/32
Zone: Trust

22  NAT-Src from a DIP Pool with Address Shifting

 Chapter 2: Source Network Address Translation

Policy > Policy Elements > Addresses > Group > (for Zone: Trust) New: Enter
the following group name, move the following addresses, then click OK:

Group Name: group1

Select host1 and use the << button to move the address from the
Available Members column to the Group Members column.

Select host2 and use the << button to move the address from the
Available Members column to the Group Members column.

Select host3 and use the << button to move the address from the
Available Members column to the Group Members column.

Select host4 and use the << button to move the address from the
Available Members column to the Group Members column.

Select host5 and use the << button to move the address from the
Available Members column to the Group Members column.

4. Policy
Policies > (From: Trust, To: Untrust) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), group1
Destination Address:
Address Book Entry: (select), Any
Service: HTTP
Action: Permit

> Advanced: Enter the following, then click Return to set the advanced
options and return to the basic configuration page:

NAT:
Source Translation: (select)
(DIP on): 10 (1.1.1.101 - 1.1.1.105)

CLI
1. Interfaces
set interface ethernet1 zone trust
set interface ethernet1 ip 10.1.1.1/24
set interface ethernet1 nat
set interface ethernet3 zone untrust
set interface ethernet3 ip 1.1.1.1/24
2. DIP
set interface ethernet3 dip 10 shift-from 10.1.1.11 to 1.1.1.101 1.1.1.105

NAT-Src from a DIP Pool with Address Shifting  23

 Concepts & Examples ScreenOS Reference Guide

3. Addresses
set address trust host1 10.1.1.11/32
set address trust host2 10.1.1.12/32
set address trust host3 10.1.1.13/32
set address trust host4 10.1.1.14/32
set address trust host5 10.1.1.15/32
set group address trust group1 add host1
set group address trust group1 add host2
set group address trust group1 add host3
set group address trust group1 add host4
set group address trust group1 add host5
4. Policy
set policy from trust to untrust group1 any http nat src dip-id 10 permit
save

NAT-Src from the Egress Interface IP Address

If you apply NAT-src to a policy but do not specify a DIP pool, then the security
device translates the source IP address to the address of the egress interface. In
such cases, the security device always applies PAT.

Example: NAT-Src Without DIP

In this example, you define a policy that instructs the security device to perform the
following tasks:

 Permit HTTP traffic from any address in the Trust zone to any address in the
Untrust zone

 Translate the source IP address in the IP packet header to 1.1.1.1, which is the
IP address of ethernet3, the interface bound to the Untrust zone, and thus the
egress interface for traffic sent to any address in the Untrust zone

 Translate the original source port number in the TCP segment header or UDP
datagram header to a new, unique number

 Send traffic with the translated source IP address and port number out
ethernet3 to the Untrust zone

Figure 19: NAT-Src Without DIP

Source Network Address Translation (NAT-src)
(Translates the source IP address to the
egress interface IP address - 1.1.1.1 - in the
destination zone. PAT is enabled.)
Trust Zone ethernet1 ethernet3 Untrust Zone
10.1.1.1/24 1.1.1.1/24
10.1.1.5:25611 1.1.1.1:41834 2.2.2.2:80

(Virtual
1.1.1.1 Device)
Original Source Translated Source Destination
SRC IP DST IP SRC PT DST PT PROTO SRC IP DST IP SRC PT DST PT PROTO
10.1.1.5 2.2.2.2 25611 80 HTTP 1.1.1.1 2.2.2.2 41834 80 HTTP

24  NAT-Src from the Egress Interface IP Address

 Chapter 2: Source Network Address Translation

WebUI
1. Interfaces
Network > Interfaces > Edit (for ethernet1): Enter the following, then click
Apply:

Zone Name: Trust

Static IP: (select this option when present)
IP Address/Netmask: 10.1.1.1/24
Select the following, then click OK:
Interface Mode: NAT

Network > Interfaces > Edit (for ethernet3): Enter the following, then
click OK:

Zone Name: Untrust

Static IP: (select this option when present)
IP Address/Netmask: 1.1.1.1/24
2. Policy
Policies > (From: Trust, To: Untrust) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), Any
Destination Address:
Address Book Entry: (select), Any
Service: HTTP
Action: Permit

> Advanced: Enter the following, then click Return to set the advanced
options and return to the basic configuration page:

NAT:
Source Translation: (select)
(DIP on): None (Use Egress Interface IP)

CLI
1. Interfaces
set interface ethernet1 zone trust
set interface ethernet1 ip 10.1.1.1/24
set interface ethernet1 nat
set interface ethernet3 zone untrust
set interface ethernet3 ip 1.1.1.1/24
2. Policy
set policy from trust to untrust any any http nat src permit
save

NAT-Src from the Egress Interface IP Address  25

 Concepts & Examples ScreenOS Reference Guide

26  NAT-Src from the Egress Interface IP Address

Chapter 3
Destination Network Address
Translation

ScreenOS provides many methods for performing Destination Network Address

Translation (NAT-dst) and destination port address mapping. This chapter describes
the various address-translation methods available and contains the following
sections:

 “Introduction to NAT-Dst” on page 28

 “Packet Flow for NAT-Dst” on page 29

 “Routing for NAT-Dst” on page 32

 “NAT-Dst—One-to-One Mapping” on page 35

 “Translating from One Address to Multiple Addresses” on page 38

 “NAT-Dst—Many-to-One Mapping” on page 41

 “NAT-Dst—Many-to-Many Mapping” on page 44

 “NAT-Dst with Port Mapping” on page 47

 “NAT-Src and NAT-Dst in the Same Policy” on page 50

NOTE: For information about destination address translation using a mapped IP (MIP) or
virtual IP (VIP) address, see “Mapped and Virtual Addresses” on page 63.

 27
 Concepts & Examples ScreenOS Reference Guide

Introduction to NAT-Dst
You can define policies to translate the destination address from one IP address to
another. Perhaps you need the security device to translate one or more public IP
addresses to one or more private addresses. The relationship of the original
destination address to the translated destination address can be a one-to-one
relationship, a many-to-one relationship, or a many-to-many relationship. Figure 20
depicts the concepts of one-to-one and many-to-one NAT-dst relationships.

Figure 20: NAT-Dst—One-to-One and Many-to-One

The security device maps traffic from here .......... to here

NAT-Dst: One-to-One Mapping

(Virtual Devices)

NAT-Dst: Many-to-One Mapping

(Virtual Devices)

Original Translated
Destination Destination
Note: The original and the translated destination IP addresses must be in the same security zone.

Both of the configurations shown in Figure 20 support destination port mapping.

Port mapping is the deterministic translation of one original destination port
number to another specific number. The relationship of the original-to-translated
number in port mapping differs from Port Address Translation (PAT). With port
mapping, the security device translates a predetermined original port number to
another predetermined port number. With PAT, the security device translates a
randomly assigned original source port number to another randomly assigned
number.

You can translate a range of destination addresses to another range—such as one

subnet to another—with address shifting, so that the security device consistently
maps each original destination address to a specific translated destination address.
Note that security does not support port mapping with address shifting. Figure 21
depicts the concept of a many-to-many relationship for NAT-dst.

28  Introduction to NAT-Dst
 Chapter 3: Destination Network Address Translation

Figure 21: NAT-Dst—Many-to-Many

NAT-Dst: Many-to-Many Mapping

(Virtual Devices)

Original Translated
Destinations Destinations
There must be entries in the route table for both the original destination IP address
and the translated destination IP address. The security device performs a route
lookup using the original destination IP address to determine the destination zone
for a subsequent policy lookup. It then performs a second route lookup using the
translated address to determine where to send the packet. To ensure that the
routing decision is in accord with the policy, both the original destination IP address
and the translated IP address must be in the same security zone. (For more
information about the relationship of the destination IP address, route lookup, and
policy lookup, see “Packet Flow for NAT-Dst” on page 29.)

Packet Flow for NAT-Dst

The following steps describe the path of a packet through a security device and the
various operations that it performs when applying NAT-dst:

1. An HTTP packet with source IP address:port number 1.1.1.5:32455 and

destination IP address:port number 5.5.5.5:80 arrives at ethernet1, which is
bound to the Untrust zone.

Figure 22: NAT-Dst Packet Flow—Packet Arrival

SRC DST SRC DST DMZ Zone

Payload ethernet2
1.1.1.5 5.5.5.5 32455 80 2.2.2.2/24

Untrust Zone
Trust Zone
ethernet1 ethernet3
1.1.1.1/24 3.3.3.3/24

1.1.1.5
Source Custom 1 Zone
ethernet4
4.4.4.4/24

5.5.5.5 4.4.4.5
The three question marks indicate that the security device has not yet performed the Original Translated
steps required to learn which interface it must use to forward the packet. Destination Destination

Introduction to NAT-Dst  29
 Concepts & Examples ScreenOS Reference Guide

2. If you have enabled SCREEN options for the Untrust zone, the security device
activates the SCREEN module at this point. SCREEN checking can produce one
of the following three results:

 If a SCREEN mechanism detects anomalous behavior for which it is

configured to block the packet, the security device drops the packet and
makes an entry in the event log.

 If a SCREEN mechanism detects anomalous behavior for which it is

configured to record the event but not block the packet, the security device
records the event in the SCREEN counters list for the ingress interface and
proceeds to the next step.

 If the SCREEN mechanisms detect no anomalous behavior, the security

device proceeds to the next step.

If you have not enabled any SCREEN options for the Untrust zone, the security
device immediately proceeds to the next step.

3. The session module performs a session lookup, attempting to match the packet
with an existing session.

If the packet does not match an existing session, the security device performs
First Packet Processing, a procedure involving the remaining steps.

If the packet matches an existing session, the security device performs Fast
Processing, using the information available from the existing session entry to
process the packet. Fast Processing bypasses all but the last step because the
information generated by the bypassed steps has already been obtained during
the processing of the first packet in the session.

4. The address-mapping module checks if a mapped IP (MIP) or virtual IP (VIP)

configuration uses the destination IP address 5.5.5.5.

NOTE: The security device checks if the destination IP address is used in a VIP
configuration only if the packet arrives at an interface bound to the Untrust zone.

If there is such a configuration, the security device resolves the MIP or VIP to
the translated destination IP address and bases its route lookup on that. It then
does a policy lookup between the Untrust and Global zones. If it finds a policy
match that permits the traffic, the security device forwards the packet out the
egress interface determined in the route lookup.

If 5.5.5.5 is not used in a MIP or VIP configuration, the security device proceeds
to the next step.

5. To determine the destination zone, the route module does a route lookup of the
original destination IP address; that is, it uses the destination IP address that
appears in the header of the packet that arrives at ethernet1. (The route module
uses the ingress interface to determine which virtual router to use for the route
lookup.) It discovers that 5.5.5.5/32 is accessed through ethernet4, which is
bound to the Custom1 zone.

30  Introduction to NAT-Dst
 Chapter 3: Destination Network Address Translation

trust-vr Route Table

To Reach: Use Interface: In Zone: Use Gateway:
0.0.0.0/0 ethernet1 Untrust 1.1.1.250
1.1.1.0/24 ethernet1 Untrust 0.0.0.0
2.2.2.0/24 ethernet2 DMZ 0.0.0.0
3.3.3.0/24 ethernet3 Trust 0.0.0.0
4.4.4.0/24 ethernet4 Custom1 0.0.0.0
5.5.5.5/32 ethernet4 Custom1 0.0.0.0

6. The policy engine does a policy lookup between the Untrust and Custom1
zones (as determined by the corresponding ingress and egress interfaces). The
source and destination IP addresses and the service match a policy redirecting
HTTP traffic from 5.5.5.5 to 4.4.4.5.

set policy from untrust to custom1 any v-server1 http nat dst ip 4.4.4.5 permit

(You have previously defined the address “v-server1” with IP address

5.5.5.5/32. It is in the Custom1 zone.)

The security device translates the destination IP address from 5.5.5.5 to

4.4.4.5. The policy indicates that neither NAT-Src nor PAT-dst is required.

7. The security device does a second route lookup using the translated IP address
and discovers that 4.4.4.5/32 is accessed through ethernet4.

8. The address-mapping module translates the destination IP address in the

packet header to 4.4.4.5. The security device then forwards the packet out
ethernet4 and makes an entry in its session table (unless this packet is part of
an existing session and an entry already exists).

Introduction to NAT-Dst  31
 Concepts & Examples ScreenOS Reference Guide

Figure 23: NAT-Dst Packet Flow—Packet Forwarding

Untrust Zone SRC DST SRC DST

1.1.1.5 5.5.5.5 32455 80 Payload
ethernet1
1.1.1.1/24
1.1.1.5
Source Custom 1 Zone
ethernet4
4.4.4.4/24

4.4.4.5
Destination
Virtual system to which Policy ID that applies
this session belongs to this session
Session Session State Flags Session Timeout 30 Units
ID (internal use only) (30 x 10 = 300 seconds)

id 4 82/s**, vsy s 0, flag 04 000 000 /0 0/00 , polic y 21 , tim e 30

6 (2 1):1 .1.1.5/32 455 -> 4 .4 . 4.5/80 , 6 , 0 0b0d0a8 aa 2b, v la n 0 , t un 0, vs d 0

Interface ID Source MAC Address Tunnel ID

Source IP Destination in the first frame
Address/Port IP Address/Port
NSP Flag (internal Transport Protocol VLAN ID VSD ID
use only) 6 = TCP
Note: Because this session does not involve a virtual system, VLAN, VPN tunnel, or virtual security device (VSD), the setting for all these ID numbers is ze

Routing for NAT-Dst

When you configure addresses for NAT-dst, the security device must have routes in
its routing table to both the original destination address that appears in the packet
header and the translated destination address (that is, the address to which the
security device redirects the packet). As explained in “Packet Flow for NAT-Dst” on
page 29, the security device uses the original destination address to do a route
lookup, and thereby determine the egress interface. The egress interface in turn
provides the destination zone—the zone to which the interface is bound—so that
the security device can do a policy lookup. When the security device finds a policy
match, the policy defines the mapping of the original destination address to the
translated destination address. The security device then performs a second route
lookup to determine the interface through which it must forward the packet to
reach the new destination address. In summary, the route to the original destination
address provides a means to perform the policy lookup, and the route to the
translated destination address specifies the egress interface through which the
security device is to forward the packet.

32  Introduction to NAT-Dst
 Chapter 3: Destination Network Address Translation

In the following three scenarios, the need to enter static routes differs according to
the network topology surrounding the destination addresses referenced in this
policy:

set policy from untrust to trust any oda1 http nat dst ip 10.1.1.5 permit

in which “oda1” is the original destination address 10.2.1.5, and the translated
destination address is 10.1.1.5.

Example: Addresses Connected to One Interface

In this scenario, the routes to both the original and translated destination addresses
direct traffic through the same interface, ethernet3. The security device
automatically adds a route to 10.1.1.0/24 through ethernet3 when you configure the
IP address of the ethernet3 interface as 10.1.1.1/24. To complete the routing
requirements, you must add an additional route to 10.2.1.5/32 through ethernet3.

Figure 24: Original and Translated Addresses Using the Same Egress Interface

ethernet3 Original Destination

“oda1” 10.2.1.5 * Translated Trust Zone
10.1.1.1/24 Destination
10.1.1.5

(Virtual
Device) 10.1.1.0/24

* Although 10.2.1.5 is not in the 10.1.1.0/24 subnet, because its route does not specify a gateway,
it is illustrated as if it is in the same connected subnet as the 10.1.1.0/24 address space.

WebUI
Network > Routing > Destination > (trust-vr) New: Enter the following, then
click OK:

Network Address / Netmask: 10.2.1.5/32

Gateway: (select)
Interface: ethernet3
Gateway IP Address: 0.0.0.0

CLI
set vrouter trust-vr route 10.2.1.5/32 interface ethernet3
save

Introduction to NAT-Dst  33
 Concepts & Examples ScreenOS Reference Guide

Example: Addresses Connected to One Interface

But Separated by a Router
In this scenario, the routes to both the original and translated destination addresses
direct traffic through ethernet3. The security device automatically adds a route to
10.1.1.0/24 through ethernet3 when you configure the IP address of the ethernet3
interface as 10.1.1.1/24. To complete the routing requirements, you must add a
route to 10.2.1.0/24 through ethernet3 and the gateway connecting the 10.1.1.0/24
and the 10.2.1.0/24 subnets.

NOTE: Because this route is required to reach any address in the 10.2.1.0/24 subnet, you
have probably already configured it. If so, no extra route needs to be added just
for the policy to apply NAT-dst to 10.2.1.5.

Figure 25: Original and Translated Addresses Separated by a Router

Translated
ethernet3 Destination Trust Zone
10.1.1.1/24 Original Destination
10.1.1.5 “oda1” 10.2.1.5
10.1.1.250/24

10.1.1.0/24 (Virtual Device)

10.1.1.250/24 10.2.1.0/24

WebUI
Network > Routing > Destination > (trust-vr) New: Enter the following, then
click OK:

Network Address / Netmask: 10.2.1.0/24

Gateway: (select)
Interface: ethernet3
Gateway IP Address: 10.1.1.250

CLI
set vrouter trust-vr route 10.2.1.0/24 interface ethernet3 gateway 10.1.1.250
save

Example: Addresses Separated by an Interface

In this scenario, two interfaces are bound to the Trust zone: ethernet3 with IP
address 10.1.1.1/24 and ethernet4 with IP address 10.2.1.1/24. The security device
automatically adds a route to 10.1.1.0/24 through ethernet3 and 10.2.1.0/24
through ethernet4 when you configure the IP addresses of these interfaces. By
putting the original destination address in the 10.2.1.0/24 subnet and the translated
destination address in the 10.1.1.0/24 subnet, you do not have to add any other
routes for the security device to apply NAT-dst from 10.1.1.5 to 10.2.1.5.

34  Introduction to NAT-Dst
 Chapter 3: Destination Network Address Translation

Figure 26: Original and Translated Addresses Using Different Egress Interfaces
Translated
Destination
ethernet3 10.1.1.5
10.1.1.1/24

10.1.1.0/24
Trust Zone
10.2.1.0/24

ethernet4 (Virtual Device)

10.2.1.1/24
Original Destination
“oda1” 10.2.1.5

NAT-Dst—One-to-One Mapping
When applying Destination Network Address Translation (NAT-dst) without PAT, the
security device translates the destination IP address and performs stateful
inspection as illustrated in Figure 27 (note that only the elements in the IP packet
and TCP segment headers relevant to NAT-dst are shown).

Figure 27: One-to-One NAT-Dst

(Virtual Device)

Source Security Device Original Destination Translated Destinatio

2.2.2.5:36104 ethernet3 1.1.1.1/24, Untrust 1.2.1.5:80 10.1.1.5:80
ethernet2 10.1.1.1/24 DMZ
Trust Zone Untrust Zone

SRC IP DST IP SRC PT DST PT PROTO

2.2.2.5 1.2.1.5 35104 80 HTTP
The security device translates the source IP
address from 1.2.1.5 to 10.1.1.5 and the source
port from 25611 to 41834. It stores the IP and
port address information in its session table.

SRC IP DST IP SRC PT DST PT PROTO

2.2.2.5 10.1.1.5 35104 80 HTTP

SRC IP DST IP SRC PT DST PT PROTO

10.1.1.5 2.2.2.5 80 35104 HTTP

The security device matches the IP and port

information in the packet with the information
stored in its session table. It then translates the
destination IP address from 10.1.1.5 to 1.2.1.5
and the destination port from 41834 to 21611.

SRC IP DST IP SRC PT DST PT PROTO

1.2.1.5 2.2.2.5 80 35104 HTTP

NAT-Dst—One-to-One Mapping  35
 Concepts & Examples ScreenOS Reference Guide

Example: One-to-One Destination Translation

In this example, you set a policy to provide one-to-one Destination Network Address
Translation (NAT-dst) without changing the destination port addresses. The policy
instructs the security device to perform the following tasks:

 Permit both FTP and HTTP traffic (defined as the service group “http-ftp”) from
any address in the Untrust zone to a the original destination address named
“oda2” with address 1.2.1.8 in the DMZ zone

 Translate the destination IP address in the IP packet header from 1.2.1.8 to

10.2.1.8

 Leave the original destination port number in the TCP segment header as is (80
for HTTP and 21 for FTP)

 Forward HTTP and FTP traffic to 10.2.1.8 in the DMZ zone

You bind ethernet3 to the Untrust zone and assign it IP address 1.1.1.1/24. You
bind ethernet2 to the DMZ and assign it IP address 10.2.1.1/24. You also define a
route to the original destination address 1.2.1.8 through ethernet2. Both the Untrust
and DMZ zones are in the trust-vr routing domain.

Figure 28: NAT-Dst—One-to-One

Original
Destination
“oda2” 1.2.1.8
ethernet3 ethernet2
1.1.1.1/24 10.2.1.1/24 (Virtual Device)
Untrust Zone

Source Translated
2.2.2.5 Destination
DMZ Zone 10.2.1.8

SRC IP DST IP SRC PT DST PT PROTO SRC IP DST IP SRC PT DST PT PROTO
2.2.2.5 1.2.1.8 25611 80 HTTP 2..2.1.5 10.2.1.8 25611 80 HTTP

SRC IP DST IP SRC PT DST PT PROTO SRC IP DST IP SRC PT DST PT PROTO
2.2.2.5 1.2.1.8 40365 21 FTP 2.2.2.5 10.2.1.8 40365 21 FTP

WebUI
1. Interfaces
Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:

Zone Name: Untrust

Static IP: (select this option when present)
IP Address/Netmask: 1.1.1.1/24

Network > Interfaces > Edit (for ethernet2): Enter the following, then click
OK:

Zone Name: DMZ

Static IP: (select this option when present)
IP Address/Netmask: 10.2.1.1/24

36  NAT-Dst—One-to-One Mapping
 Chapter 3: Destination Network Address Translation

2. Address
Policy > Policy Elements> Addresses > List > New: Enter the following
information, then click OK:

Address Name: oda2

IP Address/Domain Name:
IP/Netmask: (select), 1.2.1.8/32
Zone: DMZ
3. Service Group
Policy > Policy Elements > Services > Groups: Enter the following group
name, move the following services, then click OK:

Group Name: HTTP-FTP

Select HTTP and use the << button to move the service from the Available
Members column to the Group Members column.

Select FTP and use the << button to move the service from the Available
Members column to the Group Members column.

4. Route
Network > Routing > Destination > trust-vr New: Enter the following, then
click OK:

Network Address / Netmask: 1.2.1.8/32

Gateway: (select)
Interface: ethernet2
Gateway IP Address: 0.0.0.0
5. Policy
Policies > (From: Untrust, To: DMZ) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), Any
Destination Address:
Address Book Entry: (select), oda2
Service: HTTP-FTP
Action: Permit

> Advanced: Enter the following, then click Return to set the advanced
options and return to the basic configuration page:

NAT:
Destination Translation: (select)
Translate to IP: (select), 10.2.1.8
Map to Port: (clear)

CLI
1. Interfaces
set interface ethernet3 zone untrust
set interface ethernet3 ip 1.1.1.1/24
set interface ethernet2 zone dmz
set interface ethernet2 ip 10.2.1.1/24

NAT-Dst—One-to-One Mapping  37
 Concepts & Examples ScreenOS Reference Guide

2. Address
set address dmz oda2 1.2.1.8/32
3. Service Group
set group service http-ftp
set group service http-ftp add http
set group service http-ftp add ftp
4. Route
set vrouter trust-vr route 1.2.1.8/32 interface ethernet2
5. Policy
set policy from untrust to dmz any oda2 http-ftp nat dst ip 10.2.1.8 permit
save

Translating from One Address to Multiple Addresses

The security device can translate the same original destination address to different
translated destination addresses specified in different policies, depending on the
type of service or the source address specified in each policy. You might want the
security device to redirect HTTP traffic from 1.2.1.8 to 10.2.1.8, and FTP traffic
from 1.2.1.8 to 10.2.1.9 (see the following example). Perhaps you want the security
device to redirect HTTP traffic sent from host1 to 1.2.1.8 over to 10.2.1.8, but HTTP
traffic sent from host2 to 1.2.1.8 over to 10.2.1.37. In both cases, the security
device redirects traffic sent to the same original destination address to different
translated addresses.

Example: One-to-Many Destination Translation

In this example, you create two policies that use the same original destination
address (1.2.1.8), but that direct traffic sent to that address to two different
translated destination addresses based on the service type. These policies instruct
the security device to perform the following tasks:

 Permit both FTP and HTTP traffic from any address in the Untrust zone to a
user-defined address named “oda3” in the DMZ zone

 For HTTP traffic, translate the destination IP address in the IP packet header
from 1.2.1.8 to 10.2.1.8

 For FTP traffic, translate the destination IP address from 1.2.1.8 to 10.2.1.9

 Leave the original destination port number in the TCP segment header as is (80
for HTTP, 21 for FTP)

 Forward HTTP traffic to 10.2.1.8 and FTP traffic to 10.2.1.9 in the DMZ zone

38  NAT-Dst—One-to-One Mapping
 Chapter 3: Destination Network Address Translation

Figure 29: NAT-Dst—One-to-Many

Original Destination “oda3”
1.2.1.8:80
1.2.1.8:21
Untrust Zone ethernet3 ethernet2
1.1.1.1/24 10.2.1.1/24
DMZ Zone
2.2.2.5:25611
2.2.2.5:40365
(Virtual
Device)
Source Translated
Destination Translated
10.2.1.9:21 Destination
10.2.1.8:80

SRC IP DST IP SRC PT DST PT PROTO SRC IP DST IP SRC PT DST PT PROTO
2.2.2.5 1.2.1.8 25611 80 HTTP 2.2.2.5 10.2.1.8 25611 80 HTTP

SRC IP DST IP SRC PT DST PT PROTO SRC IP DST IP SRC PT DST PT PROTO
2.2.2.5 1.2.1.8 40365 21 FTP 2.2.2.5 10.2.1.9 40365 21 FTP

You bind ethernet3 to the Untrust zone and assign it IP address 1.1.1.1/24. You
bind ethernet2 to the DMZ, and assign it IP address 10.2.1.1/24. You also define a
route to the original destination address 1.2.1.8 through ethernet2. Both the Untrust
zone and the DMZ zone are in the trust-vr routing domain.

WebUI
1. Interfaces
Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:

Zone Name: Untrust

Static IP: (select this option when present)
IP Address/Netmask: 1.1.1.1/24

Network > Interfaces > Edit (for ethernet2): Enter the following, then click
OK:

Zone Name: DMZ

Static IP: (select this option when present)
IP Address/Netmask: 10.2.1.1/24
2. Address
Policy > Policy Elements> Addresses > List > New: Enter the following
information, then click OK:

Address Name: oda3

IP Address/Domain Name:
IP/Netmask: (select), 1.2.1.8/32
Zone: DMZ
3. Route
Network > Routing > Destination > trust-vr New: Enter the following, then
click OK:

Network Address / Netmask: 1.2.1.8/32

Gateway: (select)
Interface: ethernet2
Gateway IP Address: 0.0.0.0

NAT-Dst—One-to-One Mapping  39
 Concepts & Examples ScreenOS Reference Guide

4. Policies
Policies > (From: Untrust, To: DMZ) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), Any
Destination Address:
Address Book Entry: (select), oda3
Service: HTTP
Action: Permit

> Advanced: Enter the following, then click Return to set the advanced
options and return to the basic configuration page:

NAT:
Destination Translation: (select)
Translate to IP: (select), 10.2.1.8
Map to Port: (clear)

Policies > (From: Untrust, To: DMZ) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), Any
Destination Address:
Address Book Entry: (select), oda3
Service: FTP
Action: Permit

> Advanced: Enter the following, then click Return to set the advanced
options and return to the basic configuration page:

NAT:
Destination Translation: (select)
Translate to IP: (select), 10.2.1.9
Map to Port: (clear)

CLI
1. Interfaces
set interface ethernet3 zone untrust
set interface ethernet3 ip 1.1.1.1/24
set interface ethernet2 zone dmz
set interface ethernet2 ip 10.2.1.1/24
2. Address
set address dmz oda3 1.2.1.8/32
3. Route
set vrouter trust-vr route 1.2.1.8/32 interface ethernet2
4. Policies
set policy from untrust to dmz any oda3 http nat dst ip 10.2.1.8 permit
set policy from untrust to dmz any oda3 ftp nat dst ip 10.2.1.9 permit
save

40  NAT-Dst—One-to-One Mapping
 Chapter 3: Destination Network Address Translation

NAT-Dst—Many-to-One Mapping
The relationship of the original destination address to the translated destination
address can also be a many-to-one relationship. In this case, the security device
forwards traffic sent to several original destination addresses to a single translated
destination address. Optionally, you can also specify destination port mapping.

Example: Many-to-One Destination Translation

In this example, you create a policy that redirects traffic sent to different original
destination addresses (1.2.1.10 and 1.2.1.20) to the same translated destination
address. This policy instructs the security device to perform the following tasks:

 Permit HTTP traffic from any address in the Untrust zone to a user-defined
address group named “oda45” with addresses “oda4” (1.2.1.10) and “oda5”
(1.2.1.20) in the DMZ zone

 Translate the destination IP addresses in the IP packet header from 1.2.1.10

and 1.2.1.20 to 10.2.1.15

 Leave the original destination port number in the TCP segment header as is (80
for HTTP)

 Forward the HTTP traffic to 10.2.1.15 in the DMZ zone

Figure 30: NAT-Dst—Many-to-One

Original Destination “oda4”
1.2.1.10:80
ethernet3 ethernet2
1.1.1.1/24 10.2.1.1/24
Untrust Zone Translated
DMZ Zone Destination
10.2.1.15:80
10.2.1.15.80
Original Destination
Source “oda5” 1.2.1.20:80
1.1.1.5:25611 (Virtual Device)
1.1.1.6:40365
SRC IP DST IP SRC PT DST PT PROTO SRC IP DST IP SRC PT DST PT PROTO
1.1.1.5 1.2.1.10 25611 80 HTTP 1.1.1.5 10.2.1.15 25611 80 HTTP

SRC IP DST IP SRC PT DST PT PROTO SRC IP DST IP SRC PT DST PT PROTO
1.1.1.6 1.2.1.20 40365 80 HTTP 1.1.1.6 10.2.1.15 40365 80 HTTP

You bind ethernet3 to the Untrust zone and assign it IP address 1.1.1.1/24. You
bind ethernet2 to the DMZ and assign it IP address 10.2.1.1/24. You also define a
route to the original destination addresses 1.2.1.10 and 1.2.1.20 through ethernet2.
Both the Untrust zone and the DMZ zone are in the trust-vr routing domain.

NAT-Dst—Many-to-One Mapping  41
 Concepts & Examples ScreenOS Reference Guide

WebUI
1. Interfaces
Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:

Zone Name: Untrust

Static IP: (select this option when present)
IP Address/Netmask: 1.1.1.1/24

Network > Interfaces > Edit (for ethernet2): Enter the following, then click
OK:

Zone Name: DMZ

Static IP: (select this option when present)
IP Address/Netmask: 10.2.1.1/24
2. Addresses
Policy > Policy Elements> Addresses > List > New: Enter the following
information, then click OK:

Address Name: oda4

IP Address/Domain Name:
IP/Netmask: (select), 1.2.1.10/32
Zone: DMZ

Policy > Policy Elements> Addresses > List > New: Enter the following
information, then click OK:

Address Name: oda5

IP Address/Domain Name:
IP/Netmask: (select), 1.2.1.20/32
Zone: DMZ

Policy > Policy Elements > Addresses > Groups > (for Zone: DMZ) New:
Enter the following group name, move the following addresses, then click OK:

Group Name: oda45

Select oda4 and use the << button to move the address from the
Available Members column to the Group Members column.

Select oda5 and use the << button to move the address from the
Available Members column to the Group Members column.

3. Routes
Network > Routing > Destination > trust-vr New: Enter the following, then
click OK:

Network Address / Netmask: 1.2.1.10/32

Gateway: (select)
Interface: ethernet2
Gateway IP Address: 0.0.0.0

42  NAT-Dst—Many-to-One Mapping
 Chapter 3: Destination Network Address Translation

Network > Routing > Destination > trust-vr New: Enter the following, then
click OK:

Network Address / Netmask: 1.2.1.20/32

Gateway: (select)
Interface: ethernet2
Gateway IP Address: 0.0.0.0
4. Policy
Policies > (From: Untrust, To: DMZ) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), Any
Destination Address:
Address Book Entry: (select), oda45
Service: HTTP
Action: Permit

> Advanced: Enter the following, then click Return to set the advanced
options and return to the basic configuration page:

NAT:
Destination Translation: (select)
Translate to IP: (select), 10.2.1.15
Map to Port: (clear)

CLI
1. Interfaces
set interface ethernet3 zone untrust
set interface ethernet3 ip 1.1.1.1/24
set interface ethernet2 zone dmz
set interface ethernet2 ip 10.2.1.1/24
2. Addresses
set address dmz oda4 1.2.1.10/32
set address dmz oda5 1.2.1.20/32
set group address dmz oda45 add oda4
set group address dmz oda45 add oda5
3. Routes
set vrouter trust-vr route 1.2.1.10/32 interface ethernet2
set vrouter trust-vr route 1.2.1.20/32 interface ethernet2
4. Policy
set policy from untrust to dmz any oda45 http nat dst ip 10.2.1.15 permit
save

NAT-Dst—Many-to-One Mapping  43
 Concepts & Examples ScreenOS Reference Guide

NAT-Dst—Many-to-Many Mapping
You can use Destination Network Address Translation (NAT-dst) to translate one
range of IP addresses to another range. The range of addresses can be a subnet or a
smaller set of addresses within a subnet. ScreenOS employs an address shifting
mechanism to maintain the relationships among the original range of destination
addresses after translating them to the new range of addresses. For example, if the
range of original addresses is 10.1.1.1 – 10.1.1.50 and the starting address for the
translated address range is 10.100.3.101, then the security device translates the
addresses as follows:

 10.1.1.1 – 10.100.3.101

 10.1.1.2 – 10.100.3.102

 10.1.1.3 – 10.100.3.103

 10.1.1.48 – 10.100.3.148

 10.1.1.49 – 10.100.3.149

 10.1.1.50 – 10.100.3.150

NOTE: When configuring Destination Network Address Translation (NAT-dst), do not

specify the address group entry as the destination.

If, for example, you want to create a policy that applies the above translations to
HTTP traffic from any address in zone A to an address object named “addr1-50”,
which contains all the addresses from 10.1.1.1 to 10.1.1.50, in zone B, you can
enter the following CLI command:

set policy id 1 from zoneA to zoneB any addr1-50 http nat dst ip 10.100.3.101
10.100.3.150 permit

If any host in zone A initiates HTTP traffic to an address within the defined range in
zone B, such as 10.1.1.37, then the security device applies this policy and translates
the destination address to 10.100.3.137.

The security device only performs NAT-dst if the source and destination zones, the
source and destination addresses, and the service specified in the policy all match
these components in the packet. For example, you might create another policy that
permits traffic from any host in zone A to any host in zone B and position it after
policy 1 in the policy list:

set policy id 1 from zoneA to zoneB any addr1-50 http nat dst ip 10.100.3.101
10.100.3.150 permit
set policy id 2 from zoneA to zoneB any any any permit

44  NAT-Dst—Many-to-Many Mapping
 Chapter 3: Destination Network Address Translation

If you have these two policies configured, the following kinds of traffic sent from a
host in zone A to a host in zone B bypass the NAT-dst mechanism:

 A zone A host initiates non-HTTP traffic to 10.1.1.37 in zone B. The security

device applies policy 2 because the service is not HTTP and passes the traffic
without translating the destination address.

 A zone A host initiates HTTP traffic to 10.1.1.51 in zone B. The security device
also applies policy 2 because the destination address is not in the addr1-50
address group, and passes the traffic without translating the destination
address.

Example: Many-to-Many Destination Translation

In this example, you configure a policy that applies NAT-dst when any kind of traffic
is sent to any host in a subnet, instructing the security device to perform the
following tasks:

 Permit all traffic types from any address in the Untrust zone to any address in
the DMZ zone

 Translate the original destination address named “oda6” from the 1.2.1.0/24
subnet to a corresponding address in the 10.2.1.0/24 subnet

 Leave the original destination port number in the TCP segment header as is

 Forward HTTP traffic to the translated address in the DMZ

Figure 31: NAT-Dst—Many-to-Many

DMZ Zone
ethernet2 ethernet3
Untrust Zone 1.1.1.1/24 10.2.1.1/24 1.2.1.1 – 10.2.1.1
1.2.1.2 – 10.2.1.2
Internet 1.2.1.3 – 10.2.1.3
1.2.1.253 – 10.2.1.253
1.2.1.254 – 10.2.1.254

Original Destinations Translated Destinations

“oda6” 1.2.1.0/24 10.2.1.0/24

You bind ethernet3 to the Untrust zone and assign it IP address 1.1.1.1/24. You
bind ethernet2 to the DMZ and assign it IP address 10.2.1.1/24. You also define a
route to the original destination address subnet (1.2.1.0/24) through ethernet2.
Both the Untrust zone and the DMZ zone are in the trust-vr routing domain.

WebUI
1. Interfaces
Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:

Zone Name: Untrust

Static IP: (select this option when present)
IP Address/Netmask: 1.1.1.1/24

NAT-Dst—Many-to-Many Mapping  45
 Concepts & Examples ScreenOS Reference Guide

Network > Interfaces > Edit (for ethernet2): Enter the following, then click
OK:

Zone Name: DMZ

Static IP: (select this option when present)
IP Address/Netmask: 10.2.1.1/24
2. Address
Policy > Policy Elements> Addresses > List > New: Enter the following
information, then click OK:

Address Name: oda6

IP Address/Domain Name:
IP/Netmask: (select), 1.2.1.0/24
Zone: DMZ
3. Route
Network > Routing > Destination > trust-vr New: Enter the following, then
click OK:

Network Address / Netmask: 1.2.1.0/24

Gateway: (select)
Interface: ethernet2
Gateway IP Address: 0.0.0.0
4. Policy
Policies > (From: Untrust, To: DMZ) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), Any
Destination Address:
Address Book Entry: (select), oda6
Service: Any
Action: Permit

> Advanced: Enter the following, then click Return to set the advanced
options and return to the basic configuration page:
NAT:
Destination Translation: (select)
Translate to IP Range: (select), 10.2.1.0 – 10.2.1.254

CLI
1. Interfaces
set interface ethernet3 zone untrust
set interface ethernet3 ip 1.1.1.1/24
set interface ethernet2 zone dmz
set interface ethernet2 ip 10.2.1.1/24
2. Address
set address dmz oda6 1.2.1.0/24
3. Route
set vrouter trust-vr route 1.2.1.0/24 interface ethernet2
4. Policy
set policy from untrust to dmz any oda6 any nat dst ip 10.2.1.0 10.2.1.254 permit
save

46  NAT-Dst—Many-to-Many Mapping
 Chapter 3: Destination Network Address Translation

NAT-Dst with Port Mapping

When you configure the security device to perform Destination Network Address
Translation (NAT-dst), you can optionally enable port mapping. One reason to
enable port mapping is to support multiple server processes for a single service on a
single host. For example, one host can run two webservers—one at port 80 and
another at port 8081. For HTTP service 1, the security device performs NAT-dst
without port mapping (dst port 80 -> 80).

For HTTP service 2, the security device performs NAT-dst to the same destination IP
address with port mapping (dst port 80 -> 8081). The host can sort HTTP traffic to
the two webservers by the two distinct destination port numbers.

NOTE: ScreenOS does not support port mapping for NAT-dst with address shifting. See
“NAT-Dst—Many-to-Many Mapping” on page 44.

Example: NAT-Dst with Port Mapping

In this example, you create two policies that perform NAT-dst and port mapping on
Telnet traffic from the Trust and Untrust zones to a Telnet server in the DMZ zone.
These policies instruct the security device to perform the following tasks:

 Permit Telnet from any address in the Untrust and Trust zones to 1.2.1.15 in
the DMZ zone

 Translate the original destination IP address named “oda7” from 1.2.1.15 to

10.2.1.15

 Translate the original destination port number in the TCP segment header from
23 to 2200

 Forward Telnet traffic to the translated address in the DMZ zone

You configure the following interface-to-zone bindings and address assignments:

 ethernet1: Trust zone, 10.1.1.1/24

 ethernet2: DMZ zone, 10.2.1.1/24.

 ethernet3: Untrust zone, 1.1.1.1/24.

You define an address entry “oda7” with IP address 1.2.1.15/32 in the DMZ zone.
You also define a route to the original destination address 1.2.1.15 through
ethernet2. The Trust, Untrust, and DMZ zones are all in the trust-vr routing domain.

NAT-Dst with Port Mapping  47

 Concepts & Examples ScreenOS Reference Guide

WebUI
1. Interfaces
Network > Interfaces > Edit (for ethernet1): Enter the following, then click
Apply:

Zone Name: Trust

Static IP: (select this option when present)
IP Address/Netmask: 10.1.1.1/24
Select the following, then click OK:
Interface Mode: NAT

Network > Interfaces > Edit (for ethernet2): Enter the following, then click
OK:

Zone Name: DMZ

Static IP: (select this option when present)
IP Address/Netmask: 10.2.1.1/24

Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:

Zone Name: Untrust

Static IP: (select this option when present)
IP Address/Netmask: 1.1.1.1/24
2. Address
Policy > Policy Elements> Addresses > List > New: Enter the following
information, then click OK:

Address Name: oda7

IP Address/Domain Name:
IP/Netmask: (select), 1.2.1.15/32
Zone: DMZ
3. Route
Network > Routing > Destination > trust-vr New: Enter the following, then
click OK:

Network Address / Netmask: 1.2.1.15/32

Gateway: (select)
Interface: ethernet2
Gateway IP Address: 0.0.0.0
4. Policies
Policies > (From: Trust, To: DMZ) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), Any
Destination Address:
Address Book Entry: (select), oda7
Service: Telnet
Action: Permit

48  NAT-Dst with Port Mapping

 Chapter 3: Destination Network Address Translation

> Advanced: Enter the following, then click Return to set the advanced
options and return to the basic configuration page:

NAT:
Destination Translation: (select)
Translate to IP: (select), 10.2.1.15
Map to Port: (select), 2200

Policies > (From: Untrust, To: DMZ) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), Any
Destination Address:
Address Book Entry: (select), oda7
Service: Telnet
Action: Permit

> Advanced: Enter the following, then click Return to set the advanced
options and return to the basic configuration page:

NAT:
Destination Translation: (select)
Translate to IP: (select), 10.2.1.15
Map to Port: (select), 2200

CLI
1. Interfaces
set interface ethernet1 zone trust
set interface ethernet1 ip 10.1.1.1/24
set interface ethernet1 nat
set interface ethernet2 zone dmz
set interface ethernet2 ip 10.2.1.1/24
set interface ethernet3 zone untrust
set interface ethernet3 ip 1.1.1.1/24
2. Address
set address dmz oda7 1.2.1.15/32
3. Route
set vrouter trust-vr route 1.2.1.15/32 interface ethernet2
4. Policies
set policy from trust to dmz any oda7 telnet nat dst ip 10.2.1.15 port 2200 permit
set policy from untrust to dmz any oda7 telnet nat dst ip 10.2.1.15 port 2200
permit
save

NAT-Dst with Port Mapping  49

 Concepts & Examples ScreenOS Reference Guide

NAT-Src and NAT-Dst in the Same Policy

You can combine Source Network Address Translation (NAT-Src) and Destination
Network Address Translation (NAT-dst) in the same policy. This combination
provides you with a method of changing both the source and the destination IP
addresses at a single point in the data path.

Example: NAT-Src and NAT-Dst Combined

In the example shown in Figure 32, you configure a security device (Device-1) that
is between a service provider’s customers and server farms. The customers connect
to Device-1 through ethernet1, which has IP address 10.1.1.1/24 and is bound to
the Trust zone. Device-1 then forwards their traffic through one of two route-based
VPN tunnels to reach the servers they want to target. The tunnel interfaces that are
bound to these tunnels are in the Untrust zone. Both the Trust and Untrust zones are
in the trust-vr routing domain.

NOTE: Policy-based VPNs do not support NAT-dst. You must use a route-based VPN
configuration with NAT-dst.

Because the customers might have the same addresses as those of the servers to
which they want to connect, Device-1 must perform both Source and Destination
Network Address Translation (NAT-Src and NAT-dst). To retain addressing
independence and flexibility, the security devices protecting the server
farms—Device-A and Device-B—perform NAT-dst. The service provider instructs the
customers and the server farm admins to reserve addresses
10.173.10.1–10.173.10.7, 10.173.20.0/24, 10.173.30.0/24, 10.173.40.0/24, and
10.173.50.0/24 for this purpose. These addresses are used as follows:

 The two tunnel interfaces have the following address assignments:

 tunnel.1, 10.173.10.1/30

 tunnel.2, 10.173.10.5/30

 Each tunnel interface supports the following DIP pools with PAT enabled:

 tunnel.1, DIP ID 5: 10.173.10.2–10.173.10.2

 tunnel.2, DIP ID 6: 10.173.10.6–10.173.10.6

 When Device-1 performs NAT-dst, it translates original destination addresses

with address shifting as follows:

 10.173.20.0/24 to 10.173.30.0/24

 10.173.40.0/24 to 10.173.50.0/24

NOTE: For information about address shifting when performing NAT-dst, see
“NAT-Dst—Many-to-Many Mapping” on page 44.

50  NAT-Src and NAT-Dst in the Same Policy

 Chapter 3: Destination Network Address Translation

The configurations for both tunnels—vpn1 and vpn2—use the following

parameters: AutoKey IKE, preshared key (“device1” for vpn1, and “device2” for
vpn2), and the security level predefined as “Compatible” for both Phase 1 and
Phase 2 proposals. (For details about these proposals, see “Tunnel Negotiation” on
page 5-8.) The proxy ID for both vpn1 and vpn2 is 0.0.0.0/0 - 0.0.0.0/0 - any.

NOTE: The configuration for Device-1 is provided first. The VPN configurations for
Device-A and Device-B follow and are included for completeness.

Figure 32: NAT-Src and NAT-Dst Combined

Security Device-1 Security Device-B
tunnel.1, 10.173.10.1/30 Untrust 3.3.3.3/24, Trust 10.100.2.1/24
tunnel.1, 10.3.3.1/24
NAT-src NAT-dst
• DIP Pool 10.173.10.2 – 10.173.10.2 • Original Destination 10.173.20.0/24
Customers with different source IP addresses connect
to a provider's servers through VPN tunnels. NAT-dst • Translated Destination 10.173.30.0/24
• Original Destination 10.173.20.0/24
• Translated Destination 10.173.30.0/24

Customers’ ethernet1 ethernet3

Addresses 10.1.1.1/24 1.1.1.1/24
Untrust Zone
Trust Zone
10.100.1.0/24 vpn1 Device-A
10.100.1.0/24
10.100.2.0/24 .vpn2 Device-B
10.100.3.0/24 10.100.2.0/24
Security Device-1

Internal Router
Security Device-1
The security device performs NAT-src and tunnel.2, 10.173.10.5/30
NAT-dst because you—as the Device-1 NAT-src Security Device-B
admin—have no control over the source and • DIP Pool 10.173.10.6 – 10.173.10.6 Untrust 3.3.3.3/24, Trust 10.100.2.1/24
destination addresses. As long as there is a NAT-dst tunnel.1, 10.3.3.1/24
mutually neutral address space to translate • Original Destination 10.173.40.0/24 NAT-dst
addresses to and from, security Device-1 can • Translated Destination 10.173.50.0/24 • Original Destination 10.173.20.0/24
process customers’ service requests. • Translated Destination 10.173.30.0/24
The two security devices protecting the server
farms also perform NAT-dst so that they retain
addressing independence and flexibility.

WebUI (Security Device-1)

1. Interfaces
Network > Interfaces > Edit (for ethernet1): Enter the following, then click
Apply:

Zone Name: Trust

Static IP: (select this option when present)
IP Address/Netmask: 10.1.1.1/24
Select the following, then click OK:
Interface Mode: NAT

NAT-Src and NAT-Dst in the Same Policy  51

 Concepts & Examples ScreenOS Reference Guide

Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:

Zone Name: Untrust

Static IP: (select this option when present)
IP Address/Netmask: 1.1.1.1/24

Network > Interfaces > New Tunnel IF: Enter the following, then click OK:

Tunnel Interface Name: tunnel.1

Zone (VR): Untrust (trust-vr)
Fixed IP: (select)
IP Address / Netmask: 10.173.10.1/30

Network > Interfaces > New Tunnel IF: Enter the following, then click OK:

Tunnel Interface Name: tunnel.1

Zone (VR): Untrust (trust-vr)
Fixed IP: (select)
IP Address / Netmask: 10.173.10.5/30
2. DIP Pools
Network > Interfaces > Edit (for tunnel.1) > DIP > New: Enter the following,
then click OK:

ID: 5
IP Address Range: (select), 10.173.10.2 ~ 10.173.10.2
Port Translation: (select)
In the same subnet as the interface IP or its secondary IPs: (select)

Network > Interfaces > Edit (for tunnel.2) > DIP > New: Enter the following,
then click OK:

ID: 6
IP Address Range: (select), 10.173.10.6 ~ 10.173.10.6
Port Translation: (select)
In the same subnet as the interface IP or its secondary IPs: (select)
3. Addresses
Policy > Policy Elements> Addresses > List > New: Enter the following, then
click OK:

Address Name: serverfarm-A

IP Address/Domain Name:
IP/Netmask: (select), 10.173.20.0/24
Zone: Untrust

Policy > Policy Elements> Addresses > List > New: Enter the following, then
click OK:

Address Name: serverfarm-B

IP Address/Domain Name:
IP/Netmask: (select), 10.173.40.0/24
Zone: Untrust

52  NAT-Src and NAT-Dst in the Same Policy

 Chapter 3: Destination Network Address Translation

4. VPNs
VPNs > AutoKey IKE > New: Enter the following, then click OK:

VPN Name: vpn1

Security Level: Compatible
Remote Gateway: Create a Simple Gateway: (select)
Gateway Name: gw-A
Type: Static IP: (select), Address/Hostname: 2.2.2.2
Preshared Key: device1
Security Level: Compatible
Outgoing Interface: ethernet3

NOTE: The outgoing interface does not have to be in the same zone to which the tunnel
interface is bound, although in this case they are in the same zone.

> Advanced: Enter the following advanced settings, then click Return to
return to the basic AutoKey IKE configuration page:

Bind to Tunnel Interface: (select), tunnel.1

Proxy-ID: (select)
Local IP / Netmask: 0.0.0.0/0
Remote IP / Netmask: 0.0.0.0/0
Service: ANY

VPNs > AutoKey IKE > New: Enter the following, then click OK:

VPN Name: vpn2

Security Level: Compatible
Remote Gateway: Create a Simple Gateway: (select)
Gateway Name: gw-B
Type: Static IP: (select), Address/Hostname: 3.3.3.3
Preshared Key: device2
Security Level: Compatible
Outgoing Interface: ethernet3

> Advanced: Enter the following advanced settings, then click Return to
return to the basic AutoKey IKE configuration page:

Bind to Tunnel Interface: (select), tunnel.2

Proxy-ID: (select)
Local IP / Netmask: 0.0.0.0/0
Remote IP / Netmask: 0.0.0.0/0
Service: ANY
5. Routes
Network > Routing > Destination > trust-vr New: Enter the following, then
click OK:

Network Address / Netmask: 0.0.0.0/0

Gateway: (select)
Interface: ethernet3
Gateway IP Address: 1.1.1.250

NAT-Src and NAT-Dst in the Same Policy  53

 Concepts & Examples ScreenOS Reference Guide

Network > Routing > Destination > trust-vr New: Enter the following, then
click OK:

Network Address / Netmask: 10.173.20.0/24

Gateway: (select)
Interface: tunnel.1
Gateway IP Address: 0.0.0.0

Network > Routing > Destination > trust-vr New: Enter the following, then
click OK:

Network Address / Netmask: 10.173.30.0/24

Gateway: (select)
Interface: tunnel.1
Gateway IP Address: 0.0.0.0

Network > Routing > Destination > trust-vr New: Enter the following, then
click OK:

Network Address / Netmask: 10.173.40.0/24

Gateway: (select)
Interface: tunnel.2
Gateway IP Address: 0.0.0.0

Network > Routing > Destination > trust-vr New: Enter the following, then
click OK:

Network Address / Netmask: 10.173.50.0/24

Gateway: (select)
Interface: tunnel.2
Gateway IP Address: 0.0.0.0
6. Policies
Policies > (From: Trust, To: Untrust) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), Any
Destination Address:
Address Book Entry: (select), serverfarm-A
Service: ANY
Action: Permit
Position at Top: (select)

> Advanced: Enter the following advanced settings, then click Return to
return to the basic Policy configuration page:

NAT:
Source Translation: (select)
(DIP on): 5 (10.173.10.2–10.173.10.2)/X-late
Destination Translation: (select)
Translate to IP Range: (select), 10.173.30.0 – 10.173.30.255

54  NAT-Src and NAT-Dst in the Same Policy

 Chapter 3: Destination Network Address Translation

Policies > (From: Trust, To: Untrust) New: Enter the following, then click OK:

Source Address:
Address Book Entry: (select), Any
Destination Address:
Address Book Entry: (select), serverfarm-B
Service: ANY
Action: Permit
Position at Top: (select)

> Advanced: Enter the following advanced settings, then click Return to
return to the basic Policy configuration page:

NAT:
Source Translation: (select)
(DIP on): 6 (10.173.10.6–10.173.10.6)/X-late
Destination Translation: (select)
Translate to IP Range: (select), 10.173.50.0 – 10.173.50.255

CLI (Security Device-1)

1. Interfaces
set interface ethernet1 zone trust
set interface ethernet1 ip 10.1.1.1/24
set interface ethernet1 nat
set interface ethernet3 zone untrust
set interface ethernet3 ip 1.1.1.1/24
set interface tunnel.1 zone untrust
set interface tunnel.1 ip 10.173.10.1/30
set interface tunnel.2 zone untrust
set interface tunnel.2 ip 10.173.10.5/30
2. DIP Pools
set interface tunnel.1 dip-id 5 10.173.10.2 10.173.10.2
set interface tunnel.2 dip-id 6 10.173.10.6 10.173.10.6
3. Addresses
set address untrust serverfarm-A 10.173.20.0/24
set address untrust serverfarm-B 10.173.40.0/24
4. VPNs
set ike gateway gw-A ip 2.2.2.2 main outgoing-interface ethernet3 preshare
device1 sec-level compatible
set vpn vpn1 gateway gw-A sec-level compatible
set vpn vpn1 bind interface tunnel.1
set vpn vpn1 proxy-id local-ip 0.0.0.0/0 remote-ip 0.0.0.0/0 any
set ike gateway gw-B ip 3.3.3.3 main outgoing-interface ethernet3 preshare
device2 sec-level compatible
set vpn vpn2 gateway gw-B sec-level compatible
set vpn vpn2 bind interface tunnel.2
set vpn vpn2 proxy-id local-ip 0.0.0.0/0 remote-ip 0.0.0.0/0 any
5. Routes
set vrouter trust-vr route 0.0.0.0/0 interface ethernet3 gateway 1.1.1.250
set vrouter trust-vr route 10.173.20.0/24 interface tunnel.1
set vrouter trust-vr route 10.173.30.0/24 interface tunnel.1
set vrouter trust-vr route 10.173.40.0/24 interface tunnel.2
set vrouter trust-vr route 10.173.50.0/24 interface tunnel.2

NAT-Src and NAT-Dst in the Same Policy  55

 Concepts & Examples ScreenOS Reference Guide

6. Policies
set policy top from trust to untrust any serverfarm-A any nat src dip-id 5 dst ip
10.173.30.0 10.173.30.255 permit
set policy top from trust to untrust any serverfarm-B any nat src dip-id 6 dst ip
10.173.50.0 10.173.50.255 permit
save

WebUI (Security Device-A)

1. Interfaces
Network > Interfaces > Edit (for ethernet1): Enter the following, then click
Apply:

Zone Name: Trust

Static IP: (select this option when present)
IP Address/Netmask: 10.100.1.1/24

Select the following, then click OK:

Interface Mode: NAT

Network > Interfaces > Edit (for ethernet3): Enter the following, then click
OK:

Zone Name: Untrust

Static IP: (select this option when present)
IP Address/Netmask: 2.2.2.2/24

Network > Interfaces > New Tunnel IF: Enter the following, then click OK:

Tunnel Interface Name: tunnel.1

Zone (VR): Untrust (trust-vr)
Fixed IP: (select)
IP Address / Netmask: 10.2.2.1/24
2. Addresses
Policy > Policy Elements> Addresses > List > New: Enter the following, then
click OK:

Address Name: serverfarm-A

IP Address/Domain Name:
IP/Netmask: (select), 10.173.30.0/24
Zone: Trust

Policy > Policy Elements> Addresses > List > New: Enter the following, then
click OK:

Address Name: customer1

IP Address/Domain Name:
IP/Netmask: (select), 10.173.10.2/32
Zone: Untrust

56  NAT-Src and NAT-Dst in the Same Policy

 Chapter 3: Destination Network Address Translation

3. VPN
VPNs > AutoKey IKE > New: Enter the following, then click OK:

VPN Name: vpn1

Security Level: Compatible
Remote Gateway: Create a Simple Gateway: (select)
Gateway Name: gw-1
Type: Static IP: (select), Address/Hostname: 1.1.1.1
Preshared Key: device1
Security Level: Compatible
Outgoing Interface: ethernet3

> Advanced: Enter the following advanced settings, then click Return to
return to the basic AutoKey IKE configuration page:

Bind to Tunnel Interface: (select), tunnel.1

Proxy-ID: (select)
Local IP / Netmask: 0.0.0.0/0
Remote