UAC Interoperability with the ScreenOS Enforcer · Author: Juniper Networks Created Date: 20130215200626Z

Junos Pulse Access Control Service

UAC Interoperability with the ScreenOS Enforcer

Release

4.4

Published: 2013-02-15

Part Number: , Revision 1

Copyright © 2013, Juniper Networks, Inc.

Juniper Networks, Inc.1194 North Mathilda AvenueSunnyvale, California 94089USA408-745-2000www.juniper.net

This product includes the Envoy SNMP Engine, developed by Epilogue Technology, an Integrated Systems Company. Copyright © 1986-1997,Epilogue Technology Corporation. All rights reserved. This program and its documentation were developed at private expense, and no partof them is in the public domain.

This product includes memory allocation software developed by Mark Moraes, copyright © 1988, 1989, 1993, University of Toronto.

This product includes FreeBSD software developed by the University of California, Berkeley, and its contributors. All of the documentationand software included in the 4.4BSD and 4.4BSD-Lite Releases is copyrighted by the Regents of the University of California. Copyright ©1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994. The Regents of the University of California. All rights reserved.

GateD software copyright © 1995, the Regents of the University. All rights reserved. Gate Daemon was originated and developed throughrelease 3.0 by Cornell University and its collaborators. Gated is based on Kirton’s EGP, UC Berkeley’s routing daemon (routed), and DCN’sHELLO routing protocol. Development of Gated has been supported in part by the National Science Foundation. Portions of the GateDsoftware copyright © 1988, Regents of the University of California. All rights reserved. Portions of the GateD software copyright © 1991, D.L. S. Associates.

This product includes software developed by Maker Communications, Inc., copyright © 1996, 1997, Maker Communications, Inc.

Juniper Networks, Junos, Steel-Belted Radius, NetScreen, and ScreenOS are registered trademarks of Juniper Networks, Inc. in the UnitedStates and other countries. The Juniper Networks Logo, the Junos logo, and JunosE are trademarks of Juniper Networks, Inc. All othertrademarks, service marks, registered trademarks, or registered service marks are the property of their respective owners.

Juniper Networks assumes no responsibility for any inaccuracies in this document. Juniper Networks reserves the right to change, modify,transfer, or otherwise revise this publication without notice.

Products made or sold by Juniper Networks or components thereof might be covered by one or more of the following patents that areowned by or licensed to Juniper Networks: U.S. Patent Nos. 5,473,599, 5,905,725, 5,909,440, 6,192,051, 6,333,650, 6,359,479, 6,406,312,6,429,706, 6,459,579, 6,493,347, 6,538,518, 6,538,899, 6,552,918, 6,567,902, 6,578,186, and 6,590,785.

Junos Pulse Access Control Service UAC Interoperability with the ScreenOS Enforcer

Revision HistoryFebruary 2013—Release revision only, no new information

The information in this document is current as of the date on the title page.

ENDUSER LICENSE AGREEMENT

The Juniper Networks product that is the subject of this technical documentation consists of (or is intended for use with) Juniper Networkssoftware. Use of such software is subject to the terms and conditions of the End User License Agreement (“EULA”) posted at

http://www.juniper.net/support/eula.html. By downloading, installing or using such software, you agree to the terms and conditionsof that EULA.

Copyright © 2013, Juniper Networks, Inc.ii

http://www.juniper.net/support/eula.html

Abbreviated Table of Contents

About This Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii

Part 1 Concepts and Configuration

Chapter 1 Configuring the ScreenOS Enforcer to Interoperate with Unified AccessControl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Chapter 2 Using IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Chapter 3 Policies and Procedures for Interoperability Between the UAC Enforcerand the IC Series . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Part 2 Index

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

iiiCopyright © 2013, Juniper Networks, Inc.

Copyright © 2013, Juniper Networks, Inc.iv


Table of Contents


Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii

Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii

Documentation Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii

Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv

Obtaining Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv

Documentation Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv

Requesting Technical Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv

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

Opening a Case with JTAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvi



The IC Series and the Infranet Enforcer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Understanding Deployments with ScreenOS Infranet Enforcers . . . . . . . . . . . . . . . 4

Deployment Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Communication Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Configuration Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Version Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Using Certificate-Based Security with Infranet Enforcer Deployments . . . . . . . . . . 7

Task Summary: Setting Up Certificates for the IC Series and Infranet

Enforcer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Setting Up Certificates for the IC Series and Infranet Enforcer . . . . . . . . . . . . . . . . 8

Using OpenSSL to Create a CA and Sign the Server Certificate . . . . . . . . . . . . . . . . 9

Creating a CA and Signing the Server Certificate Using OpenSSL . . . . . . . . . . . . . . 9

Importing the Certificate Into the Infranet Enforcer . . . . . . . . . . . . . . . . . . . . . . . . . 11

Configuring Certificate Authority Server Settings . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Binding an Interface to a Security Zone on a ScreenOS Enforcer . . . . . . . . . . . . . . 13

Binding the Physical Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

ScreenOS Enforcer Configuration Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Configuring the ScreenOS Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Setting Up an Infranet Enforcer in Route Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Creating a Route Mode Instance with the ScreenOS Enforcer . . . . . . . . . . . . . . . . 18

Task Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Web UI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

vCopyright © 2013, Juniper Networks, Inc.

Setting Up an Infranet Enforcer in Transparent Mode . . . . . . . . . . . . . . . . . . . . . . 20

Creating a Transparent Mode Instance with the ScreenOS Enforcer . . . . . . . . . . . 21

Task Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Viewing the Configuration of an IC Series Device on the ScreenOS Enforcer . . . . 23

Configuration Details Displayed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Web UI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Understanding the Infranet Enforcer Captive Portal Feature . . . . . . . . . . . . . . . . . 23

Before Configuring Captive Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Creating a Redirect Policy on the Infranet Enforcer . . . . . . . . . . . . . . . . . . . . . . . . 26

Overriding the Default Redirection Destination for Captive Portal . . . . . . . . . . . . . 27

Creating a Redirect Policy on the ScreenOS Enforcer . . . . . . . . . . . . . . . . . . . . . . . 28

Using VSYS on the ScreenOS Enforcer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30


IPsec Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Using IPsec with the Infranet Enforcer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Understanding Access Control Service Support for IPsec Routing Policies . . . . . . 35

About IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Access Solution Service Client Support for IPsec Routing Policies . . . . . . . . 36

Infranet Enforcer Support for IPsec Routing Policies . . . . . . . . . . . . . . . . . . . 36

Infranet Enforcer IPsec Policy Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Dynamic IPsec Routing Policies with ScreenOS Enforcers . . . . . . . . . . . . . . . 37

Refreshing IPsec Policies on the IC Series . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Understanding IPsec Routing Policy Configuration Options . . . . . . . . . . . . . . . . . 38

Configuration Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Configuration Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Advanced Configuration Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Using the Access Control Service User Interface to Create Basic ScreenOS

Enforcer IPsec Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

IPsec Routing Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Before you Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Configuring IPsec Routing Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Using IP Address Pool Policies for IPsec in a NAT Environment . . . . . . . . . . . . . . . 44

Understanding IP Address Pool Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Configuring an IP Address Pool Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Understanding ScreenOS Enforcer Source Interface Policies . . . . . . . . . . . . . . . . 48

Configuring Source Interface Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Upgrading IPsec Enforcement Policies from Version 1.x of the Infranet

Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

Setting Up ScreenOS Enforcer IPsec Routing Policies . . . . . . . . . . . . . . . . . . . . . . 50

Configuring ScreenOS Enforcer IPsec Encryption Settings . . . . . . . . . . . . . . . . . . . 51

Using ScreenOS Enforcer Bidirectional VPN Policies . . . . . . . . . . . . . . . . . . . . . . . 52

Creating a ScreenOS Bidirectional VPN Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Configuring Junos Enforcer IPsec Routing Policies . . . . . . . . . . . . . . . . . . . . . . . . . 53

Configuration Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Configuration Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Copyright © 2013, Juniper Networks, Inc.vi



Infranet Enforcer Policies Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

About Resource Access Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Using the Juniper Networks EX Series Ethernet Switch as an Enforcer with

a Resource Access Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Configuring Resource Access Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

Understanding Infranet Enforcer Source IP Security Policies . . . . . . . . . . . . . . . . . 63

Source IP Security Policy Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

ScreenOS Infranet Enforcer Configuration Summary . . . . . . . . . . . . . . . . . . . 64

Junos Infranet Enforcer Configuration Summary . . . . . . . . . . . . . . . . . . . . . . 65

Understanding Infranet Enforcer Auth Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Understanding Dynamic Auth Table Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

Configuring Dynamic Auth Table Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Configuring Auth Table Mapping Policies for Source IP Enforcement . . . . . . . . . . 67

Configuring Auth Table Mapping Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Part 2 Index

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

viiCopyright © 2013, Juniper Networks, Inc.

Table of Contents

Copyright © 2013, Juniper Networks, Inc.viii


List of Figures



Figure 1: Binding a Physical Interface to a Security Zone . . . . . . . . . . . . . . . . . . . . . 14

Figure 2: Captive Portal Event Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Figure 3: Multiple VSYS with Shared and Unshared Zones . . . . . . . . . . . . . . . . . . . 31


Figure 4: Using an IP Address Pool in a NAT Environment . . . . . . . . . . . . . . . . . . . 45


Figure 5: Policy Interaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Figure 6: Using Auth Table Mapping Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

ixCopyright © 2013, Juniper Networks, Inc.

Copyright © 2013, Juniper Networks, Inc.x


List of Tables


Table 1: Notice Icons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv

Table 2: Text Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv



Table 3: ScreenOS Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6


Table 4: Configuration Topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Table 5: Syntax for IP Address Pools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

xiCopyright © 2013, Juniper Networks, Inc.

Copyright © 2013, Juniper Networks, Inc.xii


About This Guide

• Objectives on page xiii

• Audience on page xiii

• Documentation Conventions on page xiii

• Documentation on page xv

• Obtaining Documentation on page xv

• Documentation Feedback on page xv

• Requesting Technical Support on page xv

Objectives

This guide describes basic configuration procedures for Juniper Networks Unified Access

Control (UAC) interoperability with the ScreenOS Enforcer. This document was formerly

titled Unified Access Control Operability with the ScreenOS Enforcer. This document is

now part of the Junos Pulse documentation set.

Audience

This guide is designed for network administrators who are configuring and maintaining

a Juniper Networks IC Series device. To use this guide, you need a broad understanding

of networks in general and the Internet in particular, networking principles, and network

configuration. Any detailed discussion of these concepts is beyond the scope of this

guide.

Documentation Conventions

Table 1 on page xiv defines the notice icons used in this guide. Table 2 on page xiv defines

text conventions used throughout this documentation.

xiiiCopyright © 2013, Juniper Networks, Inc.

Table 1: Notice Icons

DescriptionMeaningIcon

Indicates important features or instructions.Informational note

Indicates a situation that might result in loss of data or hardware damage.Caution

Alerts you to the risk of personal injury or death.Warning

Alerts you to the risk of personal injury from a laser.Laser warning

Table 2: Text Conventions

ExamplesDescriptionConvention

• Specify the keyword exp-msg.

• Run the install.sh script.

• Use the pkgadd tool.

• To cancel the configuration, click Cancel.

• Represents keywords, scripts, and tools intext.

• Represents a GUI element that the userselects, clicks, checks, or clears.

Bold text like this

user@host# set cache-entry-agecache-entry-age

Represents text that the user must type.Bold text like this

nic-locators { login { resolution { resolver-name /realms/ login/A1; key-type LoginName; value-type SaeId; }

Represents information as displayed on yourterminal’s screen, such as CLI commands inoutput displays.

Fixed-width text like this

• system ldap server{stand-alone;

• Use the request saemodify device failovercommand with the force option

• user@host# . . .

• Represents configuration statements.

• Indicates SRC CLI commands and optionsin text.

• Represents examples in procedures.

Regular sans serif typeface

user@host# set local-addresslocal-address

Represents variables in SRC CLI commands.Italic sans serif typeface

Another runtime variable is <gfwif>.In text descriptions, indicate optionalkeywords or variables.

Angle brackets

Press Enter.Indicates the name of a key on the keyboard.Key name

Copyright © 2013, Juniper Networks, Inc.xiv


Table 2: Text Conventions (continued)

Press Ctrl + b.Indicates that you must press two or morekeys simultaneously.

Key names linked with a plus sign(+)

• There are two levels of access: user andprivileged.

• SRC-PE Getting Started Guide.

• o=Users, o=UMC

• The /etc/default.properties file.

• Emphasizes words.

• Identifies book names.

• Identifies distinguished names.

• Identifies files, directories, and paths intext but not in command examples.

Italic typeface

Plugin.radiusAcct-1.class=\net.juniper.smgt.sae.plugin\RadiusTrackingPluginEvent

At the end of a line, indicates that the textwraps to the next line.

Backslash

diagnostic | lineRepresent a choice to select one keyword orvariable to the left or right of this symbol.(The keyword or variable may be eitheroptional or required.)

Words separated by the | symbol

Documentation

For a list of related UAC documentation, see

http://www.juniper.net/support/products/uac/. If the information in the latest UAC Release

Notes differs from the information in the documentation, follow the UAC Release Notes.

Obtaining Documentation

To obtain the most current version of all Juniper Networks technical documentation, see

the products documentation page on the Juniper Networks web site at

http://www.juniper.net/techpubs.

Documentation Feedback

We encourage you to provide feedback, comments, and suggestions so that we can

improve the documentation. You can send your comments to

[email protected], or fill out the documentation feedback form at

https://www.juniper.net/cgi-bin/docbugreport/ . If you are using e-mail, be sure to include

the following information with your comments:

• Document name

• Page number

• Software release version

Requesting Technical Support

Technical product support is available through the Juniper Networks Technical Assistance

Center (JTAC). If you are a customer with an active J-Care or JNASC support contract,

xvCopyright © 2013, Juniper Networks, Inc.

About This Guide

http://www.juniper.net/support/products/uac/

http://www.juniper.net/techpubs

mailto:[email protected]

https://www.juniper.net/cgi-bin/docbugreport/

or are covered under warranty, and need post-sales technical support, you can access

our tools and resources online or open a case with JTAC.

• JTAC policies—For a complete understanding of our JTAC procedures and policies,

review the JTAC User Guide located at

http://www.juniper.net/us/en/local/pdf/resource-guides/7100059-en.pdf .

• Product warranties—For product warranty information, visit

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

• JTAC hours of operation—The JTAC centers have resources available 24 hours a day,

7 days a week, 365 days a year.

Self-Help Online Tools and Resources

For quick and easy problem resolution, Juniper Networks has designed an online

self-service portal called the Customer Support Center (CSC) that provides you with the

following features:

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

• Search for known bugs: http://www2.juniper.net/kb/

• Find product documentation: http://www.juniper.net/techpubs/

• Find solutions and answer questions using our Knowledge Base: http://kb.juniper.net/

• Download the latest versions of software and review release notes:

http://www.juniper.net/customers/csc/software/

• Search technical bulletins for relevant hardware and software notifications:

https://www.juniper.net/alerts/

• Join and participate in the Juniper Networks Community Forum:

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

• Open a case online in the CSC Case Management tool: http://www.juniper.net/cm/

To verify service entitlement by product serial number, use our Serial Number Entitlement

(SNE) Tool: https://tools.juniper.net/SerialNumberEntitlementSearch/

Opening a Casewith JTAC

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

• Use the Case Management tool in the CSC at http://www.juniper.net/cm/.

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

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

http://www.juniper.net/support/requesting-support.html.

Copyright © 2013, Juniper Networks, Inc.xvi


http://www.juniper.net/us/en/local/pdf/resource-guides/7100059-en.pdf

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

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

http://www2.juniper.net/kb/

http://www.juniper.net/techpubs/

http://kb.juniper.net/

http://www.juniper.net/customers/csc/software/

https://www.juniper.net/alerts/

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

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

https://tools.juniper.net/SerialNumberEntitlementSearch/

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

http://www.juniper.net/support/requesting-support.html

PART 1

Concepts and Configuration

• Configuring the ScreenOS Enforcer to Interoperate with Unified Access

Control on page 3

• Using IPsec on page 33

• Policies and Procedures for Interoperability Between the UAC Enforcer and the IC

Series on page 59

1Copyright © 2013, Juniper Networks, Inc.

Copyright © 2013, Juniper Networks, Inc.2


CHAPTER 1

Configuring the ScreenOS Enforcer toInteroperate with Unified Access Control

• The IC Series and the Infranet Enforcer on page 4

• Understanding Deployments with ScreenOS Infranet Enforcers on page 4

• Using Certificate-Based Security with Infranet Enforcer Deployments on page 7

• Task Summary: Setting Up Certificates for the IC Series and Infranet Enforcer on page 8

• Setting Up Certificates for the IC Series and Infranet Enforcer on page 8

• Using OpenSSL to Create a CA and Sign the Server Certificate on page 9

• Creating a CA and Signing the Server Certificate Using OpenSSL on page 9

• Importing the Certificate Into the Infranet Enforcer on page 11

• Configuring Certificate Authority Server Settings on page 12

• Binding an Interface to a Security Zone on a ScreenOS Enforcer on page 13

• Binding the Physical Interface on page 14

• ScreenOS Enforcer Configuration Overview on page 15

• Configuring the ScreenOS Connection on page 15

• Setting Up an Infranet Enforcer in Route Mode on page 16

• Creating a Route Mode Instance with the ScreenOS Enforcer on page 18

• Setting Up an Infranet Enforcer in Transparent Mode on page 20

• Creating a Transparent Mode Instance with the ScreenOS Enforcer on page 21

• Viewing the Configuration of an IC Series Device on the ScreenOS Enforcer on page 23

• Understanding the Infranet Enforcer Captive Portal Feature on page 23

• Before Configuring Captive Portal on page 24

• Creating a Redirect Policy on the Infranet Enforcer on page 26

• Overriding the Default Redirection Destination for Captive Portal on page 27

• Creating a Redirect Policy on the ScreenOS Enforcer on page 28

• Using VSYS on the ScreenOS Enforcer on page 30


The IC Series and the Infranet Enforcer

NOTE: A Infranet Enforcer can be either a ScreenOS firewall device, or a JSeries or SRX Series Services Gateway.

The IC Series device is the policy decision point that determines which users and endpoints

can access protected resources. You can use Juniper Networks firewalls to serve as the

enforcement point to provide the ultimate protection to ensure that network assets are

secured.

You can use either a ScreenOS Enforcer or a Junos Enforcer with the UAC solution. A

Junos Enforcer is a J Series Services Router or an SRX Series Services Gateway configured

as a Layer 3 enforcement point. A ScreenOS Enforcer is an ISG Series Integrated Services

Gateway or a SSG Series Secure Services Gateway. This document contains configuration

details for the ScreenOS Enforcer. See4.3R1SupportedPlatforms for version compatibility.

Understanding Deployments with ScreenOS Infranet Enforcers

This topic provides an overview of Junos Pulse Access Control Service deployments with

ScreenOS Infranet Enforcers. It includes the following information:

• Deployment Summary on page 4

• Communication Summary on page 4

• Configuration Summary on page 6

• Version Requirements on page 6

Deployment Summary

The IC Series device is the policy decision point that determines which users and endpoints

can access protected resources. You can use Juniper Networks firewalls to serve as the

enforcement point to provide the ultimate protection to ensure that network assets are

secured.

Communication Summary

This section describes the communication between the IC Series device and the Infranet

Enforcer.

• At startup, the ScreenOS Enforcer contacts the IC Series device over an SSL connection

using the NetScreen Address Change Notification (NACN) protocol.

• After the ScreenOS Enforcer establishes a connection with the IC Series device, the IC

Series device opens an SSH connection with the ScreenOS Enforcer. The IC Series

device uses this SSH connection to push policy and user authentication information

to the ScreenOS Enforcer.

• With ScreenOS Release 6.0 or earlier, when the IC Series device authenticates a user

and verifies that the user’s endpoint is compliant with endpoint security policies, the



https://www.juniper.net/techpubs/software/uac/4.3xrelnotes/j-ic-uac-4.3r1-supportedplatforms.pdf

IC Series device pushes user-specific configuration information to the ScreenOS

Enforcer. This information includes an auth table entry for each authenticated user.

An auth table entry consists of the user’s name, a set of roles, and the IP address of

the wired adapter, wireless adapter, or virtual adapter in the user’s computer. With

ScreenOS Release 6.1 or later, and with the Junos Enforcer, you can configure the IC

Series device to dynamically create auth table entries on the Infranet Enforcer after a

specific resource is requested.

• To use source IP enforcement, you create infranet auth source IP policies on ScreenOS

Enforcers that allow traffic from the endpoint to protected resources.

• To use IPsec enforcement, you set up a VPN tunnel for a dial-up user with Internet Key

Exchange (IKE) with an Enforcer policy. The VPN tunnel and the infranet auth IPsec

policy enable the user's endpoint (OAC or Pulse) to use an IPsec tunnel to the Infranet

Enforcer and to access protected resources. The Infranet Enforcer sends the necessary

setup information to the client.

• When the Infranet Enforcer detects traffic from an endpoint that matches an Infranet

Enforcer policy, it uses the endpoint’s auth table entry to determine the role associated

with that user.

• The Infranet Enforcer matches the destination IP address of the protected resource

(from the Infranet Enforcer policy) with a resource access policy. The Infranet Enforcer

searches for a matching role and applies the policy action.

• As necessary, the IC Series device sends commands to the Infranet Enforcer to remove

policies or auth table entries and deny access to protected resources. This can occur,

for example, when the user’s computer becomes noncompliant with endpoint security

policies or loses its connection with the IC Series device, when you change the

configuration of a user’s role, or when you disable all user accounts on the IC Series

device in response to a security problem (such as a virus on the network).

The FIPS IC6500 or a non-FIPS IC Series device can be used with a ScreenOS Enforcer

that is in FIPS mode. If FIPS is enabled on the Infranet Enforcer, the admin console

displays the information on the Connection page.

You can configure an Infranet Enforcer to work with more than one IC Series device in

a high availability configuration known as an IC Series device cluster. The Infranet

Enforcer communicates with only one IC Series device at a time. The other IC Series

devices are used for failover. If the Infranet Enforcer cannot connect to the first IC Series

device you added to the cluster, it attempts to connect to successive devices in the

configuration list until a connection occurs. If the currently connected IC Series device

fails, the Infranet Enforcer attempts to connect to the first IC Series device again. The

IC Series devices configured on an Infranet Enforcer should all be members of the same

IC Series device cluster.

You can use the Infranet Enforcer as a policy enforcement point for any number of IC

Series devices or Instant Virtual Extranet (IVE) Secure Access devices in a federated

network.


Chapter 1: Configuring the ScreenOS Enforcer to Interoperate with Unified Access Control

Configuration Summary

You must perform the following basic tasks to use the IC Series device with an Infranet

Enforcer:

• Configure the IC Series device and the ScreenOS Enforcer to communicate with each

other over a secure connection.

• Configure user authentication and authorization by setting up user roles, authentication

and authorization servers, and authentication realms on the IC Series device.

• Configure resource access policies on the IC Series device to specify which endpoints

are allowed or denied access to protected resources.

• Configure traffic enforcement between each source and destination zone with ScreenOS

Enforcer Infranet auth policies. Use one of the following methods:

• Source IP enforcement

• IPsec enforcement

Version Requirements

You can use either a ScreenOS Enforcer or a Junos Enforcer with the UAC solution. This

section describes version requirements for ScreenOS Enforcers. See 4.3R1 Supported

Platforms for version compatibility.

You can use Juniper ScreenOS Release 5.4 or later with UAC.

Not all ScreenOS releases support all features described in this document.Table 3 on

page 6 indicates what release version of ScreenOS is required for specific features.

Table 3: ScreenOSOptions

Required ScreenOS ReleaseFeature

5.4Captive portal

6.0Configurable auth table entries

6.0R2Seamless cluster failover

6.1Dynamic auth table allocation

6.1200 roles per auth table entry

6.2Messages to authenticated but unauthorized users

6.2Support for ISG-IDP

6.2Support for vsys

6.3Nonstandard port for captive portal





RelatedDocumentation

Using Certificate-Based Security with Infranet Enforcer Deployments on page 7•



Using Certificate-Based Security with Infranet Enforcer Deployments

The IC Series device and the Infranet Enforcer communicate over a secure channel using

digital security certificates as the mechanism for establishing trust. A digital certificate

is a form of identification. The certificate provides information about the identity of the

presenter and other data that helps determine whether or not to trust the presenter.

Public Key Infrastructure (PKI) refers to the hierarchical structure of trust required for

the successful implementation of public key cryptography.

When the Infranet Enforcer first connects with the IC Series device, the devices exchange

security information to verify secure communication.

• In ScreenOS implementations, the IC Series device presents its device certificate, and

the ScreenOS Enforcer must verify the certificate before further communication is

initiated.

• In Junos implementations, the Junos Enforcer presents its password to the IC Series

device, and the IC Series device verifies the password before further communication

is initiated. Once verified, the IC Series device presents its device certificate to the Junos

Enforcer. Verification of the server certificate is not required for the Junos Enforcer to

connect, however, you can verify the certificate for an additional layer of trust.

• If you are using the FIPS IC6500, only the Certificate Signing Request (CSR) method

for creating device certificates can be used. You cannot import a CA-created certificate

(pfx) with a private key file on a FIPS IC6500.

Digital certificates are issued by a Certificate Authority (CA). With PKI the CA is always

a trusted entity, so the information in a certificate issued or signed by a CA is guaranteed

to be valid.

To ensure that the trust relationship in the network between the IC Series device and the

Infranet Enforcer is secure, you create a certificate hierarchy for this trust relationship,

and then upload the appropriate certificates into the devices.


Task Summary: Setting Up Certificates for the IC Series and Infranet Enforcer on page 8•

• Setting Up Certificates for the IC Series and Infranet Enforcer on page 8

• Using OpenSSL to Create a CA and Sign the Server Certificate on page 9




Task Summary: Setting Up Certificates for the IC Series and Infranet Enforcer

To allow the ScreenOS Enforcer to communicate with the IC Series device, you must

perform all of the following tasks:

• If you do not have one already, obtain the CA certificate that signed the IC Series device

server certificate to load on the Infranet Enforcer.

• Create a CSR for an IC Series device server certificate, and use the CA certificate to

sign the server certificate.

• Import the CA certificate into the Infranet Enforcer.

• Specify the CA certificate to be used to verify the IC Series device.

If the server certificate or the CA certificate is missing or expired, the Infranet Enforcer

cannot communicate with the ScreenOS Enforcer. The Infranet Enforcer does not accept

the temporary self-signed certificate that the IC Series device created during initialization.


Using OpenSSL to Create a CA and Sign the Server Certificate on page 9•

Setting Up Certificates for the IC Series and Infranet Enforcer

To set up certificates for the IC Series device and Infranet Enforcer:

1. If you do not have a CA, install and use OpenSSL to generate a CA certificate.

2. Create a CSR for a server certificate, and then sign the CSR by using either your CA or

OpenSSL.

3. Import the signed server certificate created from the CSR into the IC Series device by

selecting System > Configuration > Certificates > Device Certificates from the left

navigation bar of the IC Series device admin console.

• Under Certificate Signing Requests, click the Pending CSR link that corresponds to

the signed certificate. The Pending Certificate Signing Request dialog box is

displayed.

• Under Step 2 Import the signed certificate and then browse to the certificate file

you received from the CA. For example:

c:\openssl\certs\ic.crt

• Click Import.

4. By default, the signed server certificate is automatically associated with the internal

port on the IC Series device. To associate the certificate with the external or virtual

port, perform these steps:

• SelectSystem>Configuration>Certificates>DeviceCertificates in the left navigation

bar.

• Click the link that corresponds to a certificate that you want to use. The Certificate

Details dialog box is displayed.



• Under Present certificate on these ports, specify the port that the IC Series device

should associate with the certificate. You can choose internal or external ports and

primary or virtual ports, but you cannot choose a port that is already associated

with another certificate.

• Click Save Changes.

5. Import the certificate of the CA that signed the IC Series device’s server certificate

into the Infranet Enforcer.

NOTE: Toprevent yourWebbrowser’s securitywarning fromappearing eachtime you sign into the IC Series device, import the certificate of the CA thatsignedthe ICSeriesdevice’s servercertificate intoyourbrowser’s listof trustedroot certification authorities.

NOTE: If you later import a different server certificate and CA certificate, youmight need to initiate a new connection to use them. To initiate a newconnection, selectMaintenance > System > Platform > Restart Services in the

IC Series device admin console. The Infranet Enforcer connects to the ICSeries device and validates the new certificate.


Creating a CA and Signing the Server Certificate Using OpenSSL on page 9•



Using OpenSSL to Create a CA and Sign the Server Certificate

If you do not have a CA, follow the instructions in this section to use OpenSSL on Windows

to create a CA certificate and to sign the CSR for the server certificate.

You can also use OpenSSL to create a trusted root CA certificate for validation of the IC

Series device by OAC or Pulse. Follow the instructions in this section to create a CA

certificate and sign the CSR for the IC Series device’s server certificate.


Creating a CA and Signing the Server Certificate Using OpenSSL on page 9•


Creating a CA and Signing the Server Certificate Using OpenSSL

To set up OpenSSL:

1. Download and install OpenSSL from

http://www.slproweb.com/products/Win32OpenSSL.html.

2. Set the install directory to c:\openssl and accept the other installation defaults.



3. At the Windows command prompt, type the following commands:

C: cd \opensslC: md certsC: cd certsC: md demoCAC:md demoCA\newcertsC: edit demoCA\index.txt

4. Press Alt+F, S to save the file.

5. Press Alt+F, X to exit the editor.

6. At the Windows command prompt, type the following command:

C: edit demoCA\serial

7. Type 01 in the document window.

8. Press Alt+F, S to save the file.

9. Press Alt+F, X to exit the editor.

10. At the Windows command prompt, type the following command:

C: set path=c:\openssl\bin;%path%C: set OPENSSL_CONF=c:\openssl\bin\openssl.cfg

11. : In Wordpad (or an equivalent text editor that correctly handles Unix line breaks),

edit the openssl config file (c:\openssl\bin\openssl.cfg), change the CA policy match

for country and state from “match” to “optional”, and save your changes. The resulting

config stanza should appear as follows:

# For the CA policy[ policy_match ]countryName = optionalstateOrProvinceName = optionalorganizationName =matchorganizationalUnitName = optionalcommonName = suppliedemailAddress = optional

12. To create a CA key, type the following command at the Windows command prompt

in the c:\openssl\certs directory:

C: openssl genrsa -out ca.key 1024Loading 'screen' into random state - doneGenerating RSA private key, 1024 bit long modulus........++++++.++++++

e is 65537 (0x10001

To create and sign a CSR from the CLI:

1. Type the following command at the Windows command prompt in the c:\openssl\certs

directory:

C: openssl req -new -x509 -days 365 -key ca.key -out demoCA/cacert.pem

2. Enter the appropriate distinguished name (DN) information for the CA certificate. You

can leave some fields blank by hitting enter.

For example:

Country Name: US



State or Province Name: MALocality Name: BostonOrganization Name: XYZOrg. Unit Name: ITCommonName: ca.xyz.come-mail Address: [email protected]

To create and sign a CSR from the Web UI:

1. Select System>Configuration >Certificates >Device Certificates in the left navigation

bar.

2. Click NewCSR. The new Certificate Signing Request page is displayed.

3. Enter the required information. For example:

Country Name: USState or Province Name: MALocality Name: BostonOrganization Name: XYZOrg. Unit Name: ITCommonName: ic.xyz.come-mail Address: [email protected]

The organization name in the CSR must match the CA certificate's organization name.

If the organization names do not match, you cannot sign the CSR.

4. Enter random characters in the Random Data box.

5. Click Create CSR. The Pending Certificate Signing Request page is displayed.

6. Select and copy all of the text in the text box in Step 1 into a text editor, and save the

text file in the following directory:

c:\openssl\certs\ic.csr

7. To sign the certificate, type the following command at the Windows command prompt

in the c:\openssl\certs directory:

openssl ca -in ic.csr -out ic.crt -keyfile ca.key

8. Enter Y to sign the certificate.

9. Enter Y to commit the certificate.

You are now ready to import the server certificate into the IC Series device and the

CA certificate into the Infranet Enforcer.


Importing the Certificate Into the Infranet Enforcer on page 11•

Importing the Certificate Into the Infranet Enforcer

To import a CA certificate on the ScreenOS Enforcer:

1. On the Infranet Enforcer Web UI, select Objects > Certificates in the left navigation

bar.

2. Select CA from the Show list.



3. Click Browse to find and select the CA certificate (such as

c:\OpenSSL\certs\demoCA\cacert.pem) Then click Load.

4. Select CA from the Show list to display the CA certificate.


Setting Up Certificates for the IC Series and Infranet Enforcer on page 8•

Configuring Certificate Authority Server Settings

The CA server you use can be owned and operated by an independent CA or by your own

organization. If you use an independent CA, you must contact them for the addresses of

their CA and CRL servers (for obtaining certificates and certificate revocation lists), and

for the information they require when submitting certificate requests. When you are your

own CA, you determine this information yourself.

On the ScreenOS Enforcer, you can use the Web UI to configure CA server settings. Select

Objects > Certificates and navigate to the proper certificate.

You can configure the following options:

• X509 Certificate Path Validation Level: Within X509 is a specification for a certificate

that binds an entity's distinguished name to its public key through the use of a digital

signature. Select Full to validate the certificate path all the way back to the root, or

select Partial to validate it only part of the way. The CRL distribution point extension

(.cdp) in an X509 certificate can be either an HTTP URL or an LDAP URL.

• Certificate Revocation Check settings:

• CRL (Certificate Revocation List): Enables the Juniper security device to use only the

CRL to check the certificate status.

• OCSP (Online Certificate Status Protocol): Enables the Juniper security device to

use only OCSP to check the certificate status.

• None: Disables CRL certificate checking. If you are not using CRL certificate checking,

be sure to disable it in the CA Server Settings dialog box.

• Best Effort: Enables the Juniper security device to use CRL to check the certificate

status. If there is no indication that the certificate is revoked, accept the certificate.

• CRL settings:

• URL Address: Specifies the internal Web-based URL of the LDAP server managing

your CRL.

• LDAP Server: Specifies the IP address or domain name of the LDAP Root CA server

that manages the CRL.

• Refresh Frequency: Applies only to the CRL only. From the list, select whether you

want to update the CRL daily, weekly, monthly, or according to the default setting

(which updates the CRL shortly after the next scheduled update).

• OCSP settings:



• URL Address: Specifies the internal Web URL of the OCSP server.

• Advanced Settings: Specifies a CA with which the Juniper security device verifies the

OCSP response.

• SCEP (Simple Certificate Enrollment Protocol) settings:

• RA CGI (registration authority certificate generation information): Specifies the RA

URL where the Juniper security device will request a CA certificate.

• CA CGI (certificate authority certificate generation information): Specifies the CA

URL.

• CA IDENT: Specifies the name of the CA for purposes of certificate ownership, if

necessary.

• Challenge: Specifies the challenge word sent to you by the CA that prove your identity

to the CA.

• Advanced Settings: Configures Advanced SCEP settings, such as polling interval and

certificate authentication.



Binding an Interface to a Security Zone on a ScreenOS Enforcer

Security zones represent virtual sections of the network that are segmented into logical

areas. Security zones can be assigned to an interface or, on large devices, to a virtual

system.

From the perspective of security policies, traffic enters one security zone and exits through

another security zone. The ScreenOS Enforcer includes several predefined zones, for

example trust and untrust.

You might need to bind the physical interfaces on the Juniper security device to security

zones, or you might need to change a binding to accommodate your deployment. Figure

1 on page 14 shows a typical setup for a ScreenOS Enforcer Integrated Security Gateway

2000 (ISG 2000).

NOTE: Slot numbering varies by platform, and interface numbering variesbymodule type. For slot numbering and interface information refer to theuser guide that accompanied the device.

Endpoints must reside in a security zone different from where your protected resources

reside. The trust and untrust security zones in Figure 1 on page 14 are default zones for

Route mode configurations on a ScreenOS Enforcer. For Transparent mode (on ScreenOS

Enforcers), use the v1-trust and v1-untrust security zones (not shown). The IC Series

device (not shown) can reside in any security zone. If you place the IC Series device in a

security zone that is different from the security zone that contains endpoints, you must

set a policy allowing traffic from the endpoints to the IC Series device.



To view the zones available on the ScreenOS Enforcer, enter the get zone command in

the ScreenOS CLI. To configure custom zones, see

http://www.juniper.net/techpubs/en_US/release-independent/screenos/information-products/pathway-pages/screenos/product/index.html

.

In Figure 1 on page 14 the endpoints reside in the Untrust zone, and the protected resources

reside in the Trust zone. Port numbering is dependent on chassis configuration.

Figure 1: Binding a Physical Interface to a Security Zone


Binding the Physical Interface on page 14•

Binding the Physical Interface

On the ScreenOS Enforcer, you can bind an interface to a security zone from either the

Web UI or the CLI.

ScreenOSWebUI

Select Network > Interfaces > Edit: Select a Zone from the menu then click OK.

ScreenOS CLI

set interface ethernet4/1 zone trust

set interface ethernet3/8 zone untrust

save





ScreenOS Enforcer Configuration Overview on page 15•

ScreenOS Enforcer Configuration Overview

You can use Route mode or Transparent mode to configure a Juniper Networks ScreenOS

Enforcer. By default, the ScreenOS Enforcer operates in Route mode. For more information

about how to set up routing, see

http://www.juniper.net/techpubs/en_US/release-independent/screenos/information-products/pathway-pages/screenos/product/index.html.

Juniper Networks recommends configuring the Infranet Enforcer to use SSHv2.

To perform ScreenOS configuration tasks the administrator must have root access.

The related documentation list provides links to information about configuring the Infranet

Enforcer. For cabling, rack mounting, and basic configuration instructions for platforms,

see IC Series Hardware.


Configuring the ScreenOS Connection on page 15•



Configuring the ScreenOS Connection

The ScreenOS Enforcer connects to the IC Series device over an SSH connection that

uses the NetScreen Address Change Notification (NACN) protocol. To configure a

connection between the two appliances, specify the following items on the IC Series

device in an Infranet Enforcer connection policy:

• An NACN password

• An administrator name and password for signing into the Infranet Enforcer using SSH

• The serial number of the Infranet Enforcer

The IC Series device uses the NACN password and serial number for a connection from

the ScreenOS Enforcer. When the ScreenOS Enforcer first turns on, it sends an NACN

message containing the NACN password and serial number to the IC Series device. The

IC Series device uses the serial number to determine which ScreenOS Enforcer is

attempting to connect, and the IC Series device uses the NACN password to authenticate

the ScreenOS Enforcer. The IC Series device then begins communicating with the

ScreenOS Enforcer using SSH.

To configure the IC Series device to connect to the Infranet Enforcer:

1. On the left navigation bar in the IC Series device admin console, selectUAC> InfranetEnforcer > Connection.

2. Click New Enforcer. The new ScreenOS Enforcer page is displayed.




3. Enter an NACN password for this Infranet Enforcer in the NACN password box. You

must enter this same NACN password when configuring the Infranet Enforcer.

4. In the appropriate boxes, enter the administrator name and password for signing into

the Infranet Enforcer.

5. Enter the serial number of the Infranet Enforcer. You can view the serial number on

the Home page of the Infranet Enforcer Web UI, or by using the ScreenOS CLI

command:

get system.

6. Select No802.1X from the Location Group list if you are not using an Infranet Enforcer

as an 802.1X RADIUS client of the IC Series device. This is the typical setting.

7. Click Save Changes.

When you finish configuring the Infranet Enforcer, the Infranet Enforcer attempts to

connect to the IC Series device. If the connection is successful, a green dot is displayed

next to the Infranet Enforcer icon under Enforcer Status selectSystem>Status>Overview

in the IC Series device admin console. The Infranet Enforcer IP address is also displayed

in UAC > Infranet Enforcer > Connection.

NOTE: To initiate a connection immediately after you finish configuring theInfranetEnforcer, restart the ICSeriesdeviceservicesbyclickingMaintenance

>System>Platform>RestartServices fromthe ICSeriesdeviceadminconsole.





Setting Up an Infranet Enforcer in RouteMode

The IC Series device can reside on either side of the Infranet Enforcer. If the IC Series

device resides on the trust interface side, and users come in through the untrust interface,

the administrator must configure a policy (untrust to trust) on the Infranet Enforcer that

allows traffic to pass between the IC Series device and OAC or Pulse. By default, Infranet

Enforcer traffic from the untrust interface to the trust interface is denied.

The following describes the setup with the IC Series device on the untrust interface side

(same side as users).



To configure an Infranet Enforcer in Route mode:

1. Set up the trust interface. The trust interface connects to the protected resource.The

untrust interface connects to the IC Series device. Set the following interface

(ethernet1/1) settings:

• Set routing

• Enable management of the following services:

• SSL

• SSH

• IP (optionsl)

2. Ensure that the DHCP server is disabled or enabled, as appropriate for the deployment.


into the Infranet Enforcer.

a. If you set up an NSRP cluster before you import the CA certificate into the Infranet

Enforcer, the CA certificate is automatically synchronized to all Infranet Enforcers

in the cluster. However, if you set up the NSRP cluster after you import the CA

certificate, you must manually synchronize the certificate to the other Infranet

Enforcers in the cluster by typing the following CLI command:

exec nsrp sync pki

You cannot load the self-signed IC Series device SSL certificate into the Juniper security

device. For more information about certificates and certificate options, see Certificates.

The certificate of the CA that signed the IC Series device’s certificate must be imported

on the Infranet Enforcer because the Infranet Enforcer must be able to trust the IC

Series device during an SSL session. When a user signs into a server by means of SSL,

the server displays a dialog box in which the user can manually accept the certificate

that is associated with that server. For the Infranet Enforcer to skip that manual step

and automatically accept the IC Series device’s certificate, the Infranet Enforcer must

have the certificate of the CA that signed the IC Series device’s certificate.

4. Create an instance of the IC Series device on the Juniper security device.

5. Enable SSH.

6. Verify routing from the IC Series device to the untrust interface.

7. Ensure that both the Infranet Enforcer and the IC Series device have the correct time.

If possible, use a Network Time Protocol (NTP) server to set the date and time of both

appliances.


Creating a Route Mode Instance with the ScreenOS Enforcer on page 18•



Creating a RouteMode Instance with the ScreenOS Enforcer

This topic describes how to configure a ScreenOS device in Route Mode to communicate

with the Access Control Service. It includes the following information:

• Task Overview on page 18

• Web UI on page 19

• CLI on page 19

Task Overview

Before you begin this procedure, you must possess the certificate of the CA that signed

the IC Series device’s server certificate. If you do not already have an authentic CA from

a trusted source, you must generate a self-signed CA.

After you connect to the Juniper security device and set interface management options,

you can create an IC Series device instance. You need to name the instance and set these

items:

• IP address or host name of the IC Series device

• Password to use when the Infranet Enforcer uses NACN to contact the IC Series device

• Source interface

• CA index number (ca-idx)

You can set these items using the Web UI or the CLI. Because the Juniper security device

can store more than one IC Series device instance, you must include the name of the IC

Series device with each command.

In the following procedure, you first set interface management options and disable the

DCHP server option. Then you enable SSHv2 and configure an IC Series device instance

named controller1. Next, you set the host IP address, which is the IP address of the IC

Series device, to 10.64.12.1. The NACN password is 8!JsP37cK9a*_HiEwe. The NACN

password must match the NACN password that you entered for the IC Series device. The

source interface is the interface that the Infranet Enforcer uses to communicate with the

IC Series device, and the CA index number is 001. For this example, the source interface

is ethernet 1/1. For a descriptive list of CA index numbers by typing the following command

at the ScreenOS CLI:

get ssl ca-list

You must use the Web UI to import the CA. For more information about certificates, see

Certificates.

To change SSH versions, delete SSH settings by typing the following CLI command:

delete ssh device all

When you use the Web UI, you do not need to fill in the Full Subject Name of IC Cert field.

If you do fill it in, be sure to enter the entire certificate subject. For example:

CN=ic1.juniper.net,CN=14087306185,CN=06990218,OU=Software,O=Juniper,S=CA, C=US



After you create the IC Series device instance, set the IC Series device with the serial

number of the Infranet Enforcer. To view the serial number of the system, look at the

Device Information pane on the home page of the Web UI or enter the following command

at the CLI:

get system

WebUI

To create the instance using the Web UI:

1. Select Network > Interfaces > Edit > Services from the left navigation bar to set

management options.

2. Select Network > DHCP > Edit to disable the DHCP server for both interfaces (Trust

and Untrust).

3. Select and load the CA if you have not already done so.

a. Select Objects > Certificates.

b. Click Browse to find and select the certificate. Then click Load.

c. Select CA from the show list.

d. ClickServerSettingsand make sureCheckMethod is set correctly for the certificate

you are using.

e. Click OK.

4. Create the IC Series device instance.

a. Select Configuration > Infranet Auth > Controllers (List) > New.

b. Type controller1 in the IC Series device instance box.

c. Type IP/domain name: 10.64.12.1 in the IP/Domain Name box.

d. For the NACN Parameters, select ethernet1/1 from the Source Interface list.

e. Type 8!JsP37cK9a*_HiEwe in the Password box.

f. Select the CA from the Selected CA list.

5. Enable SSH version 2.

a. Select Configuration > Admin >Management > Enable SSH (v2).

CLI

To create the instance using the CLI:

1. Type the following commands:

set interface ethernet1/1 manage ssl

set interface ethernet1/1 manage ssh



set interface ethernet1/1 manage ip

set interface ethernet2/1manage ping

set interface ethernet2/1 dhcp server disable

set interface ethernet1/1 dhcp server disable

delete ssh device all

set ssh version v2

set ssh enable

set infranet controller name controller1 host-name 10.64.12.1

set infranet controller name controller1 password 8!JsP37cK9a*_HiEwe

set infranet controller name controller1 src-interface ethernet1/1

set infranet controller name controller1 ca-idx 001

save


Configuring the ScreenOS Connection on page 15•


Setting Up an Infranet Enforcer in Transparent Mode

In Transparent mode, the Juniper security device is usually installed between a core router

and an access distribution device. Services are enabled at the zone level, and VLAN1 is

used for management.

Transparent mode permits you to implement the following functionality:

• The device can act as a Layer 2 forwarding device, such as a bridge.

• You can control traffic flow between Layer 2 security zones by defining policies.

To configure a ScreenOS Enforcer in Transparent mode:

1. Set up Transparent mode using the predefined security zones, v1-trust and v1- untrust.

a. Assign interfaces to v1-trust and v1-untrust.

b. Configure the IP address for a source interface to establish connectivity with the

IC Series device. You can use V1-trust, V1-untrust, or V1-dmz.

c. Configure the broadcast mechanism to flooding (default) or ARP/traceroute.

ARP/trace-route is more secure than broadcast.

d. Enable management of the following services for VLAN1:

• SSL

• SSH



• Web (optional)

2. Set up the Juniper security device zones. The protected resources can be in either zone

(v1-trust or v1-untrust) as long as the protected resources are in a zone different from

the endpoints.

The IC Series device can also reside in either zone. If the IC Series device resides in a

zone different from the endpoints, configure a policy that allows traffic to the endpoints

through the ScreenOS Enforcer.


into the ScreenOS Enforcer.

Do not import the IC Series device SSL certificate into the Juniper Networks security

device.

For more information about certificates and certificate options, see the Concepts &

Examples ScreenOS Reference Guide: Volume 5, VPNs.

4. Create an instance of the IC Series device on the ScreenOS Enforcer.

5. Enable SSH.

6. Verify routing from the IC Series device to the V1-untrust zone.

To use IPsec enforcement with a ScreenOS Enforcer in Transparent mode, you might

need to configure a source interface policy on the IC Series device.

7. Ensure that both the Infranet Enforcer and the IC Series device have the correct time.

If possible, use a Network Time Protocol (NTP) server to set the date and time of both

appliances.


Creating a Transparent Mode Instance with the ScreenOS Enforcer on page 21•


Creating a Transparent Mode Instance with the ScreenOS Enforcer

This topic describes how to configure a ScreenOS device in Transparent Mode to

communicate with the Access Control Service. It includes the following information:

• Task Overview on page 21

• CLI on page 22

Task Overview

To create an IC Series device instance in transparent mode, use the CLI to perform the

following actions:

• Assign all interfaces to Layer 2 zones.

• Assign an IP address to vlan1 and set the route command.

• Set interface management options.

• Configure an IC Series device instance named controller1.



• Set the host IP address, which is the IP address of the IC Series device, to 10.64.12.1.

• Enter the NACN password. The NACN password is 8!JsP37cK9a*_HiEwe. The NACN

password must match the NACN password that you entered for the IC Series device.

• The source interface, vlan1, is the interface that the Infranet Enforcer uses to

communicate with the IC Series device. The CA index number is 001. For a descriptive

list of CA index numbers type the following CLI command:

get ssl ca-list

You must use the Web UI to import the CA.

CLI

To create the instance using the CLI:

1. Type the following commands at the CLI:

NOTE: For the firewall tooperate inTransparent (Layer2)mode,all interfacesmustbe inaLayer2 zone, suchasv1-trustor in thenull zone. Interfacescannotremain in a Layer 3 zone.

set interface eth1 zone v1-trust

set interface eth2 zone v1-untrust

set interface vlan1 ip 10.64.12.x

set interface vlan1 route

set interface vlan1 ipmanageable

unset interface vlan1manage ping

unset interface vlan1manage telnet

unset interface vlan1manage snmp

unset interface vlan1manageweb

set infranet controller name controller1 host-name 10.64.12.1

set infranet controller name controller1 password 8!JsP37cK9a*_HiEwe

set infranet controller name controller1 src-interface vlan1

set infranet controller name controller1 ca-idx 0001



• Configuring the ScreenOS Connection on page 15




Viewing the Configuration of an IC Series Device on the ScreenOS Enforcer

This topic describes how to view details about the Access Control Service configuration

from the ScreenOS user interfaces. It includes the following information:

• Configuration Details Displayed on page 23

• Web UI on page 23

• CLI on page 23

Configuration Details Displayed

You can view the configuration of an IC Series device instance through the Web UI and

the CLI. You can view the following information:

• Name of the IC Series device instance

• IP address or domain name of the IC Series device

• Port number ( always 11122)

• Timeout (60 seconds by default)

• Source interface

The Web UI also allows you to view the NACN password.

WebUI

To view configuration information on the Web UI select the following:

1. Configuration > Infranet Auth > Controllers from the left navigation bar.

2. Configuration > Infranet Auth > General Settings from the left navigation bar.

CLI

To view configuration information at the CLI, type the following command:

1. get infranet controller name controller1





Understanding the Infranet Enforcer Captive Portal Feature

When you deploy the IC Series device and Infranet Enforcer, users may not know that

they must first sign into the IC Series device for authentication and endpoint security

checking before they can access a protected resource behind the Infranet Enforcer.



To facilitate sign-in, you can configure either a redirect infranet auth policy on the

ScreenOS Enforcer or a security policy on the Junos Enforcer to automatically redirect

HTTP traffic destined for protected resources to the IC Series device. This feature is called

captive portal. When the sign-in page for the IC Series device is displayed, the user signs

in and Host Checker for OAC or Pulse or agentless Host Checker examines the endpoint

for compliance with security policies, and if the endpoint passes the security check, access

is granted to the protected resource.

Captive portal is supported on both the ScreenOS Enforcer and the Junos Enforcer.

You can configure captive portal for endpoint clients that use either source IP enforcement

or IPsec enforcement, or a combination of both methods.

Figure 2 on page 24 illustrates the sequence of events when a user attempts to access

protected resources with captive portal configured.

Figure 2: Captive Portal Event Flow

Captive portal enables an endpoint to be redirected to a different URL when the user

attempts to access a protected resource behind an Infranet Enforcer, provided the

appropriate access policies are configured on the security device. By default, users are

not redirected if captive portal is not configured for a policy.


Before Configuring Captive Portal on page 24•

• Creating a Redirect Policy on the Infranet Enforcer on page 26

• Overriding the Default Redirection Destination for Captive Portal on page 27

Before Configuring Captive Portal

DetailsTopic

The captive portal feature requires ScreenOS Release 5.4 or later runningon the ScreenOS Enforcer.

ScreenOS version

To use captive portal with the Junos Enforcer, Release 10.2 is required.Junos version



DetailsTopic

You can configure the ScreenOS Enforcer to redirect HTTP traffic to anexternal Web server instead of the IC Series device. For example, youcan redirect HTTP traffic to a Web page that explains to users therequirement to sign into the IC Series device before they can access theprotected resource. You can also explain the security policy and includea link to the IC Series device on that Web page to help users sign in.

External Web server

The captive portal feature redirects HTTP traffic only. If the user attemptsto access a protected resource using HTTPS or another protocol suchas SMTP, the Infranet Enforcer does not redirect the user’s traffic. Whenusing HTTPS or another application, the user must manually sign intothe IC Series device first before attempting to access protectedresources.

HTTP vs. HTTPS

If there is an HTTP proxy between the endpoint and the Infranet Enforcer,the Infranet Enforcer might not redirect the HTTP traffic.

HTTP proxy

In standard configurations, ScreenOS uses default HTTP ports as theredirect destination port for traffic. In addition to default HTTP ports,nonstandard HTTP port 3128 is defined for HTTP-EXT traffic toaccommodate the SQUID proxy.

The Junos Enforcer, supports only port 80.

Default port



Creating a Redirect Policy on the Infranet Enforcer

To configure the captive portal feature, you must create special policies on the Infranet

Enforcer. On the Junos Enforcer, you configure a security policy using the CLI. On the

ScreenOS Enforcer, you can configure an infranet auth policy through either the Web UI

or the CLI.

When you configure a policy for captive portal, you can redirect all traffic or only

unauthenticated traffic.

• unauthenticated—Select this option if your deployment uses source IP only or a

combination of source IP and IPsec. The Infranet Enforcer redirects clear-text traffic

from unauthenticated users to the currently connected IC Series device, or to an IP

address or domain name that you specify in a redirect URL.

After a user signs in to the IC Series device and the user’s endpoint system meets the

requirements of the IC Series device’s security policies, the Infranet Enforcer allows

the user’s clear-text traffic to pass through in source IP deployments. For IPsec

deployments, OAC or Pulse create a VPN tunnel between the user and the Infranet

Enforcer. The Infranet Enforcer then applies the VPN policy that allows the encrypted

traffic to pass through.

• all—Select this option if your deployment uses IPsec only. The Infranet Enforcer redirects

all clear-text traffic to the currently connected IC Series device, or to an IP address or

domain name that you specify in a redirect URL.

After a user signs in to the IC Series device, OAC or Pulse creates a VPN tunnel between

the user and the Infranet Enforcer. The Infranet Enforcer then applies the VPN policy

that allows the user’s encrypted traffic to pass through. This option does not allow

clear text traffic to pass through the Infranet Enforcer, which protects the network

from IP spoofing.

From the Junos CLI

To enable captive portal. associate an instance of a captive portal with a security zone

use the following command format:

user@host# set security policies from-zone zone-name to-zone zone-name policy policy-name

To create the captive portal use the following command format:

user@host# permit application-services uac-policy captive-portal captive-portal-name

You can redirect all traffic, or only unauthenticated traffic on the Junos Enforcer using

the following command format:

edit services unified-access-control captive-portal policy redirect-traffic (all | unauthenticated)

From the ScreenOSWebUI

To create a redirect infranet auth policy on the ScreenOS Enforcer:

1. Click Policies on the left navigation bar.

2. Select a source zone from the From list.

3. Select a destination zone from the To list.



4. Click New. The advanced Policy Settings page is displayed.

5. Enter the policy configuration information such as source and destination addresses.

For more about policy configuration options, see the ScreenOS Enforcer Web UI online

help.

6. Click Advanced.

7. Select Authentication, then select Infranet-Auth.

8. Specify one of the following redirection options for the infranet auth policy:

• Redirect unauthenticated traffic

• Redirect all traffic

9. (Optional) Enter a Redirect URL that specifies where to redirect matching traffic.

10. Click OK.

11. Click OK again.

You can permit more versatile redirect support on a per-policy basis. If your Infranet

Enforcer connects to different IC Series devices (though only one at a time can

communicate), you can configure the URL for each redirect policy. If a policy-based URL

is defined and redirect is enabled in the policy, unauthenticated HTTP traffic that matches

the policy is redirected to that URL even if a global redirect URL is configured. If

policy-based URL redirect is not defined and redirect is enabled, unauthenticated traffic

that matches the policy is redirected to the global redirect.

From the ScreenOS CLI

To configure a redirect infranet auth policy for deployments that use either source IP only

or a combination of source IP and IPsec type the following command:

set policy from source-zone to dest-zone src_addr dst_addr any permit infranet-authredirect-unauthenticated

To configure a redirect infranet auth policy for deployments that use IPsec only type the

following command:

set policy from source-zone to dest-zone src_addr dst_addr any permit infranet-auth redirect-all

Overriding the Default Redirection Destination for Captive Portal

By default, after you configure a redirect infranet auth policy for ScreenOS, the Infranet

Enforcer redirects HTTP traffic to the currently connected IC Series device using HTTPS.

To perform the redirection, the Infranet Enforcer uses the IP address or domain name

that you specified when you configured the IC Series device instance on the Infranet

Enforcer. The format of the URL that the ScreenOS Enforcer uses for default redirection

is:

https://<connected IC-Series-device IP or domain name>/?target=%dest-url%

If you configured your ScreenOS Enforcer to work with multiple IC Series devices in a

cluster, and the current IC Series device becomes disconnected, the ScreenOS Enforcer

automatically redirects HTTP traffic to the next active IC Series device in its configuration

list. The ScreenOS Enforcer redirects traffic to only one IC Series device at a time.



The IC Series device domain name that you specify when configuring the IC Series device

instance in the ScreenOS Enforcer must match the IC Series device domain name in the

Web browser certificate that is used when users sign in. Otherwise, the browser displays

a certificate warning when users sign in.

You do not need to override the default redirection destination except in the following

situations:

• You are using a VIP for a cluster of IC Series device appliances, and the ScreenOS

Enforcer is configured to connect to the IC Series device’s physical IP addresses.

• You want to redirect traffic to a Web server instead of to the IC Series device.

• If, because of split DNS or IP routing restrictions at your site, the ScreenOS Enforcer

uses a different address for the IC Series device than endpoints, you must specify the

domain name or IP address that endpoints must use to access the IC Series device.

By default, the ScreenOS Enforcer also encodes and forwards to the IC Series device the

protected resource URL that the user entered. The IC Series device uses the protected

resource URL to help users navigate to the protected resource. The manner in which the

IC Series device uses the protected resource URL depends on whether or not the user’s

endpoint is running OAC or Pulse.

• If the user’s endpoint is not running OAC or Pulse (that is, it is in an agentless or Java

agent configuration), the IC Series device automatically opens a new browser window

and uses HTTP to access the protected resource after the user signs in.

• If the endpoint is using OAC or Pulse, the IC Series device inserts a link in the Web page

that automatically opens after the user signs in. The user must then click that hypertext

link to access the protected resource by means of HTTP in the same browser window.

To override the default redirect destination, you must configure policies on the Infranet

Enforcer. On the Junos Enforcer, you configure a redirect–url policy using the CLI. On the

ScreenOS Enforcer, you can configure an infranet auth policy through either the Web UI

or the CLI.

Creating a Redirect Policy on the ScreenOS Enforcer

From the ScreenOSWebUI

1. Select Configuration > Infranet Auth > Controllers > Edit from the left navigation bar.

2. In the Redirect URL box, specify the IP address or domain name of the IC Series device

or external Web server using HTTP or HTTPS in the following format:

https://<IP or domain name>/<url path>/?target=%dest-url%

For example, to redirect to an IC Series device and forward the protected resource

URL, enter:

https://abc.company.com/?target=%dest-url%

To redirect to a Web server and forward the protected resource URL enter:

https://server1.company.com/cgi-bin/redirect.cgi?target=%dest_url%



The ScreenOS Enforcer replaces the %dest-url% parameter with the protected

resource URL, and then forwards the protected resource URL in encrypted form to

the IC Series device.

NOTE: In the Redirect URL string, you can omit the ?target=%dest-url%string. For example:

http://server1.company.com

If youdonot include the?target=%dest-url%string, theusermustmanuallyopen a new browser window and enter the protected resource URL againafter signing in.

From the ScreenOS CLI

1. To specify the redirect URL, enter:

set infranet controller name controller1 url "http://10.64.12.1/?target=%dest-url%"

2. To specify the redirect URL without the ?target=%dest-url% string, enter:

set infranet controller name controller1 url http://abc.company.com

Non standard Ports

With ScreenOS Release 6.3, captive portal supports HTTP traffic on any port. To use this

feature, you must define a new service on ScreenOS, and use the service in an infranet

auth policy.

You define the service with the destination ports on which HTTP is running. Select this

service in the infranet auth policy, and associate it with application “HTTP”.

For unauthenticated HTTP traffic on the port specified in the service, ScreenOS redirects

the traffic to the URL that is mentioned in the Inranet Controller configuration or that is

mentioned in the Redirect URL field of the infranet auth policy.

To configure an alternative port for redirct:

From theWeb UI

1. Create a new service in ScreenOS.

2. Create an infranet auth policy and select DSTA-HTTP (or the name you are using

when you create the service) as the service in the infranet-auth policy.

3. Set the application as HTTP for the policy.

From the CLI

Type the following commands:

set service DSTA-HTTP protocol tcp dst-port 6060-6060

set policy id 1 from trust to untrust any any DSTA-HTTP permit infranet-authredirect-unauthenticated

set policy id 1 application HTTP



For unauthenticated HTTP traffic on the specified port, ScreenOS redirects the traffic to

the URL that is specified in the IC Series device configuration, or to the one that is

mentioned in the Redirect URL field of the infranet auth polcy.

If nonstandard ports are not used in the infranet-auth policy, the behavior is the same

as in ScreenOS Release 6.2.


Understanding the Infranet Enforcer Captive Portal Feature on page 23•

• Before Configuring Captive Portal on page 24

Using VSYS on the ScreenOS Enforcer

You can logically partition a single ScreenOS Enforcer into multiple virtual systems

(VSYS) to provide multi-tenant services. Each VSYS is a unique security domain and can

have its own administrator. VSYS is supported on ISG-1000, ISG-2000, and NS- 5000

series ScreenOS Enforcers.

VSYS support on the IC Series device allows you to provision different auth table entries

and resource access policies on discrete virtual systems on the same firewall. You can

also choose a virtual system for ScreenOS infranet-auth policies and VPN objects.

When you add a VSYS to a ScreenOS Enforcer with the appropriate CLI commands, the

virtual system appears as an Infranet Enforcer on the IC Series device. See Concepts and

Examples ScreenOS Reference Guide Volume 10: Virtual Systems.

From the perspective of the IC Series device, the virtual system appears as a stand-alone

firewall device. You configure policies on the virtual system just as if you were configuring

policies for a separate firewall.

For resource access policies and auth table policies, you type the name of a vsys in the

provided field. For Enforcer policies, you select the VSYS from a pull-down menu. This

is because resource access policies and auth table policies can be distributed to multiple

ScreenOS Enforcers, while Enforcer policies apply to only one ScreenOS Enforcer.

Virtual systems do not inherit resource access policies or auth table policies from the

root-vsys (the ScreenOS Enforcer on which the vsys is created). If you have a resource

access policy or auth table policy configured for an existing ScreenOS Enforcer, and

subsequently create one or more VSYS, you need to add new policies for the vsys if you

want to allow users to access resources behind the VSYS.

If you enable command tracing in the event log, the command exec-bulkcli appears in

the log for vsys events.

You can configure multiple VSYS with no shared zones, or you can configure different

VSYS to share a common zone. For example, you could configure all endpoints to be on

the untrust zone connecting to multiple VSYS on different zones. IPsec is not supported

with a shared zone configuration. See Figure 3 on page 31

VSYS support on the IC Series device requires ScreenOS 6.2 or greater.



Figure 3: Multiple VSYSwith Shared and Unshared Zones

When a ScreenOS Enforcer with version 6.2 or greater and the appropriate VSYS licensing

connects to the IC Series device, the IC Series device automatically issues a command

to the firewall to enable UAC support for VSYS in ScreenOS Enforcers.

Individual configuration details of ScreenOS policies with VSYS is explained in the

applicable policy sections.







CHAPTER 2

Using IPsec

• IPsec Policies on page 33

• Using IPsec with the Infranet Enforcer on page 34

• Understanding Access Control Service Support for IPsec Routing Policies on page 35

• Understanding IPsec Routing Policy Configuration Options on page 38

• Using the Access Control Service User Interface to Create Basic ScreenOS Enforcer

IPsec Policies on page 40

• IPsec Routing Policies on page 41

• Before you Begin on page 42

• Configuring IPsec Routing Policies on page 42

• Using IP Address Pool Policies for IPsec in a NAT Environment on page 44

• Understanding IP Address Pool Policies on page 46

• Configuring an IP Address Pool Policy on page 47

• Understanding ScreenOS Enforcer Source Interface Policies on page 48

• Configuring Source Interface Policies on page 49

• Upgrading IPsec Enforcement Policies from Version 1.x of the Infranet

Controller on page 50

• Setting Up ScreenOS Enforcer IPsec Routing Policies on page 50

• Configuring ScreenOS Enforcer IPsec Encryption Settings on page 51

• Using ScreenOS Enforcer Bidirectional VPN Policies on page 52

• Creating a ScreenOS Bidirectional VPN Policy on page 52

• Configuring Junos Enforcer IPsec Routing Policies on page 53

IPsec Policies

This section describes the policies that you configure to use IPsec on the Infranet Enforcer.


• IPsec Routing Policy—Specifies which Infranet Enforcer an endpoint must use to

access a resource. This policy also specifies whether that resource requires an IPsec

tunnel for endpoints to access it. Note that an IPsec tunnel does not automatically

give the endpoint access. You configure IPsec routing policies on the IC Series device.

• ScreenOS Infranet Auth IPsec Policy—Contains the source and destination. The IC

Series device uses the source and destination to set up a user, user group, IKE gateway,

and VPN for each source interface in the source zone of the policy. You can set up a

basic ScreenOS IPsec policy on the IC Series device and push the policy to the ScreenOS

Enforcer, or you can set up the policy using ScreenOS Web UI or the command line.

• IP Address Pools Policy—Specifies a pool of virtual IP addresses that you want the IC

Series device to automatically assign to endpoints in NAT environments that use IPsec

tunnels to the Infranet Enforcer. You configure IP address pools policies on the IC Series

device.

• ScreenOS Source Interface Policy—Specifies the source interface on the ScreenOS

Enforcer that receives traffic from endpoints if the ScreenOS Enforcer is in Transparent

mode. You create this type of policy only if you want endpoints to use IPsec to

communicate with a ScreenOS Enforcer that is in Transparent mode, and you are using

virtual routers. You configure source interface policies on the IC Series device.

• Junos Enforcer Security Policy—On the Junos Enforcer, security policies are used to

define the source and destination address, the application, and the phase 2 policy. You

configure security policies on the Junos Enforcer. You cannot configure security policies

on the IC Series device.


Using IPsec with the Infranet Enforcer on page 34•


• Configuring ScreenOS Enforcer IPsec Encryption Settings on page 51



Using IPsec with the Infranet Enforcer

On supported endpoints that use OAC or Pulse, you can use IPsec enforcement to encrypt

the traffic between an endpoint and the ScreenOS Enforcer, thereby adding another of

protection for network assets.

IPsec is not supported on agentless or Java agent endpoints, or on endpoints that connect

by means of non-UAC software. For these clients, you must use source IP enforcement

instead.

To use IPsec enforcement, you set up a VPN tunnel with IKE (Internet Key Exchange) on

the Infranet Enforcer. You can configure IPsec enforcement by creating IPsec routing

policies on the IC Series device. For IPsec on the ScreenOS Enforcer, you can create basic

IPsec policies. For IPsec with the Junos Enforcer, you must create security policies on the

device.



Alternatively, you can set up the VPN tunnel manually using ScreenOS CLI commands

or Web UI. We recommend that you use the IC Series device to set up basic VPN policies

on the Infranet Enforcer. If necessary, you can modify the VPN tunnel setup afterwards

on the Infranet Enforcer by using ScreenOS CLI commands or Web UI.

If you modify the VPN tunnel setup on the Infranet Enforcer by using the ScreenOS CLI

commands or Web UI, you must refresh the policies on the IC Series device.

When you use the IC Series device to configure IPsec on the ScreenOS Enforcer, the IC

Series device sets up a user, user group, IKE gateway, and VPN for each source interface

in the source zone of the policy, in addition to the policy itself. The IC Series device uses

the source interface number and the ID of the destination zone to uniquely name each

of these objects.

For IPsec with the Junos Enforcer you use the CLI to create security policies. With the

Junos Enforcer, the IC Series device uses the destination zone to match the IPsec routing

policies that are configured on the IC Series device.


Setting Up ScreenOS Enforcer IPsec Routing Policies on page 50•


Understanding Access Control Service Support for IPsec Routing Policies

This topic provides an overview of Junos Pulse Access Control Service support for IPsec

routing policies. It includes the following information:

• About IPsec on page 35

• Access Solution Service Client Support for IPsec Routing Policies on page 36

• Infranet Enforcer Support for IPsec Routing Policies on page 36

• Infranet Enforcer IPsec Policy Features on page 36

• Dynamic IPsec Routing Policies with ScreenOS Enforcers on page 37

• Refreshing IPsec Policies on the IC Series on page 37

About IPsec

IP Security (IPsec) is a suite of related protocols for cryptographically securing

communications at the IP Packet Layer. IPsec also provides methods for the manual and

automatic negotiation of security associations (SAs) and key distribution.

An IPsec tunnel consists of a pair of unidirectional SAs – one at each end of the tunnel

– that specify the security parameter index (SPI), destination IP address, and security

protocol. In a dial-up VPN, there is no tunnel gateway on the VPN dial-up client end of

the tunnel. Rather, the tunnel extends directly to the client itself.

IPsec routing policies allow you to specify the parameters for SAs between endpoints

and the Infranet Enforcer.


Chapter 2: Using IPsec

Access Solution Service Client Support for IPsec Routing Policies

OAC and Pulse support IPsec using IKEv1 with XAuth. For the client to establish an IPsec

tunnel, it must retrieve configuration information from the Infranet Enforcer. This

information is forwarded to The IC Series device by the respective device. When a user

with OAC or Pulse signs in to the IC Series device, these configuration details are passed

on to the client to establish an IPsec tunnel with the Infranet Enforcer.

To set up IPsec for endpoints with OAC or Pulse, you configure policies on the IC Series

device and on the security device. The IC Series device pushes the required IPsec

configuration parameters to the client when the client first attempts to connect to a

protected resource behind and IC Series device for which IPsec has been configured.

IPsec is not supported on agentless or Java agent endpoints, or on endpoints that connect

by means of non-UAC software. For these clients, you must use source IP enforcement

instead. Source IP enforcement allows endpoints to communicate with unencrypted

traffic.

Infranet Enforcer Support for IPsec Routing Policies

IPsec is supported on both the ScreenOS Enforcer and the Junos Enforcer (beginning in

Release 10.0).

On the Infranet Enforcers, you set up a VPN tunnel with IKE (Internet Key Exchange).

For Junos Enforcers, you use the Junos OS user interface to configure the Junos Enforcer

IPsec security zones and IPsec routing policy settings. The Access Control Service IPsec

routing policies match the destination zone set in the Junos OS configuration.

For the ScreenOS Enforcer, you can use the Access Control Service user interface to

configure basic IPsec policies and then push them to the ScreenOS Enforcer. Alternatively,

you can use the ScreenOS user interface to set up the VPN tunnel. We recommend that

you use the Access Control Service user interface. When you use Access Control Service

user interface to set up the IPsec routing policy, you specify a user, user group, IKE gateway,

and VPN for each source interface in the source zone of the policy, in addition to the

policy itself. The Access Control Service uses the source interface number and the ID of

the destination zone to uniquely name each of these objects.

NOTE: If necessary, you can later use the ScreenOS user interface tomodifythe VPN tunnel configuration. Whenever youmodify the VPN tunnel setupfrom the ScreenOS side of the configuation, youmust refresh the AccessControl Service policies.

Infranet Enforcer IPsec Policy Features

This section describes the policies that you configure to use IPsec on the Infranet Enforcer.



• IPsec Routing Policy—Specifies which Infranet Enforcer an endpoint must use to

access a resource. This policy also specifies whether that resource requires an IPsec

tunnel for endpoints to access it. Note that an IPsec tunnel does not automatically

give the endpoint access. You configure IPsec routing policies on the IC Series device.

• ScreenOS Infranet Auth IPsec Policy—Contains the source and destination. The IC

Series device uses the source and destination to set up a user, user group, IKE gateway,

and VPN for each source interface in the source zone of the policy. You can set up a

basic ScreenOS IPsec policy on the IC Series device and push the policy to the ScreenOS


• IP Address Pools Policy—Specifies a pool of virtual IP addresses that you want the IC

Series device to automatically assign to endpoints in NAT environments that use IPsec

tunnels to the Infranet Enforcer. You configure IP address pools policies on the IC Series

device.

• ScreenOS Source Interface Policy—Specifies the source interface on the ScreenOS

Enforcer that receives traffic from endpoints if the ScreenOS Enforcer is in Transparent

mode. You create this type of policy only if you want endpoints to use IPsec to

communicate with a ScreenOS Enforcer that is in Transparent mode, and you are using

virtual routers. You configure source interface policies on the IC Series device.

• Junos Enforcer Security Policy—On the Junos Enforcer, security policies are used to

define the source and destination address, the application, and the phase 2 policy. You

configure security policies on the Junos Enforcer. You cannot configure security policies

on the IC Series device.

Dynamic IPsec Routing Policies with ScreenOS Enforcers

Depending on the version of ScreenOS you are using, the steps for configuring IPsec

differs. If you are using ScreenOS Release to 6.1 and earlier, you configure ScreenOS IPsec

policies and an IPsec routing policy for each resource that you want to protect. With

ScreenOS Release 6.1 or later the IC Series device can dynamically provision IPsec routing

policies for you, eliminating the need to configure a separate policy for each resource.

The IC Series device initially queries all connected Infranet Enforcers for version

information. If ScreenOS Release 6.1 or greater is detected, the IC Series device initiates

a command to enable dynamic provisioning.

When an authenticated endpoint without an auth table entry attempts to access a

resource through the Infranet Enforcer, the Infranet Enforcer sends a message to the IC

Series device that includes the source and destination IP, the source interface on which

the dropped packet was received, and the ID of the Enforcer policy associated with the

resource. The IC Series device uses this information to negotiate an IPsec tunnel between

the endpoint and the Infranet Enforcer and provision a dynamic IPsec routing policy.

Refreshing IPsec Policies on the IC Series

Each time the Infranet Enforcer and IC Series device establish a new connection with

each other, the IC Series device queries the Infranet Enforcer for policy information, which

it uses for provisioning IPsec to endpoints. If you modify the IPsec policies on the Infranet

Enforcer while the Infranet Enforcer is connected to the IC Series device, you must refresh



the policies on the IC Series device so that the IC Series device uses the new policies,

otherwise , the IC Series device continues to use the older policies until the next time it

disconnects from and reconnects to the Infranet Enforcer.


Understanding IPsec Routing Policy Configuration Options on page 38•



Understanding IPsec Routing Policy Configuration Options

This topic provides an overview of IPsec routing policy configuration options. You should

become familiar with these options before you begin the configuration tasks. This topic

includes the following information:

• Configuration Overview on page 38


• Advanced Configuration Options on page 39

Configuration Overview

An IPsec routing policy specifies which Infranet Enforcer the device endpoints must use

to access resources when using IPsec. The IPsec routing policy also specifies that

endpoints must use an IPsec tunnel to the Infranet Enforcer to access resources.

To use IPsec with ScreenOS Release 6.1 or earlier, you must configure separate IPsec

routing policies for different resources that you wish to protect. IPsec routing policies are

specific to the resources that you add.

If you are using Screen OS Release 6.1 or later, you can configure one dynamic IPsec

routing policy for each destination zone on each Infranet Enforcer.

In IPsec routing policies with ScreenOS Release 6.1 earlier, you can specify a range of

exceptions for traffic to certain resources that you do not want to use IPsec. The

exceptions can fall within the ranges of resources that the Infranet Enforcer protects. In

this case, if you create an exception for traffic that flows through the Infranet Enforcer,

you must also create another policy on the Infranet Enforcer that allows the exception

traffic to flow through.

For example, you might create an IPsec routing policy that uses IPsec for 0.0.0.0/0 (the

entire network). In the same policy, you can specify the resources that are exceptions

and that do not use IPsec, such as 172.24.80.30 (the IC Series device), 172.24.80.31 (the

Infranet Enforcer), and 172.24.144/21 (a wireless network).

With ScreenOS Release 6.1 or later, policy exceptions are unnecessary. Dynamic IPsec

routing ensures that IPsec tunnels are created only for destinations that are governed

by the ScreenOS IPsec policy.




Table 4: Configuration Topics

DetailsTopic

The Infranet Enforcer and the IC Series device must be connected before you use the IC Series device to set up IPsec enforcement on the Infranet Enforcer.Connection

You cannot establish an IPsec tunnel if IAS (IPsec access server) is enabled on the ScreenOS Enforcer. To determine whether IAS is enabled, enter the followingcommand on the ScreenOS Enforcer Command Line Interface:

get ipsec access_session status

To turn off IAS, use the following command:

unset ipsec access-session enable.

For details about this functionality, seehttp://www.juniper.net/techpubs/en_US/release-independent/screenos/information-products/pathway-pages/screenos/product/index.html.

IPsec access server on ScreenOS Enforcer

If you configure IPsec enforcement for an Infranet Enforcer that has multiple interfaces in the source zone, the IC Series device configures a unique IKE gateway,VPN, and tunnel policy for each interface. To distinguish the tunnel policies, the IC Series device displays the name of the VPN for each tunnel policy in the VPNcolumn on UAC > Infranet Enforcer > Enforcer Policies after you click Save Changes.

Multiple interfaces

If you are using ScreenOS Release 6.1 or later you can configure the Infranet Enforcer to dynamically provision IPsec routing policies. To implement this feature,you create a ScreenOS source IP policy with a source and destination zone that matches the ScreenOS IPsec policy. Then you configure captive portal for thesource IP policy. Dynamic IPsec routing policies are not supported on the Junos Enforcer.

Dynamic IPsec routing policies

When you use the IC Series device to configure IPsec on the Infranet Enforcer, the IC Series device creates an IPsec policy that uses the following default IPsecencryption settings: NoPFS, ESP, 3DES, and SHA1. You can, however, change the phase 2 proposal on the Infranet Enforcer by using the CLI or Web UI.

Default encryption settings on the ScreenOS Enforcer

To connect from a computer inside the protected network back to the endpoint, you can create a bidirectional VPN policy on the Infranet Enforcer.Bi-directional VPN policy

To include the CLI commands that the IC Series device sends to the Infranet Enforcer in the IC Series device event logs, use the Enforcer Command Trace option(select System > Log/Monitoring > Events > Settings).

CLI commands

On the Junos Enforcer, only one IPsec VPN tunnel per “from-zone” to “to-zone” is supported.Junos Enforcer zone limitation

To troubleshoot your IPsec configuration, you can view the Event logs on the IC Series device. You can also view IPsec information on the endpoint by selectingTools > Diagnostics > IPsec Diagnostics in OAC.

Troubleshooting

Advanced Configuration Options

DetailsTopic

Do not use IPsec for the IC Series device, the Infranet Enforcer, and networks where your endpoints arelocated. For example, if you create an IPsec routing policy that uses IPsec on an entire network range(such as 0.0.0.0/0) for your protected resources, be sure to specify exceptions in the same policy forthe IP addresses assigned to IC Series device, Infranet Enforcer, and the endpoints.

IP addressexceptions




DetailsTopic

For maximum inter-operability with other third-party IPsec clients, select both Always use UDPencapsulation and Always use a virtual adapter. When both options are selected, Network addresstranslation (NAT) is simulated even if a NAT device is not present. We recommend that you select bothoptions or neither option. For example, if an endpoint contains two network interfaces, such as a wiredand a wireless interface, and a NAT device is not present between the endpoint and the Infranet Enforcer.If the endpoint does not access a protected resource by using the interface that is connected to thenetwork where the Infranet Enforcer is installed, then the user cannot access the protected resourcethrough either interface without a virtual adapter. Because the IC Series device does not automaticallyinstall a virtual adapter unless a NAT device is detected, enable the Always use a virtual adapter optionto simulate NAT and force the use of a virtual adapter for this use case.

UDP encapsulationand virtual adapters


Using the Access Control Service User Interface to Create Basic ScreenOS Enforcer

IPsec Policies on page 40

•





Using the Access Control Service User Interface to Create Basic ScreenOS EnforcerIPsec Policies

NOTE: The ScreenOS Enforcer supports static and dynamic IPsec.

If you are configuring IPsec with the ScreenOS Enforcer, you can create basic IPsec policies

on the IC Series device and then push the policies to the ScreenOS Enforcer, where you

can modify the policies.

To configure IPsec enforcement on the ScreenOS Enforcer:

1. In the admin console select UAC > Infranet Enforcer > Connection, then select New

Enforcer if you have not already configured a connection to the Infranet Enforcer on

which you want to configure IPsec enforcement.

2. SelectUAC> InfranetEnforcer>Connectionand click the name in the Enforcer column

of the Infranet Enforcer on which you want to configure IPsec enforcement.

3. Select UAC> Infranet Enforcer > Enforcer Policies. Then:

a. Select the source zone for the policy from the Source Zone list. The source zone is

the zone where the endpoint is located.

b. Select the destination zone for the policy from the Destination Zone list. The

destination zone is where the protected resources are located.

c. Select IPsec from the Typelist.



d. Click Add.

e. Click Save Changes to save the IPsec policy.

The IC Series device sets up a VPN tunnel with IKE on the Infranet Enforcer that

consists of a user, user group, IKE gateway, and VPN for each source interface in

the source zone of the policy. The IC Series device uses the source interface number

and the ID of the destination zone to uniquely name each of these objects.

4. To configure the IC Series device to provision dynamic IPsec routing policies, create

a new source IP policy on the Infranet Enforcer with the same source and destination

zone as the ScreenOS IPsec policy and with the captive portal feature configured to

redirect all traffic.

5. Select UAC > Infranet Enforcer > Resource Access, and configure Infranet Enforcer

resource access policies to specify which users are allowed or denied access to a set

of protected resources

6. Select UAC> Infranet Enforcer > IPsec Routing, and configure IPsec routing policies to

specify which Infranet Enforcer device the endpoints must use to access each set of

resources when using IPsec.

7. If you are using IPsec in a NAT environment, configure IP address pool policies by

selecting UAC > Infranet Enforcer > IP Address Pools.

8. If you want endpoints to use IPsec to communicate with an Infranet Enforcer that is

in Transparent mode, in some cases you may need a source interface policy.

9. To refresh IPsec policies, select UAC > Infranet Enforcer > Policies and click Refresh

Policies.




IPsec Routing Policies

An IPsec routing policy specifies which Infranet Enforcer the device endpoints must use

to access resources when using IPsec. The IPsec routing policy also specifies that

endpoints must use an IPsec tunnel to the Infranet Enforcer to access resources.

To use IPsec with ScreenOS Release 6.1 or earlier , you must configure separate IPsec

routing policies for different resources that you wish to protect. IPsec routing policies are

specific to the resources that you add.

If you are using Screen OS Release 6.1 or later, you can configure one dynamic IPsec

routing policy for each destination zone on each Infranet Enforcer.

In IPsec routing policies with ScreenOS Release 6.1 earlier , you can specify a range of

exceptions for traffic to certain resources that you do not want to use IPsec. The

exceptions can fall within the ranges of resources that the Infranet Enforcer protects. In

this case, if you create an exception for traffic that flows through the Infranet Enforcer,



you must also create another policy on the Infranet Enforcer that allows the exception

traffic to flow through.

For example, you might create an IPsec routing policy that uses IPsec for 0.0.0.0/0 (the

entire network). In the same policy, you can specify the resources that are exceptions

and that do not use IPsec, such as 172.24.80.30 (the IC Series device), 172.24.80.31 (the

Infranet Enforcer), and 172.24.144/21 (a wireless network).

With ScreenOS Release 6.1 or later, policy exceptions are unnecessary. Dynamic IPsec

routing ensures that IPsec tunnels are created only for destinations that are governed

by the ScreenOS IPsec policy.


Before you Begin on page 42•


Before you Begin

DetailsTopic

Do not use IPsec for the IC Series device, the Infranet Enforcer, and networks where your endpoints arelocated. For example, if you create an IPsec routing policy that uses IPsec on an entire network range(such as 0.0.0.0/0) for your protected resources, be sure to specify exceptions in the same policy forthe IP addresses assigned to IC Series device, Infranet Enforcer, and the endpoints.

IP addressexceptions

For maximum inter-operability with other third-party IPsec clients, select both Always use UDPencapsulation and Always use a virtual adapter. When both options are selected, Network addresstranslation (NAT) is simulated even if a NAT device is not present. We recommend that you select bothoptions or neither option. For example, if an endpoint contains two network interfaces, such as a wiredand a wireless interface, and a NAT device is not present between the endpoint and the Infranet Enforcer.If the endpoint does not access a protected resource by using the interface that is connected to thenetwork where the Infranet Enforcer is installed, then the user cannot access the protected resourcethrough either interface without a virtual adapter. Because the IC Series device does not automaticallyinstall a virtual adapter unless a NAT device is detected, enable the Always use a virtual adapter optionto simulate NAT and force the use of a virtual adapter for this use case.

UDP encapsulationand virtual adapters


Configuring IPsec Routing Policies on page 42•


Configuring IPsec Routing Policies

To configure an IPsec routing policy:

1. In the IC Series device admin console, select UAC > Infranet Enforcer > IPsec Routing.

2. Click NewPolicy.

3. On the New Policy page:

a. For Name, enter a name to label this IPsec routing policy.



b. For Description, enter an optional description.

4. If you are using ScreenOS Release 6.1 or later, and you want to configure the IC Series

device to dynamically provision IPsec routing policies, select the Dynamic check box.

The Resources and Exceptions text boxes and the Infranet Enforcer check boxes

disappear.

5. Go to step 10 to continue configuring this policy for ScreenOS Release 6.1 or later.

6. For Resources, enter the IP address and netmask of each resource that requires

endpoints to use IPsec, one per line, in the following format:

<ip address>[/netmask]

You cannot specify a host name in an IPsec routing policy. You must specify an IP

address.

7. For Exceptions, use the following format, one per line, to specify the IP address and

netmask of each resource that has traffic which you do not want to flow through the

Infranet Enforcer:

<ip address>[/netmask]

Each exception must be a subset of what you specify for Resources.

8. For Destination Zone, enter the zone that is configured on the Infranet Enforcer where

the protected resources specified in this IPsec routing policy are located. For example:

trust

9. Select these options to configure IPsec interoperability and tunnel persistence:

• Always use UDP encapsulation—Allows the client and the Infranet Enforcer to

create an IPsec tunnel inside a third-party IPsec tunnel by using UDP encapsulation

even if a NAT device is not present. For example, for inter-operability with third-party

IPsec clients running on the endpoint The IC Series device uses port 4500 for UDP

encapsulation in compliance with RFC 3948.

• Always use a virtual adapter—Forces the use of a virtual adapter on the endpoint.

If you select this option, you must also set up IP address pools even if a NAT device

is not present.

• Persistent Tunnel Mode—Allows you to determine whether or not a tunnel is

established when a user first connects to the IC Series device. If the check box is

selected, an IPsec tunnel is established, and users can access protected resources

behind the Infranet Enforcer. If the check box is not selected, the tunnel is not

automatically set up: a tunnel will not be initiated until there is a request for traffic.

10. From the Enforcer list, choose the Infranet Enforcer to which endpoints connect to

access the resources specified in this IPsec routing policy.

11. In the Roles section, specify:

• Policy applies to ALL roles—To apply this IPsec routing policy to all users.

• Policy applies to SELECTED roles—To apply this IPsec routing policy only to users

who are mapped to roles in the Selected roles list. Be sure to add roles to this list

from the Available roles list.



• Policy applies toall rolesOTHERTHANthose selectedbelow—To apply this IPsec

routing policy to all users except for those who map to the roles in the Selected

roles list. Be sure to add roles to this list from the Available roles list.





Using IP Address Pool Policies for IPsec in a NAT Environment

The IC Series device supports the use of IPsec tunnels through NAT devices to allow

users secure access to protected resources. In a NAT environment, a virtual IP address

must be used for the IPsec tunnel’s inner address.

You can configure a pool of virtual IP addresses that the IC Series device can automatically

assign to endpoints by creating IP address pool policies. An IP address pool is a contiguous

range of IP addresses which you configure by specifying the starting address and the

number of addresses in the pool. You can associate an IP address pool with one or more

Infranet Enforcers.

IP address pool policies are required if one of the following is true:

• You are using IPsec in a NAT environment.

• You selected the Always use a virtual adapter option in an IPsec routing policy to enable

interoperability with other third-party IPsec clients running simultaneously on the

endpoint, such as Juniper Networks Network Connect or Microsoft IPsec.

To use NAT devices in the UACl solution, the endpoints must be located on one side of

the NAT devices, and both the IC Series device and Infranet Enforcer must be located on

the other side of the devices.

Also note the following if you are using NAT:

• NAT is not supported between the IC Series device and Infranet Enforcer.

• If there is a NAT device between the endpoint and the IC Series device, but not between

the endpoint and the Infranet Enforcer, source IP enforcement does not work. This is

also true if there is a NAT device between the endpoint and the Infranet Enforcer, but

not between the endpoint and the IC Series device.

If NAT is not detected, the client uses the endpoint’s physical IP address when creating

the IPsec tunnel to the Infranet Enforcer. The IC Series device does not allocate an IP

address from the pool.

Figure 4 on page 45 shows an example of a NAT environment where endpoints 1 and 2

have the same physical IP address: 192.168.1.1. By using an IP address pool policy, you

can configure the IC Series device to assign a unique, routable, virtual IP address to each

endpoint.



Figure 4: Using an IP Address Pool in a NAT Environment

The following sequence of events occur when the IC Series device and a Juniper client

(OAC or Pulse) use an IPsec tunnel through a NAT device:

• When the client connects to the IC Series device and authenticates the user, the client

returns the endpoint’s source IP address that is used to access the Infranet Enforcer

to the IC Series device. The IC Series device saves the source IP address internally.

• When the user attempts to access a protected resource, an IKE exchange occurs to

set up an IPsec tunnel between the endpoint and the Infranet Enforcer.

• During the IKE exchange, the Infranet Enforcer detects the source IP address of the

endpoint and sends that IP address to the IC Series device.

• The IC Series device compares its saved source IP address for the endpoint with the

endpoint’s IP address sent from the Infranet Enforcer. If the addresses do not match,

the IC Series device determines that there is a NAT device between the endpoint and

the Infranet Enforcer. The IC Series device automatically provisions an IP address from

an IP address pool policy that you configured (for example, 10.11.0.10-100). The IC

Series device assigns the IP address to the endpoint based on the IP address pool

policy that applies to the user’s role. The IC Series device then sends the IP address to

the Infranet Enforcer.

• The Infranet Enforcer sends that IP address from the IP address pool (for example,

10.11.0.10) to the client on the endpoint during the Xauth authentication exchange.

• The client on the endpoint configures a virtual network adapter using the IP address

sent from the Infranet Enforcer.

• The endpoint initiates an IPsec connection to the Infranet Enforcer, and the Infranet

Enforcer sets up dynamic routes for each IP address. The user can now use the endpoint

to access protected resources.



The IC Series device allocates one IP address for the duration of each client session,

which lasts as long as the client is connected to the IC Series device. After a session ends,

the IC Series device can reuse the allocated address for a different endpoint.

When the IC Series device must provide an inner IP address for a new IPsec tunnel, it

attempts to reuse an existing inner IP address assigned to the endpoint before allocating

a new one. The IC Series device checks all of the inner IPs allocated from IP address pools

for the endpoint. For each IP address, the IC Series device determines whether the policy

from which that address was allocated applies to the user and the Infranet Enforcer for

the new IPsec tunnel. If a compliant IP address is found, it is used and no new IP address

is allocated. If a compliant IP address is not found, a new IP address is allocated.


Understanding IP Address Pool Policies on page 46•


Understanding IP Address Pool Policies

DetailsTopic

If you are using multiple Infranet Enforcers across a LAN, make sure thatthe IP address pool contains addresses that are valid for each InfranetEnforcer.

Multiple Infranet Enforcers

If you are using multiple unclustered IC Series devices across a LAN,make sure that the IP address pool contains addresses that are uniquefor each IC Series device. The endpoint is assigned an virtual IP addressfor each unclustered IC Series device to which OAC connects.

Multiple unclustered IC Series devices

Make sure that the IP pool addresses do not conflict with addresses ofhosts that the endpoint might access.

IP address conflicts

If you change or delete the IP addresses in an IP address pool, you mustdelete all user sessions in order to stop using those addresses. To deleteall user sessions, select System > Status > Active Users page of the ICSeries device admin console and click Delete All.

Deleting IP addresses in an IP pool

Be sure to specify a sufficient number of addresses in the IP addresspool for all of the endpoints in your deployment. When all of theaddresses in the pool are assigned to endpoints, additional endpointscannot obtain a virtual IP address and are blocked from accessingprotected resources. The IC Series device logs a message in the Eventlog when an IP address cannot be assigned to an endpoint.

Number of available IP addresses


Using IP Address Pool Policies for IPsec in a NAT Environment on page 44•




Configuring an IP Address Pool Policy

To configure an IP address pool policy:

1. In the IC Series device admin console, select UAC > Infranet Enforcer > IP Address

Pools.

2. Click NewPolicy.


a. For Name, enter a name to label this IP address pool policy.

b. (Optional) For Description, enter a description.

4. For IP address pool, specify IP addresses or a range of IP addresses for the IC Series

device to assign to endpoints. The IP address range can be specified as shown in Table

15 where the last component of the IP address is a range delimited by a hyphen (-).

Special characters are not allowed.

Table 5: Syntax for IP Address Pools

DescriptionIP Address Range

A single IP addressa.b.c.d

All IP addresses from the first address to the last address, inclusivea.b.c.d-e.f.g.h

An abbreviated form that specifies the range a.b.c.d through a.f.g.ha.b.c.d-f.g.h

An abbreviated form that specifies the range a.b.c.d through a.b.g.ha.b.c.d-g.h

An abbreviated form that specifies the range a.b.c.d through a.b.c.ha.b.c.d-h

All addresses in a networka.b.c.d/mask

For example, to allocate all addresses in the range 172.20.0.0 through 172.20.3.255,

specify 172.20.0.0-3.255. To allocate all addresses in a class C network, specify

10.20.30.0/24.

5. Under Infranet Enforcer, select the Infranet Enforcer to which you want to apply this

IP address pool policy and click Add. To apply the policy to all Infranet Enforcers, do

not add any Infranet Enforcers, and leave the default setting (all) listed in the Selected

Enforcers list.


• Policy applies to ALL roles—To apply this IP address pool policy to all users.

• Policy applies to SELECTED roles—To apply this IP address pool policy only to users

who are mapped to roles in the Selected roles list. Be sure to add roles to this list

from the Available roles list.



• Policyapplies toall rolesOTHERTHANthoseselectedbelow—To apply this IP address

pool policy to all users except for those who map to the roles in the Selected roles

list. Be sure to add roles to this list from the Available roles list.


If the IP addresses you specify in the IP address pool policies (that is, the virtual IP

addresses) are not routable from the network where your protected resources are located,

make sure you enable Source Network Address Translation (NAT-src) on the infranet

auth tunnel policies that configure IPsec on the Infranet Enforcer.

To enable NAT-src using the Infranet Enforcer Web UI:

1. Click Policies.

2. Click Edit on the infranet auth tunnel policy.

3. Click Advanced.

4. Select Source Translation and click OK.

For information about enabling NAT-src on the infranet auth tunnel policy, see


.


Using IP Address Pool Policies for IPsec in a NAT Environment on page 44•

• Understanding IP Address Pool Policies on page 46

Understanding ScreenOS Enforcer Source Interface Policies

If you want endpoints to use IPsec to communicate with a ScreenOS Enforcer that is in

Transparent mode, you might need to configure a source interface policy on the IC Series

device. A source interface policy specifies the source interface on the ScreenOS Enforcer

that receives traffic from endpoints.

The use cases for configuring source interface policies are limited. You need to use a

source interface policy only if you have multiple virtual routers AND you have an IPsec

routing policy with destination zone DEST, and if one of the following is true:

• There are multiple IPsec policies on the ScreenOS Enforcer with a destination zone

DEST and different source zones.

• There is an IPsec policy on the ScreenOS Enforcer with a destination zone DEST whose

source zone has multiple interfaces.

For more information about how to set up a virtual router in the ScreenOS Enforcer, see

http://www.juniper.net/techpubs/en_US/release-independent/screenos/information-products/pathway-pages/screenos/product/index.html.


Setting Up an Infranet Enforcer in Transparent Mode on page 20•

• Configuring Source Interface Policies on page 49





Configuring Source Interface Policies

To configure a source interface policy:

1. In the IC Series device admin console, select UAC > Enforcer > IPsec Routing.

2. Select the Always show source interface policies check box. The Save Changes button

blinks.

3. Click Save Changes. The Source Interface tab is displayed at the top of the page.

4. Select the Source Interface tab.

5. Click NewPolicy.


a. For Name, enter a name to label this source interface policy.


7. From the Enforcer list, choose the Infranet Enforcer to which endpoints connect.

8. For Source Interface, specify the interface on the ScreenOS Enforcer to which traffic

from endpoints connects. This is the default interface for the zone you want to build

a gateway for, not the interface name. To view the zone table on the ScreenOS

Enforcer, type the following command:

get zone


• Policy applies to ALL roles—To apply this source interface policy to all users.

• Policy applies to SELECTED roles—To apply this source interface policy only to

users who are mapped to roles in the Selected roles list. Be sure to add roles to this

list from the Available roles list.

• Policy applies to all roles OTHER THAN those selected below—To apply this

source interface policy to all users except for those who map to the roles in the

Selected roles list. Be sure to add roles to this list from the Available roles list.



Understanding ScreenOS Enforcer Source Interface Policies on page 48•




Upgrading IPsec Enforcement Policies fromVersion 1.x of the Infranet Controller

If you upgraded your Infranet Controller from a version 1.x to 2.0 or later, be aware that

the Infranet Controller does not automatically upgrade any previously configured IPsec

enforcement policies. You must manually reconfigure all IPsec enforcement policies by

using the following instructions.

To manually reconfigure IPsec enforcement policies from version 1.x of the Infranet

Controller:

1. In the Infranet Controller admin console, choose UAC > Enforcer > IPsec Routing. Note

the Infranet Enforcer and destination zone specified in each previously configured

IPsec routing policy.

2. While the Infranet Enforcer is connected to the Infranet Controller, navigate to the

UAC > Enforcer > Connection page.

3. Click the name in the Enforcer column of the Infranet Enforcer on which you want to

configure IPsec enforcement.

4. Click the Enforcer Policies tab.

5. On the Enforcer Policies page, create a new IPsec enforcement policy for each IPsec

routing policy and specify the:

• Source zone (the zone on which end-points are connected)

• Destination zone (as specified in each IPsec routing policy)

6. If necessary, use the ScreenOS Web UI or CLI to customize the new IPsec enforcement

policy.

7. Configure IP address pool policies if you are using IPsec in a NAT environment, or if

the endpoints are simultaneously running other third-party IPsec clients such as Juniper

Network Connect or Microsoft IPsec.


Using IPsec with the Infranet Enforcer on page 34•

Setting Up ScreenOS Enforcer IPsec Routing Policies

In this example, you use the IC Series device to set up IPsec enforcement from Untrust

to Trust, and Untrust has one source interface ethernet2. If ethernet2 has an interface

number of 5, and Trust has a zone ID of 2, then the IC Series device runs the following

CLI commands on the ScreenOS Enforcer:

set user $infra-u-5-2 ike-id u-fqdn u5-2.juniper.net share-limit 50000

set user $infra-u-5-2 type ike

set user-group $infra-g-5-2 user $infra-u-5-2

set ikegateway$infra-gw-5-2dial-up$infra-g-5-2Aggroutgoing-interfaceethernet2seedpreshareARANDOMSTRING proposal pre-g2-3des-sha

set ike gateway $infra-gw-5-2 xauth server $infranet query-config



set ike gateway $infra-gw-5-2 xauth server auth-method chap

set vpn $infra-vpn-5-2 gateway $infra-gw-5-2 no-replay tunnel idletime 0 sec-level compatible

set policy fromUntrust to Trust "Dial-Up VPN" any any tunnel vpn $infra-vpn-5-2 infranet-auth

To use dynamic IPsec with ScreenOS, you configure two policies. On the ScreenOS

Enforcer, you must have two policies between the zones of interest: a source IP infranet

auth policy with the "redirect-all" option, and a tunnel infranet auth policy for IPsec.


Configuring ScreenOS Enforcer IPsec Encryption Settings on page 51•

Configuring ScreenOS Enforcer IPsec Encryption Settings

When you use the IC Series device to configure IPsec on the Infranet Enforcer, the IC

Series device creates an IPsec policy that uses these default IPsec encryption settings

for the phase 2 proposal: NoPFS, ESP, 3DES, and SHA1.

You can change the phase 2 proposal by using the Infranet Enforcer CLI or Web UI. For

example, you can change the phase 2 proposal by typing the following CLI command:

set vpn $infra-vpn-2-11 gateway $infra-gw-2-11 proposal nopfs-esp-aes128-sha

Possible values for the phase 2 proposal are:

nopfs-esp-des-md5

nopfs-esp-des-sha1

nopfs-esp-3des-md5

nopfs-esp-3des-sha1

nopfs-esp-aes128-md5

nopfs-esp-aes128-sha1

nopfs-esp-aes256-sha1

nopfs-esp-null-sha1

g2-esp-des-md5

g2-esp-des-sha1

g2-esp-3des-md5

g2-esp-3des-sha1

g2-esp-aes128-md5

g2-esp-aes128-sha1

g2-esp-aes192-sha1

g2-esp-aes256-sha1

In the Web UI select the following:

VPN > AutoKey IKE > edit > advanced > select user defined custom

It does not matter what preshared seed you use for the IKE gateway because the IC Series

device overrides it when it connects to the Infranet Enforcer.



Use the following settings for the VPN tunnel setup. Otherwise the IPsec enforcement

does not work correctly between the IC Series device and the Infranet Enforcer:

• xauth authentication

• dial-up VPN

• CHAP auth method

For more information about setting up a VPN tunnel for a dial-up user with IKE, see

theConcepts&ExamplesScreenOSReferenceGuide:Volume5,VirtualPrivateNetworks

or the ScreenOS CLI Reference Guide.



Using ScreenOS Enforcer Bidirectional VPN Policies

If users need to connect from a computer inside the protected network back to the

endpoint that is connected by means of a dial-up VPN policy, you can create a bidirectional

VPN policy on the Infranet Enforcer. You create a bidirectional VPN policy on an existing

IPsec (dial-up VPN) policy that allows allow traffic from the endpoint to the protected

network.

The following examples are use cases for bidirectional VPN policies:

• A user’s endpoint at the office is connected by means of a dial-up VPN policy, and the

user wants to connect remotely to his office computer from another computer outside

the office.

• To diagnose a problem, a helpdesk employee needs to use a remote desktop system,

such as Virtual Network Computing (VNC) or Microsoft Remote Desktop on another

computer to connect to a user’s computer, and the user’s computer is connected by

means of a dial-up VPN policy.


Creating a ScreenOS Bidirectional VPN Policy on page 52•

Creating a ScreenOS Bidirectional VPN Policy

To create a bidirectional VPN policy using the CLI, use the following command:

set pol from <protected-resource-zone> to <endpoint-zone> any “Dial-up VPN” any tunnel vpn<vpn-from-policy-going-the-other-way> pair policy <id-of-policy-going-the-other-way>

In the following example, an infranet-auth dial-up VPN policy from untrust to trust on

your Infranet Enforcer. The ID of the policy is 36, and the vpn is $infra-vpn- 1-2. The

following command sets up the corresponding bidirectional VPN policy to allow traffic

from trust to untrust:

set pol from trust to untrust any "Dial-up VPN" any tunnel vpn $infra-vpn-1-2 pair-policy 36



To create a bidirectional VPN policy using the Web UI:

1. Using the IC Series device, create the IPsec (dial-up VPN) policy on theUAC> Infranet

Enforcer > Enforcer Policies page.

2. In the Infranet Enforcer Web UI, edit the dial-up VPN policy that you created in the

previous step by selecting Policies > Edit.

3. Select Modifymatching bidirectional VPN policy and click OK.

4. Select the new bidirectional VPN policy that you created in the preceding step by

selecting Policies > Edit.

a. Clear the Modifymatching bidirectional VPN policy check box.

b. Click Advanced.

c. Clear the Authentication check box on the Advanced Policy Settings page.

d. Click OK.


Using ScreenOS Enforcer Bidirectional VPN Policies on page 52•

Configuring Junos Enforcer IPsec Routing Policies

This topic describes how to configure Junos Enforcer IPsec routing policies. It includes

the following information:


• Configuration Example on page 54


You use the Junos OS CLI to configure IPsec routing policies on the Junos Enforcer. Unlike

the ScreenOS Enforcer, you cannot create policies on the IC Series device and push the

policies to the Junos Enforcer.

The source interface is specified in the IKE gateway configuration on the Junos Enforcer.

In security policies you specify a VPN, and you specify the IKE gateway in the VPN. For

more information see Junos OS Initial Configuration Guide for Security Devices.

NOTE:

• IPsec on the Junos Enforcer can handle up to 5,000 concurrent IKEgateways.

• Dynamic IPsec is not supported on the Junos Enforcer.



To configure IPsec on the Junos Enforcer, you must perform three primary tasks:

• Configure the IC Series device as a RADIUS server for the Junos Enforcer client to enable

XAUTH. You must use the internal interface on the IC Series device, the external

interface does not support XAUTH.

• Configure IKE and IPsec parameters to specify security restrictions for SAs.

• Configure security policies to route traffic between the security gateway and the

interface for endpoints.

The IC Series device polls the Junos Enforcer to retrieve the following configuration

information:

• The IKE gateway interface

• The destination zone

• Identity

• The pre-shared seed

• The RADIUS shared secret

The IC Series device pushes these details to the client to allow establishment of a dial-up

VPN tunnel.

Configuration Example

The following example describes a sample configuration for setting up IPsec on the Junos

Enforcer.

To use IPsec with the ScreenOS Enforcer, you can configure basic IPsec security policies

on the IC Series device and then push the policies to the firewall. On the Junos Enforcer,

this functionality does not exist. For the Junos Enforcer, you use the CLI to configure

settings to create SAs on the Junos Enforcer that are negotiated with the UAC agent.

Before you begin, ensure that security zones and interfaces are set up, and that IPsec

routing policies and optional IP address pool policies have been configured on the IC

Series device.

J Series devices support up to four proposals for Phase 2 negotiations, allowing you to

define the range of tunnel parameter restrictions that endpoints will accept.

For a complete description of IPsec on the Junos Enforcer see the Junos OS Initial

Configuration Guide for Security Devices.

To configure IPsec on the Junos Enforcer:

1. Configure the IC Series device as a RADIUS server for the Junos Enforcer client.

In this example, you create an instance of the IC Series device hostname dev1086 as

the RADIUS server. The IP address is 192.168.100.5. You need to provide a shared

secret, which is used to permit the IC Series device to accept RADIUS packets from

the device. Enter the following commands:



user@host# set access profile dev1086 authentication-order radiususer@host# setaccessprofiledev1086radius-server 192.168.100.5secretsome-shared-secret

If you are configuring IC Series devices in an active/active cluster, you must configure

all IP addresses for individual IC Series devices. The shared secret must be the same,

as in the following example:

user@host# set access profile dev1086 authentication-order radiususer@host# setaccessprofiledev1086radius-server 192.168.100.5secretsome-shared-secretuser@host# setaccessprofiledev1086radius-server 192.168.100.6secretsome-shared-secret

If you are configuring and active/passive cluster, configure the IC Series device’s VIP

as the RADIUS server IP address.

2. Configure IKE and IPsec security parameters.

NOTE: IPsec with the Junos Enforcer is supported only with aggressivemode and Encapsulation Security Payload (ESP).

• In aggressivemode, phase 1 security proposals are negotiatedwith twoexchanges and a total of threemessages:

• Firstmessage—The initiatorproposes theSA, initiatesaDiffie-Hellmanexchange, and sends a pseudorandom number and the IKE identity.

• Secondmessage—The recipient accepts the SA; authenticates theinitiator; and sends a pseudorandom number, the IKE identity, and, ifusing certificates, the recipient's certificate.

• Thirdmessage—The initiator authenticates the recipient, confirmstheexchange, and, if usingcertificates, sends the initiator's certificate.

Because the participants' identities are exchanged in the clear (in thefirst twomessages), Aggressivemode does not provide identityprotection.

• ESP protects the inner IP packet, while the outer header remainsunprotected.

You define the security proposals, including all of the IKE parameters that determine

the strength of the IPsec tunnels. These options define the SAs for this IPsec tunnel.

Set up a phase 1 IKE proposal named prop, using Diffie-Hellman Group 2, authentication

algorithm SHA1, and encryption algorithm 3DES-CBC. Enter the following series of

commands.

a. user@host# set security ike proposal prop1 authentication-method pre-shared-keys

The client supports only the preshared key authentication method.

b. user@host# set security ike proposal prop1 dh-group group2

The client supports group1, group2, and group5.

c. user@host# set security ike proposal prop1 authentication-algorithm sha1

The client supports md5 and sha1.

d. user@host# set security ike proposal prop1 encryption-algorithm 3des-cbc



The client supports des-cbc, 3des-dbc, aes-128-cbc, aes-192-cbc, and aes-256-cbc

Set up an IKE policy named pol1 with aggressive mode, the pre-shared key and the

proposal configured above.

a. user@host# set security ike policy pol1 mode aggressive

The client supports only aggressive mode.

b. user@host# set security ike policy pol1 proposals prop1

c. user@host# set security ike policy pol1 pre-shared-key ascii-text some-preshared-key

Only ascii-text is supported. Do not use a hexadecimal pre-shared key.

Configure an IKE gateway named gateway1 with 5000 connection-limits,

host.company.com identity, group IKE ID, IKE policy pol1 configured above, and XAUTH

dev1086 as configured above.

a. user@host# set security ike gateway gateway1 ike-policy pol1

b. user@host# set security ike gateway gateway1 dynamic hostname host.company.com

c. user@host# set security ike gateway gateway1 dynamic ike-user-type group-ike-id

d. user@host# set security ike gateway gateway1 dynamic connections-limit (maximum5,000)

e. user@host# set security ike gateway gateway1 external-interface ge-0/0/2.0

f. user@host# set security ike gateway gateway1 xauth access-profile dev1086

The IC Series device and the client support only group-ike-id.

Configure an IPsec phase 2 proposal named prop1 with ESP protocol, HMAC-SHA1-96

authentication algorithm, and 3DES-CBC encryption algorithm.

a. user@host# set security ipsec proposal prop1 protocol esp

The client supports only esp.

b. user@host# set security ipsec proposal prop1 authentication-algorithm hmac-sha1-96

The client supports hmac-md5-96, and hmac-sha1-96.

c. user@host# set security ipsec proposal prop1 encryption-algorithm 3des-cbc

The client supports des-cbc, 3des-cbc, aes-128-cbc, aes-192-cbc, aes-256-cbc,

and no encryption-algorithm.

Configure an IPsec phase 2 policy name pol1 with proposal prop1 as configured above.

a. user@host# set security ipsec policy pol1 proposals prop1

In this section, you configure an IPsec VPN named vpn1 with IKE gateway gateway1

as configured in the above example, and IPsec policy pol1 as configured above.

a. user@host# set security ipsec vpn vpn1 ike gateway gateway1

b. user@host# set security ipsec vpn vpn1 ike ipsec-policy pol1

c. user@host# set security ipsec vpn vpn1 establish-tunnels immediately

d. user@host# set security ike gateway gateway1 external-interface ge-0/0/0.0



NOTE: The external interface refers to the interface that faces theclient.

e. user@host# set security ike gateway gateway1 xauth access-profile name

3. Create the security policy.

• Enable the VPN vpn1 configured above, and add enforcement in UAC a security

policy named pol1 from the zone named untrust to the zone named trust.

user@host# set security policies from-zone untrust to-zone trust policy pol1 matchsource-address any

NOTE: Always specify anywith the following command.

user@host# set security policies from-zone untrust to-zone trust policy pol1 matchdestination-address anyuser@host# set security policies from-zone untrust to-zone trust policy pol1 matchapplication anyuser@host# set security policies from-zone untrust to-zone trust policy pol1 then permittunnel ipsec-vpn vpn1user@host# set security policies from-zone untrust to-zone trust policy pol1 then permitapplication-services uac-policy








CHAPTER 3

Policies and Procedures forInteroperabilityBetween theUACEnforcerand the IC Series

• Infranet Enforcer Policies Overview on page 59

• About Resource Access Policies on page 60

• Configuring Resource Access Policies on page 62

• Understanding Infranet Enforcer Source IP Security Policies on page 63

• Understanding Infranet Enforcer Auth Tables on page 65

• Understanding Dynamic Auth Table Allocation on page 66

• Configuring Dynamic Auth Table Allocation on page 67

• Configuring Auth Table Mapping Policies for Source IP Enforcement on page 67

• Configuring Auth Table Mapping Policies on page 69

Infranet Enforcer Policies Overview

After you set up user roles, authentication servers, realms and sign-in policies, you deploy

the Infranet Enforcer in front of servers and resources that you want to protect. You

control access through a number of different security policies that you configure on the

IC Series device.

All policy options are supported on the ScreenOS Enforcer.

• Resource access policy—Specifies which users are allowed or denied access to a set

of protected resources. You specify which users you want to allow or deny by choosing

roles for each resource access policy.

• Source IPpolicy—This is an infranet auth policy the on ScreenOS Enforcer or a security

policy on the Junos Enforcer that contains a source and destination that permits the

Infranet Enforcer to route cleartext traffic between source and destination zones. You

can set up a source IP policy on the IC Series device and push the policy to the Infranet


• Auth tablemapping policy—Specifies which Infranet Enforcer device an endpoint

must use to access resources when the endpoint is using source IP enforcement. If you

are using either a ScreenOS Enforcer with Release 6.1 or greater or the Junos Enforcer,


you do not need to configure auth table mapping policies. Instead, you can use dynamic

auth table provisioning.

NOTE: You can use a usernamewith spaces, a usernamewith quotationmarks, a usernamewithUTF-8characters, or ausernamewithabackslash(\). Each of these conventions is accepted by the firewall with a validcorresponding auth table entry.

Figure 5 on page 60 demonstrates how policies on the Infranet Enforcer and the IC Series

device interact when a user has an auth table entry on the Infranet Enforcer.

Figure 5: Policy Interaction

The Infranet Enforcer detects a flow to a specific resource and compares the source IP

of the packet with IP addresses in the auth tables. The IP address is associated with a

set of roles in the auth table. The destination IP of the packet is matched with the

destination IP of a resource access policy to which a set of roles has been assigned. The

Infranet Enforcer parses the roles in the resource access policy to determine whether or

not the role can access the resource.


About Resource Access Policies on page 60•

• Understanding Infranet Enforcer Source IP Security Policies on page 63


About Resource Access Policies

A resource access policy specifies which users are allowed or denied access to a set of

protected resources.

You identify resources within your protected network, then you specify which users you

want to allow or deny by choosing the roles for each resource access policy. Auth table

entries on the Infranet Enforcer match user requests for access with resource access

policies.



The Infranet Enforcer evaluates traffic and enforces access control based on the policies

that you specify. When traffic from a role with a security policy enabled is compared with

a policy and a matching entry is detected, the Infranet Enforcer applies the appropriate

policy action.

For example, a resource access policy can specify that a user must have an Antivirus role

to access a particular network, and the Antivirus role requires the user’s computer to run

a particular antivirus program.

With the ScreenOS Infranet Enforcer, you can create an additional layer of security by

applying security policy actions to endpoints. Antispam, logging, IDP, web filtering,

antivirus, and deep inspection policies can be applied to any role.

The IC Series device pushes the policies to the Infranet Enforcer when the Infranet Enforcer

first connects to the IC Series device and any time you make a change to a resource

access policy. When any change is made on the resource access policies page, all resource

access policies on the Infranet Enforcer are refreshed, and endpoints that are accessing

resources through resource access policies are temporarily interrupted.

With ScreenOS Release 6.2 or later, the IC Series device supports vsys. Vsys do not inherit

resource access policies from the root-vsys. If you have a resource access policy configured

for an existing ScreenOS Enforcer, and subsequently create one or more vsys, you need

to add new policies for the vsys if you want to allow users to access resources within the

vsys.

If you are using ScreenOS Release 6.2 or later or on the Junos Enforcer, you can configure

customized messages for authenticated users who attempt to access a resource to

which they are denied access.

When you specify the deny/reject action in a resource access policy for a role or roles, a

text field is displayed. Use the following variables to display information for the user:

• <USER> the login name of the user

• <SOURCEIP> the source IP of the packet

• <DESTIP> the destination IP of the packet

• <PROTOCOL> the protocol of the packet

• <DESTPORT> the destination port of the packet

You can use these variables along with your own text to compose the deny/reject message

that you send to OAC or Pulse users. When the message is sent to the user, the applicable

information about the session or the resource is substituted. The information is displayed

on the user’s endpoint in a balloon in the system tray icon.

Using the Juniper Networks EX Series Ethernet Switch as an Enforcer with a Resource AccessPolicy

With Junos Pulse Access Control Service Release 4.2 and Junos OS Release 12.2, you can

use a Juniper Networks EX Series Ethernet switch as an Enforcer. You add the EX Series

as an Infranet Enforcer in the admin console through the Infranet Enforcer Connection

page, and the EX Series becomes available as a selection on the Resource Access Policy


Chapter 3: Policies and Procedures for Interoperability Between the UAC Enforcer and the IC Series

page. See Junos Pulse Access Control Service and EX Series Switch Configuration Task

Summary

In addition to existing resource options, you can add MAC addresses as a resource.


Configuring Resource Access Policies on page 62•

• Infranet Enforcer Policies Overview on page 59

Configuring Resource Access Policies

To configure Infranet Enforcer resource access policies:

1. In the IC Series device admin console, select UAC>Enforcer > Resource Access Policy.

2. Click NewPolicy.


a. For Name, enter a name to label this Infranet Enforcer resource access policy.


4. For Resources, specify the protocol, IP address, network mask, and port of each

resource (or range of addresses) for which this Infranet Enforcer resource access

policy applies, one per line. Do not insert any spaces in your entries, or the policy may

not be applied correctly.

You cannot specify a host name in a resource access policy. You can specify only an

IP address. You can use TCP, UDP, or ICMP.

5. Under Infranet Enforcer, specify the Infranet Enforcer to which this policy applies by

using Add.

6. Specify one of the following in the Roles section:

• Policy applies to ALL roles—To apply this Infranet Enforcer resource access policy

to all users.

• Policy applies to SELECTED roles—To apply this Infranet Enforcer resource access

policy only to users who are mapped to roles in the Selected roles list. Be sure to

add roles to this list from the Available roles list.

• Policy applies to all roles OTHER THAN those selected below— To apply this

Infranet Enforcer resource access policy to all users except those who map to the

roles in the Selected roles list. Be sure to add roles to this list from the Available

roles list.

7. In the Action section, specify whether you want to use this Infranet Enforcer resource

access policy to allow or deny access to the specified resources.

If you select deny, a text box is displayed that allows you to customize a deny message

for users.

With ScreenOS Enforcer Release 6.3 r13 or later, you can also select Reject Access.

The customized deny message is available with the reject action.



The reject action is designed for clients that hang for a long period of time while waiting

for connection initiations that the firewall is blocking. With the deny action, the Enforcer

drops traffic in accordance with the UAC policy, but does not send back reject

information. The policy action of "reject" denies the traffic and sends a TCP RST to

the traffic originator for TCP traffic, or ICMP unreachable for UDP traffic. In earlier

versions of ScreenOS and on the Junos Enforcer, the selection of reject results in a

deny action.

To record deny actions in the User Access Log, select the Infranet Enforcer Deny

Messages check box on the Log/monitoring > User Access > Settings page. The log

records the user, source IP, destination IP, protocol, and destination port.

8. For ScreenOS Enforcers, in the ScreenOS Options section, use the option buttons to

select the policy options that you want to apply to selected roles. Use the Add and

Remove buttons to specify antispam, logging, IDP, web filtering, antivirus, and deep

inspection.

By default, all policy options are enabled on the IC Series device. To enforce the

policies, you must create corresponding policies on the ScreenOS Enforcer. If the IC

Series device is upgraded from a previous version, all ScreenOS options are enabled

for the resource access policies that were available prior to the upgrade.

9. If you have created a vsys on a ScreenOS Enforcer, enter the name of the vsys in the

VSYS text box, if applicable. The main UAC > Infranet Enforcer > Resource Access

Policy page displays the Enforcers and/or vsys that are associated with each policy.



About Resource Access Policies on page 60•

Understanding Infranet Enforcer Source IP Security Policies

This topic provides an overview of Infranet Enforcer source IP security policies. It includes

the following information:

• Source IP Security Policy Overview on page 63

• ScreenOS Infranet Enforcer Configuration Summary on page 64

• Junos Infranet Enforcer Configuration Summary on page 65

Source IP Security Policy Overview

Source IP enforcement permits users to access resources that are protected by the

Infranet Enforcer. IPsec provides an encrypted tunnel for bidirectional traffic, while source

IP enforcement allows unencrypted (clear text) traffic between endpoints and the Infranet

Enforcer. You can use source IP enforcement alone on the Infranet Enforcer to protect

resources alone, or with IPsec on the ScreenOS Enforcer.

To use source IP enforcement, you configure infranet auth Enforcer policies for the

ScreenOS Enforcer and for vsys on the ScreenOS Enforcer, and you configure security

policies on the Junos Enforcer. Infranet auth policies and security policies control which

zones use Infranet Enforcer resource access policies to allow or deny traffic. By default,



traffic is denied through the Infranet Enforcer. With infranet auth policies and security

policies you control the traffic that is permitted to pass.

When you first set up the Infranet Enforcer and the IC Series device, you bind zones to

interfaces. Infranet-auth policies and security policies control the traffic flow between

zones. For example, you can configure an infranet auth policy on the ScreenOS Enforcer

to enforce traffic from the Untrust zone to the Trust zone. Then, you configure resource

access policies and specify resources that are within the Trust zone. The roles that you

assign to the resource access policy are permitted to access the specified resources.

NOTE: Source IPenforcementdoesnotwork if there isaNATdevicebetweenthe endpoint and the IC Series device.

In a case where the endpoint is behind a NAT device and the IC Series device and the

Infranet Enforcer are both on the other side of the NAT device, only one configuration is

supported. Source IP enforcement with agentless access works only if it is "one-to-one"

NAT, since the IC Series device and the Infranet Enforcer both see the external (translated)

address, and there will be only one user session per IP address.

Source IP enforcement with agentless access may appear to work, but will not operate

properly, if endpoint is behind a NAT device performing is "many-to-one" NAT. The first

user that authenticates from behind the NAT external IP address will get access but only

as long asf they are the only authenticated user. If a second user authenticates from

behind the same external (translated) IP address, the previous user's session is

terminated. The web browser would show that their session was terminated, the same

as if an IC Series device administrator deleted their session from the active user table.

If the endpoint is behind a NAT device, Source IP enforcement with Junos Pulse or OAC

access does not work at all, regardless of the type of NAT. The agent reports the internal

IP address of the endpoint, but the IC will see the external IP of the endpoint. The user

can authenticate, and the active user table displays X.X.X.X-Y.Y.Y.Y, where X.X.X.X is the

IP address reported by the agent and Y.Y.Y.Y is the IP address detected by the IC. However

no auth table entry is pushed to the firewall, since the IC Series device detects that the

endpoint is behind a NAT. The IPsec enforcement section provides instructions on how

to accommodate users in this use case.

IPsec enforcement must be used to provide access for Junos Pulse or OAC users behind

a NAT device.

ScreenOS Infranet Enforcer Configuration Summary

You can configure basic infranet auth Enforcer policies that specify a source zone and a

destination zone on the IC Series device and then push the policies to the ScreenOS

Enforcer to add additional policy details, or you can use the ScreenOS Enforcer to

configure the policies with the CLI or Web UI. We recommend that you use the IC Series

device to set up the policies for source IP enforcement on the Infranet Enforcer.

Before setting a policy, you must create address book entries for the destination and

source addresses unless you use address book entries that already exist, such as Any.



The following example, sets an infranet auth policy and adds it to the top of the list of

policies using Any. The policy allows all traffic of any type from any host to another host.

The policy allows traffic according to the Infranet Enforcer resource access policies that

you configure on the IC Series device.

set policy top from untrust to trust any any permit infranet-auth

The following example sets two address book entries and a policy between them for

anyone in the 10.64.0.0/16 range can reach the 10.65.0.0/16 range.

set address Trust “10.64 Range” 10.64.0.0 255.255.0.0set address Untrust “10.65 Range” 10.65.0.0 255.255.0.0

set policy from trust to untrust “10.64 Range” “10.65 Range” any permit infranet-auth

Junos Infranet Enforcer Configuration Summary

On the Junos Enforcer, security policies enforce rules for the transit traffic. From the

perspective of security policies, traffic enters one security zone and exits another. This

combination of a from-zone and a to-zone is called a context on the Junos Enforcer.

A security zone is a logical group of interfaces with identical security requirements. Each

security zone contains an address book. Before you can set up policies between two

zones, you must define the addresses for each of the zone’s address books. A zone’s

address book must contain entries for the addressable networks and end hosts belonging

to the zone.

Each security policy that you create must contain at a minimum match criteria and an

action. You can specify additional policy options as required.

You can create security polices on the Junos Enforcer from the Junos Web interface, or

from the CLI. For details about setting up security polices on the Junos Enforcer, see the

JunosOS Initial Configuration Guide for Security Devices. For CLI instructions see JunosOS

CLI Reference.

Understanding Infranet Enforcer Auth Tables

The Infranet Enforcer holds auth tables for valid sessions on the IC Series device. Auth

tables consist of a unique identification number, the source IP address of the endpoint

that initiated the session, the username, and a list of roles that the user has been assigned.

When a user with a username containing spaces or quotes authenticates with the IC

Series device, the device removes spaces and quotes from the username in the

authentication table entry that is sent to Infranet Enforcers.

You can allow the Infranet Enforcer to automatically generate auth tables whenever

users are authenticated, or you can configure dynamic auth table allocation. With dynamic

auth table allocation, auth tables are provisioned only as a response to a valid request

from an authenticated user for a resource behind the Infranet Enforcer.

Dynamic auth table allocation is available on all Junos Enforcers, and on ScreenOS

Enforcers with Release 6.1 or later.

Dynamic auth table allocation is required to use IF-MAP Federation.




Understanding Dynamic Auth Table Allocation on page 66•

• Configuring Dynamic Auth Table Allocation on page 67


• Configuring Auth Table Mapping Policies on page 69

Understanding Dynamic Auth Table Allocation

Prior to ScreenOS Release 6.1, you manually created auth table mapping policies to use

Source IP enforcement. Each authenticated user had an auth table entry on the Infranet

Enforcer, whether they were accessing resources or not. With the Junos Enforcer and

ScreenOS 6.1 or greater on the ScreenOS Enforcer you can dynamically create auth table

entries when a user attempts to access a protected resource, eliminating the need to

manually create Auth Table Mapping Policies.

Dynamic auth table allocation reduces auth table entries to only those that are needed,

enabling you to deploy smaller firewalls with a larger user population. After the user

disconnects, the Infranet Enforcer automatically expires the auth table entry.

Dynamic auth table allocation does not work with http traffic if the ScreenOS Enforcer’s

captive portal feature is configured to redirect user traffic to an external web server other

than the IC Series device. If you permit dynamic auth table allocation on the IC Series

device, and the DNS server for the network is behind the Infranet Enforcer, endpoints

may occasionally experience DNS time-out issues before resources are provisioned.

In most deployments, Juniper Networks recommends that you use dynamic auth table

allocation. The benefits of dynamic auth table allocation are based on many factors

within the network deployment: the number of Infranet Enforcers, the anticipated number

of sessions, and the persistence of user sessions.

One scenario in which static auth tables are more practical are in deployments that force

every endpoint to go through a single Infranet Enforcer for all access. In this case, static

auth tables can reduce overall traffic between IC Series devices and Infranet Enforcers.

For deployments that use static auth table mapping policies (for example, if you are

using a ScreenOS Release 6.1 or earlier), we recommend no more than 100 connected

Infranet Enforcers. For deployment scenarios with more than 100 Infranet Enforcers, We

recommend a deployment strategy using dynamic auth table allocation.

Testing has shown that with 5,000 active sessions, performance is impacted significantly

when dynamic auth table allocation is not configured and 100 connected firewalls are

deployed.

Performance metrics vary for each UAC release. For current performance information,

refer to Juniper Networks or your strategic partner for.

Dynamic auth table allocation must use IF-MAP Federation.


Configuring Dynamic Auth Table Allocation on page 67•



Configuring Dynamic Auth Table Allocation

To enable dynamic auth table allocation:

1. Select UAC > Enforcer > Auth Table Mapping in the admin console. Either delete the

DefaultPolicyor specify anEnforcer for which you do not want to configure this feature.


3. Configure a source IP policy for all traffic, whether source IP or IPsec.


Understanding Dynamic Auth Table Allocation on page 66•

Configuring Auth Table Mapping Policies for Source IP Enforcement

NOTE: If you are using the Junos Enforcer or ScreenOS Release 6.1 or lateron the ScreenOS Enforcer, and you have permitted dynamic auth tableallocation, you do not need to configure auth table mapping policies. Youcan use dynamic auth table allocation.

The IC Series device configuration includes one default auth table mapping policy. When

the default auth table mapping policy is enabled, the IC Series device pushes one auth

table entry for each authenticated user to all Infranet Enforcer devices connected to the

IC Series device. An auth table entry consists of the user’s name, a set of roles, and the

IP address of the wired adapter, wireless adapter, or virtual adapter in the user’s computer.

If your deployment includes a mixture of low and high-capacity Infranet Enforcer devices,

the lower capacity Infranet Enforcer devices might reach the limit of concurrent auth

table entries and prevent additional users from accessing protected resources behind

the lower-capacity Infranet Enforcer devices.

Figure 6 on page 68 illustrates an example of a deployment that includes a higher-capacity

ScreenOS Enforcer ISG 2000 and a lower-capacity SSG 5 in two branch offices. If the

default auth table mapping policy is enabled and the number of users who attempt to

access protected resources behind the ISG 2000 in Branch Office 1 exceeds the limit of

concurrent auth table entries on the SSG 5, then additional users are unable to access

protected resources behind the SSG 5 in Branch Office 2.

You can prevent overloading of the lower-capacity Infranet Enforcer devices in mixed

deployments by deleting the default auth table mapping policy and creating new policies.

An auth table mapping policy specifies which Infranet Enforcer device each user role is

allowed to use when the endpoint is using source IP enforcement. These policies prevent

the IC Series device from creating unnecessary auth table entries on all connected Infranet

Enforcer devices. In the example in Figure 8, auth table entries for users assigned the

Branch1-Role are mapped to the ISG 2000 in Branch Office 1 only, which avoids

overloading the SSG 5in Branch Office 2. Similarly, the auth table entries for users assigned

the HQ-Role are mapped to the ISG 2000 in HQ Office only, and auth table entries for

users assigned the Branch2- Role are mapped to the SSG 5 in Branch Office 2 only.



Figure 6: Using Auth Table Mapping Policies

You can also use auth table mapping policies to restrict users from accessing resources

behind an Infranet Enforcer based on the user’s assigned role.

If your deployment does not use source IP enforcement, or if you have configured dynamic

provisioning of auth tables, you do not need to create auth table mapping policies. For

IPsec enforcement with the ScreenOS Enforcer, the IC Series device pushes auth table

entries only to the Infranet Enforcer devices you specify in IPsec routing policies. If you

are using a combination of source IP enforcement and IPsec enforcement, you only need

to create auth table mapping policies for the endpoints that use source IP enforcement.

With ScreenOS Release 6.2 or later, the IC Series device supports Virtual systems vsys.

Vsys do not inherit auth table mapping policies from the root-vsyv. If you have an auth

table mapping policy configured for an existing ScreenOS Enforcer, and subsequently

create one or more VSYS, you need to add new policies for the vsys if you want to allow

users to access resources behind the vsys.

Auth table mapping policies apply to OAC, Pulse, and agentless deployments.


Understanding Infranet Enforcer Auth Tables on page 65•



Configuring Auth Table Mapping Policies

To configure auth table mapping policies:

1. In the IC Series device admin console, select UAC > Enforcer > Auth Table Mapping.

2. Select the default auth table mapping policy called Default Policy and click Delete.


a. For Name, enter a name to label this auth table mapping policy.


c. In the Enforcer section, specify the Infranet Enforcer device(s) to which you want

to apply this auth table mapping policy.

d. In the Roles section, specify:

• Policy applies to ALL roles—To apply this auth table mapping policy to all users.

• Policy applies to SELECTED roles—To apply this auth table mapping policy only

to users who are mapped to roles in the Selected roles list. Be sure to add roles

to this list from the Available roles list.

• Policy applies to all roles OTHER THAN those selected below—To apply this

auth table mapping policy to all users except for those who map to the roles in

the Selected roles list. Be sure to add roles to this list from the Available roles

list.

e. In the Action section, specify auth table mapping rules for the specified Infranet

Enforcer device:

• Always Provision Auth Table—To automatically provision auth table entries for

chosen roles on the specified Infranet Enforcer.

• Provision Auth Table as Needed—To provision auth table entries only when a

user with a chosen role attempts to access a resource behind the specified

Infranet Enforcer.

• Never Provision Auth Table—To prevent chosen roles from accessing resources

behind the specified Infranet Enforcer.

4. Make sure you delete the Default Policy if you configure any of your own auth table

mapping policies. The IC Series device includes this default auth table mapping policy

that allows all source IP endpoints to use all Infranet Enforcer devices.

5. If you created a vsys on a ScreenOS Enforcer, enter the name of the vsys in the vsys

text box. To view the enforcers or vsys that are associated with each policy, select

UAC > Infranet Enforcer > Auth Table Mapping .



• Understanding Infranet Enforcer Auth Tables on page 65

• Understanding Dynamic Auth Table Allocation on page 66





PART 2

Index

• Index on page 73




Index

Aauth polices, Junos Enforcer...............................................65

auth policies, ScreenOS Enforcer.....................................64

auth table mapping polices, about..................................67

auth table mapping policies, configuring......................69

auth tables, about..................................................................65

auth tables, configuring dynamic auth table

allocation...............................................................................67

Bbiderectional VPN policies

IPsec, biderectional VPN policies,

configuring....................................................................52

Ccaptive portal, configuring redirection

destination............................................................................28

captive portal, general information.................................24

captive portal, overriding default redirection

destination.............................................................................27

captive portal, redirect auth policy..................................26

captive portal, with Junos Enforcer or ScreenOS

Enforcer..................................................................................23

certificate authority server settings, configuring..........12

certificates, configuring on Infranet Enforcer.................8

certificates, importing.............................................................11

certificates, with Infranet Enforcers....................................7

conventions

notice icons......................................................................xiii

text.......................................................................................xiii

customer support....................................................................xv

contacting JTAC...............................................................xv

Ddeny message, Infranet Enforcer......................................60

documentation

comments on...................................................................xv

dynamic auth table allocation

auth tables, dynamic allocation..............................66

dynamic IPsec, configuring..................................................51

Eencryption settings, IPsec.....................................................51

IInfranet Enforcer policies, diagram.................................60

Infranet Enforcer, communication with............................4

Infranet Enforcer, configuration overview........................6

Infranet Enforcers, certificates..............................................7

interface, binding to a security zone.................................13

IPsec address pool polices, configuring.........................47

IPsec enforcement, general.................................................37

IPsec policies.....................................................................33, 36

IPsec policies, upgrading from earlier version.............50

IPsec routing policies

routing policies, IPsec............................................38, 41

IPsec, address pool policies

NAT, IPsec.........................................................................44

IPsec, bidirectional VPN polices........................................52

IPsec, configuration details on ScreenOS

Enforcer..................................................................................50

IPsec, configuring...................................................................40

IPsec, configuring general....................................................39

IPsec, general...........................................................................35

IPsec, general configuration........................................39, 42

IPsec, overview.................................................................34, 35

IPsec, refreshing policies......................................................37

IPsec, routing policy, configuring.......................................42

IPsec, transparent mode, source interface

polices....................................................................................49

IPsec, with Junos Enforcer...................................................53

JJunos Enforcer, IPsec.............................................................53

Mmanuals

comments on...................................................................xv

Nnotice icons...............................................................................xiii

OOpenSSL, for Enforcer certificate.......................................9

Ppolicies, Infranet Enforcer....................................................59

policy decision point, Infranet Enforcers..........................4


Rresource access policies, about........................................60

resource access policies, configuring..............................62

resource access policies, deny message.......................60

route mode, ScreenOS Enforcer........................................16

SScreenOS Enforcer releases..................................................6

ScreenOS Enforcer, configuring..........................................15

ScreenOS Enforcer, connecting..........................................15

security zone..............................................................................13

source interface polices, configuring...............................49

source interface policies

transparent mode, source interface

policies..........................................................................48

source IP enforcement, about...........................................63

SQUID proxy..............................................................................25

support, technical See technical support

Ttechnical support

contacting JTAC...............................................................xv

text conventions......................................................................xiii

transparent mode, ScreenOS Enforcer..........................20

UUAC Enforer interoperability policies..............................59

Vviewing ScreenOS Enforcer configuration.....................23

vsys, ScreenOS Enforcer......................................................30



Documents

UAC Interoperability with the ScreenOS Enforcer · Author: Juniper Networks Created Date: 20130215200626Z