You are on page 1of 536

Configuring Juniper Networks Firewall/IPSec VPN Products

5.b

Student Guide

1194 North Mathilda Avenue Sunnyvale, CA 94089 USA 408-745-2000 www.juniper.net Course Number: EDU-JUN-CJFV

Juniper Networks, the Juniper Networks logo, NetScreen, and ScreenOS are registered trademarks of Juniper Networks, Inc. in the United States and other countries. JUNOS and JUNOSe are trademarks of Juniper Networks, Inc. All other trademarks, service marks, registered trademarks, or registered service marks are the property of their respective owners. Configuring Juniper Networks Firewall/IPSec VPN Products Student Guide, Revision 5.b Copyright 2007, Juniper Networks, Inc. All rights reserved. Printed in USA. Revision History: Revision 5.bApril 2007 The information in this document is current as of the date listed above. The information in this document has been carefully verified and is believed to be accurate for software Release 5.4. Juniper Networks assumes no responsibilities for any inaccuracies that may appear in this document. In no event will Juniper Networks be liable for direct, indirect, special, exemplary, incidental or consequential damages resulting from any defect or omission in this document, even if advised of the possibility of such damages.

Juniper Networks reserves the right to change, modify, transfer or otherwise revise this publication without notice. YEAR 2000 NOTICE Juniper Networks hardware and software products do not suffer from Year 2000 problems and hence are Year 2000 compliant. The JUNOS software has no known time-related limitations through the year 2038. However, the NTP application is known to have some difficulty in the year 2036. SOFTWARE LICENSE The terms and conditions for using Juniper Networks software are described in the software license provided with the software, or to the extent applicable, in an agreement executed between you and Juniper Networks, or Juniper Networks agent. By using Juniper Networks software, you indicate that you understand and agree to be bound by its license terms and conditions. Generally speaking, the software license restricts the manner in which you are permitted to use the Juniper Networks software, may contain prohibitions against certain uses, and may state conditions under which the license is automatically terminated. You should consult the software license for further details.

Contents
Chapter 1: Chapter 2: Course Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1 ScreenOS Concepts, Terminology, and Platforms . . . . . . . . . . . . . . . . . . . . . . 2-1
Security Device Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3 ScreenOS Security Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-10 Juniper Networks Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-28

Chapter 3:

Initial Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1


System Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3 Establishing Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-15 Verifying Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-40 Lab 1: Initial Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-49

Chapter 4:

Device Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1


Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3 Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-24 Lab 2: Device Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-31

Chapter 5:

Layer 3 Operations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1


Need for Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-3 Configuring Layer 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-11 Verifying Layer 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-21 Loopback Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-43 Interface-Based NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-46 Lab 3: Layer 3 Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-57

Chapter 6:

Basic Policy Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1


Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3 Policy Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-7 Common Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-41 Global Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-47 Verifying Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-50 Lab 4: Basic Policy Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-58

Chapter 7:

Policy Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1


Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-3 Logging. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-9 Counting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-14 Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-19 User Authentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-27 Lab 5: Policy Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-43

Contents iii

Chapter 8:

Address Translation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-1


Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-3 NAT-src . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-8 NAT-dst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-24 VIP Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-40 MIP Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-51 Lab 6: Address Translation Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-72

Chapter 9:

Transparent Mode (Optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-1


Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-3 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-11 Verifying Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-22 Lab 7: Transparent Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-31

Chapter 10: VPN Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-1


Concepts and Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-3 IP Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-19

Chapter 11: Policy-Based VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-1


Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-3 Verifying Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-22 Lab 8: Policy-Based VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-36

Chapter 12: Route-Based VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-1


Concepts and Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-3 Configuring VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-9 Verifying Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-22 Lab 9: Configuring Route-Based VPNs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-31

Appendix A: Additional Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1


Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-3

iv Contents

Course Overview
Configuring Juniper Networks Firewall/IPSec VPN Products (CJFV) is the first course in the ScreenOS curriculum. It is a three-day, instructor-led course that focuses on configuration of the Juniper Networks firewall/VPN products in a variety of situations, including basic administrative access, routing, firewall policies and policy options, attack prevention features, address translation, and VPN implementations. The course combines both lecture and labs, with significant time allocated for hands-on experience. Students completing this course should be confident in their ability to configure Juniper Networks firewall/VPN products in a wide range of installations.

Objectives
After successfully completing this course, you should be able to: Explain the Juniper Networks security architecture. Configure administrative access and options. Backup and restore configuration and ScreenOS files. Configure a Juniper Networks device in transparent, route, and NAT modes. Discuss the applications of multiple virtual routers. Configure the Juniper Networks firewall to permit and deny traffic based on user defined policies. Configure advanced policy options. Identify and configure network designs for various types of network address translation. Configure policy-based and routebased VPN tunnels.

Intended Audience
This course is intended for network engineers, support personnel, reseller support, and others responsible for implementing Juniper Networks products.

Course Level
This is an introductory-level course.

Prerequisites
This course assumes that students have basic networking knowledge and experience in the following areas: The Internet Networking concepts Terms including TCP/IP, bridging, switching, and routing.

Course Overview v

Course Agenda
Day 1
Chapter 1: Chapter 2: Chapter 3: Chapter 4: Course Introduction ScreenOS Concepts, Terminology, and Platforms Initial Connectivity Device Management

Day 2
Chapter 5: Chapter 6: Chapter 7: Chapter 8: Layer 3 Operations Basic Policy Configuration Policy Options Address Translation

Day 3
Chapter 9: Transparent Mode (Optional) Chapter 10: VPN Concepts Chapter 11: Policy-Based VPNs Chapter 12: Route-Based VPNs Appendix A: Additional Features

vi Course Agenda

Document Conventions
CLI and GUI Text
Frequently throughout this course, we refer to text that appears in a command-line interface (CLI) or a graphical user interface (GUI). To make the language of these documents easier to read, we distinguish GUI and CLI text from chapter text according to the following table. Style Franklin Gothic Courier New Description Normal text. Console text: Century Gothic Screen captures Noncommand-related syntax commit complete Exiting configuration mode Select File > Open, and then click Configuration.conf in the Filename text box. Usage Example Most of what you read in the Lab Guide and Student Guide.

GUI text elements: Menu names Text field entry

Input Text Versus Output Text


You will also frequently see cases where you must enter input text yourself. Often this will be shown in the context of where you must enter it. We use bold style to distinguish text that is input versus text that is simply displayed. Style Normal CLI Normal GUI CLI Input GUI Input Text that you must enter. Description No distinguishing variant. Usage Example Physical interface:fxp0, Enabled View configuration history by clicking Configuration > History. lab@San_Jose> show route Select File > Save, and enter config.ini in the Filename field.

Document Conventions vii

Defined and Undefined Syntax Variables


Finally, this course distinguishes between regular text and syntax variables, and it also distinguishes between syntax variables where the value is already assigned (defined variables) and syntax variables where you must assign the value (undefined variables). Note that these styles can be combined with the input style as well. Style CLI Variable GUI Variable CLI Undefined GUI Undefined Text where the variables value is the users discretion and text where the variables value as shown in the lab guide might differ from the value the use must input. Description Text where variable value is already assigned. Usage Example policy my-peers Click on my-peers in the dialog. Type set policy policy-name. ping 10.0.1.1 Select File > Save, and enter filename in the Filename field.

viii Document Conventions

Additional Information
Education Services Offerings
You can obtain information on the latest Education Services offerings, course dates, and class locations from the World Wide Web by pointing your Web browser to: http://www.juniper.net/training/education/

About This Publication


The Configuring Juniper Networks Firewall/IPSec VPN Products Student Guide was developed and tested using software version 5.4. Previous and later versions of software may behave differently so you should always consult the documentation and release notes for the version of code you are running before reporting errors. This document is written and maintained by the Juniper Networks Education Services development team. Please send questions and suggestions for improvement to training@juniper.net

Technical Publications
You can print technical manuals and release notes directly from the Internet in a variety of formats: Go to http://www.juniper.net/techpubs/ Locate the specific software or hardware release and title you need, and choose the format in which you want to view or print the document.

Documentation sets and CDs are available through your local Juniper Networks sales office or account representative.

Juniper Networks Support


For technical support, contact Juniper Networks at http://www.juniper.net/customers/ support/, or at 1-888-314-JTAC (within the United States) or 408-745-2121 (from outside the United States).

Additional Information ix

x Additional Information

Configuring Juniper Networks Firewall/IPSec VPN Products


Chapter 1: Course Introduction

Configuring Juniper Networks Firewall/IPSec VPN Products

This Chapter Discusses:


Objectives and course content information; Additional Juniper Networks courses; and Juniper Networks Technical Certification Program.

Chapter 12 Course Introduction

Configuring Juniper Networks Firewall/IPSec VPN Products

Introductions
This slide serves to break the ice by having you introduce yourself and state your reasons for attending the class.

Course Introduction Chapter 13

Configuring Juniper Networks Firewall/IPSec VPN Products

Course Contents
This slide lists the topics we discuss in this course.

Chapter 14 Course Introduction

Configuring Juniper Networks Firewall/IPSec VPN Products

Prerequisites
This slide lists the prerequisites for this course.

Course Introduction Chapter 15

Configuring Juniper Networks Firewall/IPSec VPN Products

General Course Administration


This slide documents general aspects of classroom administration.

Chapter 16 Course Introduction

Configuring Juniper Networks Firewall/IPSec VPN Products

Training and Study Materials


This slide describes several options for obtaining study and preparation materials.

Course Introduction Chapter 17

Configuring Juniper Networks Firewall/IPSec VPN Products

Satisfaction Feedback
Juniper Networks uses an electronic survey system to collect and analyze your comments and feedback. Depending on the class you are taking, please complete the survey at the end of the class, or be sure to look for an e-mail about two weeks from class completion that directs you to complete an online survey form (be sure to provide us with your current e-mail address). Submitting your feedback entitles you to a certificate of class completion. We thank you in advance for taking the time to help us improve our educational offerings.

Chapter 18 Course Introduction

Configuring Juniper Networks Firewall/IPSec VPN Products

Service Provider Curriculum: JUNOS Platforms


This slide displays the primary Education Services offerings that support Juniper Networks M-series and T-series technologies in a service provider environment.

Course Introduction Chapter 19

Configuring Juniper Networks Firewall/IPSec VPN Products

Service Provider Curriculum: JUNOSe Platforms


This slide displays the primary Education Services offerings that support Juniper Networks E-series router technologies.

Chapter 110 Course Introduction

Configuring Juniper Networks Firewall/IPSec VPN Products

Enterprise Routing Curriculum


This slide displays the primary Education Services offering that support Juniper Networks M-series and J-series technologies in an enterprise environment.

Course Introduction Chapter 111

Configuring Juniper Networks Firewall/IPSec VPN Products

Security Curriculum
This slide displays the primary Education Services offerings that support Juniper Networks security technologies.

Chapter 112 Course Introduction

Configuring Juniper Networks Firewall/IPSec VPN Products

WX Curriculum
This slide displays the primary Education Services offerings that support Juniper Networks WX Framework technologies.

Course Introduction Chapter 113

Configuring Juniper Networks Firewall/IPSec VPN Products

DX Curriculum
This slide displays the primary Education Services offerings that support Juniper Networks DX Application Acceleration Platform technologies.

Chapter 114 Course Introduction

Configuring Juniper Networks Firewall/IPSec VPN Products

Technical Certification Programs: Routing Tracks


This slide outlines the current levels of technical certification offered by Juniper Networks.

Course Introduction Chapter 115

Configuring Juniper Networks Firewall/IPSec VPN Products

Technical Certification Programs: Security Tracks


This slide outlines the current levels of technical certification offered by Juniper Networks.

Chapter 116 Course Introduction

Configuring Juniper Networks Firewall/IPSec VPN Products

Technical Certification Programs: WX Track


This slide outlines the current level of technical certification offered by Juniper Networks.

Course Introduction Chapter 117

Configuring Juniper Networks Firewall/IPSec VPN Products

The JNCIA Certification


This slide details the JNCIA certification level.

Chapter 118 Course Introduction

Configuring Juniper Networks Firewall/IPSec VPN Products

The JNCIS Certification


This slide details the JNCIS certification level.

Course Introduction Chapter 119

Configuring Juniper Networks Firewall/IPSec VPN Products

The JNCIP Certification


This slide details the JNCIP certification level.

Chapter 120 Course Introduction

Configuring Juniper Networks Firewall/IPSec VPN Products

The JNCIE Certification


This slide details the JNCIE certification level.

Course Introduction Chapter 121

Configuring Juniper Networks Firewall/IPSec VPN Products

Prepping and Studying


This slide lists some options for those interested in prepping for Juniper Networks certification.

Chapter 122 Course Introduction

Configuring Juniper Networks Firewall/IPSec VPN Products

Any Questions?
If you have any questions or concerns about the class you are attending, we suggest that you voice them now so that your instructor can best address your needs during class.

Course Introduction Chapter 123

Configuring Juniper Networks Firewall/IPSec VPN Products

Chapter 124 Course Introduction

Configuring Juniper Networks Firewall/IPSec VPN Products


Chapter 2: ScreenOS Concepts, Terminology, and Platforms

Configuring Juniper Networks Firewall/IPSec VPN Products

This Chapter Discusses:


Network security device requirements; The function of the Juniper Networks security architecture components; The packet processing sequence in a Juniper Networks device; and Selecting correct deployment scenarios for Juniper Networks appliances and systems.

Chapter 22 ScreenOS Concepts, Terminology, and Platforms

Configuring Juniper Networks Firewall/IPSec VPN Products

Security Device Requirements


This slide lists the topics we cover in this chapter. We discuss the highlighted topic first.

ScreenOS Concepts, Terminology, and Platforms Chapter 23

Configuring Juniper Networks Firewall/IPSec VPN Products

Security Device Requirements


When Juniper Networks began designing its firewall/VPN product line, it took into consideration several necessary operational elements. We take a closer look at these operations on the next few pages.

Chapter 24 ScreenOS Concepts, Terminology, and Platforms

Configuring Juniper Networks Firewall/IPSec VPN Products

Layer 2 Frame Forwarding


An inline security device must be able to forward traffic it receives. Therefore, at a minimum, the security device must be able to track MAC addresses on a per-port basis so as to make intelligent forwarding decisions. This behavior is identical to an Ethernet transparent bridge or switch, and consists of the following: Address learning: As frames pass through the device, source MAC addresses are associated with the ingress port. Forwarding: Frames are forwarded based on the learned address table. If the destination is in the table, the frame is forwarded only out the associated port. If the destination is not in the table, the frame is forwarded out all ports (other than the ingress port). Loop prevention: The device must be able to avoid forwarding loops and the associated broadcast storms by passing the Spanning Tree Protocol.

ScreenOS Concepts, Terminology, and Platforms Chapter 25

Configuring Juniper Networks Firewall/IPSec VPN Products

Layer 3 Packet Forwarding (Routing)


If the device is configured to operate with full IP intelligence, the device must be able to participate fully in IP routing, learning destination routes either through static configuration or dynamic routing protocols.

Chapter 26 ScreenOS Concepts, Terminology, and Platforms

Configuring Juniper Networks Firewall/IPSec VPN Products

Firewall
Fundamental firewall intelligence consists of the ability to make filtering decisions based on IP packet header information. When individual packets are received by a firewall, they are compared with a set of rules. Each rule consists of a source and destination IP address, Layer 4 protocol, source and destination ports, and most importantly, an action (permit or deny). When a packet matches a rule, the action is performed.

ScreenOS Concepts, Terminology, and Platforms Chapter 27

Configuring Juniper Networks Firewall/IPSec VPN Products

Network/Port Address Translation


When a security device resides at the edge of a network, it must be able to replace private, nonroutable addresses with public addresses before the traffic is sent to the public network. Translation can consist of replacing the IP address, port numbers, or both, depending on the configuration.

Chapter 28 ScreenOS Concepts, Terminology, and Platforms

Configuring Juniper Networks Firewall/IPSec VPN Products

Virtual Private Networks


Finally, if the security device will be used to build virtual private networks (VPNs) using the public network as an access medium between two private sites, it must be able to perform the following: Encapsulate the original traffic in a packet that can be transported over the public network; Encrypt the original packet so that it cannot be easily decoded should it be intercepted on the public network; and Authenticate the originating device as a member of the VPN and not some random device operating on the public network.

ScreenOS Concepts, Terminology, and Platforms Chapter 29

Configuring Juniper Networks Firewall/IPSec VPN Products

ScreenOS Security Architecture


The slide highlights the topic we discuss next.

Chapter 210 ScreenOS Concepts, Terminology, and Platforms

Configuring Juniper Networks Firewall/IPSec VPN Products

ScreenOS Security Architecture


Juniper Networks has developed a device architecture that meets all the requirements we discussed. We define the elements of this architecture on the next few slides.

ScreenOS Concepts, Terminology, and Platforms Chapter 211

Configuring Juniper Networks Firewall/IPSec VPN Products

Security Architecture Components


Interfaces are connections to specific subnets. Different Juniper Networks devices use different namesinterface Trust on a NS-5GT device, or interface E1 on an NS-208 device. But no matter the name, an interface is assigned an IP address only if the firewall is operating in Layer 3 mode. Zones are logical groupings of subnets and interfaces. All devices within a zone share the same security requirements. Zone configuration can be as simple as a two-zone setupall interfaces connected to internal networks are in one zone, all interfaces connected to the external world are in a different zone. A more complicated configuration might divide interfaces based on internal department or function in addition to external and DMZ connections. The Juniper Networks firewall implements security based on policies. A security policy is a rulebase that specifies which traffic is to be permitted to pass through the firewall, based on the same parameters that are used to identify traffic flow. Policies are implemented on a zone basis; that is, one policy set applies to traffic leaving Zone A and entering Zone B, while a different set of policies can apply to traffic leaving Zone A and entering Zone C. A virtual router (VR) is a logical routing construct within the Juniper Networks device. Each VR maintains its own routing table and routing logic. For traffic to flow between VRs, inter-VR routing must be configured. Continued on next page.

Chapter 212 ScreenOS Concepts, Terminology, and Platforms

Configuring Juniper Networks Firewall/IPSec VPN Products

Security Architecture Components (contd.)


The forwarding table is used to determine the outbound interface for a particular packet. It consists of IP networks if the device is operating in Layer 3 mode and MAC addresses if the device is operating in Layer 2 mode. A virtual system (VSYS) is a logical division of the Juniper Networks device into multiple administrative areas. Each VSYS operates as its own firewall with its own set of policies. Only Juniper Networks firewall systems can support a VSYS implementation. Juniper Networks firewalls track traffic passing through the firewall based on flows and sessions. An individual flow is identified by the combination of source and destination address, protocol, and protocol-specific upper-layer identifiers (ports, in the case of TCP or UDP; message ID, in the case of ICMP, and so forth). As most connections require two-way communication between devices, the two flows between the devices are tracked together in memory as a session.

ScreenOS Concepts, Terminology, and Platforms Chapter 213

Configuring Juniper Networks Firewall/IPSec VPN Products

Zones and Interface Assignments


The Juniper Networks internal architecture is designed with a strict hierarchical relationship between virtual routers, zones, and interfaces. An interface cannot be configured for IP connectivity without first being associated with a zone.

Chapter 214 ScreenOS Concepts, Terminology, and Platforms

Configuring Juniper Networks Firewall/IPSec VPN Products

Zones and Interfaces


An interface cannot be configured for IP connectivity without first being associated with a zone.

ScreenOS Concepts, Terminology, and Platforms Chapter 215

Configuring Juniper Networks Firewall/IPSec VPN Products

Virtual Systems
Multiple firewall devices emulated in one physical hardware device is a virtual system. Only the high-end Juniper Networks firewalls support virtual systems.

Chapter 216 ScreenOS Concepts, Terminology, and Platforms

Configuring Juniper Networks Firewall/IPSec VPN Products

Interface Designations
The slide shows a list of platforms and interface naming. You can see that on the different platforms interfaces have different names.

ScreenOS Concepts, Terminology, and Platforms Chapter 217

Configuring Juniper Networks Firewall/IPSec VPN Products

Virtual Interfaces
The slide shows a list of the syntax of virtual interfaces on the ScreenOS devices.

Chapter 218 ScreenOS Concepts, Terminology, and Platforms

Configuring Juniper Networks Firewall/IPSec VPN Products

Interface ConfigurationLayer 1 and Layer 2


Juniper Networks devices support many different Layer 1 and Layer 2 interfaces.

ScreenOS Concepts, Terminology, and Platforms Chapter 219

Configuring Juniper Networks Firewall/IPSec VPN Products

Stateful Packet Inspection


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 headerssource and destination IP addresses, source and destination port numbers, and packet sequence numbersand 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 information in the header does not match the state of its associated session, the packet is dropped.

Chapter 220 ScreenOS Concepts, Terminology, and Platforms

Configuring Juniper Networks Firewall/IPSec VPN Products

Application Layer Gateways


On a security device, an application layer gateway (ALG) is a software component designed to manage specific protocols such as the Session Initiation Protocol (SIP) or FTP. The ALG intercepts and analyzes the specified traffic, allocates resources, and defines dynamic policies to permit the traffic to pass securely through the security device.

ScreenOS Concepts, Terminology, and Platforms Chapter 221

Configuring Juniper Networks Firewall/IPSec VPN Products

Attack Prevention
Attack prevention describes the Juniper Networks security options available in ScreenOS software. Many of these options are SCREEN options that you can enable at the security zone level. SCREEN options apply to traffic reaching the Juniper Networks security device through any interface bound to a zone for which you enabled such options. SCREEN 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.

Chapter 222 ScreenOS Concepts, Terminology, and Platforms

Configuring Juniper Networks Firewall/IPSec VPN Products

Packet Flow Sequence Through Security Zones


In ScreenOS software, the flow sequence of an incoming packet progresses as presented on the slide and detailed here: 1. 2. 3. The interface module identifies the incoming interface and, consequently, the source zone to which the interface is bound. If you enabled SCREEN options for the source zone, the security device activates the SCREEN module at this point. 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 following Steps 4 through 9. If a mapped IP (MIP) or virtual IP (VIP) address is used, the address-mapping module resolves the MIP or VIP address so that the routing table can search for the actual host address. Prior to route lookup, ScreenOS software checks the packet for policy-based routing (PBR). 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. The policy engine searches the policy set lists for a policy between the addresses in the identified source and destination zones.

4.

5.

6.

Continued on next page.

ScreenOS Concepts, Terminology, and Platforms Chapter 223

Configuring Juniper Networks Firewall/IPSec VPN Products

Packet Flow Sequence Through Security Zones (contd.)


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.) 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. 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.

8.

9.

Chapter 224 ScreenOS Concepts, Terminology, and Platforms

Configuring Juniper Networks Firewall/IPSec VPN Products

Packet Flow Example: Part 1


Lets apply this decision process to a specific example. In this case, Host B at 10.1.20.5 wants to initiate an HTTP session with the Web server at 200.5.5.5. The traffic passes through the Juniper Networks firewall and therefore is subject to the decision process.

ScreenOS Concepts, Terminology, and Platforms Chapter 225

Configuring Juniper Networks Firewall/IPSec VPN Products

Packet Flow Example: Part 2


The slide shows the packet as received by the Juniper Networks device on interface E1. Following the flowchart, we can track the progress of the packet through the Juniper Networks device: 1. 2. 3. Based on a lookup in the session table, we determine that this is not an existing session. The forwarding table shows that we know how to reach the destination network. The interfaces are in different zones, so we must examine the associated policy.

Chapter 226 ScreenOS Concepts, Terminology, and Platforms

Configuring Juniper Networks Firewall/IPSec VPN Products

Packet Flow Example: Part 3


The following is a continuation of the list from the previous page: 4. The packet is from host 10.1.20.5 and is HTTP. This packet matches the policy statement on the slide. The action for this particular type of traffic is to permit it.

Therefore, the firewall forwards the packet out interface E8 (as determined by the destination lookup) and adds the information to the session table. Traffic in both directions for this particular session will be allowed to pass without any subsequent policy evaluation. Not shown is the network address translation that takes place on the packet.

ScreenOS Concepts, Terminology, and Platforms Chapter 227

Configuring Juniper Networks Firewall/IPSec VPN Products

Juniper Networks Platforms


The slide highlights the topic we discuss next.

Chapter 228 ScreenOS Concepts, Terminology, and Platforms

Configuring Juniper Networks Firewall/IPSec VPN Products

Deploying Juniper Networks Devices


Juniper Networks has several firewall/VPN devices. Most are built around Juniper Networks application-specific integrated circuits (ASICs) that are specifically designed to accelerate the complex and processor-intensive calculations required by a complete security implementation, including the following: Hardware policy and Network Address Translation (NAT) engine up to Layer 4; High-performance hardware Data Encryption Standard (DES) and triple Data Encryption Standard (3DES) encryption; High-performance hardware Message Digest 5 (MD5) and Secure Hash Algorithm 1 (SHA-1) authentication; Parallel encryption and authentication; Hardware random number generator; Public key acceleration; and High-performance Rivest Cipher 4 (RC4) encryption.

(Note that the 5-GT and Hardware Security Client (HSC) devices do not use ASICs; instead, these devices use high-performance CPUs to provide the required performance and throughput.) Continued on next page.

ScreenOS Concepts, Terminology, and Platforms Chapter 229

Configuring Juniper Networks Firewall/IPSec VPN Products

Deploying Juniper Networks Device (contd.)


The firewall/VPN offerings can be divided into two groups. Appliances are devices that support a single VSYS implementation. These devices are typically deployed at the lower end of the network spectrum, from small office through small to medium enterprise level. Firewall systems have modular hardware options that allow for a variety of interface configurations. Systems also support multiple VSYS implementations, making them suitable for large enterprise and carrier environments. For individual secure remote access, Juniper Networks has the NS-Remote. This software runs on Windows and Windows NT platforms, and it provides a complete VPN and firewall client for that PC. VPNs can be built from the client to Juniper Networks firewall/VPN devices, other machines running Juniper Networks-Remote software, or any IPSec or Layer 2 Tunneling Protocol (L2TP)-compatible device. Firewall capabilities ensure additional network and host-based security for mobile users at all times, regardless of whether the VPN is active.

Chapter 230 ScreenOS Concepts, Terminology, and Platforms

Configuring Juniper Networks Firewall/IPSec VPN Products

Juniper Networks Firewall/VPN Products


This slide illustrates the current firewall/VPN product offerings from Juniper Networks. As these numbers do change over time, reference the Juniper Networks product Website at http://www.juniper.net/products/integrated/ for current information.

ScreenOS Concepts, Terminology, and Platforms Chapter 231

Configuring Juniper Networks Firewall/IPSec VPN Products

NS Configuration Line
Designed for the fixed telecommuter and the small remote office environment, the Juniper Networks NS-Hardware Security Client (NS-HSC) solution is the most cost-effective integrated security solution for the fixed telecommuter and small remote office. Combining a complete set of best-in-class unified threat management (UTM) security features including intrusion prevention system (IPS), antivirus (includes antispyware, antiadware, antiphishing), antispam, and Web filtering allows the NS-5GT device to defend the network against worms, spyware, trojans, malware and other emerging attacks. It can easily be deployed and managed in large deployments using Rapid Deployment capabilities within Juniper Networks Security Manager to eliminate expensive staging steps.

Chapter 232 ScreenOS Concepts, Terminology, and Platforms

Configuring Juniper Networks Firewall/IPSec VPN Products

SSG Product Line


The Juniper Networks Secure Services Gateway (SSG) products are purpose-built security appliances that deliver a perfect blend of performance, security and LAN/ WAN connectivity. Traffic flowing in and out can be protected from worms, spyware, trojans, and malware by a complete set of UTM security features including stateful firewall, IPSec VPN, IPS, antivirus (includes antispyware, antiadware, antiphishing), antispam, and Web filtering. The SSG product line includes the following devices: SSG 5: The SSG 5 device is a fixed form-factor platform that delivers 160 Mbps of stateful firewall traffic and 40 Mbps of IPSec VPN throughput. SSG 20: The SSG 20 device is a modular platform that delivers 160 Mbps of stateful firewall traffic and 40 Mbps of IPSec VPN throughput. SSG 140: The SSG 140 device is a modular platform that delivers 360 Mbps of stateful firewall traffic and 100 Mbps of IPSec VPN throughput. SSG 520: The SSG 520 device delivers 650+ Mbps of firewall traffic and 300 Mbps of IPSec VPN throughput. SSG 550: The SSG 550 device delivers 1+ Gbps of firewall traffic and 500 Mbps of IPSec VPN. The SSG 550 device supports redundant power supplies and is NEBS compliant.

ScreenOS Concepts, Terminology, and Platforms Chapter 233

Configuring Juniper Networks Firewall/IPSec VPN Products

ISG Product Line


The Juniper Networks Integrated Security Gateway (ISG) devices are purpose-built, security solutions that leverage a fourth-generation security ASICthe GigaScreen3 along with high-speed microprocessors to deliver unmatched firewall and VPN performance. The Juniper Networks ISG 1000 and ISG 2000 are ideally suited for securing enterprise, carrier, and data center environments where advanced applications such as voice over IP (VoIP) and streaming media dictate consistent, scalable performance. Integrating best-in-class Deep Inspection firewall, VPN, and DoS solutions, the ISG 1000 and ISG 2000 devices enable secure, reliable connectivity along with network and application-level protection for critical, high-traffic network segments. The ISG product line includes the following devices: ISG 1000: The ISG 1000 device is a fully integrated firewall/VPN/IDP system with gigabit performance, a modular architecture, and rich virtualization capabilities. The base firewall/VPN system comes with four fixed 10/100/1000 interfaces and two additional I/O modules for interface expansion. ISG 2000: The ISG 2000 device is a fully integrated firewall/VPN/IDP system with multigigabit performance, a modular architecture, and rich virtualization capabilities. The base firewall/VPN system allows for up to four I/O modules and three security modules for IDP integration.

Chapter 234 ScreenOS Concepts, Terminology, and Platforms

Configuring Juniper Networks Firewall/IPSec VPN Products

High-End Systems (NS-500 and NS-5200)


The Juniper Networks NS-5000 series is a line of purpose-built, high-performance firewall/VPN security systems designed to deliver a new level of high-performance capabilities for large enterprise, carrier, and data center networks. The NS-5000 series consists of two products: the 2-slot NS-5200 system and the 4-slot NS-5400 system. NS-5000 security systems integrate firewall, VPN, DoS and distributed denial-of-service (DDoS) protection, and traffic-management functionality, in a low-profile modular chassis. Built around Juniper Networks third-generation security ASIC and distributed system architecture, the NS-5000 series offers excellent scalability and flexibility, while providing a higher-level security system through Juniper Networks ScreenOS custom operating system. Both products employ a switch fabric for data exchange and separate multibus channel for control information, delivering scalable performance for the most demanding environments.

ScreenOS Concepts, Terminology, and Platforms Chapter 235

Configuring Juniper Networks Firewall/IPSec VPN Products

Appliance Deployment
This slide illustrates typical deployments of Juniper Networks firewall/VPN appliances. The SSG 520 device near the top of the slide is providing firewall protection between internal zones as well as from the Internet. It is also providing VPN tunnel access via the Internet for remote offices (via the SSG 20 and SSG 5 devices) and a remote mobile user (via the NS-Remote).

Chapter 236 ScreenOS Concepts, Terminology, and Platforms

Configuring Juniper Networks Firewall/IPSec VPN Products

System Deployment
On this slide, a Juniper Networks firewall/VPN systemthe NS-5400 deviceis providing firewall controls for a service provider providing VPN connectivity for two different customers. The virtual system capabilities of the NS-5400 device allow the two customer networks to be completely isolated from each other, even though they are physically connected to the same device. Each VSYS has its own set of policies, and the service provider has the option of creating VSYS-specific administrators, thereby allowing customers to maintain their own internal security implementations.

ScreenOS Concepts, Terminology, and Platforms Chapter 237

Configuring Juniper Networks Firewall/IPSec VPN Products

Other Juniper Networks Products


The slide lists some of Juniper Networks other security products. Security Manager is also required for IDP sensor configuration and IDP blade configuration.

Chapter 238 ScreenOS Concepts, Terminology, and Platforms

Configuring Juniper Networks Firewall/IPSec VPN Products

This Chapter Discussed:


Network security device requirements; The function of the Juniper Networks security architecture components; The packet processing sequence in a Juniper Networks device; and Selecting correct deployment scenarios for Juniper Networks appliances and systems.

ScreenOS Concepts, Terminology, and Platforms Chapter 239

Configuring Juniper Networks Firewall/IPSec VPN Products

Review Questions
1. 2. 3. 4.

Chapter 240 ScreenOS Concepts, Terminology, and Platforms

Configuring Juniper Networks Firewall/IPSec VPN Products


Chapter 3: Initial Connectivity

Configuring Juniper Networks Firewall/IPSec VPN Products

This Chapter Discusses:


System component functions; Establishing connectivity to the Juniper Networks device using the console and the network; and Configuring administrative settings and options.

Chapter 32 Initial Connectivity

Configuring Juniper Networks Firewall/IPSec VPN Products

System Components
This slide lists the topics we cover in this chapter. We discuss the highlighted topic first.

Initial Connectivity Chapter 33

Configuring Juniper Networks Firewall/IPSec VPN Products

System Components
In a Juniper Networks device, the ScreenOS image and the saved configuration file are stored in flash memory. Upon startup, after the power-on self-test (POST) completes, the ScreenOS image loads into RAM and begins executing. The ScreenOS software loads the saved configuration file into RAM and executes the statements in sequential order. As a result, various processes are started, buffers, caches and tables are created, and parameters are assigned to system resources. Once the initialization of the device is complete, any additional configuration changes you make (either from the CLI, the WebUI, or TFTP) are applied to the running configuration in RAM. Once defined, those changes take effect immediately. You can use Security Manager to centrally manage many Juniper Networks devices. This course demonstrates how you can use Security Manager to do just that. A Juniper Networks device can also interact with one or more external servers that provide auxiliary services. These auxiliary services can include, but are not limited to, authentication, domain name lookup, logging, simple network management, and proxies.

Chapter 34 Initial Connectivity

Configuring Juniper Networks Firewall/IPSec VPN Products

User Interface Options


Juniper Networks devices have three administrative options: the command-line interface (CLI), the Web user interface (WebUI), and Security Manager. You can secure each user interface by using encrypted connections.

Initial Connectivity Chapter 35

Configuring Juniper Networks Firewall/IPSec VPN Products

CLI Characteristics
You can manage a Juniper Networks device from the console port by making a serial connection (COM port) from a workstation or PC. The console ports on Juniper Networks devices vary as to the cable requirements. The NS-5GT and NS-500 devices use a DB9 female to DB9 male straight-through serial cable. The SSG 5, NS-25, NS-50, NS-200, and NS-5000 products use an RJ45 serial cable. On the PC, activate a terminal emulation program with the following settings: 9600 bps 8 bit, no parity 1 stop bit No flow control

Chapter 36 Initial Connectivity

Configuring Juniper Networks Firewall/IPSec VPN Products

CLIFunctionality
After establishing a connection to the console port, the device prompts you to log in. The default login on all Juniper Networks devices is a username of netscreen and a password of netscreen.

Keyboard Shortcuts
The Juniper Networks CLI supports most common keyboard shortcuts for command editing as well as command recall and command completion. In addition, command abbreviation is available with most commands capable of being abbreviated to three or four characters. The Question Mark key (?) is available for help with command syntax, both at the prompt and within partially completed commands. Note the unset command. You can use this command to remove individual settings from RAM. If you use the command unset all, you do not modify RAM; instead, you erase the saved configuration file from flash memory. Use this option when repurposing a device to erase all saved configuration, then reset the box to boot up with a default (unconfigured) device.

Initial Connectivity Chapter 37

Configuring Juniper Networks Firewall/IPSec VPN Products

Display Status InformationCLI


Use the get system command to display generic information about a Juniper Networks device. Information that you can attain from this command includes the following: Serial number: You can also find this number on the rear or the bottom of the chassis. You can use the serial number as a username and password login when performing asset recovery. We discuss the asset recovery procedure later in the course. Software version: This is the version of the ScreenOS software currently running on the device. Operational mode of the system: The device is capable of operating in Layer 2 (transparent) mode or Layer 3 (NAT/route) mode. When operating in NAT/route mode, the interfaces of the Juniper Networks device are assigned logical IP addresses, and the unit acts as a Layer 3 forwarding device (that is, a router). In transparent mode, the interfaces are not assigned IP addresses, and the unit acts as a Layer 2 forwarding device (that is, a switch). Interface status: Link status (up or down) indicates the connection state of the interface. Link up status indicates that the link LED on the hardware interface is lit. Half-duplex and full-duplex operation is also shown, as the result of the autonegotiation process.

Continued on next page.

Chapter 38 Initial Connectivity

Configuring Juniper Networks Firewall/IPSec VPN Products

Display Status InformationCLI (contd.)


Interface address: The IP address and the subnet mask are shown in the ip: field. If no IP address is configured on the interface, the output displays a value of 0.0.0.0/0. Management address: (not shown on slide) The manager-ip address is the address to which the interface responds for management requests such as ping or Telnet. By default, the IP address and the manager-ip address are the same as the interface IP address.

Initial Connectivity Chapter 39

Configuring Juniper Networks Firewall/IPSec VPN Products

WebUI Characteristics
The ScreenOS software on Juniper Networks devices also supports a Web-based graphical user interface (GUI). Opening a browser window on the PC and navigating to an IP address on the Juniper Networks device activates the WebUI. All Juniper Networks devices ship with a default IP address of 192.168.1.1, which is accessible from the product-specific interface for the device. As long as this IP address is reachable, you can browse to the Juniper Networks device and configure it. However, if you change the IP address of the interface through which you are connected, you will lose the Web session. Therefore, we recommend that you perform the initial IP configuration from the CLI, then use the browser afterward. We discuss this IP configuration later in this section. If you browse to a Juniper Networks NS-5GT device that has no configuration saved in flash memory, an Initial Configuration Wizard will display instead of the login screen. This Wizard takes you through a series of screens that defines the operational mode, assigns the root administrator name and password, defines the address and subnet mask for selected interfaces, and enables auxiliary services such as DNS.

Chapter 310 Initial Connectivity

Configuring Juniper Networks Firewall/IPSec VPN Products

Main ScreenWebUI
The WebUI presentation always opens to the Home screen. The page is organized with a navigation panel on the left and information or configuration panels on the right. In the left panel, the Toggle Menu button enables you to switch between Dynamic Hypertext Markup Language (DHTML) and Java format when navigating between functions. The Home screen presents a variety of key system information. Much of the status information is similar to the output of a get system command at the CLI. In addition, the WebUI also includes administrator logins, system resource utilization, recent log events, and alarms. You can monitor system events and system resources conveniently from the Home screen and, as a result, you can refresh the screen to show the most current status. The Home screen defaults to manual refresh, although you can schedule the refresh in advance for common intervals, ranging from ten seconds to several minutes. Navigation in the WebUI is simple. Clicking a category title or the plus sign (+) associated with the category title expands the category and reveals the sub topics. Once a sub topic is selected, the right panel updates and displays the current settings or available configuration options.

Initial Connectivity Chapter 311

Configuring Juniper Networks Firewall/IPSec VPN Products

Security Manager characteristics


The ideal approach combines the best of both device-based and policy-based approachesan approach that treats the entire network as a system. Juniper Networks has created this ideal scenario with Security Manager. Individual devices are visible for both configuration and logging purposes, yet policies, objects, and templates are global entities that you can apply to individual devices to ensure uniform configurations. At the same time, you can configure device-specific overrides to replace template settings when needed. Note that a system-based approach has advantages beyond the ease of device configuration. When dealing with network security, the ability to verify security device settings is critical. Security policies in Security Manager allow you to verify that the corporate security policies are being enforced on all devices.

Chapter 312 Initial Connectivity

Configuring Juniper Networks Firewall/IPSec VPN Products

Device-Based Management with Security Manager


On the slide, you can see that the ScreenOS WebUI and the Security Managers device configuration windows are similar; both give you access to the device-level configuration. Elements that are device-specific can include IP address and routing configuration. You can use Security Manager to configure other device settings, but you might not be taking full advantage of the abstractions available in Security Manager. For example, all devices in your network probably use the same DNS server. Instead of configuring DNS settings on a per-device basis, you can create a template with DNS settings and apply it to all devices.

Initial Connectivity Chapter 313

Configuring Juniper Networks Firewall/IPSec VPN Products

Policy-Based Management with Security Manager


When it comes to policies, objects, and VPNs, Security Manager functions in a policy-based fashion. Instead of per-device policies, you can take a network-wide view when creating policies. You then apply these policies to devices, ensuring consistent definitions across the network. This same logic applies to VPN creation; instead of configuringand possibly misconfiguringeach side of a VPN connection, you define VPNs at a single point, then configuration information is pushed out to the individual devices.

Chapter 314 Initial Connectivity

Configuring Juniper Networks Firewall/IPSec VPN Products

Establishing Connectivity
The slide highlights the topic we discuss next.

Initial Connectivity Chapter 315

Configuring Juniper Networks Firewall/IPSec VPN Products

Administrative AccessConfiguration Overview


Configuring a Juniper Networks device for remote access consists of several components: Interface IP address: The default IP address of 192.168.1.1 rarely matches the configuration of the network where the Juniper Networks device will be installed, so at least one valid IP address must be assigned to an interface. Administrator name and password: Every Juniper Networks ships with a default root username and password of netscreen. One of the first tasks you should perform is to change either the default username, or password, or both. Leaving these items at their default is not secure! Additional administrators: You might want to configure additional administrators with either read/write or read-only access. Other administrative options: You might want to configure several additional management options; we discuss these options in detail. Enable Layer 1 and Layer 2: You might want to configure Layer 1 or Layer 2 interfaces on the ScreenOS device.

Chapter 316 Initial Connectivity

Configuring Juniper Networks Firewall/IPSec VPN Products

Interface Configuration Procedure


Configuring an interface with an IP address consists of three steps.

Initial Connectivity Chapter 317

Configuring Juniper Networks Firewall/IPSec VPN Products

Zone and Interface Assignments


The Juniper Networks internal architecture is designed with a strict hierarchical relationship between virtual routers, zones, and interfaces. An interface cannot be configured for IP connectivity without first being associated with a zone.

Chapter 318 Initial Connectivity

Configuring Juniper Networks Firewall/IPSec VPN Products

Zone Types
Three main types of zones exist on a Juniper Networks firewall. You use security zones for creating security policies. The Juniper Networks device includes predefined security zones, but you can create your own security zones with naming conventions that map more closely to your network infrastructure. You use Layer 2 (V1) security zones when the Juniper Networks device operates in transparent mode; you use Layer 3 zones when the Juniper Networks device operates in NAT/route mode. (We discuss both these modes in detail later in this course.) Function zones are zones that serve a single, specific purpose within the firewall. They are not used in security policies. Function zones include the following: Null: This zone is the default zone for an interface that is not bound to any other zone. An interface is not configurable while it is bound to the Null zone. Self: This zone hosts the logical and internal interface for remote management connections (Telnet, HTTP, SSH). MGT: This zone hosts the out-of-band management interface on firewall systems (NS-500 device, NS-5000 devices).

Continued on next page.

Initial Connectivity Chapter 319

Configuring Juniper Networks Firewall/IPSec VPN Products

Zone Types (contd.)


HA: This zone hosts the high-availability interfacesHA1 and HA2on firewall systems, and hosts an inline port used for HA on the NS-200 devices. VLAN: The VLAN zone contains the VLAN1 interface, used for management purposes in transparent mode.

The Tunnel zone is used for backward-compatible tunnel support when upgrading from ScreenOS software versions earlier than Release 3.1.

Chapter 320 Initial Connectivity

Configuring Juniper Networks Firewall/IPSec VPN Products

Configuring Zones and Interfaces


Configuration using the CLI requires two commands: one command to assign the interface to a zone, and the second command to assign the IP address and subnet. In the WebUI, select the name of a Layer 3 zone, then type in an IP address and netmask for this interface. Leave the Manageable check box on; this option allows you to access the Juniper Networks device remotely using this interface. Click the OK button at the bottom of the screen. Caution: If you reconfigure the interface providing connectivity to your browser, you will lose your connection. Depending on the management services enabled, you might not be able to browse again to the IP address you just configured.

Initial Connectivity Chapter 321

Configuring Juniper Networks Firewall/IPSec VPN Products

Securing Administrator Traffic


When it comes to internal management tools, you can use several methods to enhance the security of management connections.

Chapter 322 Initial Connectivity

Configuring Juniper Networks Firewall/IPSec VPN Products

Management Services
Depending on the zone assignment of an interface, different management services are enabled. These defaults protect the Juniper Networks device from unauthorized access. The two-step process to enable SSH on an interface is the following: set interface e1 manage ssh set ssh enable When you enable SSH, you must enable the SSH server.

Initial Connectivity Chapter 323

Configuring Juniper Networks Firewall/IPSec VPN Products

Management ServicesWebUI
You can override these defaults selectively on each interface by checking the appropriate boxes in the WebUI. The Manageable check box next to the interface IP address overrides any selected service options; if Manageable is not checked, no management services will be available from the interface.

Chapter 324 Initial Connectivity

Configuring Juniper Networks Firewall/IPSec VPN Products

Management ServicesSecurity Manager


You can override these defaults selectively on each interface by checking the appropriate boxes in Security Manager.

Initial Connectivity Chapter 325

Configuring Juniper Networks Firewall/IPSec VPN Products

manage-ip Address
By default, the management IP address on an interface is the same as the interface IP address. However, you might want to configure a separate IP address for management purposes. This address adds an additional element of security to your system; management services will only be available via the manage-ip address, not the interface address. As the manage-ip address is never published nor used as a source address (for example, in a routing update), it is invisible to any snooping on your network and therefore, more secure. Note, however, that the physical interface IP address will still respond if pinged. Another instance where the manage-ip address is useful is in a redundant configuration. The interface address will be identical for both redundant devices, but the manage-ip address can be unique for each, allowing individual accessibility. The only requirement for a separate management address is that the address be selected from the same block of subnet addresses as the interface IP address.

Chapter 326 Initial Connectivity

Configuring Juniper Networks Firewall/IPSec VPN Products

Default Route
Adding a default route to the Juniper Networks device is important. This route allows for unknown destination addresses to be forwarded to an upstream router. You should add the default route to the virtual router that you are using, most commonly trust-vr.

Initial Connectivity Chapter 327

Configuring Juniper Networks Firewall/IPSec VPN Products

Default RouteWebUI
Adding a default route in the WebUI is a two-step process. You can add the default route to the routing table by first selecting the correct virtual router, trust-vr, then clicking New. Second, fill out the static route entry. Remember that 0.0.0.0/0 is the network that you want to forward to the default gateway.

Chapter 328 Initial Connectivity

Configuring Juniper Networks Firewall/IPSec VPN Products

Default RouteSecurity Manager


Adding a default route in the Security Manager is a three-step process. First, edit the trust-vr router. Next, add a new routing table destination. Finally, add the default route entry to the routing table. Remember that 0.0.0.0/0 is the network that you want to forward to the default gateway.

Initial Connectivity Chapter 329

Configuring Juniper Networks Firewall/IPSec VPN Products

Device Administrators
Now that we know how to access the Juniper Networks device (IP address) and which services are available (management services), the next step is configuring who can access the system. The Juniper Networks device ships with a root administrator configured with the default username and password of netscreen. You should always change this parameter in a production environment. (Note: Do not change this in the classroom lab!) The root administrator can create other administrators. These additional administrators can have read/write or read-only access to the system. The root administrator has a few additional privileges over a read/write administrator, including the following: Creating additional administrators; Activating and deactivating asset recovery features; and Replacing configurations from remote devices to flash memory.

A read-only administrator can only view CLI and WebUI information and is limited to get and ping commands. You can create a maximum of 20 administrators on a Juniper Networks device. However, only ten administrators can be logged in simultaneously.

Chapter 330 Initial Connectivity

Configuring Juniper Networks Firewall/IPSec VPN Products

Changing the Root Administrator Name and Password


The CLI commands are also shown on the slide. Changing the name and password are two separate commands. Remember that only one root user can be defined on each device.

Initial Connectivity Chapter 331

Configuring Juniper Networks Firewall/IPSec VPN Products

Creating System Administrators


Creating a new administrator is equally straightforward. Be sure to select the appropriate level of accessall privilege (read/write), or read-only access.

Chapter 332 Initial Connectivity

Configuring Juniper Networks Firewall/IPSec VPN Products

TimeoutConsole
By default, console and Telnet sessions time out after 10 minutes of inactivity. You can modify this parameter or disable it by setting the timeout value to zero. We suggest that you never set the timeout value to zero. To verify the current console timeout, use the get console command: ns208-> get console Console timeout: 120(minute), Page size: 22/22, debug: buffer privilege 250, config has not been changed! ID State Duration Task Type Host 0 Logout 0 2816 Local 2 Login 6190 4928 Local ns208->

Initial Connectivity Chapter 333

Configuring Juniper Networks Firewall/IPSec VPN Products

TimeoutWebUI
The WebUI timeout, like the console timeout, defaults to 10 minutes. When changing the WebUI timeout, specify a number of minutes (between 1 and 999) of idle time before the browser closes. If you do not want the WebUI to time out, uncheck the Enable Web Management Idle Timeout check box. For class, we recommend that the timeout be set to 60 minutes to keep the WebUI from expiring during lecture time. Other options on this screen include a link to online help. This link defaults to the Juniper Networks Web site; however, if you do not have Internet access, you can change this link to point to a local site where the documentation is stored. You can use the remaining options to further control administrative access to your Juniper Networks device. You can use Security Manager to also adjust the WebUI timeout: SecMgr: Edit Device > Device Admin > Web Management

Chapter 334 Initial Connectivity

Configuring Juniper Networks Firewall/IPSec VPN Products

Permitted IP Addresses
To provide yet another level of security, you can configure the Juniper Networks device to accept management requests only from a select range of device addresses.

Initial Connectivity Chapter 335

Configuring Juniper Networks Firewall/IPSec VPN Products

Configuring Permitted IP Addresses


Regardless of the name, once configured, the addresses listed reference the only devices from which management service requests will be accepted. You are limited to six entries; each entry can be either a specific host or a subnet or network. Caution: When enabling this feature from a Telnet or Web session, ensure that the address through which the unit is being managed (your IP address) is specified as the first entry on the list. If you do not specify your own address first, your own session will be terminated, and you will lose connectivity.

Chapter 336 Initial Connectivity

Configuring Juniper Networks Firewall/IPSec VPN Products

Management Operation
All the individual management components shown in the slide work together to provide tight security regarding who can access what services on which interfaces on the Juniper Networks device.

Initial Connectivity Chapter 337

Configuring Juniper Networks Firewall/IPSec VPN Products

Layer 1 and Layer 2 Configuration


After configuring Layer 3 interfaces, you might have Layer 1 and Layer 2 interfaces to configure.

Chapter 338 Initial Connectivity

Configuring Juniper Networks Firewall/IPSec VPN Products

Reset to Factory-Default Configuration


Using the console connection, reset the device to the factory-default configuration. Do not save the configuration if prompted to do so.

Initial Connectivity Chapter 339

Configuring Juniper Networks Firewall/IPSec VPN Products

Verifying Connectivity
The slide highlights the topic we discuss next.

Chapter 340 Initial Connectivity

Configuring Juniper Networks Firewall/IPSec VPN Products

Verifying Connectivity
Using the CLI get commands shown on the slide can assist in verifying connectivity.

Initial Connectivity Chapter 341

Configuring Juniper Networks Firewall/IPSec VPN Products

Verifying Interface ConfigurationCLI


Use the get interface name command to view the interface configuration using the CLI. Also remember from the previous chapter that the interfaces bound to the Trust zone have most of the management services enabled. By default, interfaces bound to the Untrust zone have no management services enabled.

Chapter 342 Initial Connectivity

Configuring Juniper Networks Firewall/IPSec VPN Products

Verifying Interface ConfigurationWebUI


To verify interface configuration when using the WebUI, view the interface configuration screen.

Initial Connectivity Chapter 343

Configuring Juniper Networks Firewall/IPSec VPN Products

Verifying AdministratorsCLI
The CLI separates administrator information from SSH information. On the slide you can determine if SSH is enabled and whether PKA keys are created for each administrator.

Chapter 344 Initial Connectivity

Configuring Juniper Networks Firewall/IPSec VPN Products

Verifying AdministratorsWebUI
After you create your administrators, they are added to the list shown on the WebUI. Note that the top half of the screen refers to an external database of administrators. Instead of defining administrators locally, you can use a RADIUS server to define administrators. This method allows you to overcome the limit of 20 administrators. The settings here allow you to determine what access an externally authenticated administrator has to the system. To complete RADIUS configuration, you must set up connectivity to the RADIUS server. You set up this connectivity under the Configuration > Auth > AuthServers menu, or with the command: set auth-server name radius options

Initial Connectivity Chapter 345

Configuring Juniper Networks Firewall/IPSec VPN Products

Verifying the Manage IP AddressCLI


The Manage IP address is displayed in the get system output if it is configured. Verify configuration from the WebUI on the same screen that you configured permitted IP addresses. If you want to remove a Manage IP address, it might be necessary to change the configuration from the console to make that interface more secure. The command is: unset admin manager-ip [all | A.B.C.D]

Chapter 346 Initial Connectivity

Configuring Juniper Networks Firewall/IPSec VPN Products

This Chapter Discussed:


System component functions; Establishing connectivity to the Juniper Networks device using the console and the network; and Configuring administrative settings and options.

Initial Connectivity Chapter 347

Configuring Juniper Networks Firewall/IPSec VPN Products

Review Questions
1. 2.

Chapter 348 Initial Connectivity

Configuring Juniper Networks Firewall/IPSec VPN Products

Lab 1: Initial Configuration


The slide lists the objectives for this lab.

Initial Connectivity Chapter 349

Configuring Juniper Networks Firewall/IPSec VPN Products

Chapter 350 Initial Connectivity

Configuring Juniper Networks Firewall/IPSec VPN Products


Chapter 4: Device Management

Configuring Juniper Networks Firewall/IPSec VPN Products

This Chapter Discusses:


Connecting to external management devices; Managing license keys; Managing configuration and software image files; and Performing disaster recovery procedures.

Chapter 42 Device Management

Configuring Juniper Networks Firewall/IPSec VPN Products

Management
This slide lists the topics we cover in this chapter. We discuss the highlighted topic first.

Device Management Chapter 43

Configuring Juniper Networks Firewall/IPSec VPN Products

External Management Devices


A Juniper Networks device relies on and supports common services that might be operating on external servers, such as name translations, authentication, logging, and management functions.

Chapter 44 Device Management

Configuring Juniper Networks Firewall/IPSec VPN Products

DNS Configuration
DNS configuration consists of the ability to set three DNS servers as well as setting a refresh schedule to update the resolved address table.

Device Management Chapter 45

Configuring Juniper Networks Firewall/IPSec VPN Products

NTP Configuration
Network time servers allow devices on the network to keep their time synchronized with a master time server. Juniper Networks devices are Network Time Protocol (NTP) clients that can synchronize their time to an NTP server. 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. You can also use the WebUI command Sync Clock With Client to update the ScreenOS device.

Chapter 46 Device Management

Configuring Juniper Networks Firewall/IPSec VPN Products

SNMP Parameters
The Simple Network Management Protocol (SNMP) agent for the Juniper Networks device provides you with a way to view statistical data about the network and the devices on it, and to receive notification of system events of interest. The Juniper Networks device supports SNMPv1 and SNMPv2c. It also supports all relevant MIB II groups. The following is a list of SNMP parameters: Contact: Name of contact; Location: Name of location; Port: Listen or trap port number; Community name: Name of the SNMP community; Community version: Version of the SNMP community; Community host: IP address; and Community host trap: IP address.

Device Management Chapter 47

Configuring Juniper Networks Firewall/IPSec VPN Products

SNMP Configuration
The device uses the SNMP configuration to send and receive network management information. Configuration consists of setting ports and adding a community.

Chapter 48 Device Management

Configuring Juniper Networks Firewall/IPSec VPN Products

SNMP ConfigurationWebUI: Part 1


As shown in the slide, in the main screen, configure basic system information (contact and location), the appropriate SNMP port numbers, then click Apply. Next, configure community information by clicking the New Community button.

Device Management Chapter 49

Configuring Juniper Networks Firewall/IPSec VPN Products

SNMP ConfigurationWebUI: Part 2


For each community, set the name, permissions, and SNMP version that the server will use for get commands. Next, list each management server that is a member of this community, setting the SNMP version used for traps and the source interface to be used for the traps for each management server. The slide shows this configuration screen of the WebUI.

Chapter 410 Device Management

Configuring Juniper Networks Firewall/IPSec VPN Products

Syslog Configuration
Syslog is a facility that enables the logging of system events to a single file for later review. A Juniper Networks device can generate syslog messages for system events at predefined severity levels and optionally, for traffic that policies permit across a firewall. It sends these messages using UDP or TCP (port 514) to up to four designated syslog hosts. The severity level of an event determines whether the event is communicated in a syslog message. By default, syslog is disabled even if servers are configured, so be sure you issue the enable command or click the check box to turn on the service. The source interface parameter determines which interface IP address the device uses for the source of logging messages. You might need to set this parameter if you connect to your syslog server through a VPN; the source interface will be an interface in your trusted zone.

Device Management Chapter 411

Configuring Juniper Networks Firewall/IPSec VPN Products

Managing License Keys


ScreenOS software offers several optional features that you can purchase separately. To enable these features on your device, you must load the associated license keys. You obtain feature licenses from the License Management System (LMS) at Juniper Networks (http://www.juniper.net/generate_license). You need two pieces of information to generate your licenses: The hardware ID of your device, visible at the bottom of the license configuration screen; and The authorization code, provided at the time of purchase of the licensed features.

After you enter the information, the LMS displays the license keys for your system. You can then cut and paste the keys to your device.

Chapter 412 Device Management

Configuring Juniper Networks Firewall/IPSec VPN Products

Managing License KeysSecurity Manager


Some security devices support the activation of optional features or the increased capacity of existing features without having to upgrade to a different device or system image through the installation of license keys. You can purchase various keys that either increase the capacity of existing features or enable new features. For example, purchase a DRP key to enable the Dynamic Routing Protocol on your security device, and purchase a VSYS key to add more virtual systems, virtual routers, and zones on your security device. You can use the administration feature of the device to add license keys.

Device Management Chapter 413

Configuring Juniper Networks Firewall/IPSec VPN Products

File Management
The Juniper Networks device relies on two files for proper operation: the ScreenOS image binary, and a configuration file. By default, these files are loaded into RAM from flash memory at system startup. Because flash storage space is limited, additional file storage options are available. All devices have a TFTP-client feature in the ScreenOS software that allows the transfer of files to and from an external TFTP server. Mid-range and high-end systems have some form of additional local storage, either PCMCIA or compact flash, depending on the device. The WebUI also allows use of the local management stations hard drive for file storage.

Chapter 414 Device Management

Configuring Juniper Networks Firewall/IPSec VPN Products

Saving Your Configuration


If you use the CLI, you must enter the save command to write your changes to flash memory. Any read/write administrator can perform this task. If you use the WebUI to configure your Juniper Networks device, your configuration is automatically saved to flash memory every time you click the OK or Apply button. Changes you make to devices and objects using Security Manager are saved automatically. You must manually save changes that are made to policies and VPNs.

Device Management Chapter 415

Configuring Juniper Networks Firewall/IPSec VPN Products

Configuration File ManagementCLI


External device access requires root access. You can save configuration files off to external devices, or you can load them back from external devices. When retrieving configurations, you have two options: A simple copy replaces the configuration file currently in flash memory with the file coming from the external device. To load that file into RAM, you must restart the system. The merge option combines the downloaded file with the configuration currently in RAM, then it saves the combined file to flash memory. Be very careful when performing this operation; if the incoming file has settings that conflict with what is presently in RAM, the conflicting file will overwrite those settings. (Think of loading a file from an external source as typing in commands manually, only very quickly.)

Chapter 416 Device Management

Configuring Juniper Networks Firewall/IPSec VPN Products

Configuration File ManagementWebUI


When using the WebUI, the system assumes that the local drive is the external source and destination for files.

Device Management Chapter 417

Configuring Juniper Networks Firewall/IPSec VPN Products

Configuration ManagementSecurity Manager


You can use the device configuration screen in Security Manager to import and export a devices configuration. Security Manager uses atomic configuration, a fail-safe feature for security devices running ScreenOS software Release 5.x. Atomic configuration ensures that a current, valid configuration is not overwritten by a flawed configuration in flash memory. The update must complete without errors and the device connection to the management system must remain active, or the update is aborted to prevent an invalid, error-prone, or flawed configuration to install on the device. Note that you do not need to configure atomic configuration (all activities occur automatically). Security devices running ScreenOS software Release 5.1 or higher support atomic updating, which enables the device to receive the entire modeled configuration (all commands) before executing those commands (instead of executing commands as they are received from the management system). Because Security Manager sends all commands at one time, the performance of the management connection is enhanced. Atomic updating also enables the device to temporarily lose connection to Security Manager during the update process. If the management connection is down when the device completes executing the commands in the modeled configuration, the device reestablishes the connection. Because the device must no longer maintain a constant connection to the management system during updating, you can configure changes to the management connection from the Security Manager UI. Note that you do not need to configure atomic updating (all activities occur automatically).

Chapter 418 Device Management

Configuring Juniper Networks Firewall/IPSec VPN Products

Configuration Rollback
Configuration rollback is a feature in ScreenOS software. It allows for a second backup configuration file to be stored in flash memory. At system restart, the system checks a retry counter. If the counter is set to zero, the system tries to load the primary configuration file. If the loading fails, the system increments the counter. If the counter is set to any value other than zero, the system attempts to load the last known good (LKG) configuration file. As soon as any configuration is successfully loaded, the counter is reset to zero.

Rollback Commands
If at any time you want the system to boot from the LKG file, you can use the exec config rollback command to reset the system using the LKG file. Caution: If sufficient flash memory does not exist to support both configuration files, the system does not create the LKG file. The system instead displays an error message.

Device Management Chapter 419

Configuring Juniper Networks Firewall/IPSec VPN Products

Software Image Management


Upgrading consists of two steps: copying the image into flash memory, then restarting the system. Be sure that this process is not interrupted, or you might cause irreparable damage to your system.

Chapter 420 Device Management

Configuring Juniper Networks Firewall/IPSec VPN Products

Upgrade ExampleCLI
When performing an upgrade via the CLI, the file transfer process displays an exclamation point (!) for every segment successfully transferred. The system then performs a checksum against the file to ensure successful transfer. Once the file is validated, it is written to flash memory. To load the file from flash memory into RAM, reset the system.

Device Management Chapter 421

Configuring Juniper Networks Firewall/IPSec VPN Products

Upgrade ExampleWebUI
Upgrading from the WebUI involves selecting a file, then leaving the system alone to transfer the file, validate it, then reset. To verify that the upgrade is successful, reconnect to the Juniper Networks device and check the software version.

Chapter 422 Device Management

Configuring Juniper Networks Firewall/IPSec VPN Products

Upgrade ExampleSecurity Manager


Upgrading from Security Manager involves using the Firmware Manager to load the firmware into Security Manager. Then, you use the Change Device Firmware tool to change the firmware on a device. To verify that the upgrade is successful, reconnect to the Juniper Networks device and check the software version.

Device Management Chapter 423

Configuring Juniper Networks Firewall/IPSec VPN Products

Recovery
The slide highlights the topic we discuss next.

Chapter 424 Device Management

Configuring Juniper Networks Firewall/IPSec VPN Products

Disaster Recovery
Although not a common occurrence, sometimes events happen that require drastic actions to recover from an electronic mishap. Some examples of these events include the following: A corrupted flash image that prevents a device from booting correctly; Loss of the root-level password; and A device so badly misconfigured that it is simpler to erase the configuration and start over.

Fortunately, Juniper Networks devices have features that allow you to handle these mishaps in an efficient manner. You can overwrite a corrupted ScreenOS image in flash memory with an image from a TFTP server by using a special boot mode. This procedure involves interrupting the normal boot sequence and initiating a file transfer from a local TFTP server. You can overcome the loss of the root password, but the results of the process are very destructive; the configuration in flash memory is completely erased so as to prevent theft of the configuration through this process. Therefore, we highly recommend storing backups of your configuration on external devices. When a device configuration is so messed up that the unit fails to operate, sometimes the only logical action is to clear the configuration and start anew. Again, having a backup copy of a valid device configuration on a server can make the recovery almost painless.

Device Management Chapter 425

Configuring Juniper Networks Firewall/IPSec VPN Products

Recovering the ScreenOS ImageBoot Mode: Part 1


When power is applied to a Juniper Networks device, the boot process is initiated. If you have console access, you can interrupt the boot sequence by pressing any key on your keyboard within the first 60 seconds. (Most commonly, the key is pressed when the Hit any key to run Loader message is being displayed on the console device.) You will be required to enter the following information: Boot file name: The name of the image file located on the TFTP server. Self IP address: An IP address that will be applied to E1 or the Trust interface. The device will use this address to source a load request from the Juniper Networks device to the TFTP server. TFTP IP address: The IP address of the TFTP server on the local subnet. This device must be connected to the segment accessible from E1 or the Trust interface.

Once you enter the information, the data transfer from the TFTP server begins. See the following page for more information about this process.

Chapter 426 Device Management

Configuring Juniper Networks Firewall/IPSec VPN Products

Recovering the ScreenOS ImageBoot Mode: Part 2


The file transfer from the TFTP server is a series of requests, acknowledgements and transfers, as indicated by the letters r, a, and t. As shown on the slide, once the transfer is complete, you agree to write the image to flash memory and also agree to run the new image. Running the new image causes a boot sequence to be initiated. If the recovery operation is a success, a normal boot sequence follows. Although the ScreenOS image in flash memory was corrupted, the configuration file remained intact, and the device will return to its normal operational state after the boot sequence completes.

Device Management Chapter 427

Configuring Juniper Networks Firewall/IPSec VPN Products

Lost Root Password


If you forget or lose the root administration password, with ScreenOS software, you can perform asset recovery via a login or by using the pinhole on the exterior of the Juniper Networks device. Either procedure erases all configuration data from flash memory and restores the system to factory defaults. You can disable these features via the CLI, but if you do so and later forget the root password, you have no option but to return your system to Juniper Networks. To disable recovery via login, use the following command: unset admin device-reset To disable recovery via pinhole, use the following command: unset admin hw-reset Once you reset the system, you can either configure sufficient IP connectivity to download a saved configuration from TFTP, or you can paste it in from your PC. Remember to reset the password after you load the configuration!

Chapter 428 Device Management

Configuring Juniper Networks Firewall/IPSec VPN Products

This Chapter Discussed:


Connecting to external management devices; Managing license keys; Managing configuration and software image files; and Performing disaster recovery procedures.

Device Management Chapter 429

Configuring Juniper Networks Firewall/IPSec VPN Products

Review Questions
1. 2.

Chapter 430 Device Management

Configuring Juniper Networks Firewall/IPSec VPN Products

Lab 2: Device Administration


The slide lists the objectives for this lab.

Device Management Chapter 431

Configuring Juniper Networks Firewall/IPSec VPN Products

Chapter 432 Device Management

Configuring Juniper Networks Firewall/IPSec VPN Products


Chapter 5: Layer 3 Operations

Configuring Juniper Networks Firewall/IPSec VPN Products

This Chapter Discusses:


The need for routing on the Juniper Networks firewall; Configuring static routes; The function of a virtual router (VR); The uses of loopback interfaces; How to add virtual interfaces: VLANS; Loopback; and Tunnel;

The difference between Network Address Translation (NAT) and route interface modes; Configuring interfaces for NAT or route mode; and Verifying operation.

Chapter 52 Layer 3 Operations

Configuring Juniper Networks Firewall/IPSec VPN Products

Need for Routing


This slide lists the topics we cover in this chapter. We discuss the highlighted topic first.

Layer 3 Operations Chapter 53

Configuring Juniper Networks Firewall/IPSec VPN Products

Layer 3 Operations Mode


In Layer 3 Mode, each interface on the firewall has its own IP address. Forwarding decisions between interfaces are based on IP address, not MAC address. Therefore, the firewall acts as a Layer 3 router, not a Layer 2 switch.

Chapter 54 Layer 3 Operations

Configuring Juniper Networks Firewall/IPSec VPN Products

The Need for Routing


Because the firewall is now making forwarding decisions based on Layer 3 addresses, it must build an internal forwarding table of subnets and networks. By default, when interfaces are configured with IP addresses, the device populates this forwarding table with the associated local subnets. This population with subnets is great if all destinations are directly connected to the firewall, but in most networks the firewall is sandwiched between routers connecting many other subnets and networks. For the firewall to make correct forwarding decisions, it needs you to add more information to the forwarding table. Two basic options for adding routes exist: manual configuration of static routes and configuration of dynamic routing protocols. We discuss static route configuration in this course.

Layer 3 Operations Chapter 55

Configuring Juniper Networks Firewall/IPSec VPN Products

Static Routes
You manually configure a static route. The route includes the destination network, the interface used to reach that network, and the address of the next-hop router in the path to the destination. Note that even if the destination network is several hops away, the next-hop router is always on the same subnet as the firewall. The next-hop router, in turn, will have the same type of forwarding information, handing the packet to the next router in line until the destination network is reached.

Chapter 56 Layer 3 Operations

Configuring Juniper Networks Firewall/IPSec VPN Products

Default Routes
Literally millions of networks and subnets are connected via the Internet. Configuring a detailed static route to each of them is an impossible task. Instead, define a special static route called a default route, a route to network 0.0.0.0/0. This route acts as a none-of-the-above entry in the forwarding tableif the destination network is not in the forwarding table, send the packet to this specific next hop. The next-hop router might have more detailed informationor it might have its own default route pointing to yet another router. The ScreenOS software searches a routing table from the most specific to the least specific route. The default gateway is the least specific route.

Layer 3 Operations Chapter 57

Configuring Juniper Networks Firewall/IPSec VPN Products

Virtual RoutersOne VR
Thus far, we have looked at the Juniper Networks firewall as a single router. All networksboth private and publicare included in the local routing table. This setup might suit a smaller environment using static routing, but in larger networks using dynamic routing protocols, this setup requires complex routing configurations to hide the private addresses from outside and unsecured networks.

Chapter 58 Layer 3 Operations

Configuring Juniper Networks Firewall/IPSec VPN Products

ScreenOS Two-VR Architecture


Juniper Networks allows for multiple VRs to coexist within a single firewall. One VR provides forwarding for private networks; the other VR provides forwarding for public networks. You carefully configure and control the routing between the two VRs, making the securing of the routing entries much easier. Each virtual router has the following characteristics: Its own routing table; Capability of being viewed separately; Running routing protocols such as BGP or OSPF; Supporting IP addresses that overlap with those of other virtual routers; and Control over the routes that can be exported or imported to or from other virtual routers.

The overlapping address capability is particularly useful in remote office or corporate merger situations where private addressing might be used on both sides of the firewall.

Layer 3 Operations Chapter 59

Configuring Juniper Networks Firewall/IPSec VPN Products

Dynamic routing
The Juniper Networks device supports several dynamic routing protocols, such as RIP, OSPF, and BGP. RIP is one of the basic dynamic routing protocols supported. The OSPF is an interior gateway protocol (IGP) used for routing within a single autonomous system (AS). The BGP is a routing protocol used for communication between ASs on the Internet.

Chapter 510 Layer 3 Operations

Configuring Juniper Networks Firewall/IPSec VPN Products

Configuring Layer 3
The slide highlights the topic we discuss next.

Layer 3 Operations Chapter 511

Configuring Juniper Networks Firewall/IPSec VPN Products

Case Study
We use the case study shown on the slide to demonstrate how you can configure Layer 3 networks on a Juniper Networks device.

Chapter 512 Layer 3 Operations

Configuring Juniper Networks Firewall/IPSec VPN Products

Configuring for Layer 3 Operations


The slide shows the steps we use to configure Layer 3 operations on a Juniper Networks device.

Layer 3 Operations Chapter 513

Configuring Juniper Networks Firewall/IPSec VPN Products

Step 1: Creating Zones


You can create a user-defined zone to use in ScreenOS software. When using the WebUI, you see several options displayed. (These options are also available using the CLIuse the question mark (?) to see them.) Here we discuss the following two main options: Virtual router name: Select the VR with which this new zone will be associated. When using the CLI, you do not need to make this association. Zone type: Layer 2 is for transparent mode, Layer 3 is for IP routing mode, and tunnel supports legacy configurations.

Chapter 514 Layer 3 Operations

Configuring Juniper Networks Firewall/IPSec VPN Products

Step 2: Assigning Interfaces to Zones: Part 1


You must assign interfaces to a valid security zone before you can configure them with an IP address. You use the set interface command to assign an interface to the Null zone. When in the Null zone, you can perform no IP configuration on an interface.

Layer 3 Operations Chapter 515

Configuring Juniper Networks Firewall/IPSec VPN Products

Step 2: Assigning Interfaces to Zones: Part 2


You must assign interfaces to a valid security zone before you can configure them with an IP address.

Chapter 516 Layer 3 Operations

Configuring Juniper Networks Firewall/IPSec VPN Products

Step 3: Assigning IP Addresses to Interfaces: Part 1


This slide provides a review of the command we discussed in Chapter 3.

Layer 3 Operations Chapter 517

Configuring Juniper Networks Firewall/IPSec VPN Products

Step 3: Assigning IP Addresses to Interfaces: Part 2


The slide shows how to assign an IP address to an interface using either the WebUI or Security Manager.

Chapter 518 Layer 3 Operations

Configuring Juniper Networks Firewall/IPSec VPN Products

Step 4: Configuring Static Routes: Part 1


Make sure that when using the CLI you include the next-hop gatewayeven though the CLI allows you to omit it. Omitting the gateway places the entry in the forwarding table, but the firewall does not know to which specific device to hand packets, thus routing fails. The only time you do not need a next-hop address is when using tunnel interfaces; we discuss tunnel interfaces in Chapter 12 later in this course.

Layer 3 Operations Chapter 519

Configuring Juniper Networks Firewall/IPSec VPN Products

Step 4: Configuring Static Routes: Part 2


The slide illustrates how to add a static route to a Juniper Networks device. Remember to select Gateway when using the WebUI.

Chapter 520 Layer 3 Operations

Configuring Juniper Networks Firewall/IPSec VPN Products

Verifying Layer 3
The slide highlights the topic we discuss next.

Layer 3 Operations Chapter 521

Configuring Juniper Networks Firewall/IPSec VPN Products

Verifying Interface Configuration


After you configure a network interface, verify that the correct zone and IP address are set. One common mistake is to enter the wrong subnet mask in the interface window.

Chapter 522 Layer 3 Operations

Configuring Juniper Networks Firewall/IPSec VPN Products

Verifying Static RoutesCLI


You can view the routing table to verify that your routes were added. Again, make sure that a next-hop gateway is defined. The asterisk (*) means that an interfaces is up and the route is active.

Layer 3 Operations Chapter 523

Configuring Juniper Networks Firewall/IPSec VPN Products

Verifying Static RoutesWebUI


You can view the routing table to verify that your routes were added. Again, make sure that a next-hop gateway is defined. You can also remove user-defined routes using this screen by clicking the Remove option. Note that directly connected networks cannot be removed from the routing table this way; to remove these networks, you must reconfigure the associated interface IP address.

Chapter 524 Layer 3 Operations

Configuring Juniper Networks Firewall/IPSec VPN Products

Verifying Routing: Part 1


Use the get route ip command to verify that you have a route to a particular host. The output shows all entries in the routing table that could be used to reach the specified host address.

Layer 3 Operations Chapter 525

Configuring Juniper Networks Firewall/IPSec VPN Products

Verifying Routing: Part 2


ping is a standard IP troubleshooting command that sends an echo packet to the specified host, which in turn sends an echo reply. If the specified host cannot be reached, or if the return trip traffic cannot make it back, the ping will fail. By default, ping sends five 100-byte packets with a timeout of 2 seconds, using the outbound interface specified in the routing table as the source address. You can use extended ping to change timeouts, number of pings, source IP address, and so on.

Chapter 526 Layer 3 Operations

Configuring Juniper Networks Firewall/IPSec VPN Products

Verifying Routing: Part 3


Another standard IP troubleshooting tool is the trace-route command. Where ping tests a path end to end, trace-route tests the path hop by hop. You can use trace-route to pinpoint routing failures.

Layer 3 Operations Chapter 527

Configuring Juniper Networks Firewall/IPSec VPN Products

Routing Interdependencies
When relying on static routes for your configuration, remember that IP sessions are bidirectional. Even if a packet makes it all the way from the source and session initiator to the destination, if the routers cannot send the reply back to the source, communication will fail.

Chapter 528 Layer 3 Operations

Configuring Juniper Networks Firewall/IPSec VPN Products

Debug Utility
The debug utility is a powerful troubleshooting tool that allows you to track the flow of a packet or events in a Juniper Networks device. The debug capability is supported for many functions; a partial list is shown on the slide. (Obtain a complete list using the debug ? command.) By default, the device sends the output to the debug buffer. One of the most helpful debug commands is debug flow basic. This command provides output that tracks the sequence of events that occurs as the Juniper Networks device processes a packet.

Layer 3 Operations Chapter 529

Configuring Juniper Networks Firewall/IPSec VPN Products

Debug Buffer
The debug buffer is memory that is set aside for collecting output from the debug and snoop utilities. You can examine the size of the debug buffer, and if necessary, make changes to the buffer size. To work with the buffer, first clear the debug buffer with the command clear dbuf. Then perform a test operation, such as ping. Finally, analyze the contents of the debug buffer using the get dbuf stream command.

Chapter 530 Layer 3 Operations

Configuring Juniper Networks Firewall/IPSec VPN Products

Troubleshooting ToolsOutput Options


For the troubleshooting options debug and snoop, you can direct output either to the console or to the debug buffer. By default, the device directs output to the debug buffer. You can configure the system to redirect output to the console for live viewing, but we do not recommend this configuration.

Layer 3 Operations Chapter 531

Configuring Juniper Networks Firewall/IPSec VPN Products

Set Flow Filter


In a production network with a great deal of traffic, the debug utility can produce a lot of output not related to the problem you are troubleshooting. To narrow down the information produced by debug, you can configure filters called flow filters. Use the set ffilter command to configure the filter. You can filter on IP addresses (source or destination), IP protocol field, and TCP/UDP port numbers (source or destination).

Chapter 532 Layer 3 Operations

Configuring Juniper Networks Firewall/IPSec VPN Products

Flow Filter Options


You can combine filter parameters using logical AND/OR functions. The logical AND parameters must be on the same line. Enter the logical OR operations on separate lines.

Layer 3 Operations Chapter 533

Configuring Juniper Networks Firewall/IPSec VPN Products

Viewing Flow Filter


Use the get ffilter command to view current settings for debug filters. You can remove filters individually. The device reorders the identifiers for the remaining filters if a filter is removed.

Chapter 534 Layer 3 Operations

Configuring Juniper Networks Firewall/IPSec VPN Products

Packet Flow Review


Before looking at the output from the debug utility, review the sequence of events that occurs when a Juniper Networks device processes a packet: The packet arrives: Note the incoming interface and associated zone. The device performs a sanity check on the packet: This check involves operations such as length checks and checksum verification. Determine if a session already exists: If so, the device uses the session information to forward the packet. The device performs a route lookup: From this, you determine the outgoing interface and the associated outgoing zone. Note that the first return-trip packet might also have a route lookup performed; the routing table must contain a route back to the original source. All subsequent packets are then forwarded based solely on session information.

The device performs a policy lookup. The device checks for an existing ARP cache entry. The device creates the session and forwards the packet.

Layer 3 Operations Chapter 535

Configuring Juniper Networks Firewall/IPSec VPN Products

Debug Procedure
The effective use of debug follows a specific process: 1. 2. 3. Get the output of ffilter to check for existing debug filters. Set some flow filters on the debug data stream. Enable the debug utility for the desired option. You can enable multiple options but doing so might produce output that is difficult to analyze. In most circumstances it is better to use one option at a time. Clear the debug buffer. The debug buffer displays the oldest information first. Clearing the debug buffer avoids having to search through old output. Issue the ping command (or whatever command is being used to generate traffic). The debug buffer captures the result. Disable debug to terminate output going to the debug buffer. Use get dbuf stream to analyze the output from the debug utility. Check to see if the problem is resolved. Turn off the flow filters if the problem is resolved. If the problem is not resolved, go back to Step 2 and repeat the process until the problem is resolved.

4.

5. 6. 7. 8.

Chapter 536 Layer 3 Operations

Configuring Juniper Networks Firewall/IPSec VPN Products

Debug Flow BasicCase Study


As an example of analysis with debug, we perform a ping from Station A to Station C in the sample lab layout. We perform the debug operation at the SSG 5 so the ping packet enters on interface eth0/5 and exits on interface eth0/6.

Layer 3 Operations Chapter 537

Configuring Juniper Networks Firewall/IPSec VPN Products

Debug Flow Basic Output: Part 1


The output from the debug utility in the debug buffer shows the following sequence of events: 1. 2. 3. 4. First, the device performs a sanity check, verifying that the packet is an IP packet. The device selects eth0/5 as the incoming interface for NAT options. We will see more on the significance of this step in later chapters. The device performs a route lookup. We routed from the eth0/5 interface to the eth0/6 interface. The device performs a policy search from zone 104 (private) to zone 103 (public). (We must use the get zone command to determine the zone names.) The device finds a matching policy. (Again, to see the exact parameters of the policy, we must use the get policy id number command.)

5.

Chapter 538 Layer 3 Operations

Configuring Juniper Networks Firewall/IPSec VPN Products

Debug Flow Basic Output: Part 2


This list is a continuation from the previous page: 6. 7. 8. The device creates a session for this packet. The device performs an ARP lookup and finds an entry in the ARP cache. The device indicates the address after translation. In this case, no address translation occurred. We later consider other examples that use address translation.

Note that debug output varies from system to system and software version to software version. The key messages appear regardless of version.

Layer 3 Operations Chapter 539

Configuring Juniper Networks Firewall/IPSec VPN Products

Debug Flow BasicExisting Session


For subsequent packets that match the session, the debug output is much more concise. Note that on the ISG-2000 series and the NS-5000 series devices most packets matching established sessions cannot be captured by debug. Debug only captures packets that are handled by the CPU. On these platforms, the majority of established session packets are handled by ASICs, so debug cannot access the information. This debug limitation is not significant; in most cases, you use debug to diagnose session establishment failures. Once the session is established, use get session and other get commands to acquire the information you need.

Chapter 540 Layer 3 Operations

Configuring Juniper Networks Firewall/IPSec VPN Products

No Route to Destination
debug flow basic often provides clear indication of where packet processing failures occur. In the example shown on the slide, the packet is dropped because no route was found in the route table lookup in the trust-vr. If you do not set a default gateway, this error also appears if you try to access the Internet.

Layer 3 Operations Chapter 541

Configuring Juniper Networks Firewall/IPSec VPN Products

Denied by Policy
In the example shown on the slide, the packet is dropped because it was denied by policy. Note that the output indicates that the device searched both a specific policy and a global policy. This output indicates that the packet did not match any particular policy and so was dropped by default. If a policy explicitly denies traffic, the output then shows that either the specific policy or the global policy was responsible for dropping the traffic.

Chapter 542 Layer 3 Operations

Configuring Juniper Networks Firewall/IPSec VPN Products

Loopback Interface
The slide highlights the topic we discuss next.

Layer 3 Operations Chapter 543

Configuring Juniper Networks Firewall/IPSec VPN Products

Loopback Interface
A loopback interface is a logical interface that is up as long as one physical interface is up on the device. Use loopback interfaces whenever an always-on IP address is preferred: for management purposes, for VPN termination (VPNs can stay up even if physical interfaces fail if dynamic routing is available), or for dynamic routing purposes.

Chapter 544 Layer 3 Operations

Configuring Juniper Networks Firewall/IPSec VPN Products

Loopback Interface Configuration


Using the CLI for interface configuration is essentially identical to the configuration of other interfaces. In the WebUI, you create a loopback interface using the pull-down menu in the upper right of the interface list screen. The device automatically assigns the loopback interface number. From there, it is treated as any other interfaceyou configure the zone assignment, IP address, and desired management services. The one distinction is that the loopback interface does not have a separate Manage IP address; because it is not physically reachable, it does not need this address.

Layer 3 Operations Chapter 545

Configuring Juniper Networks Firewall/IPSec VPN Products

Interface-Based NAT
The slide highlights the topic we discuss next.

Chapter 546 Layer 3 Operations

Configuring Juniper Networks Firewall/IPSec VPN Products

Network Address Translation


Private addresses allow for tremendous flexibility in addressing internal networks. However, private addresses are not valid on the Internet. We need a mechanism to dynamically replace private addresses with publicly routable addresses when traffic leaves our private zones and enters the public space. The Juniper Networks device has several address translation options available. We discuss interface-based translation in this chapter. Interface-based translation uses Network Address Port Translation (NAPT), which translates both addresses and upper-layer port numbers. NAPT allows a single public address to be used for multiple private addresses; port mapping keeps each private address and port combination distinct.

Layer 3 Operations Chapter 547

Configuring Juniper Networks Firewall/IPSec VPN Products

Interface-Based NAT
Interface-based NAT is the simplest form of translation to configure on the Juniper Networks firewall, but it has limited functionality. If your configuration uses one virtual router, consider the following parameters: The ingress interface must belong to the Trust or DMZ zones, and you must configure it for NAT mode (this is the default). The egress interface must belong to the Untrust or DMZ zone.

Interface-based NAT does not work between any pairs of zones other than traffic passing from the Trust zone to Untrust zone. If, for example, the ingress interface is in the Trust zone and is set for NAT mode, and the egress interface is in the Public zone, interface-based NAT will not occur. If your configuration uses two virtual routers, consider the following parameters: The ingress interface must belong to a security zone, and you must configure it for NAT mode. The egress interface must belong to another security zone in the untrust-vr.

Therefore, interface-based NAT works between user-defined zones, but only if the egress zone is assigned to the untrust-vr. If your configuration does not match these parameters, you can use one of the policy-based translation options, which we discuss in a later chapter.

Chapter 548 Layer 3 Operations

Configuring Juniper Networks Firewall/IPSec VPN Products

Route Mode
You can configure all interfaces to operate in route mode. The device never translates traffic between route mode interfaces. Full routing is required for all networks. The following three reasons explain why you would place all interfaces in route mode: The firewall is an internal firewall; all addresses are private and do not require translation. All addresses are valid Internet addresses and do not require translation. The network is running applications that are difficult to translate, such as NetBIOS or H.323.

Layer 3 Operations Chapter 549

Configuring Juniper Networks Firewall/IPSec VPN Products

NAT Mode
When an interface is configured in NAT mode, translation takes place only if traffic crosses the right combination of zones and VRs as discussed earlier. When translation occurs, the private source address and port number are replaced in the packet with the outbound public interface address and a dynamically assigned port number. The destination host sends responses to this public address. The Juniper Networks device receives the response and uses the port number to determine which private address/port pair to translate.

Chapter 550 Layer 3 Operations

Configuring Juniper Networks Firewall/IPSec VPN Products

Configuring Interface Modes


Use the commands shown on the slide to place an interface in NAT mode or route mode. By default, interfaces assigned to the Trust and DMZ zones are placed in NAT mode, and interfaces assigned to any other zone are placed in route mode. You can override these defaults using the commands shown on the slide.

Layer 3 Operations Chapter 551

Configuring Juniper Networks Firewall/IPSec VPN Products

Verifying Interface Modes


To verify an interface mode, view the details of the interface configuration, either by examining the configuration window in the WebUI or in Security Manager, or by using the get interface name command in the CLI.

Chapter 552 Layer 3 Operations

Configuring Juniper Networks Firewall/IPSec VPN Products

Verifying NAT Behavior


Use the get session command to verify NAT. Note that in the first example on the slide, both flows in the session use the same addresses in both directions. This packet is a routed packet; no translation takes place.

Using Translation
In the second example on the slide, both flows are identified as part of the same session, but the source and session originator address is different in each direction. This difference indicates that translation is taking place for this session.

Layer 3 Operations Chapter 553

Configuring Juniper Networks Firewall/IPSec VPN Products

Interface-Based NAT Direction Dependencies


Interface-based NAT only works for sessions originating from the trusted network. Sessions initiated from the untrusted network are not translated, and these sessions require either routing to be configured to reach the private address or some form of policy-based translation that defines a public address and maps it to the private address. Policy-based NAT solves this problem.

Chapter 554 Layer 3 Operations

Configuring Juniper Networks Firewall/IPSec VPN Products

This Chapter Discussed:


The need for routing on the Juniper Networks firewall; Configuring static routes; The function of a VR; The uses of loopback interfaces; Configuring a loopback interface; The difference between NAT and route interface modes; Configuring interfaces for NAT or route mode; and Verifying operation.

Layer 3 Operations Chapter 555

Configuring Juniper Networks Firewall/IPSec VPN Products

Review Questions
1. 2. 3. 4.

Chapter 556 Layer 3 Operations

Configuring Juniper Networks Firewall/IPSec VPN Products

Lab 3: Layer 3 Operations


The slide lists the objectives for this lab.

Layer 3 Operations Chapter 557

Configuring Juniper Networks Firewall/IPSec VPN Products

Chapter 558 Layer 3 Operations

Configuring Juniper Networks Firewall/IPSec VPN Products


Chapter 6: Basic Policy Configuration

Configuring Juniper Networks Firewall/IPSec VPN Products

This Chapter Discusses:


The purpose of a security policy; The configuration elements required for policy creation; Creating address book entries and address groups; Creating custom service entries and service groups; Creating security policy entries; Potential problems associated with policy creation; Configuring global policy rules; and Verifying policies.

Chapter 62 Basic Policy Configuration

Configuring Juniper Networks Firewall/IPSec VPN Products

Functionality
This slide lists the topics we cover in this chapter. We discuss the highlighted topic first.

Basic Policy Configuration Chapter 63

Configuring Juniper Networks Firewall/IPSec VPN Products

Security Policy Functionality


In ScreenOS software, a policy is a single statement that controls traffic from a specified source to a specified destination using a specified service. If a packet arrives that matches those specifications, the firewall/VPN device performs the action specified in the policy.

Chapter 64 Basic Policy Configuration

Configuring Juniper Networks Firewall/IPSec VPN Products

Security Zones and Policies


We mentioned the need for policies when traffic is sent between different zones, but we avoided going into detail on the subject. Security policies apply only to traffic that crosses zones. In the example shown on the left side of the slide, a flow from Host A to Host B does not invoke a policy; although the traffic is crossing the firewall, it is staying within the Private zone. You can modify this behavior to check intrazone traffic; however, a session initiated by Host B to Host D is subject to the policy set associated with traffic coming from zone Private and going to zone External. Policy sets are unidirectional. If Host D tries to initiate a session with Host B, the firewall examines the policies defined for traffic coming from zone External and going to zone Private. This policy set is different from the policy set examined if Host B initiates a session to Host D.

Basic Policy Configuration Chapter 65

Configuring Juniper Networks Firewall/IPSec VPN Products

Policy Components
Once you complete your zone and interface configuration, you can begin creating your security policies. As stated earlier, you associate policies with a pair of zones and a traffic direction. This policy set consists of one or more individual policy statements (sometimes called rules or simply policies). Each statement includes a source address, destination address, service (which defines Layer 47 information), and action. We cover additional options for each policy statement in the next chapter.

Chapter 66 Basic Policy Configuration

Configuring Juniper Networks Firewall/IPSec VPN Products

Policy Configuration
The slide highlights the topic we discuss next.

Basic Policy Configuration Chapter 67

Configuring Juniper Networks Firewall/IPSec VPN Products

Policy Configuration Procedure


Configuring policies on a Juniper Networks firewall consists of four basic steps, listed on the slide. We break down the tasks in each step on the following slides.

Chapter 68 Basic Policy Configuration

Configuring Juniper Networks Firewall/IPSec VPN Products

Step 1: Creating Address Book Entries


The first step in configuring a policy is to create entries in your address book. Each zone has an associated list of addressesindividual hosts, subnets, or both. When you create your address book entries, remember to account for all hosts within a zone, not just the directly connected subnets. What actual entries you define depends entirely on your security requirements: Do you have individual hosts that have special access requirements? Do all users on a subnet have the same access? Can you group subnets together in a supernetted address book entry?

Basic Policy Configuration Chapter 69

Configuring Juniper Networks Firewall/IPSec VPN Products

Step 1: Creating Address Book EntriesCLI


The slide shows the CLI commands you use to display and create address book entries. You must have DNS configured on the ScreenOS device for DNS entries to work in address book entries.

Chapter 610 Basic Policy Configuration

Configuring Juniper Networks Firewall/IPSec VPN Products

Step 1: Creating Address Book EntriesWebUI: Part 1


Address book entries are organized on a per-zone basis. To view the list of existing address book entries, click through the WebUI navigation on the left of the screen as follows: Objects > Addresses > List. Then select the zone you want to view using the pull-down list circled on the slide. When you configure an address book entry, you assign it a name. You can display a subset of entries alphabetically by name using the alpha-numeric links at the top of the screen. The screen capture on the slide shows the two default address book entries that exist in every zone: Any, which includes all addresses, and Dial-Up VPN, which is only used for point-to-point, dial-up connections. To add a new entry to the address book, click the New button in the upper right of the screen.

Basic Policy Configuration Chapter 611

Configuring Juniper Networks Firewall/IPSec VPN Products

Step 1: Creating Address Book EntriesWebUI: Part 2


After clicking New, the screen shown on the slide appears. Enter the following parameters: Address Name: This is the name displayed in both the address list and the policy list. You can use the address and mask combination for this particular address book entry as the name, although you can use other naming conventionslocation names, workgroup names, and so onas long as the name has meaning to your network and you deploy it consistently. Comment: This is an optional field that gives you an opportunity to add inline documentation to your configuration. IP Address/Domain Name: This is the actual address book entry. In this example we define a specific host entry, as indicated by the 32-bit mask. Another option is to enter a domain name and use DNS to resolve the address. Note that if DNS resolves multiple addresses, the ScreenOS software adds all addresses to the address book entry. Most other Juniper Networks functions that use name resolution, such as ping and syslog, only use the first address returned. Zone: This specifies the zone in which this particular address is found.

Chapter 612 Basic Policy Configuration

Configuring Juniper Networks Firewall/IPSec VPN Products

Step 1: Creating Address Book EntriesSecurity Manager


You can add global address objects using this window.

Basic Policy Configuration Chapter 613

Configuring Juniper Networks Firewall/IPSec VPN Products

Step 2: Defining Services


The second step in policy creation is to define any custom services required for your network. A service definition consists of the protocol and port numbers associated with a particular application or protocol stack (for example, NetBIOS).

Chapter 614 Basic Policy Configuration

Configuring Juniper Networks Firewall/IPSec VPN Products

Step 2: Predefined Services


Juniper Networks firewalls have a number of predefined services that are based on well-known ports and common applications. Before configuring a custom service, check this list to see if your service is already defined. To view the list of existing service entries, click through the WebUI navigation on the left of the screen as follows: Objects > Services > Predefined. Then scroll through the list. You can move the cursor over an icon to see more information, such as a brief description of the service, the transport protocol, and the port number. The CLI command displays the details of the defined services if you include a service name. Without a name, a list of defined services similar to the WebUI output is displayed. Although you can modify these existing service entries, we recommend that you do not do so and that you instead create custom services where needed.

Basic Policy Configuration Chapter 615

Configuring Juniper Networks Firewall/IPSec VPN Products

Step 2: Creating a Custom Service


If your network is using a custom application, or if you changed applications to ports other than well-known ports, you can create a new service so that the firewall can identify your unique traffic. To create a custom entry, click through the WebUI navigation on the left of the screen as follows: Objects > Services > Custom > Edit. Then enter the following parameters: Service Name: This is the name of the service. This name is displayed in the policy list. Therefore, we recommend a descriptive name. Service Timeout: This allows you to specify a timeout value for an inactive session, never time out a session, or allow the end-to-end protocol to determine when the session times out. Transport protocol: The options displayed vary depending on the version of ScreenOS software running on your firewall. Later versions allow you to select TCP, UDP, ICMP, or other. Ports: These fields allow you to specify either a specific port or range of ports allowed for this application.

You can include multiple protocols in a single service definition. For example, the FTP service definition includes both FTP control (port 21) and FTP data (port 20).

Chapter 616 Basic Policy Configuration

Configuring Juniper Networks Firewall/IPSec VPN Products

Step 3: Creating Policy EntriesCLI


After defining your address book entries and services, you can create policy entries for your zones. Configuration using the CLI requires the same parameters, but the address book entries and service entries are not readily accessible. You must remember the address book names when creating the policies.

Basic Policy Configuration Chapter 617

Configuring Juniper Networks Firewall/IPSec VPN Products

Step 3: Creating Policy EntriesWebUI: Part 1


After defining your address book entries and services, you can create policy entries for your zones. To create a new policy, select the From and To zones from the pull-down lists at the top of the policy screen shown on the slide, then click New. Clicking Go displays a list of current policies between the From and To zones.

Chapter 618 Basic Policy Configuration

Configuring Juniper Networks Firewall/IPSec VPN Products

Step 3: Creating Policy EntriesWebUI: Part 2


For basic policy configuration, we are concerned with addresses, services, and the action selected for the particular combination of address and service. Use the pull-down bars to select the appropriate entries from your address book, service list, and action for this policy statement. Keep in mind that the pull-down menus display the names of your address book and service entries. (This duplication is one reason why a good naming convention is so important.) Once you finish these selections, click OK to add the entry to your policy set. In the example on the slide, the source address pull-down list only displays addresses and address groups defined in the private zone, including the preconfigured parameters Any and Dial-Up VPN. Likewise, the destination address pull-down list only displays addresses defined in the public zone. This display is determined by the zone combination selected before opening the policy statement configuration window. The list of services includes all defined services and service groups, including predefined and custom. One of the predefined options is Any. Actions: Permit allows traffic to flow. Deny drops the packet. Reject drops the packet and sends an unreachable message to the originating host. Tunnel is used for VPNs, which we discuss later. We also discuss the other displayed options later in the course.

Basic Policy Configuration Chapter 619

Configuring Juniper Networks Firewall/IPSec VPN Products

Step 3: Creating Policy EntriesSecurity Manager


The slide shows the process for creating a policy using Security Manager. We discuss this process in the Security Manager Fundamentals course. Therefore, what follows is simply a review of the process. Remember that a policy is a group of rules in Security Manager.

Chapter 620 Basic Policy Configuration

Configuring Juniper Networks Firewall/IPSec VPN Products

Step 4: Policy Ordering


The final step in policy configuration is placing your policy entries in the correct order for your network. Policy statements are processed in a top-down fashion. If a statement matches the packet being evaluated, the ScreenOS device executes the policy action and searches no more policy lines. If the device finds no matches, it denies the traffic by default. If your policy list consists exclusively of deny statements, no traffic is allowed by your policy; you must have a permit statement somewhere in the list. When you add new policy entries, the ScreenOS device adds them to the new policy entries at the end of the policy listwhich is probably not the proper location. A good rule to follow when configuring policies is to place the most specific entries at the top of the list and the more general entries at the bottom of the list. For example, place host-specific entries before subnets.

Basic Policy Configuration Chapter 621

Configuring Juniper Networks Firewall/IPSec VPN Products

Step 4: Reordering PoliciesCLI


The graphic on the slide shows an example of using the CLI to reorder policies.

Chapter 622 Basic Policy Configuration

Configuring Juniper Networks Firewall/IPSec VPN Products

Step 4: Reordering PoliciesWebUI: Part 1


Using the WebUI, you have two options for sorting your policiesthe move button or the move arrow. Using the move button allows you to specify a policy ID to insert the new policy above. The move arrow gives you a graphic display.

Basic Policy Configuration Chapter 623

Configuring Juniper Networks Firewall/IPSec VPN Products

Step 4: Reordering PoliciesWebUI: Part 2


Using the move button requires that you know the policy ID number. Policy ID numbers are assigned during policy configuration and do not reflect the precedence of a particular policy entry. Clicking the move arrow for a particular policy entry brings up the display shown on the slide. Click the arrow in the location where you want the policy statement to move.

Chapter 624 Basic Policy Configuration

Configuring Juniper Networks Firewall/IPSec VPN Products

Step 4: Reordering RulesSecurity Manager


The title on the slide is correct; when using Security Manager, you reorder rulesnot policies.

Basic Policy Configuration Chapter 625

Configuring Juniper Networks Firewall/IPSec VPN Products

Configuration Options
In large networks with complex security requirements, you might encounter this situation: you have ten network managers on five different subnets who must access three different data collection systems. You can create separate policy entries for each combination of network manager and data collection systemor you can use policy options to group the network manager and server entries, creating a single policy statement that includes all addresses. Using groups not only makes administration easier, it also more efficiently allocates system resources. If not using groups, the configuration we described allocates memory for 30 policies (10 administrators x 3 servers = 30 policy entries). Grouped policy statements require fewer system resources.

Chapter 626 Basic Policy Configuration

Configuring Juniper Networks Firewall/IPSec VPN Products

Address Groups
The address group option allows you to group existing address book entries into a single entry that you can then add to a policy. 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. For example, if you use the name Paris for an individual address entry, you cannot also use it for a group name. If you reference an address group in an access policy, you cannot remove the group. You can edit the group, however. You cannot add the following predefined addresses to groups: Any, All Virtual IPs, and Dial-Up VPN.

Basic Policy Configuration Chapter 627

Configuring Juniper Networks Firewall/IPSec VPN Products

Creating Address GroupsCLI


The slide shows the CLI commands for creating address groups.

Chapter 628 Basic Policy Configuration

Configuring Juniper Networks Firewall/IPSec VPN Products

Creating Address GroupsWebUI


The WebUI uses a standard add and subtract window for creating groups. The available members depend on the zone with which the address group is associated.

Basic Policy Configuration Chapter 629

Configuring Juniper Networks Firewall/IPSec VPN Products

Creating Address GroupsSecurity Manager


Adding address groups is very easy using Security Manager. You simply add all the hosts and networks that you will be using for your security policy rules.

Chapter 630 Basic Policy Configuration

Configuring Juniper Networks Firewall/IPSec VPN Products

Viewing Address Groups


You can view your address groups on a per-zone basis using the WebUI. The CLI output separates address groups by zone.

Basic Policy Configuration Chapter 631

Configuring Juniper Networks Firewall/IPSec VPN Products

Creating a Service Group


Just as we grouped address book entries into an address group, we can group services into a service group. You can add both predefined and custom services to groups. Grouping services provides the same advantages as grouping addresses: ease of administration and better utilization of system resources. Service groups are subject to the following limitations: Service groups cannot have the same names as services. For example, if you have a service named FTP, you cannot have a service group named FTP. If you reference a service group in an access policy, you can edit the group, but you cannot remove it until you remove the reference to it in the policy. If you delete a custom service book entry from the service book, the ScreenOS software also removes the entry from all the groups in which it is referenced. You cannot add the static service ANY to groups.

Chapter 632 Basic Policy Configuration

Configuring Juniper Networks Firewall/IPSec VPN Products

Viewing Service Groups


You can view a summary of your service groups using the commands or links shown in the graphic on the slide.

Basic Policy Configuration Chapter 633

Configuring Juniper Networks Firewall/IPSec VPN Products

Multicell Policies
The multicell policies option allows you to have multiple address book entries, service book entries, or both selected in an individual policy statement. Each entry appears as a separate listing within the policy display.

Chapter 634 Basic Policy Configuration

Configuring Juniper Networks Firewall/IPSec VPN Products

Multicell Policy CreationCLI


Using the CLI, you first create a basic policy entry using one of the addresses or services you want to add. Once the policy exists, you can enter a configuration sub-mode by using the set policy id command. Note the prompt change in the screen output shown on the slide. In this sub-mode, you can add multiple addresses or services by using the set commands. Other policy options are also available in this sub-mode. When finished, type exit to return to the main CLI mode.

Basic Policy Configuration Chapter 635

Configuring Juniper Networks Firewall/IPSec VPN Products

Multicell Policy CreationWebUI: Part 1


In the WebUI, the address book and service options include a Multiple button. Clicking this button brings up a display similar to the group creation display; before you click the button, however, you must select a specific address book or service. If you leave the window at the default of Any, an error message appears saying that any cannot be combined with other entries. After clicking the Multiple button, an add/subtract window is displayed. Entries on the right are available entries; entries on the left are added to the policy when you click OK. Although this process looks similar to building groups, the end result is different; instead of displaying a single group name in the policy, the process displays the individual entry names.

Chapter 636 Basic Policy Configuration

Configuring Juniper Networks Firewall/IPSec VPN Products

Multicell Policy CreationWebUI: Part 2


Multicell policies not only allow you to group addresses in the typical manner; you can also create a group of addresses to exclude from the policy rule. By building a list of addresses and then clicking the Negate the Following box, you instruct the Juniper Networks device to apply the policy to all addresses except the policy listed in the cell.

Basic Policy Configuration Chapter 637

Configuring Juniper Networks Firewall/IPSec VPN Products

Multicell Rule CreationSecurity Manager


Note again that in Security Manager, this is rule creation, not policy creation. Remember that Security Manager has one policy containing multiple rules.

Chapter 638 Basic Policy Configuration

Configuring Juniper Networks Firewall/IPSec VPN Products

Viewing Multicell Policies


With multicell policies, individual entry names appear in the policy display in both the WebUI and the CLI.

Basic Policy Configuration Chapter 639

Configuring Juniper Networks Firewall/IPSec VPN Products

Modifying Multicell Policies


In the CLI, once you enter the policy, you can remove individual entries using the unset command. Be careful; using the unset policy command in main mode removes the policy entirely.

Chapter 640 Basic Policy Configuration

Configuring Juniper Networks Firewall/IPSec VPN Products

Common Problems
The slide highlights the topic we discuss next.

Basic Policy Configuration Chapter 641

Configuring Juniper Networks Firewall/IPSec VPN Products

Common Problems
The most common problem with policy configuration is incorrect ordering, so completing Step 4 in policy creation (reordering policy entries) is essential. If you do not perform this step at the time of policy creation, you can perform it at a later time using the procedures we just described. Two other common configuration problems relate to the use of names in policy creation. We discuss these problems on the following slides.

Chapter 642 Basic Policy Configuration

Configuring Juniper Networks Firewall/IPSec VPN Products

Names Not Equaling Address


When trying to troubleshoot policy issues, you must remember that in both Security Manager (top of slide) and the WebUI (bottom of slide), names are displayed in the policy displays, both in existing policies and in the policy configuration window. Compare the name of the address book entry on the slide with the address entry itself. The masks are not the same. Does this cause a problem? It depends on your policy configuration, of course, but in general, if your intention is to allow traffic from a specific host and not from the subnet, your policy will not function the way you intend. You cannot modify an address book entry if it is being used by a policy.

Basic Policy Configuration Chapter 643

Configuring Juniper Networks Firewall/IPSec VPN Products

Group Membership
Using address and service groups can also introduce confusion when troubleshooting policies. The group names Security Managers and Allowed Services are only helpful if you know what addresses and services they contain. Troubleshooting might involve checking the actual group memberships to ensure that the correct hosts and services are included. Multicell policies avoid the latter problem by displaying individual entries in the window. You still have the names problem, however, as the entries display address book names.

Chapter 644 Basic Policy Configuration

Configuring Juniper Networks Firewall/IPSec VPN Products

Modifying or Removing Policies, Addresses, and Services


If you must modify a policy entry, an address entry or group, or a service entry or group, you can do so at any time. Use the edit option in the WebUI, or reset the set command in the CLI. Removing an entry is more complicated. If an address entry, a group or service entry, or a group is in use by a policy, you do not have the option to remove it until you first modify or remove the policy entry referring to it.

Basic Policy Configuration Chapter 645

Configuring Juniper Networks Firewall/IPSec VPN Products

Disabling a Policy
A useful option when troubleshooting policies is the ability to manually disable a policy entry. The policy is still defined in memory, but it is no longer included in the policy evaluation. This feature is useful when troubleshooting ordering problems. If disabling a policy entry has no effect on traffic passing through the firewall, the policy entry is not effective when enabled and must either be moved or redefined.

Chapter 646 Basic Policy Configuration

Configuring Juniper Networks Firewall/IPSec VPN Products

Global Policy
The slide highlights the topic we discuss next.

Basic Policy Configuration Chapter 647

Configuring Juniper Networks Firewall/IPSec VPN Products

Global Zone
You can use the global zone to create default policies. If you have traffic that you always want to permitwhether it is from specific sources, to specific destinations, or to specific servicesyou can create a global policy to allow it The policy checking process first checks for a policy match in the zones determined by the routing lookup. If no match is found, the global zone is checked. If the ScreenOS software finds no match in the global zone, it takes the default action. The normal setting for the default is to deny traffic. You can set the system to default to permitting traffic, but we do not recommend this setting.

Chapter 648 Basic Policy Configuration

Configuring Juniper Networks Firewall/IPSec VPN Products

Global Policy
We mentioned earlier that a global policy is searched if the ScreenOS software finds no specific zone-to-zone policy definition. The following information further explains the global zone: The get policy global command shows all the set global policies. The default setting is to deny all traffic, as shown on the slide. Next, we defined a global policy. The policy still denies all traffic; the only change is that we made a log entry for the action. (This is a convenient way to log all denys of traffic without having to make an entry in each policy.) When we view the global policy now, we see a policy ID 6 showing the details, including the logging. The debug output shows a ping packet routed from eth1 to eth7. A policy search from zone 1000 to zone 1002 (private to public) finds no policy. ScreenOS software searches the global policy next and drops the packet because of policy ID 6. The packet is logged.

Basic Policy Configuration Chapter 649

Configuring Juniper Networks Firewall/IPSec VPN Products

Verifying Policies
The slide highlights the topic we discuss next.

Chapter 650 Basic Policy Configuration

Configuring Juniper Networks Firewall/IPSec VPN Products

Verifying Policies
We now verify policies using the CLI get commands. Also, we review the debug flow basic learned in the last chapter. The CLI get session command allows you to view the active sessions in the ScreenOS device.

Basic Policy Configuration Chapter 651

Configuring Juniper Networks Firewall/IPSec VPN Products

Zone and Policy Troubleshooting


To begin a discussion of troubleshooting zone issues, we review the initial configuration. All the predefined zones are in the trust-vr (except Null). The system-defined zones have ID numbers that start at zero. Consider two other points regarding the configuration: 1. The Private zone has ID number 1000, the External zone has ID number 1001, and the Public zone has ID number 1002. These ID numbers are useful when using the debug utility. Currently, only two policies are definedpolicy ID 3 (from external to private), and policy ID 4 (from private to public). Again, the ID numbers are useful because the debug utility uses zone ID numbers and not zone ID names.

2.

Chapter 652 Basic Policy Configuration

Configuring Juniper Networks Firewall/IPSec VPN Products

Debug Procedure Review


Consider the following sequence of events for effective use of the debug utility: 1. Enable the debug utility for the desired option. You can enable multiple options but doing so might produce output that is difficult to analyze. In most circumstances it is better to use one option at a time. Clear the debug buffer. The debug buffer displays the oldest information first. Clearing the debug buffer avoids having to search through old output. Issue the ping command (or whatever command is being used to generate traffic). The result is captured in the debug buffer. Disable debug to terminate output going to the debug buffer. Use get dbuf stream to analyze the output form the debug utility. Check to see if the problem is resolved. If it is, use the unset ffilter command. If it is not resolved, go back to Step 2 and start the debug process.

2.

3. 4. 5. 6.

Basic Policy Configuration Chapter 653

Configuring Juniper Networks Firewall/IPSec VPN Products

No Policy Configured
Any time network traffic flows from one security zone to another, a policy is required. If no policy is present from zone to zone, look for a global policy, which serves as a default policy for the system.

Chapter 654 Basic Policy Configuration

Configuring Juniper Networks Firewall/IPSec VPN Products

Intrazone Block
If two (or more) interfaces are in the same zone, no policy is required for packets to travel between these interfaces. However, you can force policy checking to occur. This scenario is illustrated in the following sequence: Intrazone block was enabled for the zone Private. Thus, a policy must be present in packets that go between interfaces in this zone (eth1 and eth2). A packet comes in on eth1. The packet is routed to eth2. Because intrazone block is enabled, ScreenOS software performs a policy search. First, a policy from zone 1000 to zone 1000 (private to private) occurs. Next, a search for a global policy is performed. Because no match exists in the global policy, the packet is dropped due to intrazone block.

The solution to this problem is to configure an exception policy for the zone in question, or to disable intrazone blocking if all traffic should be allowed.

Basic Policy Configuration Chapter 655

Configuring Juniper Networks Firewall/IPSec VPN Products

This Chapter Discussed:


The purpose of a security policy; The configuration elements required for policy creation; Creating address book entries and address groups; Creating custom service entries and service groups; Creating security policy entries; Potential problems associated with policy creation; Configuring global policy rules; and Verifying policies.

Chapter 656 Basic Policy Configuration

Configuring Juniper Networks Firewall/IPSec VPN Products

Review Questions
1. 2. 3.

Basic Policy Configuration Chapter 657

Configuring Juniper Networks Firewall/IPSec VPN Products

Lab 4: Basic Policy Configuration


The slide shows the objective for this lab.

Chapter 658 Basic Policy Configuration

Configuring Juniper Networks Firewall/IPSec VPN Products


Chapter 7: Policy Options

Configuring Juniper Networks Firewall/IPSec VPN Products

This Chapter Discusses:


Configuring policy options; and Verifying the operations of policy options.

Chapter 72 Policy Options

Configuring Juniper Networks Firewall/IPSec VPN Products

Overview
This slide lists the topics we cover in this chapter. We discuss the highlighted topic first.

Policy Options Chapter 73

Configuring Juniper Networks Firewall/IPSec VPN Products

Policy OptionsMain Screen WebUI


There are many more boxes and buttons on the graphic shown on this slide than we discussed in the basic policy chapter. We cover all these features in the next few chapters of the course. The Application pull-down menu, URL filtering checkbox, Deep Inspection button, and AntiVirus windows are all covered in another course on attack prevention. We discuss tunnel-related settings in the VPN chapters. We cover logging later in this chapter.

Chapter 74 Policy Options

Configuring Juniper Networks Firewall/IPSec VPN Products

Advanced Policy OptionsWebUI: Part 1


The screen capture on the slide shows the Advanced Policy Settings window, accessible using the Advanced button in the main policy editing window. This graphic shows the top half of the screen. We discuss policy-based translation in Chapter 8, which covers address translation, and we cover authentication in this chapter.

Policy Options Chapter 75

Configuring Juniper Networks Firewall/IPSec VPN Products

Advanced Policy OptionsWebUI: Part 2


The bottom half of the screen shows several more options: Counting: Keeps packet counters for this particular policy statement. Alarm Threshold: Counters exceeding configured thresholds send an alarm to the management station.

Schedule: Allows policy to be automatically enabled or disabled based on a configured schedule. Traffic Shaping: Allows you to reserve bandwidth on a per-policy basis.

Chapter 76 Policy Options

Configuring Juniper Networks Firewall/IPSec VPN Products

Advanced Policy OptionsSecurity Manager: Part 1


There are two ways to access advanced policy options: Right-click in the rule options window to view a drop-down box and select a specific advanced policy option; or Configure all advanced policy options at once.

Policy Options Chapter 77

Configuring Juniper Networks Firewall/IPSec VPN Products

Advanced Policy OptionsSecurity Manager: Part 2


As shown on the slide, several advanced policy options spread out over many windows. These windows are just a few of the advanced policy options windows.

Chapter 78 Policy Options

Configuring Juniper Networks Firewall/IPSec VPN Products

Logging
The slide highlights the topic we discuss next.

Policy Options Chapter 79

Configuring Juniper Networks Firewall/IPSec VPN Products

Traffic Logs
The traffic log shows the time a connection is closed. This log also shows pertinent packet information for each session. You can troubleshoot translation by using traffic logs that check for successful session translation. You can also use traffic logs to verify a policy in general. For example, ask if this policy is logging any sessions. If not, the policy is not matching any traffic. Note that the ScreenOS software only adds log entries after the session closes or times out. To see active sessions, use the get session command on the CLI. Also note that a Juniper Networks device only stores 4096 log entries. For long-term logging, it is better to use syslog.

Chapter 710 Policy Options

Configuring Juniper Networks Firewall/IPSec VPN Products

Configuring Traffic Logs: Part 1


In the CLI, you can add logging during initial policy creation by typing the keyword log at the end of the policy statement. As shown on the slide, to modify an existing policy, go into policy edit mode by entering the number of the policy. Then, add logging.

Policy Options Chapter 711

Configuring Juniper Networks Firewall/IPSec VPN Products

Configuring Traffic Logs: Part 2


Adding logging to your policy is as simple as clicking a check box in the WebUI and Security Manager.

Chapter 712 Policy Options

Configuring Juniper Networks Firewall/IPSec VPN Products

Verifying and Accessing Logging


You can verify that logging is enabled by looking for the log icon in the policy list. Click the icon in either the policy list or the reports window to bring up the log window shown on slide 7-11. In the CLI, the table shown on the right side of the of the get policy command output indicates whether logging is enabled for this policy. An X in the L column indicates that logging is enabled. To display the log, use the get log traffic command.

Policy Options Chapter 713

Configuring Juniper Networks Firewall/IPSec VPN Products

Counting
The slide highlights the topic we discuss next.

Chapter 714 Policy Options

Configuring Juniper Networks Firewall/IPSec VPN Products

Traffic Counters
Traffic counters display a graphical view of traffic that matches the policy. The X-axis of the graph represents time, and the Y-axis represents the number of bytes. You can modify the X-axis to display in seconds, minutes, hours, days, or months. You can also add alarms to counters by setting traffic thresholds in bytes per second and kilobytes per minute. Traffic exceeding these thresholds causes an alarm to be entered into the system log. Use the CLI to access raw counter data.

Policy Options Chapter 715

Configuring Juniper Networks Firewall/IPSec VPN Products

Configuring Traffic Counters


The processes for adding traffic counters and for enabling logging are similar. The CLI command used to add traffic counters is also similar to the command used to enable logging.

Chapter 716 Policy Options

Configuring Juniper Networks Firewall/IPSec VPN Products

Configuring Traffic Counters


Enabling traffic counters is as easy as clicking a check box. If you want to include the traffic counter alarm feature, set the thresholds. The Valid for Serial option extends thresholds to non-Ethernet interfaces. This option is enabled by default.

Policy Options Chapter 717

Configuring Juniper Networks Firewall/IPSec VPN Products

Verifying and Accessing Traffic Counters


To access the counter window, click the hourglass icon in the Policies window or in the Reports window. In the CLI, the table on the right side of the get policy command output indicates whether logging is enabled for this policy. An X in the C column indicates that logging is enabled. Use the CLI to access raw counter data.

Chapter 718 Policy Options

Configuring Juniper Networks Firewall/IPSec VPN Products

Scheduling
The slide highlights the topic we discuss next.

Policy Options Chapter 719

Configuring Juniper Networks Firewall/IPSec VPN Products

Policy Scheduling
You can use schedules to automatically enable and disable individual policy statements based on the time of day. Schedules are separate objects you apply to policies, and they can be either recurring or one-time events. Because schedules rely on clock settings, we recommend that you use the Network Time Protocol (NTP) to provide an accurate clock feed.

Chapter 720 Policy Options

Configuring Juniper Networks Firewall/IPSec VPN Products

Configuring Policy Scheduling


Because the schedule is a separate object, you must define it first before applying it to a policy.

Policy Options Chapter 721

Configuring Juniper Networks Firewall/IPSec VPN Products

Creating a ScheduleCLI
CLI schedule configuration is straightforward. When you create a recurring schedule, make sure you enter the same name for each day of the week.

Chapter 722 Policy Options

Configuring Juniper Networks Firewall/IPSec VPN Products

Creating a ScheduleWebUI
In the WebUI, a recurring schedule has two periods per day when the policy can be active. If you only want a single period per day, simply leave the second period blank. The schedule name you enter here is displayed in the list of schedules when you configure the policy.

Policy Options Chapter 723

Configuring Juniper Networks Firewall/IPSec VPN Products

Creating a ScheduleSecurity Manager


A recurring schedule has two periods per day when the policy can be active. If you only want a single period per day, simply leave the second set of start and stop windows blank. The schedule name you enter here is displayed in the list of schedules when you configure the policy.

Chapter 724 Policy Options

Configuring Juniper Networks Firewall/IPSec VPN Products

Applying a Schedule to a Policy


To apply the schedule using the WebUI or Security Manager, select the schedule name from the pull-down menu. The schedule name appears after you configure a schedule. Using the CLI, you must first type out the entire policy statement, then add the keyword schedule, followed by the schedule name. The ability to set the schedule is currently not available in policy editing mode.

Policy Options Chapter 725

Configuring Juniper Networks Firewall/IPSec VPN Products

Verifying Scheduling
If a policy is configured with a schedule, the policy line has a gray background in the policy list. If the policy is grayed out, this policy is outside the schedule window. If the policy is not grayed out, the policy is within the schedule window.

Chapter 726 Policy Options

Configuring Juniper Networks Firewall/IPSec VPN Products

User Authentication
The slide highlights the topic we discuss next.

Policy Options Chapter 727

Configuring Juniper Networks Firewall/IPSec VPN Products

User Authentication
You can configure user authentication on the Juniper Networks device in conjunction with a policy. Even though traffic matches a policy, it does not pass through the firewall until the user is authenticated. Policy authentication is another layer of protection in the network. For example, one of your employees leaves for the day but forgets to log off the system. This computer and all it can access are now available to anyone walking by. However, if no active firewall sessions are present, the evil user must still enter a username and password before the traffic can pass through the firewall. Note the statement active firewall sessions. A users authentication is good for as long as a session remains active on the Juniper Networks device plus 10 minutes. You can change this setting with the following command: set auth-server local timeout minutes

Chapter 728 Policy Options

Configuring Juniper Networks Firewall/IPSec VPN Products

Firewall Authentication
Think of firewall authentication as inline authentication. A user must generate either a Web session, a Telnet session, or an FTP session that matches the authentication policy. The user is then prompted for the username and password. Once authenticated, any traffic the policy permits is allowed through. If the user forgets to authenticate, no traffic is permitted, even traffic that matches the policy. For example, your authentication policy permits ping. An unauthenticated user tries to ping, and even though the addresses and service match, authentication has not occurred; therefore, the firewall drops the traffic. The user then opens a Web browser session through the firewall, authenticates, and tries to ping again. This time the ping is permitted.

Policy Options Chapter 729

Configuring Juniper Networks Firewall/IPSec VPN Products

WebAuth Authentication
WebAuth is another authentication option that requires your users to actively browse to a specific IP address before their traffic is passed. This IP address is an address on the Juniper Networks device specifically used for authentication purposes. As with firewall authentication, once the user is authenticated using WebAuth, any traffic matching the policy is permitted.

Chapter 730 Policy Options

Configuring Juniper Networks Firewall/IPSec VPN Products

What the User Sees


From the user's perspective, the username and password prompt is a familiar dialogue. Note that if the FTP server or Telnet target also requires a username and password, the user is prompted again for a name and password; the Juniper Networks device does not relay authentication information.

Policy Options Chapter 731

Configuring Juniper Networks Firewall/IPSec VPN Products

Authentication Configuration Steps


We cover authentication configuration steps in detail on the next few slides.

Chapter 732 Policy Options

Configuring Juniper Networks Firewall/IPSec VPN Products

Step 1: Creating a User Database


Note that creating a user database assumes that you will define it on the Juniper Networks device. You can use RADIUS, LDAP, or SecurID instead of a local database; however, configuring an external authentication server is beyond the scope of this course.

Policy Options Chapter 733

Configuring Juniper Networks Firewall/IPSec VPN Products

Step 1: Creating a User DatabaseWebUI


To create a user database using WebUI, simply add local users on the device. Try not to forget the passwords assigned to users.

Chapter 734 Policy Options

Configuring Juniper Networks Firewall/IPSec VPN Products

Step 1: Creating a User DatabaseSecurity Manager


To create a user database using Security Manager, add a new local user on the device that you are managing.

Policy Options Chapter 735

Configuring Juniper Networks Firewall/IPSec VPN Products

Step 2: Configuring an Authentication Policy


The CLI commands used to enable authentication policy are straightforward.

Chapter 736 Policy Options

Configuring Juniper Networks Firewall/IPSec VPN Products

Step 2: Configuring an Authentication PolicyWebUI and Security Manager


If you are using firewall authentication, select the Auth Server radio button. The default setting is to use the local user database. Using external databases requires configuring server objects, which is covered in detail in other courses. If you are using WebAuth, select the WebAuth radio button. Note that the word Local appears in parenthesis; this word indicates that the local database is being used for WebAuth. Configuring WebAuth to use an external server is performed on a different screen. To configure firewall authentication when using Security Manager, you must make a configuration change on the security policy rule. Right-click the security policy rule options section and select Authentication. Now you can choose Web Authentication for this rule.

Policy Options Chapter 737

Configuring Juniper Networks Firewall/IPSec VPN Products

Step 3: Configuring a WebAuth Address


The CLI requires two commands: one command to enable WebAuth, and one command to set the IP address.

Chapter 738 Policy Options

Configuring Juniper Networks Firewall/IPSec VPN Products

Step 3: Configuring a WebAuth AddressWebUI and Security Manager


The WebAuth address is set on the interface(s) in the source zone as determined by the policy. The WebAuth address must be on the same subnet as the interface address.

Policy Options Chapter 739

Configuring Juniper Networks Firewall/IPSec VPN Products

Verifying Authentication
A policy that includes authentication displays a user icon in the WebUI policy list or an X in the A column on the CLI. You can see who is currently logged in with the get user all command, and you can view login statistics with the get auth table command.

Chapter 740 Policy Options

Configuring Juniper Networks Firewall/IPSec VPN Products

This Chapter Discussed:


Configuring policy options; and Verifying the operations of policy options.

Policy Options Chapter 741

Configuring Juniper Networks Firewall/IPSec VPN Products

Review Questions
1. 2. 3. 4.

Chapter 742 Policy Options

Configuring Juniper Networks Firewall/IPSec VPN Products

Lab 5: Policy Options


The slide lists the objectives for this lab.

Policy Options Chapter 743

Configuring Juniper Networks Firewall/IPSec VPN Products

Chapter 744 Policy Options

Configuring Juniper Networks Firewall/IPSec VPN Products


Chapter 8: Address Translation

Configuring Juniper Networks Firewall/IPSec VPN Products

This Chapter Discusses:


Policy-based Network Address Translation (NAT) options; Configuring address translation features; and Verifying NAT mode operation.

Chapter 82 Address Translation

Configuring Juniper Networks Firewall/IPSec VPN Products

Scenarios
This slide lists the topics we cover in this chapter. We discuss the highlighted topic first.

Address Translation Chapter 83

Configuring Juniper Networks Firewall/IPSec VPN Products

Interface-Based NATReview
As we discussed earlier, interface-based NAT is available on all platforms, but only in limited configurations. In more complex networks needing NAT, policy-based options are available.

Chapter 84 Address Translation

Configuring Juniper Networks Firewall/IPSec VPN Products

Policy-Based NAT: Part 1


You have several options available for when and how internal addresses are translated to external addresses. The option you select depends on several factors: Application; Number of routable addresses; and Number of internal devices and servers.

Placing the interfaces in route mode and configuring policy-based NAT by using a policy provides you with greater control. When using a policy, you can enable and disable port translation, and the ScreenOS device assigns the translated addresses from a pool of addresses. There are two basic families of policy-based address translationunidirectional and bidirectional. As the names imply, the ScreenOS device applies unidirectional translation only to sessions initiating in the direction of the defined policy. The device applies bidirectional translation to traffic both originating from and sent to a specified private/public address set.

Address Translation Chapter 85

Configuring Juniper Networks Firewall/IPSec VPN Products

Policy-Based NAT: Part 2


The following list provides a summary of the four basic types of translation: Source NAT (NAT-src): Translates a private source address to a public source address. It is typically used for hosts inside a private network accessing the Internet. Destination NAT (NAT-dst): Translates a public destination address to a private destination address. It is typically used when internal hosts are using private addressing but must be accessed from the public network. Virtual IP(VIP) address: A one-to-many mapping that statically associates a specified public address with many internal addresses based on service (for example, port number). Used when internal service hosts (for example, mail servers) must initiate and receive sessions from the public space using a consistent IP address, but the public address space is limited. Mapped IP (MIP) address: A one-to-one mapping that statically associates a specified private address with a specified public address. It is used for a specific host that must both initiate and receive sessions from the public space using a consistent IP address.

Chapter 86 Address Translation

Configuring Juniper Networks Firewall/IPSec VPN Products

Which One Do I Use?


With so many options when considering a NAT implementation, you should first look at the requirements of the network, then match those requirements to the functionality of a particular address translation type. You can use NAT-src to ensure that private addresses are hidden in the public network. It also ensures that internal hosts cannot be accessed using the public addresses, as the translation only takes place in one direction. NAT-dst opens up only specified host addresses to access from the outside networks. Use MIP addresses if the network design requires that the mapping between public and private addresses be constant and available in either direction. VIP addresses are limited to the Untrust zone. If customers want VIP address functionality in a different zone, they can use NAT-dst to accomplish the same thing.

Address Translation Chapter 87

Configuring Juniper Networks Firewall/IPSec VPN Products

NAT-src
The slide highlights the topic we discuss next.

Chapter 88 Address Translation

Configuring Juniper Networks Firewall/IPSec VPN Products

Dynamic IP Address
Before we move on, we should discuss dynamic IP (DIP) addresses. A DIP address set allows you to configure a range or pool of IP addresses from which the Juniper Networks device can dynamically take addresses to use when performing NAT. You configure DIP address pools on an interface. The range of addresses in a DIP pool must be in the same subnet as an IP address associated with that interfaceeither the interface address, a secondary address on the interface, or an extended address on the interface. The DIP pool cannot conflict with any other addresses, so it should not contain the interface IP address, router IP address, or any other address mapping (for example, MIP or VIP addresses). Consider the following additional DIP address restrictions: Only applied to traffic exiting the interface where the DIP address is configured; Can consist of a single IP address or range of IP addresses; Address range cannot exceed 254 addresses; and System supports 252 DIP address sets across all interfaceseach DIP address set has a unique identifier that must be in the range of 4255.

Address Translation Chapter 89

Configuring Juniper Networks Firewall/IPSec VPN Products

NAT-src Options
We look at NAT-src first. NAT-src has the following four different configuration options: NAT-src: This functions like interface-based NAT without the zone limitations. The source address is translated to the address of the outbound interface. Port translation ensures that each session is uniquely identified. DIP address pool with port translation: A DIP address is a pool of addresses that can be used for source translation. Address selection is dynamic and done on a round-robin basis. Port translation allows for a large group of private addresses to use a smaller group of public addresses for translation. DIP address pool without port translation: Functions as DIP address pool, but without port translation. If port translation is not used, you should ensure that sufficient public addresses are available. IP address shifting: A one-to-one mapping of a range of private addresses to a range of public addresses. No port translation is performed.

Chapter 810 Address Translation

Configuring Juniper Networks Firewall/IPSec VPN Products

NAT-src Examples
In the first example on the slide, we perform simple NAT-src, translating the source address to the interface address. The port number uniquely identifies the returning flow for translation back to the private address. In the second example, we use a DIP address pool with port translation. The example shows that multiple internal addresses can share a single external address through port translation. In reality, addresses are assigned on a round-robin basis, so the likelihood of these two sources having the same post-translation IP address is based on the size of the DIP address pool. The third example shows a DIP address without port translation. Note that the IP address of the post-translation packet is different, but the port number is the same. Again, remember that this option requires that you have sufficient IP addresses for your outbound connection requirements. The fourth example illustrates IP address shift. DIP address shift is a one-to-one relationship between a group of private and a group of public addresses. You must have the same number of addresses on each side of the translation. The ScreenOS device performs no port translation. Continued on next page.

Address Translation Chapter 811

Configuring Juniper Networks Firewall/IPSec VPN Products

NAT-src Examples (contd.)


The following table might illustrate IP address shifting more clearly:

Pretranslation 10.1.1.5 10.1.1.6 10.1.1.7 10.1.1.8 10.1.1.9

Post-translation 1.1.8.10 1.1.8.11 1.1.8.12 1.1.8.13 1.1.8.14

Chapter 812 Address Translation

Configuring Juniper Networks Firewall/IPSec VPN Products

NAT-src Configuration: WebUI


To configure NAT-src for the CLI and WebUI, you must perform two steps. Perform these two steps after you determine the type of NAT-src and DIP address pool your network requires.

NAT-src Configuration: Security Manager


To configure NAT-src for Security Manager, you must perform three steps. These steps are to make a DIP address pool on the device first, then make a global DIP address poll. Finally, create a rule to use the global DIP address.

Address Translation Chapter 813

Configuring Juniper Networks Firewall/IPSec VPN Products

Step 1: Creating a DIP AddressCLI


If you use the CLI, select the correct command variant for the type of DIP address you want to create.

Chapter 814 Address Translation

Configuring Juniper Networks Firewall/IPSec VPN Products

Step 1: Creating a DIP AddressWebUI


You configure the DIP address on the outbound interface. Using the WebUI menu, navigate to the interface, select Edit, then click DIP at the top of the page. Click New. Note the following: The DIP address ID number must be unique on the system you are configuring. Choose between IP Address Range and IP Shift. The address range specifies the starting and ending address of the DIP address. If your DIP address will only have a single address, you do not need to specify and ending address. Port translation is enabled by default; if you want to disable it, click the check box. IP Shift: The from box is the first address in the private range. The to boxes are the start and end of the public address range. The last address in the private range will be determined automatically. Remember, when using IP address shift, private addresses out of the translated range will be permitted without translation.

Choose the source of the DIP address. If you select In the same subnet as the extended IP, configure the extended address and mask for the interface.

Address Translation Chapter 815

Configuring Juniper Networks Firewall/IPSec VPN Products

Step 1: Creating a DIP AddressSecurity Manager: Part 1


Creating a DIP address using Security Manager is a two-step process. You must edit the device and add a new dynamic IP address on the physical interface. The parameters in Security Manager are the same as in the WebUI.

Chapter 816 Address Translation

Configuring Juniper Networks Firewall/IPSec VPN Products

Step 1: Creating a DIP AddressSecurity Manager: Part 2


The slide shows the second step for creating a DIP address using Security Manager. You must now add a global DIP address object to the object manager. This step is needed so that you can use the global DIP address in a security policy rule.

Address Translation Chapter 817

Configuring Juniper Networks Firewall/IPSec VPN Products

Step 2: Creating a Policy


You must create a policy that enables NAT-src. You can apply a DIP address to the policy if needed. NAT-src with no DIP address is just like interface-based NAT.

Chapter 818 Address Translation

Configuring Juniper Networks Firewall/IPSec VPN Products

Step 2: Creating a PolicyWebUI


Source translation is an advanced policy feature. Use the same procedure we discussed earlier to configure the policy basics, then click the Advanced button. Click the Source Translation check box. If you want to use a DIP address, use the pull-down menu to display a list of DIP addresses configured on the system. If not, leave the box displaying None (use Egress Interface IP).

Address Translation Chapter 819

Configuring Juniper Networks Firewall/IPSec VPN Products

Step 2: Creating a PolicySecurity Manager


Remember that with Security Manager the definition of a policy is different than with the WebUI. When using Source NAT you must add a new rule and use rule options to apply NAT-src to that rule. You must make sure that you set the installation on the device that has the global DIP address that you will use. If you want to use NAT-src with no DIP address, simply check the Use Interface radio button in the window.

Chapter 820 Address Translation

Configuring Juniper Networks Firewall/IPSec VPN Products

Verifying DIP Address Configuration


To verify that your DIP address was created correctly, you can use the WebUI or the CLI to display what was configured. The DIP Type column indicates whether port translation is enabled or disabled, or whether IP address shift is configured.

Address Translation Chapter 821

Configuring Juniper Networks Firewall/IPSec VPN Products

Verifying NAT-src OptionsCLI


Using the CLI, you can verify that translation was added to the policy. You can also view any currently established sessions and the associated translation with the get session command.

Chapter 822 Address Translation

Configuring Juniper Networks Firewall/IPSec VPN Products

Verifying NAT-srcWebUI
You can verify that translation was added to the policy by looking at the action icon in the WebUI. A blue checkmark indicates that translation was added using the advanced policy options. To view translation in action from the WebUI, add logging to your policy. Terminated sessions that match the policy statement are added to the log; the log displays both the pretranslation and post-translation addresses. In the example on the slide, the policy is using a DIP address with port translation enabled. We can determine this configuration because the translated address is different for each session, even though the private source address is the same. Furthermore, the ports are translated. If DIP shifting were used, the private source would always use the same public source address.

Address Translation Chapter 823

Configuring Juniper Networks Firewall/IPSec VPN Products

NAT-dst
The slide highlights the topic we discuss next.

Chapter 824 Address Translation

Configuring Juniper Networks Firewall/IPSec VPN Products

NAT-dst
You can configure Destination NAT (NAT-dst) in one of four variants: One-to-one mapping maps a single public IP address (as defined in an address book entry) to a single private IP address. Many-to-one mapping translates a group of public addresses (as defined in an address book entry) to a single private IP address. Many-to-many mapping translates a group of public addresses (as defined in an address book entry) to a contiguous range of private IP addresses, using the address-shifting mechanism we discussed earlier in association with DIP addresses. Port mapping allows you to add port translation to NAT-dst configurations.

Address Translation Chapter 825

Configuring Juniper Networks Firewall/IPSec VPN Products

NAT-dst Examples
The slide illustrates the different types of NAT-dst. Note the port translation that occurs in the last example. This translation is not dynamic port selection; you, the administrator, specify the post-translation port.

Chapter 826 Address Translation

Configuring Juniper Networks Firewall/IPSec VPN Products

NAT-dst Requirements
For NAT-dst to work, the public address must be mapped to the correct internal or private zone. This requirement comes directly out of our packet-handling process; we perform a routing lookup to determine the source and destination zone before we apply a policy. Because translation is policy based, we must have the pretranslation address in the correct zone so that the correct policy can be applied. You can accomplish this correct mapping through either configuring the public address as a secondary address on one of the internal interfaces or by configuring a static route to the public address range with the outbound interface being one of the internal interfaces. Additionally, you must configure the addresses to be translated as address book entries in the internal zone. It is not possible to use any as the pretranslation destination when using NAT-dst.

Address Translation Chapter 827

Configuring Juniper Networks Firewall/IPSec VPN Products

NAT-dst Configuration Procedure


Before you begin configuration, determine which public addresses will be used.

Chapter 828 Address Translation

Configuring Juniper Networks Firewall/IPSec VPN Products

Step 1: Configuring an Address Book Entry


The first step in the NAT-dst configuration procedure is creating address book entries for the public address that will be translated to private addresses.

Address Translation Chapter 829

Configuring Juniper Networks Firewall/IPSec VPN Products

Step 1: Configuring an Address Book EntryWebUI and Security Manager


You can use all the address book features we discussed previously, including address groups.

Chapter 830 Address Translation

Configuring Juniper Networks Firewall/IPSec VPN Products

Step 2a: Configuring ReachabilitySecondary Address


For the policy to be examined, a routing entry must exist in the private zone for the pretranslation addresses. One way to ensure that this entry exists is to configure a secondary address on one of the interfaces in the internal zone, using a mask that encompasses the expected range of public addresses. This secondary address automatically adds an entry for this subnet in the routing table.

Address Translation Chapter 831

Configuring Juniper Networks Firewall/IPSec VPN Products

Step 2a: Configuring ReachabilitySecondary AddressWebUI and Security Manager


The slide shows the secondary address configuration process in both the WebUI and Security Manager.

Chapter 832 Address Translation

Configuring Juniper Networks Firewall/IPSec VPN Products

Step 2b: Configuring ReachabilityStatic Route


An alternative to configuring a secondary address is to configure a static route to the appropriate subnet using a private interface as the outbound interface in the route definition. If you omit a gateway IP address, you ensure that untranslated traffic cannot be forwarded via the interface.

Address Translation Chapter 833

Configuring Juniper Networks Firewall/IPSec VPN Products

Step 2b: Configuring ReachabilityStatic RouteWebUI and Security Manager


The slide shows the static route configuration process in both the WebUI and Security Manager.

Chapter 834 Address Translation

Configuring Juniper Networks Firewall/IPSec VPN Products

Step 3: Configuring a PolicyCLI


The get session command verifies the destination address being translated. Notice that the address 20.1.1.10 is being translated to 10.1.1.10.

Address Translation Chapter 835

Configuring Juniper Networks Firewall/IPSec VPN Products

Step 3: Configuring a PolicyWebUI


Fill in the basic policy window fields using the address book entry you defined in Step 1 as the destination address. Then click Advanced. Enable destination translation, then select whether you will be translating to a single address or a range of addresses. Port mapping is only available when translating to a single address. Enable it by clicking the check box, then entering the internal port number. Remember, the pretranslation port is determined by selecting a particular service when configuring the basic policy.

Chapter 836 Address Translation

Configuring Juniper Networks Firewall/IPSec VPN Products

Step 3: Configuring a PolicySecurity Manager


The slide shows the policy configuration process using Security Manager.

Address Translation Chapter 837

Configuring Juniper Networks Firewall/IPSec VPN Products

Verifying NAT-dstCLI
Using the CLI, you can verify that translation was added to the policy. You can also view any currently established sessions and the associated translation with the get session command.

Chapter 838 Address Translation

Configuring Juniper Networks Firewall/IPSec VPN Products

Verifying NAT-dstWebUI
You can verify that translation was added to the policy by looking at the action icon in the WebUI. A blue checkmark indicates that translation was added using the advanced policy options. Unfortunately, the logging feature only captures source translation, so no destination translation is visible using the WebUI.

Address Translation Chapter 839

Configuring Juniper Networks Firewall/IPSec VPN Products

VIP Addresses
The slide highlights the topic we discuss next.

Chapter 840 Address Translation

Configuring Juniper Networks Firewall/IPSec VPN Products

VIP Addresses
A customer has several internal servers that must accessed from the Internet. The problem is that the customer has purchased one or maybe two IP addresses from its ISP. MIP addresses are not possible because there would need to be a MIP address for every server. A virtual IP (VIP) address maps traffic received at one IP address to another IP address based on the destination port number in the TCP or UDP header. Using the examples on the slide, if an IP packet is received with a destination address of 1.1.8.100 and a destination port of 80, the address is translated to 10.1.30.5. Likewise, a packet received with the same destination IP address, 1.1.8.100, but with a destination port of 21, is translated to 10.1.20.5.

Address Translation Chapter 841

Configuring Juniper Networks Firewall/IPSec VPN Products

VIP Address Configuration Procedure


Note that using a VIP address requires that the public interface be in the Untrust zone.

Chapter 842 Address Translation

Configuring Juniper Networks Firewall/IPSec VPN Products

Step 1: Defining a VIP Address


Configuration using the CLI consists of typing an entry for each internal service. Using the WebUI, creating a VIP address is a two-step process. With Security Manager you must add a VIP address to the device and then create a global VIP address in the Object Manager.

Address Translation Chapter 843

Configuring Juniper Networks Firewall/IPSec VPN Products

Step 1: Defining a VIP AddressWebUI


Using the Web interface, creating a VIP address is a two-step process. First, define the VIP address, which must be in the same subnet as the interface address. Once the address is defined, click the New VIP Service at the top of the screen. A new window will open. The following list provides details about the fields: Virtual IP: The VIP address. Virtual Port: The pretranslation port number. Map to Service: The post-translation port number and service. Map to IP: The internal server address. Server Auto Detection: Enable the Juniper Networks device to check whether the internal server or host is available. This option can save processor cycles; do not bother with translation if the service is unavailable. This option is enabled by default.

Chapter 844 Address Translation

Configuring Juniper Networks Firewall/IPSec VPN Products

Step 1: Defining a VIP AddressSecurity Manager


Defining a VIP address using Security Manager is a two-step process. You use the same process you used for defining a DIP address. Add a new VIP address to the device, then define all the VIP address mappings needed for that new VIP address. Next, add a new global VIP address and map it to the device VIP address. Note that forgetting to define a global VIP address is common.

Address Translation Chapter 845

Configuring Juniper Networks Firewall/IPSec VPN Products

Step 2: Defining a Policy


Defining a VIP address policy is similar to defining a MIP address policy. You define the policy from the public zone (in the case of a VIP address, this is always the Untrust zone) to the private zone.

Chapter 846 Address Translation

Configuring Juniper Networks Firewall/IPSec VPN Products

Step 2: Defining a PolicyWebUI


You define the policy from the public zone (in the case of a VIP address, this is always the Untrust zone) to the private zone. You set the destination address to the VIP address that is defined.

Address Translation Chapter 847

Configuring Juniper Networks Firewall/IPSec VPN Products

Step 2: Defining a PolicySecurity Manager


You define the policy from the Untrust zone to the Trust zone. You set the global VIP address to the destination address in the security policy rules section.

Chapter 848 Address Translation

Configuring Juniper Networks Firewall/IPSec VPN Products

Verifying VIP Address Configuration


You can view the VIP address mappings using the WebUI or the CLI.

Address Translation Chapter 849

Configuring Juniper Networks Firewall/IPSec VPN Products

Verifying VIP Address Operations


The get session and get address global command will verify VIP address operations.

Chapter 850 Address Translation

Configuring Juniper Networks Firewall/IPSec VPN Products

MIP Addresses
The slide highlights the topic we discuss next.

Address Translation Chapter 851

Configuring Juniper Networks Firewall/IPSec VPN Products

MIP Address
You use a MIP address to define a static one-to-one mapping of a specific private address to a specific public address. The following translation occurs as appropriate: Source translation occurs when traffic is sent from the private host to the public network. Destination translation occurs when traffic arrives from the public network destined for the public address.

No port translation occurs when using a MIP address. Unlike other translation options, the public MIP address can be any legal IP address; it does not have to be associated with the interface on which it is configured. The only requirement is that upstream routers needs a route for the MIP address that directs traffic to the interface where the MIP address is configured.

Chapter 852 Address Translation

Configuring Juniper Networks Firewall/IPSec VPN Products

MIP Address Configuration Procedure


Defining a mapped IP address is a two-step process. Define the MIP address, then invoke it using a policy. With Security Manager it is a three-step process. Define the MIP address in the device, then create a global MIP address. Next, create a policy rule to invoke the MIP address.

Address Translation Chapter 853

Configuring Juniper Networks Firewall/IPSec VPN Products

Step 1: Defining MIP Addresses


You configure the MIP address on the public-facing interface. It is like defining a VIP address. Remember that a MIP address is a bidirectional mapping of addresses.

Chapter 854 Address Translation

Configuring Juniper Networks Firewall/IPSec VPN Products

Step 1: Defining a MIP AddressWebUI


You configure the MIP address on the public-facing interface. The following list provides details about the fields: Mapped IP: The public address for this mapped pair. Netmask: Used if mapping a range of addresses (we discuss this option later). Host IP Address: The private address for this mapped pair. Host Virtual Router Name: The VR where the private address is defined.

Address Translation Chapter 855

Configuring Juniper Networks Firewall/IPSec VPN Products

Step 1: Defining a MIP AddressSecurity Manager


Defining a MIP address policy is similar to defining a VIP address policy. You define the policy from the public zone (in the case of a VIP address, this is always the Untrust zone) to the private zone.

Chapter 856 Address Translation

Configuring Juniper Networks Firewall/IPSec VPN Products

Step 2: Configuring a MIP Address Policy


Configure the policy coming from the public network to the private space. The source address depends on your requirements, but the destination address is the MIP address. This might seem strange because the MIP address is a placeholder of sorts, not an actual destination. Remember that the packet destination address is the public MIP address; by permitting the MIP address as the destination, you invoke the translation process. If you permit the destination address without the MIP address, translation does not occur.

Address Translation Chapter 857

Configuring Juniper Networks Firewall/IPSec VPN Products

Step 2: Configuring a MIP Address PolicyWebUI


The slide shows the MIP address policy configuration process using the WebUI.

Chapter 858 Address Translation

Configuring Juniper Networks Firewall/IPSec VPN Products

Step 2: Configuring a MIP Address PolicySecurity Manager


You define the policy from the Untrust zone to the Trust zone. The global MIP address is set to the destination address in the security policy rules section.

Address Translation Chapter 859

Configuring Juniper Networks Firewall/IPSec VPN Products

Verifying MIP Address OperationCLI


You can use the get session command to verify MIP address functionality in either direction if sessions are active.

Chapter 860 Address Translation

Configuring Juniper Networks Firewall/IPSec VPN Products

Verifying MIP Address OperationWebUI


Unlike unidirectional translation, using a MIP address does not change the action icon in the WebUI. You can see that the MIP address is in use in the public-to-private policy set. You can configure the private-to-public policy set without any special considerations; translation for the private address will automatically occur. If you add logging to your policy, you can see translation for terminated sessions.

Address Translation Chapter 861

Configuring Juniper Networks Firewall/IPSec VPN Products

MIP ShortcutUsing Masks


If you have a contiguous range of addresses that must be translated, you can use the netmask field in the MIP address definition. Note that this is not IP address shift; the associations are based on masking. The host IP address you specify will be within the range of translated addresses, but it will not necessarily be the first address in the range if you are not careful with your masking.

Chapter 862 Address Translation

Configuring Juniper Networks Firewall/IPSec VPN Products

MIP Addresses Using Masks


In the screen capture example on the slide, although the specified addresses were 1.1.8.15 and 10.1.10.5, the actual translation range will be 1.1.8.81.1.8.15, translated to 10.1.10.010.1.10.7. The binary for the last octet is shown here: 00001111 = 15 00000101 = 5 11111000 = mask public range: 00001000 - 00001111 = 8-15 private range: 00000000 - 00000111 = 0-7

Address Translation Chapter 863

Configuring Juniper Networks Firewall/IPSec VPN Products

MIP Address ComplicationsOther Interfaces?


In the example on the slide, we have a MIP address defined on E8, mapping to Host A's address. What if we have traffic arriving from a third zonein this case, the public zoneusing the public MIP address?

Chapter 864 Address Translation

Configuring Juniper Networks Firewall/IPSec VPN Products

The SolutionTwo Policies


The solution is to configure two policies. Remember, the public MIP address is associated with the interface in the external zone; therefore, we need a policy permitting traffic from the public zone to the external zone. Once the packet arrives in the external zone, the existing MIP address policy translates the packet and forwards it to the destination zone accordingly. Note that this process applies to traffic originating from the public zone. If Host A wants to initiate a session with Host C, the MIP address is not involved; traffic would be sent directly from the private zone to the public zone without translation.

Address Translation Chapter 865

Configuring Juniper Networks Firewall/IPSec VPN Products

Which Takes Precedence?


With all these translation options, what takes precedence if you mix and match? The answer is that MIP addresses and VIP addresses take priority over other translation methods, and MIP addresses take precedence over VIP addresses.

Chapter 866 Address Translation

Configuring Juniper Networks Firewall/IPSec VPN Products

This Chapter Discussed:


Policy-based NAT options; Configuring address translation features; and Verifying NAT mode operation.

Address Translation Chapter 867

Configuring Juniper Networks Firewall/IPSec VPN Products

Review Questions: NAT-src


1. 2. 3. 4.

Chapter 868 Address Translation

Configuring Juniper Networks Firewall/IPSec VPN Products

Review Questions: NAT-dst


1. 2. 3.

Address Translation Chapter 869

Configuring Juniper Networks Firewall/IPSec VPN Products

Review Questions: Virtual IP Address


1. 2.

Chapter 870 Address Translation

Configuring Juniper Networks Firewall/IPSec VPN Products

Review Questions: Mapped IP Address


1. 2. 3.

Address Translation Chapter 871

Configuring Juniper Networks Firewall/IPSec VPN Products

Lab 6: Address Translation Tools


The slide lists the objectives for this lab.

Chapter 872 Address Translation

Configuring Juniper Networks Firewall/IPSec VPN Products


Chapter 9: Transparent Mode (Optional)

Configuring Juniper Networks Firewall/IPSec VPN Products

This Chapter Discusses:


The advantages of transparent mode operation; Transparent mode zones, interfaces, and Layer 3 mode zones; and Using the VLAN1 interface to manage the Juniper Networks device in transparent mode.

Chapter 92 Transparent Mode (Optional)

Configuring Juniper Networks Firewall/IPSec VPN Products

Description
This slide lists the topics we cover in this chapter. We discuss the highlighted topic first.

Transparent Mode (Optional) Chapter 93

Configuring Juniper Networks Firewall/IPSec VPN Products

Transparent Mode
In this chapter we cover the Layer 2 mode of operation for the Juniper Networks devices: transparent mode. This mode essentially allows you to immediately deploy Juniper Networks firewall and VPN functionality without making changes to the existing network topology. In this mode, the Juniper Networks device behaves as a Layer 2 forwarding device, similar to a bridge or switch.

Chapter 94 Transparent Mode (Optional)

Configuring Juniper Networks Firewall/IPSec VPN Products

Transparent Mode in Action


There are advantages to implementing a Juniper Networks device in transparent mode: no changes are required in the network. The Juniper Networks device is simply dropped in, and a firewall with full VPN capabilities is ready to be implemented. No IP addressing scheme must be matched or changed. In addition, the Juniper Networks device can segment the network into various security zones based on the sensitivity of the resources. Operating in transparent mode allows the following: Requires no IP addresses on physical interfaces; Requires no changes to address deployment; Offers full VPN and firewall capabilities; and Management is performed using the virtual VLAN1 interface.

Transparent Mode (Optional) Chapter 95

Configuring Juniper Networks Firewall/IPSec VPN Products

Layer 2 Security Zones


As we discussed in an earlier chapter, a physical interface must always be associated with a zone. Three predefined Layer 2 zones are on the Juniper Networks device: V1-Trust, V1-DMZ, and V1-Untrust. The predefined V1 zones can coexist with other zones on the Juniper Networks device. However, V1 zones are isolated from other zones that might exist on the Juniper Networks device. User-defined Layer 2 zones can be created; the names of the Layer 2 zones must begin with L2-. The Juniper Networks device does not allow traffic to pass between Layer 2 and Layer 3 security zones. Note that V1 zones and L2 zones are functionally the same. The only difference is that V1 zones are the predefined Layer 2 zones. By default, management is enabled on the V1-Trust zone, and ping is enabled on the V1-DMZ zone.

Chapter 96 Transparent Mode (Optional)

Configuring Juniper Networks Firewall/IPSec VPN Products

Interfaces in Transparent Mode


Transparent mode is an interface-level setting. To place an interface into transparent mode, the interface must be assigned to a Layer 2 zone (V1- or L2-) All the interfaces that are a member of any V1 or L2 zone belong to the same Layer 2 broadcast domain, and thus the Juniper Networks device becomes transparent to the network.

Transparent Mode (Optional) Chapter 97

Configuring Juniper Networks Firewall/IPSec VPN Products

VLAN1 Interface
The VLAN1 interface is a virtual interface that you can use for management and for terminating VPNs when operating in transparent mode. You can configure this interface with an IP address so that devices connected to an interface in any transparent zone can manage the Juniper Networks device, if permitted. You must configure the VLAN1 interface with an IP address in the same subnet as the other devices connected to the V1 zones. The interface exists in the VLAN zone and can only be accessed using the interfaces in the transparent zones.

Chapter 98 Transparent Mode (Optional)

Configuring Juniper Networks Firewall/IPSec VPN Products

Default Management Behavior


In the example on the slide, three interfaces are configured in each of the three zones: V1-Trust, V1-DMZ and V1-Untrust. Because the VLAN1 interface belongs to the VLAN zone, all devices in the V1 zones should be able to manage the Juniper Networks device. Devices A and B can ping the VLAN1 interface, but device C cannot. Why? All three devices are in the same VLAN and all three devices are in the same subnet 1.1.1.0/24, so it should work, right? If you are familiar with Juniper Networks policies and zones, you might think this is the issue. After all, device C is in a different zone than the VLAN1 interface. However, a policy is not a factor here because the VLAN zone is a special zone for management not security. As you will learn, policies apply only to security zones and thus do not apply here. The reason why a device in the zone V1-Untrust cannot communicate to the VLAN1 interface by default is because it is designed that way. Looking at the table on the slide, you can see that ping is enabled only on the interfaces in the V1-Trust and V1-DMZ zone. As we discussed in an earlier chapter, each physical interface has management options that allow or deny certain kinds of management service(s). Even though the interfaces do not have IP addresses, management services are still configured on physical ports.

Transparent Mode (Optional) Chapter 99

Configuring Juniper Networks Firewall/IPSec VPN Products

Management Operations
In the administration chapter, we discussed the relationships between all the available management settingsmanage-IP, manager-IP, interface settings, and authentication.

Transparent Mode
When operating in transparent mode, the ScreenOS device ignores the management settings of physical interfaces. Instead, you configure management services on a per-zone basis. When configured, all interfaces bound to the zone share the same management access.

Chapter 910 Transparent Mode (Optional)

Configuring Juniper Networks Firewall/IPSec VPN Products

Configuration
The slide highlights the topic we discuss next.

Transparent Mode (Optional) Chapter 911

Configuring Juniper Networks Firewall/IPSec VPN Products

Configuring for Transparent Mode


The slide lists the steps for configuring transparent mode on a Juniper Networks device. Transparent mode interface configuration consists of creating a Layer 2 zone (if needed), placing an interface in a Layer 2 zone, and configuring management options. We outline these steps on the following slides.

Chapter 912 Transparent Mode (Optional)

Configuring Juniper Networks Firewall/IPSec VPN Products

Configuring for Transparent Mode


We use the example on the slide to show how you configure the transparent mode.

Transparent Mode (Optional) Chapter 913

Configuring Juniper Networks Firewall/IPSec VPN Products

Step 1: Creating Layer 2 Zones


Recall that predefined Layer 2 zones exist: V1-Trust, V1-DMZ, and V1-Untrust. If you make the decision to not use these predefined zones for transparent mode, you must use user-defined zones. (Remember that the name must begin with L2-.) The VLAN tag in the example on the slide is used to specify the broadcast domain to which the Layer 2 zone will belong.

Chapter 914 Transparent Mode (Optional)

Configuring Juniper Networks Firewall/IPSec VPN Products

Step 2: Assigning Interfaces to Zones


An interface must be a member of a Layer 2 security zone. No default Layer 2 zone memberships exist on any Juniper Networks device.

Transparent Mode (Optional) Chapter 915

Configuring Juniper Networks Firewall/IPSec VPN Products

Step 3a: Configuring an IP Address


We now assign an IP address to the Layer 2 zone. This IP address is used to manage the device over the network. Remember that you cannot set the IP address on the interface unless you assigned the interface to a zone.

Chapter 916 Transparent Mode (Optional)

Configuring Juniper Networks Firewall/IPSec VPN Products

Step 3b: Selecting a Broadcast Option


As mentioned, the Juniper Networks device in transparent mode behaves as a Layer 2 switch or bridge. When a host or any kind of network device connected to the Juniper Networks device in transparent mode 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. (Which one of you owns this IP address?) 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 that owns 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. In this regard, the Juniper Networks devices job in transparent mode, by default, is to forward any broadcast packets, like an ARP request. As ARP traffic passes through a Juniper Networks device, the device notes the source MAC address in each packet and learns which interface leads to that MAC address. In fact, the Juniper Networks 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. Continued on next page.

Transparent Mode (Optional) Chapter 917

Configuring Juniper Networks Firewall/IPSec VPN Products

Flooding Versus ARP/Trace-Route


When a Juniper Networks 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 performing 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 (TTL) value set to 1) out all interfaces (except the interface at which the packet arrived). 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.

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, without trace-route, the Juniper Networks device can only discover the destination MAC address for a unicast packet if the destination IP address is in the same subnet as the ingress IP address. Actually, the trace route returns the IP and MAC addresses of all the routers in the subnet. The Juniper Networks 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. Note that of the two methodsflood and ARP/trace routeARP/trace route is more secure because the Juniper Networks device floods ARP queries and trace-route packetsnot the initial packetout all interfaces.

Chapter 918 Transparent Mode (Optional)

Configuring Juniper Networks Firewall/IPSec VPN Products

Step 3c: Configuring VLAN1 Services


By default, user-defined zones do not have any management services enabled. Select the services which are appropriate for your implementation.

Transparent Mode (Optional) Chapter 919

Configuring Juniper Networks Firewall/IPSec VPN Products

Step 4: Configuring Management Services per Zone


This step is optional. By default, all services are disabled on user-defined zones.

Chapter 920 Transparent Mode (Optional)

Configuring Juniper Networks Firewall/IPSec VPN Products

Step 5: Configuring Policies Between L2 Zones


The default policy on the device is not enough to allow network traffic to flow. You must add a new policy between the Layer 2 zones to allow access.

Transparent Mode (Optional) Chapter 921

Configuring Juniper Networks Firewall/IPSec VPN Products

Verifying Operations
The slide highlights the topic we discuss next.

Chapter 922 Transparent Mode (Optional)

Configuring Juniper Networks Firewall/IPSec VPN Products

Transparent Mode Tools


Next we look at a few tools that will help you identify that an interface is operating in transparent mode. We also reemphasize the concept of passing traffic between Layer 2 zones.

Transparent Mode (Optional) Chapter 923

Configuring Juniper Networks Firewall/IPSec VPN Products

Using the get interface name Command


This slide shows that a particular interface (ethernet1 in this example) is in transparent mode.

Chapter 924 Transparent Mode (Optional)

Configuring Juniper Networks Firewall/IPSec VPN Products

Using the get arp Command


The get arp command displays the ARP cache on the device, and you can use it in either transparent mode or Layer 3 operational mode. It is especially useful when selecting the ARP/trace-route method of broadcasting. The slide shows that an IP address/MAC address pair is associated with a particular virtual router and interface. When operating in transparent mode, the interface displayed is actually the zone name.

Transparent Mode (Optional) Chapter 925

Configuring Juniper Networks Firewall/IPSec VPN Products

Using the get mac-learn Command


To view the Layer 2 forwarding table, use the get mac-learn command. The display on the slide shows the table of learned MAC addresses and the outgoing interfaces with which each one is associated. The timeout value is the number of seconds a particular entry will remain in the table before it is deleted. This command does not generate output for interfaces in a Layer 3 mode.

Static Mapping
Although most often the MAC table is automatically updated using the flood or ARP/ trace-route options, you can add a static entry as well using the CLI command: set mac mac_address outgoing_interface

Chapter 926 Transparent Mode (Optional)

Configuring Juniper Networks Firewall/IPSec VPN Products

Using the get session Command


The Juniper Networks device is a stateful firewall. The get session command displays the session table. The fields display the IP addresses of the session, the port number, and the protocol number. ICMP is protocol number 1. Because ICMP does not have port numbers, the Juniper Networks device builds a pseudo-session by using the ICMP sequence number and identifier number.

Transparent Mode (Optional) Chapter 927

Configuring Juniper Networks Firewall/IPSec VPN Products

Points to Consider
One of the most common configuration problems is forgetting to add a policy for the new zones added.

Chapter 928 Transparent Mode (Optional)

Configuring Juniper Networks Firewall/IPSec VPN Products

Summary
The advantages of transparent mode operation; Transparent mode zones, interfaces, and Layer 3 mode zones; and Using the VLAN1 interface to manage the Juniper Networks device in transparent mode.

Transparent Mode (Optional) Chapter 929

Configuring Juniper Networks Firewall/IPSec VPN Products

Review Questions
1. 2. 3. 4.

Chapter 930 Transparent Mode (Optional)

Configuring Juniper Networks Firewall/IPSec VPN Products

Lab 7: Transparent Mode


The slide shows the objective for this lab.

Transparent Mode (Optional) Chapter 931

Configuring Juniper Networks Firewall/IPSec VPN Products

Chapter 932 Transparent Mode (Optional)

Configuring Juniper Networks Firewall/IPSec VPN Products


Chapter 10: VPN Concepts

Configuring Juniper Networks Firewall/IPSec VPN Products

This Chapter Discusses:


The definition of virtual private network (VPN); Security concerns and how to address them; The components of the IP Security (IPSec) protocol suite; and The Internet Key Exchange (IKE) protocol process for tunnel establishment.

Chapter 102 VPN Concepts

Configuring Juniper Networks Firewall/IPSec VPN Products

Concepts and Terminology


This slide lists the topics we cover in this chapter. We discuss the highlighted topic first.

VPN Concepts Chapter 103

Configuring Juniper Networks Firewall/IPSec VPN Products

Virtual Private Networks


Historically, companies with multiple sites have used a variety of methods to provide inter-office data connectivity, including leased lines, Frame Relay, or ATM links. These technologies have the benefit of providing private, dedicated connections between locations, but they are expensive to purchase and to maintain. An alternative to private lines is the virtual private network (VPN). Sites are connected to a shared public network, which uses tunnels to transmit data between sites. Tunneling technologies use encapsulation; the original datagram is encapsulated inside a new datagram sent from one tunnel peer to another. The receiving tunnel peer decapsulates the data and forwards the original datagram. Various tunnel protocols exist, including generic routing encapsulation (GRE), the Layer 2 Tunneling Protocol (L2TP), and IP Security (IPSec). One of the issues to address with any tunnel protocol is how to secure your data as it traverses the public network. Without some sort of strategy, theoretically, anyone connected to the public network can intercept your data.

Chapter 104 VPN Concepts

Configuring Juniper Networks Firewall/IPSec VPN Products

The Need for Security


The following list outlines the three driving concerns for network security: confidentiality, integrity, and validation: Confidentiality: Online banking, credit card information, companys competitive information. How do we keep this information secure from the man in the middle? We want the information to be stored in such a way that if someone were to capture this datagram, the information would appear meaningless. Integrity: Even though the information maybe secure and hidden, in that someone might not be able to determine or understand its contents, it could still be changed. Bits could be tweaked and the data would now not be what was originally sent through the network. So how do we make sure that if the data has been compromised, the remote station recognizes this and refuses to process the information? Authentication: How does the remote station verify that the information did come from the device that it expected it to come from? You do not want to be communicating and sending critical information to the wrong recipient!

VPN Concepts Chapter 105

Configuring Juniper Networks Firewall/IPSec VPN Products

Data Encryption
Encryption provides data confidentiality. Encryption is the method of taking user datareferred to as plaintextand converting it into unreadable or secret data called ciphertext. Ciphertext is created by feeding data into an encryption algorithm along with an encryption key (a string of bits that seeds the encryption process). To reverse the process and decrypt the ciphertext, you must know both the encryption algorithm and encryption key. Encrypted data can be decrypted in one of the two following ways: Symmetric key encryption uses the same key for both encryption and decryption. Asymmetric key encryption uses a private key for encryption, and a mathematically related public key for decryption.

The cipher strength depends on the key size; the larger the key, more secure the cipher output. The trade-off is in processing time; larger keys take more computational cycles to encrypt and decrypt.

Chapter 106 VPN Concepts

Configuring Juniper Networks Firewall/IPSec VPN Products

Symmetric Key Encryption


Symmetric key encryption is the most straightforward form of encryption with the least amount of overhead. It is called symmetric because the key used to encrypt the data is the same key used to decrypt it. Thus, the same key has to be known on both sides of a connection. Symmetric key sizes vary between 40 bits and 1024 bits. They are very fast and widely used for bulk data encryption. Because the key must be known to both the sender and the receiver, key management is a problem when using symmetric keys. Examples include RC4, the DES, the Advanced Encryption Standard (AES), and Blowfish.

VPN Concepts Chapter 107

Configuring Juniper Networks Firewall/IPSec VPN Products

Public Key Encryption


With the asymmetric key/public key encryption method, a pair of mathematically related keys is used. One of the keys is kept secret and known only to the owner; this is the private key. The other key is widely distributed and can be accessed by anyone; this is the public key. Data encrypted by private key can only be decrypted using the corresponding public key, and vice versa. The keys are mathematically related such that it is almost impossible to derive one key out of another. Public key sizes vary from 512 bits to 2048 bits. Because of the large size, public keys are extremely slow and generally not feasible for bulk data encryption. However, public keys are widely used for user and device authentication (for example, digital certificates). Examples include RSA.

Chapter 108 VPN Concepts

Configuring Juniper Networks Firewall/IPSec VPN Products

Digital Integrity
Now that we have the data encrypted as it traverses the Internet, we must ensure that the data is not modified along the way. Even though a novice hacker might not be able to crack the encryption algorithm and key, the hacker could still create havoc by modifying bits being carried in the encrypted payload. If this modification of bits happens, the decrypted output will not match the original data. Who knows what the consequences might be! Hashing solves this problem by creating a fingerprint of the data, similar to a cyclic redundancy check (CRC). Before data is sent out, it is run through a hashing engine that produces a fixed-length hash output. The hash is then placed in a field in the packet along with the data and then sent over the network. The destination takes the same data and runs it through the same hashing algorithm, calculating its own hash. The destination then compares the hash that it calculated against the hash that is carried in the packet. If they are the same, that is verification that the data was not modified in transit. If the hashes do not match, the packet is dropped.

VPN Concepts Chapter 109

Configuring Juniper Networks Firewall/IPSec VPN Products

One-Way Hash Algorithms


A hash function must have the following two basics properties: 1. It must be one way so that the original data cannot be calculated from the hashed output; this is so that you cannot derive the plaintext from the ciphertext. It must be collision resistant. A collision occurs when two different inputs give the same output. Above all, it should not be possible to predict a different input value that will give the same output, which is necessary because the purpose of hashing is to verify that the data has not been changed.

2.

To see how it is possible to create a one-way function, think of the example on the slide, which shows a modulus operation. Given the value of 3, it is not possible to work out what the original value was because an infinite range of possible answers exists. However, this example would not be suitable as a real-world hash function because it does not satisfy the collision-resistant requirementa malicious person could change the plaintext by any multiple of the modulus number and know that the hashed value would still be the same. The most secure hash function that is widely used at present is the SHA-1. SHA-1 is a preferred over MD5, although MD5 is still widely supported. These functions produce a fixed-length output, which is useful when working with IP packets because the overhead of transmitting the hash value is predictable.

Chapter 1010 VPN Concepts

Configuring Juniper Networks Firewall/IPSec VPN Products

Hash Process
The following steps outline the hash process: 1. 2. 3. 4. 5. The sender runs the data through the hash process. The sender appends the hash value to the data and sends both to the receiver. The receiver separates the data and the hash value. The receiver hashes the data. The receiver then compares the calculated hash value to the received hash value. If the hash values match, the data has not been altered.

VPN Concepts Chapter 1011

Configuring Juniper Networks Firewall/IPSec VPN Products

Source Authentication
Encryption protects the packet contents from being viewed on the public network. Hashing verifies that the data was not altered. But what about validating the source of the data? Source authentication is performed using the Hashed Method Authentication code (HMAC). The sender appends a secret preshared key to the data, then performs the hash function. For the hashes to successfully match, the receiver must append the same key value to the data before performing the hash function. The key itself is never transmitted along with the data.

Chapter 1012 VPN Concepts

Configuring Juniper Networks Firewall/IPSec VPN Products

Protecting Data Integrity with HMAC


The following steps outline hashing with HMAC: 1. 2. 3. 4. 5. The sender appends preshared key to data, then performs hash function. The data and hash value are sent to receiver. The receiver separates the data and the hash value. The receiver appends the preshared key to the data, then performs the hash function. The receiver then compares the calculated hash value to the received hash value. If the hash values match, the data has not been altered. If the hash values do not match, either the data itself was corrupted, or the keys did not match, meaning the source is invalid. Either way, the packet is discarded.

VPN Concepts Chapter 1013

Configuring Juniper Networks Firewall/IPSec VPN Products

How Do Keys Get Exchanged?


As we saw, both encryption and authentication are dependent on security keys, which leads to the problem of key exchange. If keys must be the same on both sides of a connection, how can we securely exchange key information? One option is to manually configure the keys on both sides of the connection. Manual key configuration is straightforward, but misconfigurations, especially when each firewall has a different administrator, are common. Furthermore, manual configuration means that keys are rarely changed, which is itself a potential security issue; given a large enough sample, any code can be broken. Automating the key exchange process is a fine idea, but we must overcome the problem of sending keys across a public network. Anyone intercepting the key has the ability to decode the data.

The Solution
Whitfield Diffie and Martin Hellman developed a solution to this problem in 1970. The Diffie-Hellman algorithm is a method whereby two parties can agree upon a secret key that is known only to them. The strength of the technique is that it allows the participants to create the secret value over an unsecured medium without exchanging the secret value itself. It is also impossible to reverse-generate the secret if it is somehow intercepted.

Chapter 1014 VPN Concepts

Configuring Juniper Networks Firewall/IPSec VPN Products

Diffie-Hellman Groups
Diffie and Hellman proposed five groups of prime numbers and generator values to be used in their key exchange algorithm. The group is used to generate unique keys using a combination of exponential and modulus calculations. Juniper Networks ScreenOS devices support Diffie-Hellman (DH) Groups 1, 2, and 5. The larger the prime number, the stronger the keyand the more computationally intensive the calculation. Both tunnel peers must be configured to use the same DH group; otherwise, the key generation process will fail. Continued on next page.

VPN Concepts Chapter 1015

Configuring Juniper Networks Firewall/IPSec VPN Products

Diffie-Hellman Groups (contd.)


Diffie Hellman Group 1 uses a 768-bit prime number: g = Generator = 2 P = Prime = FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF Diffie Hellman Group 2 uses a 1024-bit prime number: g = Generator = 2 P = Prime = FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381 FFFFFFFF FFFFFFFF Diffie Hellman Group 5 uses a 1536-bit prime number: g = Generator = 2 P = Prime = FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D 670C354E 4ABC9804 F1746C08 CA237327 FFFFFFFF FFFFFFFF

Chapter 1016 VPN Concepts

Configuring Juniper Networks Firewall/IPSec VPN Products

The DH Key Exchange Process


Using the same DH group, each ScreenOS device creates a unique public/private key. These keys are mathematically related using the DH algorithm. The public key values are exchanged across the network. Each peer then runs its local private key and the received public key value through the DH algorithm to compute a common session key. The session key itself is never passed across the network. Continued on next page.

VPN Concepts Chapter 1017

Configuring Juniper Networks Firewall/IPSec VPN Products

The DH Key Exchange Process (contd.)


For reference, we show here a Diffie-Hellman exchange, using a small prime number instead of a large one. Generator: g=3 Large prime (using a small prime for this example): P = 101 ScreenOS device A private key: x = 7 (random number) ScreenOS device A public key: A = 37 mod 101 = 2187 mod 101 = 66 ScreenOS device B private key: y = 10 (random number) ScreenOS device B public key: B = 310 mod 101 = 59049 mod 101 = 65 ScreenOS device A session key: KA = 657 mod 101 = 4902227890625 mod 101 = 17 ScreenOS device B session key: KB = 6610 mod 101 = 1568336880910795776 mod 101 = 17 This can also be written as: gxy = 3(7 * 10) mod 101 = 17 Note that the value 17 was never exchanged.

Chapter 1018 VPN Concepts

Configuring Juniper Networks Firewall/IPSec VPN Products

IP Security
This slide highlights the topic we discuss next.

VPN Concepts Chapter 1019

Configuring Juniper Networks Firewall/IPSec VPN Products

IP Security
IP Security (IPSec) is a set of standards that defines how the encryption, validation, and authentication methods we just discussed are actually implemented in networks. The two protocols defined in the standard are the Encapsulating Security Protocol (ESP) and the Authentication Header (AH) protocol. ESP provides for the confidentiality, integrity, and authentication of data. Through ESP, encryption, hashing, and authentication can all be performed. Instead of having to worry about implementing each of these algorithms separately, you simply implement ESP to oversee these services. AH does not perform any encryption. It only verifies the integrity and authentication of the data.

Chapter 1020 VPN Concepts

Configuring Juniper Networks Firewall/IPSec VPN Products

IPSec Modes
You can implement IPSec in the following two modes: Tunnel mode: This mode is the most commonly implemented method. Tunnel mode is implemented between an IPSec gateways or IPSec gateway and a remote client providing secure access to the networks behind gateway. In this method, the end systems need not be aware of the IPSec protocol suite. All encryption and decryption takes place on the IPSec gateways on behalf of the hosts behind the gateway. Transport mode: This mode is implemented between IPSec end systems. The end systems should be aware of IPSec protocol suite. They do all the encryption and decryption of data.

VPN Concepts Chapter 1021

Configuring Juniper Networks Firewall/IPSec VPN Products

Encapsulating Security Payload Protocol


The Encapsulating Security Payload Protocol (ESP) provides data confidentiality, data integrity, authentication, and antireplay services. It does not use a transport protocol like TCP or UDP; it rides directly on top of IP using protocol number 50. ESP uses symmetric key algorithms like DES, 3DES, or AES, and hash methods like MD5 and SHA-1 to provide security services. Antireplay services ensure that datagrams cannot be captured by a third party and retransmitted. By checking sequence numbers, a receiver can determine whether a packet was already received and can discard any repetitions.

Chapter 1022 VPN Concepts

Configuring Juniper Networks Firewall/IPSec VPN Products

Tunnel Mode ESP Packets


In tunnel mode, the ESP header is inserted between the new IP header and the original IP header. The ESP header contains the following: Protocol number 50, indicating that this is an ESP packet. Security parameter index (SPI), which is an arbitrary 32-bit value that, in combination with the destination IP address and security protocol (ESP), uniquely identifies the security association for this datagram. Sequence number, which is an unsigned 32-bit field containing a monotonically increasing counter value (sequence number). It is used to detect antireplay. Padding/pad length. Depending on original data size, padding might be required to fill the packet. Next header, which is information on the next expected segment.

The ESP trailer contains the following:

ESP Auth is the integrity check value (ICV) (that is, the hash value) for this packet.

VPN Concepts Chapter 1023

Configuring Juniper Networks Firewall/IPSec VPN Products

Authentication Header
The Authentication Header (AH) protocol provides only data integrity, authentication, and antireplay services. AH is identified by IP protocol number 51. It uses MD5 or SHA-1 to provide data integrity services.

Chapter 1024 VPN Concepts

Configuring Juniper Networks Firewall/IPSec VPN Products

Tunnel Mode AH Packets


AH authenticates only the immutable fields in the IP header. Fields like TTL and type of service (ToS) change during the packet transit, so these fields are not authenticated. The AH header contains the following: Protocol number 51, indicating this is an AH packet. Next header, which is information on the next expected segment. Payload length, which indicates the size of the payload. SPI, which is an arbitrary 32-bit value that, in combination with the destination IP address and security protocol (AH), uniquely identifies the security association for this datagram. Sequence number, which is an unsigned 32-bit field containing a monotonically increasing counter value (sequence number). It is used to detect antireplay.

The AH trailer contains the ICV (that is, the hash value) for this packet.

VPN Concepts Chapter 1025

Configuring Juniper Networks Firewall/IPSec VPN Products

Tunnel Establishment Using the Internet Key Exchange Protocol


The Internet Key Exchange (IKE) protocol is a secure key management protocol used by IPSec to have information exchanged in a secure and dynamic manner with little or no intervention. IKE proposal exchange is the phase one of the IPSec tunnel establishment process. The following attributes are exchanged between IPSec peers as a part of the IKE process: Encryption algorithm; Hash algorithm; Authentication method; and Diffie-Hellman group.

Once these attributes are negotiated between the IPSec peers, IKE is used to secure future attribute exchanges used to protect data. IKE exchanges are authenticated using one of the following methods: Preshared keys; Digital signatures; and Public key encryption.

IKE is preferred over manual keys in IPSec implementations because of the ease of management and scalability.

Chapter 1026 VPN Concepts

Configuring Juniper Networks Firewall/IPSec VPN Products

Security Associations
A security association (SA) is a set of policies and key(s) used to protect information. SAs are established upon the successful completion of IKE negotiations. An SA is uniquely identified by SPI value, tunnel destination address, and the security protocol (ESP or AH) being used. The lifetime of an SA can be based either on time or on the volume of traffic that is protected by the proposal.

VPN Concepts Chapter 1027

Configuring Juniper Networks Firewall/IPSec VPN Products

SA Database
SAs are stored in a security association database. Each entry includes the name of the particular VPN, the remote gateway IP address, the SPIs for each direction, the agreed-upon security protocol, encryption and authentication algorithms, and keys.

Chapter 1028 VPN Concepts

Configuring Juniper Networks Firewall/IPSec VPN Products

Proxy ID
The proxy ID is used to exchange policy rules between two VPN peers. By default, policy checking is enabled on all ScreenOS devices. Thus, the policy that is sent via the proxy ID will be compared to the locally configured policy. It is critical that address book entries match. For example, if ScreenOS device A uses source address 10.1.10.0/24 and destination address 10.1.210.0/24 in the policy statement, ScreenOS device B must use the same address definitions when creating the policy. If ScreenOS device B uses 10.1.210.3/32 instead of the subnet, the policy statements will not match, and the VPN will not be established. Proxy ID mismatches are the most common reasons for VPN establishment failures, so be sure to double-check the proxy ID when doing your configurations.

VPN Concepts Chapter 1029

Configuring Juniper Networks Firewall/IPSec VPN Products

IKE Phases: Part 1


IKE tunnel establishment happens in two phases. Phase 1 establishes a secured channel between gateways for Phase 2 negotiations to occur. The Diffie-Hellman key exchange algorithm is used to establish a shared key for encryption.

Chapter 1030 VPN Concepts

Configuring Juniper Networks Firewall/IPSec VPN Products

IKE Phases: Part 2


Phase 2 establishes the specific VPN connections. SAs are negotiated to determine the encryption and authentication algorithms to be used when sending user data. The SA is identified by a unique SPI, which is also negotiated during Phase 2. A single Phase 1 channel can be used to establish multiple Phase 2 SAs or VPNs. If you want, you can enable perfect forward secrecy (PFS), which creates a second Diffie-Hellman exchange that is performed during Phase 2 to negotiate a new tunnel key.

VPN Concepts Chapter 1031

Configuring Juniper Networks Firewall/IPSec VPN Products

IKE Phase 1: Main Mode


IKE main mode is used when both tunnel peers have static IP addresses. The Phase 1 exchange determines the following attributes: Encryption algorithm; Hash algorithm; DH group; and Authentication method: Preshared keys; Digital signatures; and Public key encryption.

The first two messages validate the peer configuration (by checking the cookie against the locally configured peer IP address), and negotiate the above parameters. Both tunnel peers must have at least one matching proposal configured for the Phase 1 exchange to be successful. The next two messages exchange Diffie-Hellman public key values and nonces necessary to compute the shared key. The last two messages send simple identification information using the negotiated key; these messages validate that the key was calculated properly. Continued on next page.

Chapter 1032 VPN Concepts

Configuring Juniper Networks Firewall/IPSec VPN Products

IKE Phase 1: Main Mode (contd.)


For Message 1 and Message 2, peers exchange cookies and SA proposals. Cookies are 8-byte pseudo-random numbers generated by the sending machine (I=initiator) and receiving machine (R=receptor). Every cookie is unique to the machine and to each particular exchange. These cookies guarantee uniqueness and replay protection by hashing the sender's IP address, port, protocol, and timestamp, which results in a unique identifier known only to the originator. Hence, they are included in every IPsec packet and used to identify the communication. In turn, the receptor inserts its known cookie in Message 2 if it accepts the SA proposal. The initiator sees that the cookies from both parties does not match if a man-in-the-middle generated numerous false messages with a false return address. When the initiator receives the second message with a cookie that is not its own, the communication is simply stopped; further messages are not sent. The ScreenOS device supports up to four SA proposals. An IPsec SA proposal contains the following: Phase 1 authentication method (main mode or aggressive mode); Diffie-Hellman group number; Encryption algorithm; Authentication algorithm; and Key lifetime.

For Message 3 and Message 4, the Diffie-Hellman public values are exchanged to create a common session key. Nonces, which are essentially random numbers, are also exchanged at this time to be used as seeds for keys generated later. After both sides have exchanged their Diffie-Hellman public values, a key is created on each side to encrypt the rest of the IKE Phase 1 messages. The session key is a result of the exchanged public keys being sent to each partner. Messages 5 and 6 contain the preshared key, Diffie-Hellman session key, cookies, and nonces are exchanged to verify identity and validate the new session key.

VPN Concepts Chapter 1033

Configuring Juniper Networks Firewall/IPSec VPN Products

IKE Phase 2: Quick Mode


Once Phase 1 is complete, proposals are exchanged to establish a specific VPN. The following attributes are negotiated in Phase 2: Security protocol (ESP or AH); Tunnel mode or transport mode; Proxy IDs; and Optional DH group.

Upon successful completion of quick mode, user data will be encrypted between the configured IPSec peers. Both tunnel peers must have at least one matching proposal configured for the Phase 2 exchange to be successful. The result of Phase 2 is to create an IPSec VPN for user data to be securely transmitted through the network. Continued on next page.

Chapter 1034 VPN Concepts

Configuring Juniper Networks Firewall/IPSec VPN Products

IKE Phase 2: Quick Mode (contd.)


For Message 1 and Message 2, a Phase 2 proposal list is exchanged, which contains encrypted and authenticated information that determines the algorithms and keys for encrypting and authenticating user data. Again, up to four proposals can be exchanged and as long as one proposal is acceptable.Then, Phase 2 continues to Message 3. The Phase 2 Proposal list contains the following: ESP or AH; Diffie-Hellman group number (0 for no PFS); Encryption algorithm; Authentication algorithm; Key lifetime; Proxy ID (policy rule); and Diffie-Hellman public keys (optional if using PFS).

Message 3 is used to acknowledge information sent from quick mode Message 2 so that the Phase 2 tunnel can be established.

VPN Concepts Chapter 1035

Configuring Juniper Networks Firewall/IPSec VPN Products

IKE Phase 1: Aggressive Mode


IKE aggressive mode is used when one of the tunnel peers has a dynamic IP address, which could be a remote end user dialing in to the Internet, or a remote site using DHCP to acquire an IP address. (Main mode cannot be used because the first two messages validate peer IP addresses. In the case of a dynamic host address, the address cannot be preconfigured at the peer.) Phase 1 aggressive mode must be initiated by the device with the dynamic IP address. The first two messages negotiate policy and exchange Diffie-Hellman public values and nonces. In addition, the second message authenticates the responder; the ID hash is compared with the locally configured peer ID. The third message authenticates the initiator and provides a proof of participation in the exchange.

Chapter 1036 VPN Concepts

Configuring Juniper Networks Firewall/IPSec VPN Products

IPSec Tunnel EstablishmentSummary


To review: IKE Phase 1 establishes a secure channel between gateways using the Diffie-Hellman key exchange. IKE Phase 2 establishes an SA for a specific policy set and VPN. Once Phase 2 is completed successfully, data can flow through the IPSec tunnel. Data will be encrypted (if ESP is used), authenticated, and encapsulated according to IPSec standards.

VPN Concepts Chapter 1037

Configuring Juniper Networks Firewall/IPSec VPN Products

Packet Handling and Receiving: Part 1


The following steps outline the packet handling process: 1. 2. 3. 4. 5. 6. The packet arrives at remote ScreenOS device. The ScreenOS device looks up destination route. The route is crossing zones. The ScreenOS device looks up policy. Traffic matches a tunnel policy. The original packet is encrypted. The packet is hashed with authentication key. The tunnel packet is built with a new IP header, IPSec header, and hash value. The new packet is sent to tunnel peer.

Chapter 1038 VPN Concepts

Configuring Juniper Networks Firewall/IPSec VPN Products

Packet Handling and Receiving: Part 2


The following list is a continuation from the previous page: 7. 8. The corporate ScreenOS device receives the encrypted packet. The corporate ScreenOS device looks up incoming SPI in local SA database. Matching record contains encryption and authentication algorithms, and keys. The device compares locally calculated hash with received hash. The device decrypts packet. The device performs routing lookup for decrypted packet. The device checks policy match for decrypted packet. Forward if tunnel policy exists for packet.

9. 10. 11. 12.

VPN Concepts Chapter 1039

Configuring Juniper Networks Firewall/IPSec VPN Products

This Chapter Discused:


The definition of a VPN; Security concerns and how to address them; The components of the IPSec protocol suite; and The IKE protocol process for tunnel establishment.

Chapter 1040 VPN Concepts

Configuring Juniper Networks Firewall/IPSec VPN Products

Review Questions:
1. 2. 3. 4.

VPN Concepts Chapter 1041

Configuring Juniper Networks Firewall/IPSec VPN Products

Chapter 1042 VPN Concepts

Configuring Juniper Networks Firewall/IPSec VPN Products


Chapter 11: Policy-Based VPNs

Configuring Juniper Networks Firewall/IPSec VPN Products

This Chapter Discusses:


The definition of policy-based VPN; The minimum components needed to configure a policy-based VPN; Configuring an IKE-based VPN; and Verifying operation.

Chapter 112 Policy-Based VPNs

Configuring Juniper Networks Firewall/IPSec VPN Products

Configuration
This slide lists the topics we cover in this chapter. We discuss the highlighted topic first.

Policy-Based VPNs Chapter 113

Configuring Juniper Networks Firewall/IPSec VPN Products

Policy-Based VPN Definition


A policy-based VPN is exactly what the name implies: a policy statement is configured with an action of tunnel. Traffic matching that policy is tunnelled out the VPN specified in the policy statement.

Policy Checking
The policy configuration is also used during the tunnel establishment process. Juniper Networks derives the proxy ID value exchanged during IKE Phase 2 from the policy configuration. These values are compared, and if they do not match, the tunnel is not established.

Chapter 114 Policy-Based VPNs

Configuring Juniper Networks Firewall/IPSec VPN Products

Minimum Configuration Items


Policy-based VPNs have two main configuration components: the VPN itself, and the policy that directs traffic into the tunnel. VPN configuration has two pieces: the IKE Phase 1 gateway configuration, and the IKE Phase 2 VPN configuration. These pieces are separated because you can have multiple Phase 2 VPN configurations using a single Phase 1 gateway.

Policy-Based VPNs Chapter 115

Configuring Juniper Networks Firewall/IPSec VPN Products

Policy-Based VPN Configuration Procedure


The slide outlines the configuration procedure for policy-based VPNs.

Chapter 116 Policy-Based VPNs

Configuring Juniper Networks Firewall/IPSec VPN Products

Step 1a: Configuring the IKE Gateway


The first step in creating an IPSec tunnel using IKE is to create the Phase 1 tunnel. The IKE gateway must be configured at both ends of the tunnel. Also, note the following: Gateway Name: Can be up to 31 characters in length. Remote Gateway Type: Main mode uses a static IP address; select this mode when the IP address of the remote device is statically assigned. The other options are for DHCP and dial-up environments. If these options are selected, the remote gateway must initiate the tunnel connection. This gateway has no idea how to reach the remote gateway. Once the tunnel is established, data can flow in either direction. When selecting the dynamic or dial-up options, IKE performs a simple IP address spoofing check. Another requirement for dynamic addressing is selecting IKE aggressive mode in the Advanced window (on next slide). Preshared Key: This identity is hashed and sent in Messages 5 and 6. If you select Use as Seed, this preshared key will also be used in the Diffie-Hellman exchange to generate the public and private keys. Local ID: Used only when the local Juniper Networks device has a dynamically assigned IP address. If either end of the tunnel has a dynamically assigned address, aggressive mode must be specified. Outgoing Interface: This is the interface providing connectivity to the remote gateway, usually the interface connected to the Internet.

Policy-Based VPNs Chapter 117

Configuring Juniper Networks Firewall/IPSec VPN Products

Step 1a: Configuring the IKE GatewayWebUI


The slide shows how you use the WebUI to configure IKE Phase 1. The preshared key is used for HMAC.

Chapter 118 Policy-Based VPNs

Configuring Juniper Networks Firewall/IPSec VPN Products

Step 1a: Configuring the IKE GatewaySecurity Manager


The slide shows how you configure IKE Phase 1 using Security Manager.

Policy-Based VPNs Chapter 119

Configuring Juniper Networks Firewall/IPSec VPN Products

Step 1b: Advanced IKE Gateway Configuration


Up to four proposals can be passed. Only one proposal must be sent. Proposals that start with pre indicate that the identity will by derived by a preshared key. This is not a key for encryption or authentication but a way to make sure we are who we say we are and that we are not creating a tunnel to the wrong party and giving them access to the internal corporate network. Alternatively, identity could be derived by RSA or DSA, which use digital certificates that have been verified by a certificate authority. The mode selected is main mode because we are communicating with a remote office that has a static IP address. IKE can then perform a simple IP address spoofing check. If either end of the tunnel has a dynamically assigned IP address, aggressive mode must be configured.

Chapter 1110 Policy-Based VPNs

Configuring Juniper Networks Firewall/IPSec VPN Products

Step 1b: Advanced IKE Gateway ConfigurationSecurity Manager


This slide shows the advanced IKE gateway configuration screen in Security Manager.

Policy-Based VPNs Chapter 1111

Configuring Juniper Networks Firewall/IPSec VPN Products

Step 2a: Creating an IKE VPN


The next step in creating an IPSec tunnel using IKE is to create the Phase 2 configuration. Note the following: Name: Required field. 31 bits in length. Remote Gateway: Required field. This is the name of the Phase 1 gateway configuration. sec-level standard: Required field. This is the name of encryption algorithm to be used for securing network traffic.

Chapter 1112 Policy-Based VPNs

Configuring Juniper Networks Firewall/IPSec VPN Products

Step 2a: Creating an IKE VPNWebUI


The slide shows the configuration of IKE phase 2 using the WebUI. You do have the option of creating a gateway on the fly by selecting the Create a Simple Gateway button, then entering the parameters in the box. However, you do not have the option of configuring custom encryption and authentication selections this way.

Policy-Based VPNs Chapter 1113

Configuring Juniper Networks Firewall/IPSec VPN Products

Step 2a: Creating an IKE VPNSecurity Manager


The slide shows the configuration of IKE Phase 2 using Security Manager.

Chapter 1114 Policy-Based VPNs

Configuring Juniper Networks Firewall/IPSec VPN Products

Step 2b: Configuring AutoKey IKEAdvanced


Up to four proposals can be sent, but only one is required. If the proposal list starts with nopfs, perfect forward secrecy is not enabled. Otherwise, it is enabled and a Diffie-Hellman group number is required. You cannot have a nopfs (no perfect forward secrecy) proposal list and a DH group in the same Phase 2 tunnel configuration. For example, nopfs-esp-3des-sha and g2-esp-3des-sha are not a valid proposal offering. Furthermore, the DH group must be the same across the proposal offering. You can prevent replay attacks by enabling the Replay Protection feature. Replay attack is when a hacker intercepts packets and uses them later to flood the system causing denial-of-service (DoS) attacks or to gain access to the internal network. Replay protection causes the Juniper Networks device to check every IPSec packet to see if it has been received before. The Juniper Networks device looks at the sequence number in the ESP header, and if packets arrive out of a specified sequence range, the packets are dropped.

Policy-Based VPNs Chapter 1115

Configuring Juniper Networks Firewall/IPSec VPN Products

Step 3: Object Addresses


As with any other policy statement, you must configure address book entries. We mentioned earlier that the Juniper Networks ScreenOS device uses address book entries to derive the proxy ID exchanged during IKE Phase 2, and that the entries must match on both sides of the tunnel. Names do not have to match, but the IP address definitionaddress and maskmust be identical on each side. In the example on the slide, both Juniper Networks devices are configuring an entry for the home office address. The only difference is that the home office Juniper Networks device defines the entry in the Trust zone, while the corporate office defines the entry in the Untrust zone.

Chapter 1116 Policy-Based VPNs

Configuring Juniper Networks Firewall/IPSec VPN Products

Step 3: Object AddressesWebUI and Security Manager


Address book entries must be added for each side of the tunnel.

Policy-Based VPNs Chapter 1117

Configuring Juniper Networks Firewall/IPSec VPN Products

What Policy Set Is Needed?


Each tunnel peer builds a policy from its perception of the network. The physical network layout on the slide translates differently for each individual firewall, as the slide illustrates. Furthermore, because bidirectional communication is required over the tunnel, each firewall must build two policy statementsone for each direction. Note that to build a policy-based tunnel, the outgoing interface of the tunnel must be in a different zone from the user traffic. A policy is needed to direct information to the tunnel. If the user traffic and the outgoing interface for the tunnel are in the same zone, you must configure a route-based VPN (which we discuss in the next chapter).

Chapter 1118 Policy-Based VPNs

Configuring Juniper Networks Firewall/IPSec VPN Products

Step 5: Configuring a VPN Policy


For a VPN policy, select your address book entries and services as before. The action you select now is tunnel. Then select the VPN to be used for this policy.

Policy-Based VPNs Chapter 1119

Configuring Juniper Networks Firewall/IPSec VPN Products

Step 4: Configuring a VPN PolicyWebUI


For a VPN policy, select your address book entries and services as before. The action you select now is tunnel. Then select the VPN to be used for this policy. Make sure you click the check box modifying the matching bidirectional policy. Because a VPN requires bidirectional communication, policies in both directions are required. This check box offers a shortcut. You can also click the Position at Top check box; VPN policies typically should be at the top of your policy list.

Chapter 1120 Policy-Based VPNs

Configuring Juniper Networks Firewall/IPSec VPN Products

Step 4: Configuring a VPN PolicySecurity Manager


Configuring the VPN policy using Security Manager has a few steps. You must first go to the policy configuration screen for the device. Next, add two VPN rules to the current policy. Then right-click each VPN rule and assign the IPSec VPN policy to the device policy.

Policy-Based VPNs Chapter 1121

Configuring Juniper Networks Firewall/IPSec VPN Products

Verifying Operations
The slide highlights the topic we discuss next.

Chapter 1122 Policy-Based VPNs

Configuring Juniper Networks Firewall/IPSec VPN Products

Verifying Tunnels: Part 1


The tunnel is not established until user traffic triggers the IKE process. You can use any traffic that matches the tunnel policy to initiate the tunnel connection. On the slide, we used the ability of the Juniper Networks device to select the source address for ping to trigger tunnel establishment. By pinging from the trust interface to a destination on the other side of the tunnel, we match the tunnel policy. Note that the first packet or two of a session might time out while the IKE negotiations take place.

Policy-Based VPNs Chapter 1123

Configuring Juniper Networks Firewall/IPSec VPN Products

Verifying Tunnels: Part 2


Use the get ike cookie command to verify that Phase 1 was completed successfully. If there is a problem with Phase I, no cookie is created. Output includes the key lifetimes for both the local and remote end, the next rekeying time, and the Phase 1 proposal chosen in IKE Messages 1 and 2. If an IKE cookie is not displayed for the tunnel, Phase 1 failed, and we must proceed to troubleshooting. To verify the successful completion of Phase 2, use the get sa command. Look under the status column; an A indicates that the tunnel is active. An I indicates Inactive. The Life columns indicate rekey intervals. IKE standards state that you can rekey after a certain time interval or a certain amount of data has been sent. Phase 2 cannot begin until Phase 1 is complete.

Chapter 1124 Policy-Based VPNs

Configuring Juniper Networks Firewall/IPSec VPN Products

Common Configuration Errors


Because of the many configuration elements that must be coordinated between two devices, VPN configuration can be complicated. The most common errors are listed here: Address book errors: Address book entries do not match. Proposal mismatch: The proposal list configured on each side does not agree. Preshared key mismatch: The key does not match. No route information: To establish the gateway connection, you must have a route to reach the gatewayeither an explicit route or a default route.

Policy-Based VPNs Chapter 1125

Configuring Juniper Networks Firewall/IPSec VPN Products

Troubleshooting Tools
The best tool for troubleshooting VPN setup issues is the system event log. The ScreenOS device captures a summary of IKE communications in this log, and it is easily interpretable. We will look at the event log, plus the commands listed on the slide, in more detail on the next few pages. Remember that VPN problems might not be VPN-specific problems, but because we discussed routing and policy issues in other chapters, we will focus on VPN setup specifically.

Chapter 1126 Policy-Based VPNs

Configuring Juniper Networks Firewall/IPSec VPN Products

Troubleshooting Tools
You can use the system log output to troubleshoot VPN establishment problems. You can access these logs using the WebUI or the CLI; the remaining slides show CLI output.

Policy-Based VPNs Chapter 1127

Configuring Juniper Networks Firewall/IPSec VPN Products

Phase 1Unrecognized Peer


Because setting up a tunnel involves two devices, each device receives its own output in the event log. The initiator is the device attempting to bring up the tunnel (that is, the device that sent the first message); the responder is the remote gateway defined at the initiator. For most problems, it is the responder device that reports the actual cause of the problem in the log. In the example on the slide, the responder did not recognize the incoming request as originating with a valid gateway peer. This issue might be caused by one of the three following misconfigurations at the responder: Peer gateway address misconfigured; Peer ID misconfigured; or Outgoing interface is incorrect.

Chapter 1128 Policy-Based VPNs

Configuring Juniper Networks Firewall/IPSec VPN Products

Phase 1Proposal Mismatch


In the example on the slide, the Phase 1 proposals do not match. The initiator simply sees retransmissions and a retransmission limit indicator. The responder shows the problem; all proposals sent by the initiator were rejected.

Policy-Based VPNs Chapter 1129

Configuring Juniper Networks Firewall/IPSec VPN Products

Phase 2Proposal Mismatch


If Phase 2 proposals do not match, both the initiator and responder report the problem.

Chapter 1130 Policy-Based VPNs

Configuring Juniper Networks Firewall/IPSec VPN Products

Phase 2Proxy ID Mismatch: Part 1


In the case of a proxy ID mismatch, the responder has all the information. The initiator simply reports that Phase 2 failed, then records no other output. At the responder, the output in the system log shows the address book entries configured at the initiator. The administrator of the responder can then compare that information with the local address book and make corrections on the appropriate device.

Policy-Based VPNs Chapter 1131

Configuring Juniper Networks Firewall/IPSec VPN Products

Phase 2Proxy ID Mismatch: Part 2


If you are the receiver, the proxy ID sent by your peer is displayed in the event log. You can check your own proxy ID with the command get policy id number. In this case, the mismatch is obviousthe receivers local settings bear no resemblance to the proxy ID received from the sender.

Chapter 1132 Policy-Based VPNs

Configuring Juniper Networks Firewall/IPSec VPN Products

Fixing the Mismatch


In this case, the receiver is wrong; however, the procedure to change proxy ID is the same for either device. The addresses used in the policy must be set to the correct values. Compare the proxy ID shown on this slide with the one received in the previous slide. Now they match. The slide shows correcting the values using the CLI. Because of internal dependencies, the policies and existing address book entries must be erased and recreated. In this case, the WebUI is easier to use as you do not have to remove the policies before editing the address book entries.

Policy-Based VPNs Chapter 1133

Configuring Juniper Networks Firewall/IPSec VPN Products

This Chapter Discussed:


The definition of policy-based VPN; The minimum components needed to configure a policy-based VPN; Configuring an IKE-based VPN; and Verifying operation.

Chapter 1134 Policy-Based VPNs

Configuring Juniper Networks Firewall/IPSec VPN Products

Review Questions:
1. 2. 3.

Policy-Based VPNs Chapter 1135

Configuring Juniper Networks Firewall/IPSec VPN Products

Lab 8: Policy-Based VPNs


The slide lists the objectives for this lab.

Chapter 1136 Policy-Based VPNs

Configuring Juniper Networks Firewall/IPSec VPN Products


Chapter 12: Route-Based VPNs

Configuring Juniper Networks Firewall/IPSec VPN Products

This Chapter Discusses:


The concepts of a route-based VPN; Configuring route-based VPNs; and Verifying operation.

Chapter 122 Route-Based VPNs

Configuring Juniper Networks Firewall/IPSec VPN Products

Concepts and Terminology


This slide lists the topics we cover in this chapter. We discuss the highlighted topic first.

Route-Based VPNs Chapter 123

Configuring Juniper Networks Firewall/IPSec VPN Products

Route-Based VPNs: Part 1


When using policy-based VPNs, a separate VPN is created for each policy configured. If you have 20 policy statements controlling which traffic will be sent between the remote office and corporate office, you will have 20 VPNs established using the same gateway pair. Route-based VPNs separate the policy configuration from the VPN configuration. The VPN is built using tunnel interfaces, creating a point-to-point connection between two sites similar to a Frame Relay link or leased line between routers. Routing is used to direct traffic through the tunnel based solely on IP address. You can then use permit/deny policies to control traffic flow without the need for multiple VPNs being established. In fact, you can dispense with policies altogether if you do not require host-level or application-level controls for traffic coming from the remote site to the corporate site. If the tunnel interface is created in the same zone as the arriving traffic, no policy lookup is required.

Chapter 124 Route-Based VPNs

Configuring Juniper Networks Firewall/IPSec VPN Products

Route-Based VPNs: Part 2


Route-based VPNs use tunnel interfaces to build point-to-point connections between sites. Routing directs traffic to the remote site using the tunnel interface, where it is encrypted and encapsulated before being transported through the public network. The destination of the encrypted packet is the tunnel peer, just as it was with policy-based VPNs. The association between the tunnel interface and the VPN configuration is done through a binding; the VPN configuration determines which encryption and authentication algorithms will be used for tunnelled traffic.

Route-Based VPNs Chapter 125

Configuring Juniper Networks Firewall/IPSec VPN Products

Tunnel Interfaces
A tunnel interface is a virtual interface; it has no physical existence. However, it is still an IP interface and needs the same basic configuration as any other interface: zone assignment, interface number (tunnel.x), and IP addressing.

Chapter 126 Route-Based VPNs

Configuring Juniper Networks Firewall/IPSec VPN Products

Tunnel Interface: Fixed IP Address


If you choose to assign an IP address to the tunnel interface, you must follow the same IP rules you would for any other interface; that is, the address must be a unique subnet within the virtual router (VR) to which the interface is bound. No overlapping addresses are allowed. If you must perform address translation using MIP or DIP addresses, the tunnel interface must have an IP address so as to be configured with a MIP or DIP address pool. If you do address the tunnel interface, and if both devices that make up the tunnel are using route-based VPNs, the tunnel interfaces must be in the same subnet for routing to function properly.

Route-Based VPNs Chapter 127

Configuring Juniper Networks Firewall/IPSec VPN Products

Tunnel Interfaces: Unnumbered IP Address


An unnumbered IP address allows you to configure an interface without having to specify a unique IP address. When specifying unnumbered, the system borrows an IP address from another interface and uses that address as the source IP address whenever information is initiated from the tunnel interface. The interface from which the system is borrowing the IP address must be in the same zone as the tunnel interface. Using unnumbered IP addresses preserves your IP address space; you do not have to use up subnets for these logical point-to-point links.

Chapter 128 Route-Based VPNs

Configuring Juniper Networks Firewall/IPSec VPN Products

Configuring VPNs
The slide highlights the topic we discuss next.

Route-Based VPNs Chapter 129

Configuring Juniper Networks Firewall/IPSec VPN Products

Route-Based VPN Configuration


Configuring a route-based VPN consists of creating a tunnel interface, configuring the gateway and VPN as we discussed in the last chapter, and configuring the appropriate routing entries.

Chapter 1210 Route-Based VPNs

Configuring Juniper Networks Firewall/IPSec VPN Products

Step 1: Creating the Tunnel Interface


There is a limit to the number of tunnel interfaces that can be configured on the Juniper Networks device. For example, the NS-208 can have 100 tunnel interfaces. As with any other interface, the tunnel interface must be bound to a zone to function. If the tunnel interface is bound to the same security zone as the source of the traffic to be tunnelled, the ScreenOS device requires no policies for traffic forwarding; the ingress and egress interfaces are in the same zone. (If intrazone blocking is enabled, a policy is still required.) If the tunnel interface is bound to a different zone, the device requires a permit policy to allow traffic to pass through the tunnel. This idea is not the same as a policy-based VPN; the policy action is permit, not tunnel. The tunnelling action is accomplished through a route directing traffic through the tunnel interface.

Route-Based VPNs Chapter 1211

Configuring Juniper Networks Firewall/IPSec VPN Products

Step 1: Creating a Tunnel InterfaceWebUI and Security Manager


The slide shows the tunnel interface configuration process using the WebUI and Security Manager.

Chapter 1212 Route-Based VPNs

Configuring Juniper Networks Firewall/IPSec VPN Products

Step 2: Configuring the IKE Gateway


The IKE gateway must be configured at both ends of the tunnel: Gateway Name: This name can be up to 31 characters in length. Remote Gateway Type: Main mode uses a static IP address; select this address when the IP address of the remote device is statically assigned. The other options are for DHCP and dial-up environments. If these options are selected, the remote gateway must initiate the tunnel connection. This gateway has no idea how to reach the remote gateway. Once the tunnel is established, data can flow in either direction. When selecting the dynamic and dial-up options, IKE performs a simple IP address spoofing check. Another requirement for dynamic addressing is selecting IKE aggressive mode in the Advanced window (see next slide). Preshared Key: This is the identity that will be hashed and sent in Messages 5 and 6. If you select Use as Seed, this preshared key will also be used in the Diffie-Hellman exchange to generate the public and private keys. Local ID: This setting is used only when the local Juniper Networks device has a dynamically assigned IP address. If either end of the tunnel has a dynamically assigned address, aggressive mode must be specified. Outgoing Interface: This interface provides connectivity to the remote gateway, usually the interface connected to the Internet.

Route-Based VPNs Chapter 1213

Configuring Juniper Networks Firewall/IPSec VPN Products

Step 2: Configuring the IKE GatewayWebUI


Configuring an IKE Gateway is the same whether it is used in a policy-based VPN or route-based VPN configuration.

Chapter 1214 Route-Based VPNs

Configuring Juniper Networks Firewall/IPSec VPN Products

Step 2: Configuring the IKE GatewaySecurity Manager


The slide shows how you configure an IKE gateway using Security Manager. You can enable NAT traversal using this window.

Route-Based VPNs Chapter 1215

Configuring Juniper Networks Firewall/IPSec VPN Products

Step 3: Creating AutoKey IKE


For route-based VPNs, the Phase 2 configuration changes slightly. The command is still the sameselect the encryption and authentication methods for the tunnel, and select the Phase 1 gateway. Then bind the Phase 2 VPN to the tunnel interface.

Chapter 1216 Route-Based VPNs

Configuring Juniper Networks Firewall/IPSec VPN Products

Step 3: Creating Auto-Key IKEWebUI


For route-based VPNs, the Phase 2 configuration changes slightly. The basic screen is still the sameselect the encryption and authentication methods for the tunnel, and select the Phase 1 gateway. Then click the Advanced button to bind the Phase 2 VPN to the tunnel interface. Because no policies are associated with this VPN configuration, the proxy ID fields are set to all zeros. If this setting does not match the proxy ID generated by the tunnel peer, the Phase 2 negotiations will fail. If both tunnel peers are using route-based VPNs, both peers will have a proxy ID of all zeros. The tunnel will work, but you might have difficulty supporting multiple VPNs using the same gateway. Therefore, it is a good idea to set the proxy ID even though it might not be necessary for tunnel establishment.

Route-Based VPNs Chapter 1217

Configuring Juniper Networks Firewall/IPSec VPN Products

Step 3: Creating AutoKey IKESecurity Manager


The slide shows how you configure AutoKey IKE using Security Manager. For route-based VPNs, the Phase 2 configuration changes slightly. The basic screen is still the sameselect the encryption and authentication methods for the tunnel, and select the Phase 1 gateway. Then click the Binding\Proxy ID tab to bind the Phase 2 VPN to the tunnel interface.

Chapter 1218 Route-Based VPNs

Configuring Juniper Networks Firewall/IPSec VPN Products

Step 4: Configuring Routing


The next step is to configure routing to the remote networks using the tunnel interface as the outbound interface. Because the tunnel is point to point, you do not have to specify a gateway address.

Route-Based VPNs Chapter 1219

Configuring Juniper Networks Firewall/IPSec VPN Products

Step 4: Configuring RoutingWebUI and Security Manager


Using the WebUI or Security Manager, configure routing to the remote networks. Make sure you select tunnel.1 as the interface for the new routing entry.

Chapter 1220 Route-Based VPNs

Configuring Juniper Networks Firewall/IPSec VPN Products

Step 5: Creating Policies


Depending on the tunnel interface/zone configuration, you might or might not need policies.

Route-Based VPNs Chapter 1221

Configuring Juniper Networks Firewall/IPSec VPN Products

Verifying Operations
The slide highlights the topic we discuss next.

Chapter 1222 Route-Based VPNs

Configuring Juniper Networks Firewall/IPSec VPN Products

Verifying Configuration: Part 1


To verify connectivity, generate user traffic from your local private network to the remote private network. For simplicity, an alternative is to generate a ping locally on the Juniper Networks device using the CLI to a remote device. To test VPN connectivity between both Juniper Networks private networks without having to rely on end devices being set up correctly, an extended ping generated from the CLI in combination with the source interface specified takes the source IP address as the private Juniper Networks interface, and it also takes the remote IP address as the remote Juniper Networks interface. This ping, which specifies eth0/1, ensures that it passes through the VPN, depending on how the policies (if any) are configured.

Route-Based VPNs Chapter 1223

Configuring Juniper Networks Firewall/IPSec VPN Products

Verifying Configuration: Part 2


Use the get ike cookie command to verify that Phase 1 was completed successfully. If there is a problem with Phase I, no cookie is created. Output includes the key lifetimes for both the local and remote end, the next rekeying time, and the Phase 1 proposal chosen in IKE Messages 1 and 2. If an IKE cookie is not displayed for the tunnel, Phase 1 failed, and we must proceed to troubleshooting. To verify the successful completion of Phase 2, use the get sa command. Look under the status column; an A indicates that the tunnel is active. An I indicates inactive. Phase 2 cannot begin until Phase 1 is complete.

Chapter 1224 Route-Based VPNs

Configuring Juniper Networks Firewall/IPSec VPN Products

Issues and Common Misconfigurations: Part 1


We discussed some of the common mistakes in the last chapter; route-based VPNs have some additional potential pitfalls. Because the proxy ID for a route-based VPN defaults to zero, the potential for a mismatch is high, especially if the tunnel peer is using a policy-based configuration. If NAT is required but the tunnel interface is not assigned an IP address, NAT will not function properly. If the tunnel interface is not in the same zone as the origin of the traffic to be tunneled, you must configure a policy. If the policy does not exist, the default deny policy will block traffic for interzone traffic.

Route-Based VPNs Chapter 1225

Configuring Juniper Networks Firewall/IPSec VPN Products

Issues and Common Misconfigurations: Part 2


Depending on the zones used, intrazone blocking might be enabled by default. If this is the case, traffic will not be allowed to pass even though the ingress and tunnel interface are in the same zone. If this is your configuration and traffic is not flowing, check the zone configuration to see if intrazone blocking is enabled. Finally, if the forwarding table does not correctly associate the destination network with the tunnel interface, traffic cannot be forwarded.

Chapter 1226 Route-Based VPNs

Configuring Juniper Networks Firewall/IPSec VPN Products

Troubleshooting Tools
The best tool for troubleshooting VPN setup issues is the system event log. The ScreenOS device captures a summary of IKE communications in this log, and the log is easily interpretable. We will look at the event log, plus the commands listed on the slide, in more detail on the next few pages. Remember that VPN problems might not be VPN-specific problems, but because we discussed routing and policy issues in other chapters, we will focus on VPN setup specifically.

Route-Based VPNs Chapter 1227

Configuring Juniper Networks Firewall/IPSec VPN Products

Troubleshooting Tools
Because setting up a tunnel involves two devices, each device receives its own output in the event log. The initiator is the device attempting to bring up the tunnel (that is, the device that sent the first message); the responder is the remote gateway defined at the initiator. For most problems, it is the responder device that reports the actual cause of the problem in the log. In the example on the slide, the responder did not recognize the incoming request as originating with a valid gateway peer. This issue could be caused by one of the following three misconfigurations at the responder: Peer gateway address misconfigured; Peer ID misconfigured; or Outgoing interface is incorrect.

Chapter 1228 Route-Based VPNs

Configuring Juniper Networks Firewall/IPSec VPN Products

This Chapter Discussed:


The concepts of a route-based VPN; Configuring route-based VPNs; and Verifying operation.

Route-Based VPNs Chapter 1229

Configuring Juniper Networks Firewall/IPSec VPN Products

Review Questions:
1. 2. 3.

Chapter 1230 Route-Based VPNs

Configuring Juniper Networks Firewall/IPSec VPN Products

Lab 9: Configuring Route-Based VPNs


The slide lists the objective for this lab.

Route-Based VPNs Chapter 1231

Configuring Juniper Networks Firewall/IPSec VPN Products

Chapter 1232 Route-Based VPNs

Configuring Juniper Networks Firewall/IPSec VPN Products


Appendix A: Additional Features

Configuring Juniper Networks Firewall/IPSec VPN Products

This Chapter Discusses:


Juniper Networks hardware.

Appendix A2 Additional Features

Configuring Juniper Networks Firewall/IPSec VPN Products

Hardware
The slide shows the topic we cover in this appendix.

Additional Features Appendix A3

Configuring Juniper Networks Firewall/IPSec VPN Products

Performance: Purpose-Built Hardware Platform


Purpose-built hardware is the foundation of rock-solid security. This hardware has many advantages over other solutions.

Appendix A4 Additional Features

Configuring Juniper Networks Firewall/IPSec VPN Products

Performance: Advanced Hardware Design


The advanced hardware design has a unique architecture over PC appliances.

Additional Features Appendix A5

Configuring Juniper Networks Firewall/IPSec VPN Products

This Chapter Discussed:


Juniper Networks hardware.

Appendix A6 Additional Features