Configuring Juniper Networks FW_VPN

1194 North Mathilda AvenueSunnyvale, CA 94089USA408-745-2000www.juniper.net

Configuring Juniper Networks Firewall/IPSec VPN Products5.b

Student Guide

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.

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.

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.b—April 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.

Contents • iii

Contents

Chapter 1: Course Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-1

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

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

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

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

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

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

iv • Contents

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

Chapter 9: Transparent Mode (Optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-1Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-3Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-11Verifying Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-22Lab 7: Transparent Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-31

Chapter 10: VPN Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-1Concepts and Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-3IP Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-19

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

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

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

. Course Overview • v

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.

vi • Course Agenda

Course Agenda

Day 1

Chapter 1: Course Introduction

Chapter 2: ScreenOS Concepts, Terminology, and Platforms

Chapter 3: Initial Connectivity

Chapter 4: Device Management

Day 2

Chapter 5: Layer 3 Operations

Chapter 6: Basic Policy Configuration

Chapter 7: Policy Options

Chapter 8: 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

Document Conventions • vii

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.

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 Description Usage Example

Franklin Gothic

Normal text. Most of what you read in the Lab Guide and Student Guide.

Courier New

Console text:

• Screen captures

• Noncommand-related syntax

commit complete

Exiting configuration mode

Century Gothic

GUI text elements:

• Menu names

• Text field entry

Select File > Open, and then click Configuration.conf in the Filename text box.


Normal CLI

Normal GUI

No distinguishing variant. Physical interface:fxp0, Enabled

View configuration history by clicking Configuration > History.

CLI Input

GUI Input

Text that you must enter. lab@San_Jose> show route

Select File > Save, and enter config.ini in the Filename field.

viii • Document Conventions

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.


CLI Variable

GUI Variable

Text where variable value is already assigned.

policy my-peers

Click on my-peers in the dialog.

CLI Undefined

GUI Undefined

Text where the variable’s value is the user’s discretion and text where the variable’s value as shown in the lab guide might differ from the value the use must input.

Type set policy policy-name.

ping 10.0.1.1

Select File > Save, and enter filename in the Filename field.

Additional Information • ix

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 [email protected]

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

x • Additional Information

Configuring Juniper Networks Firewall/IPSec VPN Products

Chapter 1: Course Introduction


Chapter 1–2 • Course Introduction

This Chapter Discusses:

• Objectives and course content information;

• Additional Juniper Networks courses; and

• Juniper Networks Technical Certification Program.


Course Introduction • Chapter 1–3

Introductions

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



Course Contents

This slide lists the topics we discuss in this course.



Prerequisites

This slide lists the prerequisites for this course.



General Course Administration

This slide documents general aspects of classroom administration.



Training and Study Materials

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



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.



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.



Service Provider Curriculum: JUNOSe Platforms

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



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.



Security Curriculum

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



WX Curriculum

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



DX Curriculum

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



Technical Certification Programs: Routing Tracks

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



Technical Certification Programs: Security Tracks

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



Technical Certification Programs: WX Track

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



The JNCIA Certification

This slide details the JNCIA certification level.



The JNCIS Certification

This slide details the JNCIS certification level.



The JNCIP Certification

This slide details the JNCIP certification level.



The JNCIE Certification

This slide details the JNCIE certification level.



Prepping and Studying

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



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.




Chapter 2: ScreenOS Concepts, Terminology, and Platforms


Chapter 2–2 • ScreenOS Concepts, Terminology, and Platforms


• 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 2–3

Security Device Requirements

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



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.



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.



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.



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.



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.



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 Security Architecture

The slide highlights the topic we discuss next.



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.



Security Architecture Components

Interfaces are connections to specific subnets. Different Juniper Networks devices use different names—interface 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 setup—all 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.



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.



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.



Zones and Interfaces

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



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.



Interface Designations

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



Virtual Interfaces

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



Interface Configuration—Layer 1 and Layer 2

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



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 headers—source and destination IP addresses, source and destination port numbers, and packet sequence numbers—and maintains the state of each TCP session and pseudo-UDP session traversing the firewall. (The device also modifies session states based on changing elements such as dynamic port changes or session termination.) When a responding TCP packet arrives, the device compares the information reported in its header with the state of its associated session stored in the inspection table. If they match, the responding packet is allowed to pass the firewall. If the information in the header does not match the state of its associated session, the packet is dropped.



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.



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.



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. The interface module identifies the incoming interface and, consequently, the source zone to which the interface is bound.

2. If you enabled SCREEN options for the source zone, the security device activates the SCREEN module at this point.

3. The session module performs a session lookup, attempting to match the packet with an existing session. If the packet does not match an existing session, the security device performs first-packet processing, a procedure involving the following Steps 4 through 9.

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

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

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




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

8. The session module creates a new entry in the session table containing the results of Steps 1 through 7. The security device then uses the information maintained in the session entry when processing subsequent packets of the same session.

9. The security device performs the operation specified in the session. Some typical operations are source address translation, VPN tunnel selection and encryption, decryption, and packet forwarding.



Packet Flow Example: Part 1

Let’s 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.




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. Based on a lookup in the session table, we determine that this is not an existing session.

2. The forwarding table shows that we know how to reach the destination network.

3. The interfaces are in different zones, so we must examine the associated policy.




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.



Juniper Networks Platforms




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




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.



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.



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.



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.



ISG Product Line

The Juniper Networks Integrated Security Gateway (ISG) devices are purpose-built, security solutions that leverage a fourth-generation security ASIC—the 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.



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.



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



System Deployment

On this slide, a Juniper Networks firewall/VPN system—the NS-5400 device—is 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.



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.



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.



Review Questions

1.

2.

3.

4.


Chapter 3: Initial Connectivity


Chapter 3–2 • Initial Connectivity


• 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 3–3

System Components




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.



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.



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



CLI—Functionality

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.



Display Status Information—CLI

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.




Display Status Information—CLI (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.



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.



Main Screen—WebUI

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.



Security Manager characteristics

The ideal approach combines the best of both device-based and policy-based approaches—an 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.



Device-Based Management with Security Manager

On the slide, you can see that the ScreenOS WebUI and the Security Manager’s 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.



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 configuring—and possibly misconfiguring—each side of a VPN connection, you define VPNs at a single point, then configuration information is pushed out to the individual devices.



Establishing Connectivity




Administrative Access—Configuration 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.



Interface Configuration Procedure

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



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.



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




Zone Types (contd.)

• HA: This zone hosts the high-availability interfaces—HA1 and HA2—on 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.



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.



Securing Administrator Traffic

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



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.



Management Services—WebUI

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.



Management Services—Security Manager

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



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.



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.



Default Route—WebUI

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.



Default Route—Security 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.



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.



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.



Creating System Administrators

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



Timeout—Console

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 consoleConsole timeout: 120(minute), Page size: 22/22, debug: bufferprivilege 250, config has not been changed!ID State Duration Task Type Host 0 Logout 0 2816 Local 2 Login 6190 4928 Localns208->



Timeout—WebUI

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



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.



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.



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.



Layer 1 and Layer 2 Configuration

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



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.



Verifying Connectivity




Verifying Connectivity

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



Verifying Interface Configuration—CLI

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.



Verifying Interface Configuration—WebUI

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



Verifying Administrators—CLI

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.



Verifying Administrators—WebUI

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



Verifying the Manage IP Address—CLI

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]




• System component functions;

• Establishing connectivity to the Juniper Networks device using the console and the network; and

• Configuring administrative settings and options.



Review Questions

1.

2.



Lab 1: Initial Configuration

The slide lists the objectives for this lab.




Chapter 4: Device Management


Chapter 4–2 • Device Management


• Connecting to external management devices;

• Managing license keys;

• Managing configuration and software image files; and

• Performing disaster recovery procedures.


Device Management • Chapter 4–3

Management




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.



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.



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.



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.



SNMP Configuration

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



SNMP Configuration—WebUI: 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.



SNMP Configuration—WebUI: 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.



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.



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.



Managing License Keys—Security 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.



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 station’s hard drive for file storage.



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.



Configuration File Management—CLI

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



Configuration File Management—WebUI

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



Configuration Management—Security Manager

You can use the device configuration screen in Security Manager to import and export a device’s 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).



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.



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.



Upgrade Example—CLI

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.



Upgrade Example—WebUI

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.



Upgrade Example—Security 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.



Recovery




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.



Recovering the ScreenOS Image—Boot 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.



Recovering the ScreenOS Image—Boot 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.



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!




• Connecting to external management devices;

• Managing license keys;

• Managing configuration and software image files; and

• Performing disaster recovery procedures.



Review Questions

1.

2.



Lab 2: Device Administration





Chapter 5: Layer 3 Operations


Chapter 5–2 • Layer 3 Operations


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


Layer 3 Operations • Chapter 5–3

Need for Routing




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.



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.



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.



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 table—if 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 information—or 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.



Virtual Routers—One VR

Thus far, we have looked at the Juniper Networks firewall as a single router. All networks—both private and public—are 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.



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.



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.



Configuring Layer 3




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.



Configuring for Layer 3 Operations

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



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 CLI—use 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.



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.



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.



Step 3: Assigning IP Addresses to Interfaces: Part 1

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



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.



Step 4: Configuring Static Routes: Part 1

Make sure that when using the CLI you include the next-hop gateway—even 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.



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.



Verifying Layer 3




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.



Verifying Static Routes—CLI

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.



Verifying Static Routes—WebUI

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.



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.




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.




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.



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.



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.



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.



Troubleshooting Tools—Output 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.



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



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.



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.



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.



Debug Procedure

The effective use of debug follows a specific process:

1. Get the output of ffilter to check for existing debug filters.

2. Set some flow filters on the debug data stream.

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

4. Clear the debug buffer. The debug buffer displays the oldest information first. Clearing the debug buffer avoids having to search through old output.

5. Issue the ping command (or whatever command is being used to generate traffic). The debug buffer captures the result.

6. Disable debug to terminate output going to the debug buffer.

7. Use get dbuf stream to analyze the output from the debug utility.

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



Debug Flow Basic—Case 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.



Debug Flow Basic Output: Part 1

The output from the debug utility in the debug buffer shows the following sequence of events:

1. First, the device performs a sanity check, verifying that the packet is an IP packet.

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

3. The device performs a route lookup. We routed from the eth0/5 interface to the eth0/6 interface.

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

5. The device finds a matching policy. (Again, to see the exact parameters of the policy, we must use the get policy id number command.)



Debug Flow Basic Output: Part 2

This list is a continuation from the previous page:

6. The device creates a session for this packet.

7. The device performs an ARP lookup and finds an entry in the ARP cache.

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



Debug Flow Basic—Existing 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.



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.



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.



Loopback Interface




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.



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 interface—you 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.



Interface-Based NAT




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.



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.



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.



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.



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.



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.



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.



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.




• 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




Review Questions

1.

2.

3.

4.



Lab 3: Layer 3 Operations





Chapter 6: Basic Policy Configuration


Chapter 6–2 • Basic Policy Configuration


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


Basic Policy Configuration • Chapter 6–3

Functionality




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.



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.



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 4–7 information), and action. We cover additional options for each policy statement in the next chapter.



Policy Configuration




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.



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 addresses—individual 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?



Step 1: Creating Address Book Entries—CLI

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.



Step 1: Creating Address Book Entries—WebUI: 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.



Step 1: Creating Address Book Entries—WebUI: 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 conventions—location names, workgroup names, and so on—as 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.



Step 1: Creating Address Book Entries—Security Manager

You can add global address objects using this window.



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



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.



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



Step 3: Creating Policy Entries—CLI

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.



Step 3: Creating Policy Entries—WebUI: 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.



Step 3: Creating Policy Entries—WebUI: 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.



Step 3: Creating Policy Entries—Security 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.



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 list—which 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.



Step 4: Reordering Policies—CLI

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



Step 4: Reordering Policies—WebUI: Part 1

Using the WebUI, you have two options for sorting your policies—the 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.



Step 4: Reordering Policies—WebUI: 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.



Step 4: Reordering Rules—Security Manager

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



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 system—or 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.



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.



Creating Address Groups—CLI

The slide shows the CLI commands for creating address groups.



Creating Address Groups—WebUI

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.



Creating Address Groups—Security 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.



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.



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.



Viewing Service Groups

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



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.



Multicell Policy Creation—CLI

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.



Multicell Policy Creation—WebUI: 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.



Multicell Policy Creation—WebUI: 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.



Multicell Rule Creation—Security Manager

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



Viewing Multicell Policies

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



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.



Common Problems




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.



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.



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.



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.



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.



Global Policy




Global Zone

You can use the global zone to create default policies. If you have traffic that you always want to permit—whether it is from specific sources, to specific destinations, or to specific services—you 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.



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.



Verifying Policies




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.



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.

2. Currently, only two policies are defined—policy 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.



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.

2. Clear the debug buffer. The debug buffer displays the oldest information first. Clearing the debug buffer avoids having to search through old output.

3. Issue the ping command (or whatever command is being used to generate traffic). The result is captured in the debug buffer.

4. Disable debug to terminate output going to the debug buffer.

5. Use get dbuf stream to analyze the output form the debug utility.

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



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.



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.




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



Review Questions

1.

2.

3.



Lab 4: Basic Policy Configuration

The slide shows the objective for this lab.


Chapter 7: Policy Options


Chapter 7–2 • Policy Options


• Configuring policy options; and

• Verifying the operations of policy options.


Policy Options • Chapter 7–3

Overview




Policy Options—Main 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.



Advanced Policy Options—WebUI: 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.



Advanced Policy Options—WebUI: 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.



Advanced Policy Options—Security 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.



Advanced Policy Options—Security 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.



Logging




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.



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.



Configuring Traffic Logs: Part 2

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



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.



Counting




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.



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.



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.



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.



Scheduling




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.



Configuring Policy Scheduling

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



Creating a Schedule—CLI

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



Creating a Schedule—WebUI

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.



Creating a Schedule—Security 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.



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.



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.



User Authentication




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 user’s 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



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.



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.



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.



Authentication Configuration Steps

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



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.



Step 1: Creating a User Database—WebUI

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



Step 1: Creating a User Database—Security Manager

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



Step 2: Configuring an Authentication Policy

The CLI commands used to enable authentication policy are straightforward.



Step 2: Configuring an Authentication Policy—WebUI 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.



Step 3: Configuring a WebAuth Address

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



Step 3: Configuring a WebAuth Address—WebUI 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.



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.




• Configuring policy options; and

• Verifying the operations of policy options.



Review Questions

1.

2.

3.

4.



Lab 5: Policy Options





Chapter 8: Address Translation


Chapter 8–2 • Address Translation


• Policy-based Network Address Translation (NAT) options;

• Configuring address translation features; and

• Verifying NAT mode operation.


Address Translation • Chapter 8–3

Scenarios




Interface-Based NAT—Review

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.



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 translation—unidirectional 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.



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.



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.



NAT-src




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 interface—either 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 interfaces—each DIP address set has a unique identifier that must be in the range of 4–255.



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.



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.




NAT-src Examples (contd.)

The following table might illustrate IP address shifting more clearly:

Pretranslation Post-translation

10.1.1.5 1.1.8.10

10.1.1.6 1.1.8.11

10.1.1.7 1.1.8.12

10.1.1.8 1.1.8.13

10.1.1.9 1.1.8.14



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.



Step 1: Creating a DIP Address—CLI

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



Step 1: Creating a DIP Address—WebUI

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.



Step 1: Creating a DIP Address—Security 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.



Step 1: Creating a DIP Address—Security 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.



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.



Step 2: Creating a Policy—WebUI

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



Step 2: Creating a Policy—Security 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.



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.



Verifying NAT-src Options—CLI

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.



Verifying NAT-src—WebUI

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.



NAT-dst




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.



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.



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.



NAT-dst Configuration Procedure

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



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.



Step 1: Configuring an Address Book Entry—WebUI and Security Manager

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



Step 2a: Configuring Reachability—Secondary 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.



Step 2a: Configuring Reachability—Secondary Address—WebUI and Security Manager

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



Step 2b: Configuring Reachability—Static 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.



Step 2b: Configuring Reachability—Static Route—WebUI and Security Manager

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



Step 3: Configuring a Policy—CLI

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.



Step 3: Configuring a Policy—WebUI

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.



Step 3: Configuring a Policy—Security Manager

The slide shows the policy configuration process using Security Manager.



Verifying NAT-dst—CLI

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.



Verifying NAT-dst—WebUI

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.



VIP Addresses




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.



VIP Address Configuration Procedure

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



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.



Step 1: Defining a VIP Address—WebUI

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.



Step 1: Defining a VIP Address—Security 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.



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.



Step 2: Defining a Policy—WebUI

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.



Step 2: Defining a Policy—Security 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.



Verifying VIP Address Configuration

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



Verifying VIP Address Operations

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



MIP Addresses




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.



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.



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.



Step 1: Defining a MIP Address—WebUI

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.



Step 1: Defining a MIP Address—Security 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.



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.



Step 2: Configuring a MIP Address Policy—WebUI

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



Step 2: Configuring a MIP Address Policy—Security 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.



Verifying MIP Address Operation—CLI

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



Verifying MIP Address Operation—WebUI

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.



MIP Shortcut—Using 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.



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.8–1.1.8.15, translated to 10.1.10.0–10.1.10.7. The binary for the last octet is shown here:

00001111 = 1500000101 = 511111000 = mask

public range: 00001000 - 00001111 = 8-15private range: 00000000 - 00000111 = 0-7



MIP Address Complications—Other 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 zone—in this case, the public zone—using the public MIP address?



The Solution—Two 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.



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.




• Policy-based NAT options;

• Configuring address translation features; and

• Verifying NAT mode operation.



Review Questions: NAT-src

1.

2.

3.

4.



Review Questions: NAT-dst

1.

2.

3.



Review Questions: Virtual IP Address

1.

2.



Review Questions: Mapped IP Address

1.

2.

3.



Lab 6: Address Translation Tools



Chapter 9: Transparent Mode (Optional)


Chapter 9–2 • Transparent Mode (Optional)


• 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 9–3

Description




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.



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.



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.



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.



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.



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.



Management Operations

In the administration chapter, we discussed the relationships between all the available management settings—manage-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.



Configuration




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.



Configuring for Transparent Mode

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



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.



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.



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.



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 device’s 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.




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 methods—flood and ARP/trace route—ARP/trace route is more secure because the Juniper Networks device floods ARP queries and trace-route packets—not the initial packet—out all interfaces.



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.



Step 4: Configuring Management Services per Zone

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



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.



Verifying Operations




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 betweenLayer 2 zones.



Using the get interface name Command

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



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.



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



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.



Points to Consider

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



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.



Review Questions

1.

2.

3.

4.



Lab 7: Transparent Mode

The slide shows the objective for this lab.




Chapter 10: VPN Concepts


Chapter 10–2 • VPN Concepts


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


VPN Concepts • Chapter 10–3

Concepts and Terminology




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.



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, company’s 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!



Data Encryption

Encryption provides data confidentiality. Encryption is the method of taking user data—referred to as plaintext—and 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.



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.



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.



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.



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.

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

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 requirement—a 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.



Hash Process

The following steps outline the hash process:

1. The sender runs the data through the hash process.

2. The sender appends the hash value to the data and sends both to the receiver.

3. The receiver separates the data and the hash value.

4. The receiver hashes the data.

5. The receiver then compares the calculated hash value to the received hash value. If the hash values match, the data has not been altered.



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.



Protecting Data Integrity with HMAC

The following steps outline hashing with HMAC:

1. The sender appends preshared key to data, then performs hash function.

2. The data and hash value are sent to receiver.

3. The receiver separates the data and the hash value.

4. The receiver appends the preshared key to the data, then performs the hash function.

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



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.



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 key—and 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.




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


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


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



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.




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.



IP Security

This slide highlights the topic we discuss next.



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.



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.



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.



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.

The ESP trailer contains the following:

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

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



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.



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.



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.



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.



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.



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.



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.



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.



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:


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




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;


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



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.




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


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



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.



IPSec Tunnel Establishment—Summary

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.



Packet Handling and Receiving: Part 1

The following steps outline the packet handling process:

1. The packet arrives at remote ScreenOS device.

2. The ScreenOS device looks up destination route. The route is crossing zones.

3. The ScreenOS device looks up policy. Traffic matches a tunnel policy.

4. The original packet is encrypted.

5. The packet is hashed with authentication key.

6. The tunnel packet is built with a new IP header, IPSec header, and hash value. The new packet is sent to tunnel peer.



Packet Handling and Receiving: Part 2

The following list is a continuation from the previous page:

7. The corporate ScreenOS device receives the encrypted packet.

8. The corporate ScreenOS device looks up incoming SPI in local SA database. Matching record contains encryption and authentication algorithms, and keys.

9. The device compares locally calculated hash with received hash.

10. The device decrypts packet.

11. The device performs routing lookup for decrypted packet.

12. The device checks policy match for decrypted packet. Forward if tunnel policy exists for packet.



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.



Review Questions:

1.

2.

3.

4.




Chapter 11: Policy-Based VPNs


Chapter 11–2 • Policy-Based VPNs


• The definition of policy-based VPN;

• The minimum components needed to configure a policy-based VPN;

• Configuring an IKE-based VPN; and



Policy-Based VPNs • Chapter 11–3

Configuration




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.



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 VPN Configuration Procedure

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



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.



Step 1a: Configuring the IKE Gateway—WebUI

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



Step 1a: Configuring the IKE Gateway—Security Manager

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



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.



Step 1b: Advanced IKE Gateway Configuration—Security Manager

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



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.



Step 2a: Creating an IKE VPN—WebUI

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.



Step 2a: Creating an IKE VPN—Security Manager

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



Step 2b: Configuring AutoKey IKE—Advanced

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.



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 definition—address and mask—must 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.



Step 3: Object Addresses—WebUI and Security Manager

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



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 statements—one 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).



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.



Step 4: Configuring a VPN Policy—WebUI

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.



Step 4: Configuring a VPN Policy—Security 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.







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.



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.



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 gateway—either an explicit route or a default route.



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.




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.



Phase 1—Unrecognized 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.



Phase 1—Proposal 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.



Phase 2—Proposal Mismatch

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



Phase 2—Proxy 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.



Phase 2—Proxy 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 obvious—the receiver’s local settings bear no resemblance to the proxy ID received from the sender.



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.




• The definition of policy-based VPN;

• The minimum components needed to configure a policy-based VPN;

• Configuring an IKE-based VPN; and




Review Questions:

1.

2.

3.



Lab 8: Policy-Based VPNs



Chapter 12: Route-Based VPNs


Chapter 12–2 • Route-Based VPNs


• The concepts of a route-based VPN;

• Configuring route-based VPNs; and



Route-Based VPNs • Chapter 12–3

Concepts and Terminology




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.



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.



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.



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.



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.



Configuring VPNs




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.



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.



Step 1: Creating a Tunnel Interface—WebUI and Security Manager

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



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.



Step 2: Configuring the IKE Gateway—WebUI

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



Step 2: Configuring the IKE Gateway—Security Manager

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



Step 3: Creating AutoKey IKE

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



Step 3: Creating Auto-Key IKE—WebUI

For route-based VPNs, the Phase 2 configuration changes slightly. The basic screen is still the same—select 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.



Step 3: Creating AutoKey IKE—Security 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 same—select 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.



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.



Step 4: Configuring Routing—WebUI 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.



Step 5: Creating Policies

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







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.



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.



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.



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.




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.




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.




• The concepts of a route-based VPN;

• Configuring route-based VPNs; and




Review Questions:

1.

2.

3.



Lab 9: Configuring Route-Based VPNs

The slide lists the objective for this lab.




Appendix A: Additional Features


Appendix A–2 • Additional Features


• Juniper Networks hardware.


Additional Features • Appendix A–3

Hardware

The slide shows the topic we cover in this appendix.



Performance: Purpose-Built Hardware Platform

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


Additional Features • Appendix A–5

Performance: Advanced Hardware Design

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




• Juniper Networks hardware.

Documents

Configuring Juniper Networks FW_VPN