Junos Pulse Access Control Service ScreenOS

Junos Pulse Access Control Service
ScreenOS Enforcer Feature Guide
Release
5.0
Published: 2014-02-10
Copyright © 2014, Juniper Networks, Inc.
Juniper Networks, Inc.
1194 North Mathilda Avenue
Sunnyvale, California 94089
USA
408-745-2000
www.juniper.net
Copyright © 2014, Juniper Networks, Inc. All rights reserved.
Juniper Networks, Junos, Steel-Belted Radius, NetScreen, and ScreenOS are registered trademarks of Juniper Networks, Inc. in the United
States and other countries. The Juniper Networks Logo, the Junos logo, and JunosE are trademarks of Juniper Networks, Inc. All other
trademarks, service marks, registered trademarks, or registered service marks are the property of their respective owners.
Juniper Networks 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.
Junos Pulse Access Control Service ScreenOS Enforcer Feature Guide
Release 5.0
Copyright © 2014, Juniper Networks, Inc.
All rights reserved.
The information in this document is current as of the date on the title page.
YEAR 2000 NOTICE
Juniper Networks hardware and software products are Year 2000 compliant. Junos OS has no known time-related limitations through the
year 2038. However, the NTP application is known to have some difficulty in the year 2036.
END USER LICENSE AGREEMENT
The Juniper Networks product that is the subject of this technical documentation consists of (or is intended for use with) Juniper Networks
software. 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 conditions of
that EULA.
ii
Copyright © 2014, Juniper Networks, Inc.
Table of Contents
About the Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
Documentation and Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
Supported Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
Documentation Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
Documentation Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
Requesting Technical Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
Self-Help Online Tools and Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv
Opening a Case with JTAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv
Part 1
Overview
Chapter 1
Infranet Enforcer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
The Access Control Service and the Infranet Enforcer . . . . . . . . . . . . . . . . . . . . . . . 3
ScreenOS Enforcer Configuration Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Infranet Enforcer Policies Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Understanding Infranet Enforcer Source IP Security Policies . . . . . . . . . . . . . . . . . . 5
Source IP Security Policy Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
ScreenOS Infranet Enforcer Configuration Summary . . . . . . . . . . . . . . . . . . . . 6
Junos Infranet Enforcer Configuration Summary . . . . . . . . . . . . . . . . . . . . . . . . 7
Chapter 2
Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Using Certificate-Based Security with Infranet Enforcer Deployments . . . . . . . . . . 9
Task Summary: Setting Up Certificates for the Access Control Service and
Infranet Enforcer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Using OpenSSL to Create a CA and Sign the Server Certificate . . . . . . . . . . . . . . . 10
Chapter 3
Deployments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Understanding Deployments with ScreenOS Infranet Enforcers . . . . . . . . . . . . . . . 11
Deployment Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Communication Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Configuration Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Version Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Understanding Deployments with ScreenOS Enforcer Virtual Systems . . . . . . . . 14
ScreenOS Virtual Systems Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Overlapping IP Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Deployment Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Deployment with IF-MAP Federation Example . . . . . . . . . . . . . . . . . . . . . . . . 17
Chapter 4
Captive Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Understanding the Infranet Enforcer Captive Portal Feature . . . . . . . . . . . . . . . . . 19
Before Configuring Captive Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Copyright © 2014, Juniper Networks, Inc.
iii
ScreenOS Enforcer Feature Guide
Chapter 5
IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Using IPsec with the Infranet Enforcer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
IPsec Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Understanding Access Control Service Support for IPsec Routing Policies . . . . . . 25
About IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Access Solution Service Client Support for IPsec Routing Policies . . . . . . . . . 25
Infranet Enforcer Support for IPsec Routing Policies . . . . . . . . . . . . . . . . . . . . 26
Infranet Enforcer IPsec Policy Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Dynamic IPsec Routing Policies with ScreenOS Enforcers . . . . . . . . . . . . . . . 27
Refreshing IPsec Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Understanding IPsec Routing Policy Configuration Options . . . . . . . . . . . . . . . . . 28
Configuration Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Configuration Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Advanced Configuration Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
IPsec Routing Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Before you Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Using IP Address Pool Policies for IPsec in a NAT Environment . . . . . . . . . . . . . . . 31
Understanding IP Address Pool Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Understanding ScreenOS Enforcer Source Interface Policies . . . . . . . . . . . . . . . . 34
Chapter 6
Bidirectional VPN Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Using ScreenOS Enforcer Bidirectional VPN Policies . . . . . . . . . . . . . . . . . . . . . . . 35
Chapter 7
Resource Access Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
About Resource Access Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Using the Juniper Networks EX Series Ethernet Switch as an Enforcer with
a Resource Access Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Chapter 8
Auth Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Understanding Infranet Enforcer Auth Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Understanding Dynamic Auth Table Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Part 2
Configuration
Chapter 9
IC Series Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Configuring Overlapping IP Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Chapter 10
Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Configuring Certificate Authority Server Settings . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Chapter 11
ScreenOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Configuring the ScreenOS Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Chapter 12
IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Configuring IPsec Routing Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Configuring an IP Address Pool Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Configuring Source Interface Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Configuring ScreenOS Enforcer IPsec Encryption Settings . . . . . . . . . . . . . . . . . . 55
Chapter 13
Resource Access Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Configuring Resource Access Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Specifying Resources for User Access Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
iv
Copyright © 2014, Juniper Networks, Inc.
Table of Contents
Chapter 14
Auth Tables and Mapping Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Configuring Dynamic Auth Table Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Configuring Auth Table Mapping Policies for Source IP Enforcement . . . . . . . . . . 61
Configuring Auth Table Mapping Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Part 3
Administration
Chapter 15
Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Setting Up Certificates for the Access Control Service and Infranet Enforcer . . . . 67
Creating a CA and Signing the Server Certificate Using OpenSSL . . . . . . . . . . . . . 68
Importing the Certificate Into the Infranet Enforcer . . . . . . . . . . . . . . . . . . . . . . . . 70
Chapter 16
Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Binding an Interface to a Security Zone on a ScreenOS Enforcer . . . . . . . . . . . . . . 71
Binding the Physical Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Chapter 17
Route Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Setting Up an Infranet Enforcer in Route Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Creating a Route Mode Instance with the ScreenOS Enforcer . . . . . . . . . . . . . . . . 74
Task Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Web UI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Chapter 18
Transparent Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Setting Up an Infranet Enforcer in Transparent Mode . . . . . . . . . . . . . . . . . . . . . . . 77
Creating a Transparent Mode Instance with the ScreenOS Enforcer . . . . . . . . . . . 78
Task Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Chapter 19
IC Series Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Viewing the Access Control Service Configuration on the ScreenOS Enforcer . . . 81
Configuration Details Displayed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Web UI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Chapter 20
Redirect Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Creating a Redirect Policy on the Infranet Enforcer . . . . . . . . . . . . . . . . . . . . . . . . 83
Creating a Redirect Policy on the ScreenOS Enforcer . . . . . . . . . . . . . . . . . . . . . . 85
Chapter 21
Captive Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Overriding the Default Redirection Destination for Captive Portal . . . . . . . . . . . . . 87
Chapter 22
IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Using the Access Control Service User Interface to Create Basic ScreenOS
Enforcer IPsec Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Setting Up ScreenOS Enforcer IPsec Routing Policies . . . . . . . . . . . . . . . . . . . . . . 90
Chapter 23
Bidirectional VPN Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Creating a ScreenOS Bidirectional VPN Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Copyright © 2014, Juniper Networks, Inc.
v
ScreenOS Enforcer Feature Guide
vi
Copyright © 2014, Juniper Networks, Inc.
List of Figures
Part 1
Overview
Chapter 1
Infranet Enforcer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Figure 1: Policy Interaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Chapter 3
Deployments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Figure 2: Multiple vsys in Shared and Unshared Zones . . . . . . . . . . . . . . . . . . . . . . 15
Figure 3: Layer 3 Authentication with Overlapping IP Addresses . . . . . . . . . . . . . . 17
Figure 4: IF-MAP Authentication with Overlapping IP Addresses . . . . . . . . . . . . . . 18
Chapter 4
Captive Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Figure 5: Captive Portal Event Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Chapter 5
IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Figure 6: Using an IP Address Pool in a NAT Environment . . . . . . . . . . . . . . . . . . . 32
Part 2
Configuration
Chapter 14
Auth Tables and Mapping Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Figure 7: Using Auth Table Mapping Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Part 3
Administration
Chapter 16
Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Figure 8: Binding a Physical Interface to a Security Zone . . . . . . . . . . . . . . . . . . . . 72
Copyright © 2014, Juniper Networks, Inc.
vii
ScreenOS Enforcer Feature Guide
viii
Copyright © 2014, Juniper Networks, Inc.
List of Tables
About the Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
Table 1: Notice Icons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii
Table 2: Text and Syntax Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii
Part 1
Overview
Chapter 3
Deployments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Table 3: ScreenOS Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Chapter 5
IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Table 4: Configuration Topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Part 2
Configuration
Chapter 12
IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Table 5: Syntax for IP Address Pools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Chapter 13
Resource Access Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Table 6: DNS Hostname Special Characters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Table 7: Port Possible Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Copyright © 2014, Juniper Networks, Inc.
ix
ScreenOS Enforcer Feature Guide
x
Copyright © 2014, Juniper Networks, Inc.
About the Documentation
•
Documentation and Release Notes on page xi
•
Supported Platforms on page xi
•
Documentation Conventions on page xi
•
Documentation Feedback on page xiii
•
Requesting Technical Support on page xiii
Documentation and Release Notes
®
To obtain the most current version of all Juniper Networks technical documentation,
see the product documentation page on the Juniper Networks website at
http://www.juniper.net/techpubs/.
If the information in the latest release notes differs from the information in the
documentation, follow the product Release Notes.
Juniper Networks Books publishes books by Juniper Networks engineers and subject
matter experts. These books go beyond the technical documentation to explore the
nuances of network architecture, deployment, and administration. The current list can
be viewed at http://www.juniper.net/books.
Supported Platforms
For the features described in this document, the following platforms are supported:
•
IC4500
•
IC6500 FIPS
•
IC6500
•
MAG Series
Documentation Conventions
Table 1 on page xii defines notice icons used in this guide.
Copyright © 2014, Juniper Networks, Inc.
xi
ScreenOS Enforcer Feature Guide
Table 1: Notice Icons
Icon
Meaning
Description
Informational note
Indicates important features or instructions.
Caution
Indicates a situation that might result in loss of data or hardware damage.
Warning
Alerts you to the risk of personal injury or death.
Laser warning
Alerts you to the risk of personal injury from a laser.
Table 2 on page xii defines the text and syntax conventions used in this guide.
Table 2: Text and Syntax Conventions
Convention
Description
Examples
Bold text like this
Represents text that you type.
To enter configuration mode, type the
configure command:
user@host> configure
Fixed-width text like this
Italic text like this
Italic text like this
Text like this
< > (angle brackets)
xii
Represents output that appears on the
terminal screen.
user@host> show chassis alarms
•
Introduces or emphasizes important
new terms.
•
•
Identifies guide names.
A policy term is a named structure
that defines match conditions and
actions.
•
Identifies RFC and Internet draft titles.
•
Junos OS CLI User Guide
•
RFC 1997, BGP Communities Attribute
No alarms currently active
Represents variables (options for which
you substitute a value) in commands or
configuration statements.
Configure the machine’s domain name:
Represents names of configuration
statements, commands, files, and
directories; configuration hierarchy levels;
or labels on routing platform
components.
•
To configure a stub area, include the
stub statement at the [edit protocols
ospf area area-id] hierarchy level.
•
The console port is labeled CONSOLE.
Encloses optional keywords or variables.
stub <default-metric metric>;
[edit]
root@# set system domain-name
domain-name
Copyright © 2014, Juniper Networks, Inc.
About the Documentation
Table 2: Text and Syntax Conventions (continued)
Convention
Description
Examples
| (pipe symbol)
Indicates a choice between the mutually
exclusive keywords or variables on either
side of the symbol. The set of choices is
often enclosed in parentheses for clarity.
broadcast | multicast
# (pound sign)
Indicates a comment specified on the
same line as the configuration statement
to which it applies.
rsvp { # Required for dynamic MPLS only
[ ] (square brackets)
Encloses a variable for which you can
substitute one or more values.
community name members [
community-ids ]
Indention and braces ( { } )
Identifies a level in the configuration
hierarchy.
; (semicolon)
Identifies a leaf statement at a
configuration hierarchy level.
(string1 | string2 | string3)
[edit]
routing-options {
static {
route default {
nexthop address;
retain;
}
}
}
GUI Conventions
Bold text like this
Represents graphical user interface (GUI)
items you click or select.
> (bold right angle bracket)
Separates levels in a hierarchy of menu
selections.
•
In the Logical Interfaces box, select
All Interfaces.
•
To cancel the configuration, click
Cancel.
In the configuration editor hierarchy,
select Protocols>Ospf.
Documentation Feedback
We encourage you to provide feedback, comments, and suggestions so that we can
improve the documentation. You can send your comments to
techpubs-comments@juniper.net, 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 or topic name
•
URL or page number
•
Software release version (if applicable)
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,
Copyright © 2014, Juniper Networks, Inc.
xiii
ScreenOS Enforcer Feature Guide
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 Case with 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.
xiv
Copyright © 2014, Juniper Networks, Inc.
PART 1
Overview
•
Infranet Enforcer on page 3
•
Certificates on page 9
•
Deployments on page 11
•
Captive Portal on page 19
•
IPsec on page 23
•
Bidirectional VPN Policies on page 35
•
Resource Access Policies on page 37
•
Auth Tables on page 39
Copyright © 2014, Juniper Networks, Inc.
1
ScreenOS Enforcer Feature Guide
2
Copyright © 2014, Juniper Networks, Inc.
CHAPTER 1
Infranet Enforcer
•
The Access Control Service and the Infranet Enforcer on page 3
•
ScreenOS Enforcer Configuration Overview on page 3
•
Infranet Enforcer Policies Overview on page 4
•
Understanding Infranet Enforcer Source IP Security Policies on page 5
The Access Control Service and the Infranet Enforcer
NOTE: An Infranet Enforcer can be either a ScreenOS firewall device, or a J
Series or SRX Series Services Gateway.
The Access Control Service 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. See 4.3R1 Supported Platforms for version compatibility.
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.
Copyright © 2014, Juniper Networks, Inc.
3
ScreenOS Enforcer Feature Guide
Related
Documentation
•
Configuring the ScreenOS Connection on page 49
•
Setting Up an Infranet Enforcer in Route Mode on page 73
•
Setting Up an Infranet Enforcer in Transparent Mode on page 77
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
Access Control Service.
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 IP policy—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 Access Control Service and push the policy to the
Infranet Enforcer, or you can set up the policy using ScreenOS Web UI or the command
line.
•
Auth table mapping 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 username with spaces, a username with quotation
marks, a username with UTF-8 characters, or a username with a backslash
(\). Each of these conventions is accepted by the firewall with a valid
corresponding auth table entry.
Figure 1 on page 5 demonstrates how policies on the Infranet Enforcer and the Access
Control Service interact when a user has an auth table entry on the Infranet Enforcer.
4
Copyright © 2014, Juniper Networks, Inc.
Chapter 1: Infranet Enforcer
Figure 1: 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.
Related
Documentation
•
About Resource Access Policies on page 37
•
Understanding Infranet Enforcer Source IP Security Policies on page 5
•
Configuring Auth Table Mapping Policies for Source IP Enforcement on page 61
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 5
•
ScreenOS Infranet Enforcer Configuration Summary on page 6
•
Junos Infranet Enforcer Configuration Summary on page 7
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 UAC policies. On a ScreenOS Enforcer, a
UAC policy is an infranet auth policy (a policy that includes an infranet-auth statement).
On a Junos Enforcer, a UAC policy is a uac-policy security policy (a security policy that
Copyright © 2014, Juniper Networks, Inc.
5
ScreenOS Enforcer Feature Guide
includes an application-services uac-policy statement, and may or may not also include
a match source-identity statement for user-role firewall functionality).
UAC 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 UAC policies,
you control the traffic that is permitted to pass.
When you first set up the Infranet Enforcer and the Access Control Service, you bind
zones to interfaces. UAC policies control the traffic flow between zones. For example,
you can configure a UAC 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 IP enforcement does not work if there is a NAT device between
the endpoint and the Access Control Service.
In a case where the endpoint is behind a NAT device and the Access Control Service and
the Infranet Enforcer are both on the other side of the NAT device, only one configuration
is supported. Source IP enforcement works only with agentless access, and only if it is
“one-to-one” NAT, since the Access Control Service 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 might appear to work, but does not operate
properly, if an 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 as 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 shows that their session was terminated, the same as if
an Access Control Service 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
agent 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 will be provisioned to the firewall, since the Access
Control Service detects that the endpoint is behind a NAT.
To provide access for Junos Pulse or OAC users behind a NAT device, you must use the
IPsec policy feature. The IPsec enforcement section provides instructions on how to
accommodate users in this use case.
ScreenOS Infranet Enforcer Configuration Summary
You can configure Source IP security policies in either of the following ways:
•
6
You can configure basic Source IP policies (source and destination zone) on the Access
Control Service and then push the policies to the ScreenOS Enforcer to add additional
policy details. (Recommended)
Copyright © 2014, Juniper Networks, Inc.
Chapter 1: Infranet Enforcer
•
You can configure the policies directly on the ScreenOS Enforcer (using the ScreenOS
Web UI or CLI).
NOTE: To use ScreenOS global policies as infranet auth policies, you must
configure them directly on the ScreenOS Enforcer. ScreenOS global policies
do not include source and destination zones, and policies pushed from Access
Control Service must include source and destination zones, so the infranet
auth policy pushed by Access Control Service is not useful when configuring
ScreenOS global policies.
TIP: On ScreenOS, you create a policy using address book entries for the
destination and source addresses, as well as policy wildcards, such as Any.
The following example sets an infranet auth policy and adds it to the top of the list of
policies controlling traffic from the Untrust zone to the Trust zone. The policy applies to
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 Access Control
Service.
set policy top from untrust to trust any any any permit infranet-auth
The following example sets two address book entries and a policy for anyone in the
10.64.0.0/16 range to reach the 10.65.0.0/16 range, subject to resource access policies.
set address Trust “10.64 Range” 10.64.0.0 255.255.0.0
set 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.
The following example sets a uac-policy security policy controlling traffic from the Untrust
zone to the Trust zone. The policy applies to all traffic of any type from any host to another
Copyright © 2014, Juniper Networks, Inc.
7
ScreenOS Enforcer Feature Guide
host. The policy allows traffic according to the Infranet Enforcer resource access policies
that you configure on the Access Control Service.
set security policies from-zone Untrust to-zone Trust policy ENFORCE_ALL match source-address
any
set security policies from-zone Untrust to-zone Trust policy ENFORCE_ALL match
destination-address any
set security policies from-zone Untrust to-zone Trust policy ENFORCE_ALL match application
any
set security policies from-zone Untrust to-zone Trust policy ENFORCE_ALL then permit
application-services uac-policy
The following example sets two address book entries and a policy for anyone in the
10.64.0.0/16 range to reach the 10.65.0.0/16 range, subject to resource access policies.
set security zones security-zone Trust address-book address 10.64_Range 10.64.0.0/16
set security zones security-zone Untrust address-book address 10.65_Range 10.65.0.0/16
set security policies from-zone Trust to-zone Untrust policy ENFORCE_ALL match source-address
10.64_Range
set security policies from-zone Trust to-zone Untrust policy ENFORCE_ALL match
destination-address 10.65_Range
set security policies from-zone Trust to-zone Untrust policy ENFORCE_ALL match application
any
set security policies from-zone Trust to-zone Untrust policy ENFORCE_ALL then permit
application-services uac-policy
Related
Documentation
•
Concepts & Examples ScreenOS Reference Guide: Part 2, “Fundamentals”
•
Concepts & Examples ScreenOS Reference Guide: Part 9, “User Authentication” Chapter 3,
“Infranet Enforcer”
•
8
Junos OS: Infranet Authentication Feature Guide for Security Devices
Copyright © 2014, Juniper Networks, Inc.
CHAPTER 2
Certificates
•
Using Certificate-Based Security with Infranet Enforcer Deployments on page 9
•
Task Summary: Setting Up Certificates for the Access Control Service and Infranet
Enforcer on page 10
•
Using OpenSSL to Create a CA and Sign the Server Certificate on page 10
Using Certificate-Based Security with Infranet Enforcer Deployments
The Access Control Service 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 Access Control Service, the devices
exchange security information to verify secure communication.
•
In ScreenOS implementations, the Access Control Service 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 Access
Control Service, and the Access Control Service verifies the password before further
communication is initiated. Once verified, the Access Control Service 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.
Copyright © 2014, Juniper Networks, Inc.
9
ScreenOS Enforcer Feature Guide
To ensure that the trust relationship in the network between the Access Control Service
and the Infranet Enforcer is secure, you create a certificate hierarchy for this trust
relationship, and then upload the appropriate certificates into the devices.
Related
Documentation
•
Task Summary: Setting Up Certificates for the IC Series and Infranet Enforcer on page 10
•
Setting Up Certificates for the IC Series and Infranet Enforcer on page 67
•
Using OpenSSL to Create a CA and Sign the Server Certificate on page 10
•
Configuring Certificate Authority Server Settings on page 47
Task Summary: Setting Up Certificates for the Access Control Service and Infranet
Enforcer
To allow the ScreenOS Enforcer to communicate with the Access Control Service, you
must perform all of the following tasks:
•
If you do not have one already, obtain the CA certificate that signed the Access Control
Service server certificate to load on the Infranet Enforcer.
•
Create a CSR for an Access Control Service 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 Access Control Service.
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 Access Control Service created during
initialization.
Related
Documentation
•
Using OpenSSL to Create a CA and Sign the Server Certificate on page 10
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
Access Control Service by OAC or Pulse. Follow the instructions in this section to create
a CA certificate and sign the CSR for the Access Control Service’s server certificate.
Related
Documentation
10
•
Creating a CA and Signing the Server Certificate Using OpenSSL on page 68
•
Importing the Certificate Into the Infranet Enforcer on page 70
Copyright © 2014, Juniper Networks, Inc.
CHAPTER 3
Deployments
•
Understanding Deployments with ScreenOS Infranet Enforcers on page 11
•
Understanding Deployments with ScreenOS Enforcer Virtual Systems on page 14
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 11
•
Communication Summary on page 11
•
Configuration Summary on page 13
•
Version Requirements on page 13
Deployment Summary
The Access Control Service 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 Access Control Service and the
Infranet Enforcer.
•
At startup, the ScreenOS Enforcer contacts the Access Control Service over an SSL
connection using the NetScreen Address Change Notification (NACN) protocol.
•
After the ScreenOS Enforcer establishes a connection with the Access Control Service,
the Access Control Service opens an SSH connection with the ScreenOS Enforcer. The
Access Control Service uses this SSH connection to push policy and user authentication
information to the ScreenOS Enforcer.
•
With ScreenOS Release 6.0 or earlier, when the Access Control Service authenticates
a user and verifies that the user’s endpoint is compliant with endpoint security policies,
the Access Control Service 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
Copyright © 2014, Juniper Networks, Inc.
11
ScreenOS Enforcer Feature Guide
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
Access Control Service 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 Access Control Service 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 Access Control Service, when you
change the configuration of a user’s role, or when you disable all user accounts on the
Access Control Service 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 Access Control
Service in a high availability configuration known as a cluster. The Infranet Enforcer
communicates with only one cluster node at a time. The other nodes are used for
failover. If the Infranet Enforcer cannot connect to the first node you added to the
cluster, it attempts to connect to successive devices in the configuration list until a
connection occurs. If the currently connected node fails, the Infranet Enforcer attempts
to connect to the first node again. The Access Control Service nodes configured on an
Infranet Enforcer should all be members of the same cluster.
You can use the Infranet Enforcer as a policy enforcement point for any number of
Access Control Services or Instant Virtual Extranet (IVE) Secure Access devices in a
federated network.
12
Copyright © 2014, Juniper Networks, Inc.
Chapter 3: Deployments
Configuration Summary
You must perform the following basic tasks to use the Access Control Service with an
Infranet Enforcer:
•
Configure the Access Control Service 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 Access Control Service.
•
Configure resource access policies on the Access Control Service 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 13 indicates what release version of ScreenOS is required for
specific features.
Table 3: ScreenOS Options
Feature
Required ScreenOS Release
Captive portal
5.4
Configurable auth table entries
6.0
Seamless cluster failover
6.0R2
Dynamic auth table allocation
6.1
200 roles per auth table entry
6.1
Messages to authenticated but unauthorized users
6.2
Support for ISG-IDP
6.2
Support for vsys
6.2
Copyright © 2014, Juniper Networks, Inc.
13
ScreenOS Enforcer Feature Guide
Table 3: ScreenOS Options (continued)
Related
Documentation
Feature
Required ScreenOS Release
Nonstandard port for captive portal
6.3
•
Using Certificate-Based Security with Infranet Enforcer Deployments on page 9
•
Binding an Interface to a Security Zone on a ScreenOS Enforcer on page 71
•
ScreenOS Enforcer Configuration Overview on page 3
Understanding Deployments with ScreenOS Enforcer Virtual Systems
This topic describes deployments with ScreenOS virtual systems. It includes the following
information:
•
ScreenOS Virtual Systems Overview on page 14
•
Overlapping IP Addresses on page 16
•
Deployment Example on page 16
•
Deployment with IF-MAP Federation Example on page 17
ScreenOS Virtual Systems Overview
You can logically partition a single ScreenOS Enforcer into multiple virtual systems (vsys)
to provide multitenant services. Each vsys is a unique security domain and can have its
own administrator. vsys is supported on ISG1000, ISG2000, and NS5000 series ScreenOS
Enforcers.
Support for vsys allows you to provision different auth table entries and resource access
policies on discrete vsys on the same firewall. You can also choose a vsys for ScreenOS
infranet auth policies and VPN objects.
When you add a vsys to a ScreenOS Enforcer with the appropriate CLI commands, the
vsys appears as an Infranet Enforcer on the Access Control Service. For more information,
see
http://www.juniper.net/techpubs/en_US/release-independent/screenos/information-products/pathway-pages/screenos/product/index.html.
On IC series devices, the vsys appears as a standalone firewall device. You configure
policies on the vsys just as you do for a separate firewall.
For resource access policies and auth table policies, you add a vsys by entering its name
in the provided field. For Enforcer policies, you select the vsys from a list. 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 a resource access
policy or auth table policy is configured for an existing ScreenOS Enforcer, and you
14
Copyright © 2014, Juniper Networks, Inc.
Chapter 3: Deployments
subsequently create one or more vsys, you must add new policies for the vsys to allow
users to access resources behind the vsys.
If you enable command tracing in the event log, the
exec-bulkcli
command is displayed 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 can configure all endpoints to be on the
untrust zone connecting to multiple vsys in different zones. IPsec is not supported with
a shared-zone configuration. Figure 2 on page 15 shows multiple vsys in shared and
unshared zones.
Support for vsys on the Access Control Service requires ScreenOS Release 6.2 or later.
Figure 2: Multiple vsys in Shared and Unshared Zones
When a ScreenOS Enforcer Release 6.2 or later and the appropriate vsys licensing
connects to the Access Control Service, the Access Control Service automatically issues
a command to the firewall to enable UAC support for vsys in ScreenOS Enforcers.
Copyright © 2014, Juniper Networks, Inc.
15
ScreenOS Enforcer Feature Guide
Overlapping IP Addresses
On ScreenOS, each vsys can have individual administrators, and one or more vsys can
be assigned to a single customer. For example, a service provider can provision different
vsys to different customers. In turn, these customers might use overlapping IP addresses
in their internal networks. For instance, many organizations use the internal IP address
range 192.168.0.0 – 192.168.255.255. For ScreenOS, this is not an issue because the
ScreenOS Enforcer supports overlapping IP addresses. Previous releases of UAC did not
support overlapping IP addresses. As a result, the Access Control Service was unable to
distinguish between two authorized users with matching addresses. With UAC Release
4.1, if the administrator creates mappings on the Access Control Service as described in
this section, the Access Control Service can recognize users with identical IP addresses
in multiple vsys, and the correct session information is sent to the ScreenOS firewall auth
table.
In the preceding scenarios, customer networks use the same internal IP address ranges
supplied by different service providers. When overlapping IP addresses occur among
different customer networks, if an IC administrator has created a mapping between the
VLAN and vsys, the Access Control Service can use this mapping to correctly identify the
user and to send accurate session information to ScreenOS.
Deployment Example
In the following deployment, (see Figure 3 on page 17) authentication to the service
provider occurs through UAC on the IC series device. On this network, different VLANs
and different firewalls are configured on the service provider side for each customer
network. Both customer networks use the same IP address ranges. When the Access
Control Service correctly identifies and authenticates a user from one of the customer
networks who attempts to access a protected resource on the server provider side, the
following occurs:
16
•
With the first login attempt, the Access Control Service knows the user’s VLAN.
•
When the user attempts to access a protected resource, the firewall drops the first
packet.
•
With the user’s next access attempt (resend), the firewall sends the Access Control
Service the vsys and source IP address.
•
If the Access Control Service administrator has configured a mapping on the IC between
the VLAN and the vsys for the firewall on which each customer network is connected,
the Access Control Service can use the source IP and the VLAN ID to correctly identify
the user session. This allows the Access Control Service to provide session information
for the ScreenOS auth table. (Note that the VLAN ID is part of the user session
information.)
Copyright © 2014, Juniper Networks, Inc.
Chapter 3: Deployments
Figure 3: Layer 3 Authentication with Overlapping IP Addresses
Deployment with IF-MAP Federation Example
In the following deployment, (see Figure 4 on page 18) the network configuration is similar
to the preceding example, except that the service provider uses two Access Control
Services and both are in a Federated network. Both customer networks use the same IP
address ranges. In order for the Access Control Service that controls access to the
protected resource to correctly identify and authenticate a user who attempts access
from one of the customer networks, the following events occur:
•
When the user logs in to the first Access Control Service, the Access Control Service
correctly identifies the user’s VLAN. The Access Control Service publishes information
about the user session to the IF-MAP server. If the Access Control Service administrator
has configured a mapping on the first Access Control Service between the VLAN and
an administrative domain, the Access Control Service publishes the source IP address
with the administrative domain.
•
When the user attempts to access a protected resource, the firewall drops the first
packet and identifies the vsys and the source IP address to the second Access Control
Service. The second Access Control Service looks up the source IP address in the
IF-MAP server to obtain session information so it can provision the ScreenOS auth
table. If the Access Control Service administrator has configured a mapping on the
second Access Control Service between the vsys and the VLAN, and between the VLAN
and an administrative domain, the second Access Control Service looks up the
combination of the source IP address and administrative domain.
Copyright © 2014, Juniper Networks, Inc.
17
ScreenOS Enforcer Feature Guide
•
With the user’s next access attempt (resend), the firewall is provisioned and forwards
the packet to the protected resource.
Figure 4: IF-MAP Authentication with Overlapping IP Addresses
Related
Documentation
18
•
Configuring the IC Series Device for Overlapping IP Addresses on page 45
Copyright © 2014, Juniper Networks, Inc.
CHAPTER 4
Captive Portal
•
Understanding the Infranet Enforcer Captive Portal Feature on page 19
•
Before Configuring Captive Portal on page 20
Understanding the Infranet Enforcer Captive Portal Feature
When you deploy the Access Control Service and Infranet Enforcer, users may not know
that they must first sign into the Access Control Service 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 Access Control Service. This feature
is called captive portal. When the sign-in page for the Access Control Service 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.
“Captive Portal” on page 19 illustrates the sequence of events when a user attempts to
access protected resources with captive portal configured.
Copyright © 2014, Juniper Networks, Inc.
19
ScreenOS Enforcer Feature Guide
Figure 5: 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.
Related
Documentation
•
Before Configuring Captive Portal on page 20
•
Creating a Redirect Policy on the Infranet Enforcer on page 83
•
Overriding the Default Redirection Destination for Captive Portal on page 87
Before Configuring Captive Portal
Topic
Details
ScreenOS version
The captive portal feature requires ScreenOS Release 5.4 or later running
on the ScreenOS Enforcer.
Junos version
To use captive portal with the Junos Enforcer, Release 10.2 is required.
External Web server
You can configure the ScreenOS Enforcer to redirect HTTP traffic to an
external Web server instead of the Access Control Service. For example,
you can redirect HTTP traffic to a Web page that explains to users the
requirement to sign into the Access Control Service before they can
access the protected resource. You can also explain the security policy
and include a link to the Access Control Service on that Web page to
help users sign in.
HTTP vs. HTTPS
The captive portal feature redirects HTTP traffic only. If the user attempts
to access a protected resource using HTTPS or another protocol such
as SMTP, the Infranet Enforcer does not redirect the user’s traffic. When
using HTTPS or another application, the user must manually sign into
the Access Control Service first before attempting to access protected
resources.
HTTP proxy
If there is an HTTP proxy between the endpoint and the Infranet Enforcer,
the Infranet Enforcer might not redirect the HTTP traffic.
20
Copyright © 2014, Juniper Networks, Inc.
Chapter 4: Captive Portal
Topic
Details
Default port
In standard configurations, ScreenOS uses default HTTP ports as the
redirect destination port for traffic. In addition to default HTTP ports,
nonstandard HTTP port 3128 is defined for HTTP-EXT traffic to
accommodate the SQUID proxy.
The Junos Enforcer, supports only port 80.
Copyright © 2014, Juniper Networks, Inc.
21
ScreenOS Enforcer Feature Guide
22
Copyright © 2014, Juniper Networks, Inc.
CHAPTER 5
IPsec
•
Using IPsec with the Infranet Enforcer on page 23
•
IPsec Policies on page 24
•
Understanding Access Control Service Support for IPsec Routing Policies on page 25
•
Understanding IPsec Routing Policy Configuration Options on page 28
•
IPsec Routing Policies on page 30
•
Before you Begin on page 31
•
Using IP Address Pool Policies for IPsec in a NAT Environment on page 31
•
Understanding IP Address Pool Policies on page 33
•
Understanding ScreenOS Enforcer Source Interface Policies on page 34
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 Access Control Service. 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 Access Control Service 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 Access Control Service.
When you use the Access Control Service to configure IPsec on the ScreenOS Enforcer,
the Access Control Service sets up a user, user group, IKE gateway, and VPN for each
Copyright © 2014, Juniper Networks, Inc.
23
ScreenOS Enforcer Feature Guide
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.
For IPsec with the Junos Enforcer you use the CLI to create security policies. With the
Junos Enforcer, the Access Control Service uses the destination zone to match the IPsec
routing policies that are configured on the Access Control Service.
Related
Documentation
•
Setting Up ScreenOS Enforcer IPsec Routing Policies on page 90
•
Configuring Junos Enforcer IPsec Routing Policies
IPsec Policies
This section describes the policies that you configure to use IPsec on the Infranet Enforcer.
Related
Documentation
24
•
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 Access Control
Service.
•
ScreenOS Infranet Auth IPsec Policy—Contains the source and destination. The Access
Control Service 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 Access Control Service 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
Access Control Service to automatically assign to endpoints in NAT environments that
use IPsec tunnels to the Infranet Enforcer. You configure IP address pools policies on
the Access Control Service.
•
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 Access Control Service.
•
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 Access Control Service.
•
Using IPsec with the Infranet Enforcer on page 23
•
Setting Up ScreenOS Enforcer IPsec Routing Policies on page 90
•
Configuring ScreenOS Enforcer IPsec Encryption Settings on page 55
•
Understanding Access Control Service Support for IPsec Routing Policies on page 25
Copyright © 2014, Juniper Networks, Inc.
Chapter 5: IPsec
•
Understanding IPsec Routing Policy Configuration Options on page 28
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 25
•
Access Solution Service Client Support for IPsec Routing Policies on page 25
•
Infranet Enforcer Support for IPsec Routing Policies on page 26
•
Infranet Enforcer IPsec Policy Features on page 26
•
Dynamic IPsec Routing Policies with ScreenOS Enforcers on page 27
•
Refreshing IPsec Policies on page 27
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.
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 Access Control Service by the respective device. When
a user with OAC or Pulse signs in, 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 Access
Control Service and on the security device. The Access Control Service pushes the required
IPsec configuration parameters to the client when the client first attempts to connect
to a protected resource behind and Access Control Service 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.
Copyright © 2014, Juniper Networks, Inc.
25
ScreenOS Enforcer Feature Guide
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 to modify
the VPN tunnel configuration. Whenever you modify the VPN tunnel setup
from the ScreenOS side of the configuation, you must refresh the Access
Control Service policies.
Infranet Enforcer IPsec Policy Features
This section describes the policies that you configure to use IPsec on the Infranet Enforcer.
26
•
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 Access Control
Service.
•
ScreenOS Infranet Auth IPsec Policy—Contains the source and destination. The Access
Control Service 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 Access Control Service 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
Access Control Service to automatically assign to endpoints in NAT environments that
use IPsec tunnels to the Infranet Enforcer. You configure IP address pools policies on
the Access Control Service.
•
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
Copyright © 2014, Juniper Networks, Inc.
Chapter 5: IPsec
communicate with a ScreenOS Enforcer that is in Transparent mode, and you are using
virtual routers. You configure source interface policies on the Access Control Service.
•
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 Access Control Service.
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 Access Control Service can dynamically provision IPsec
routing policies for you, eliminating the need to configure a separate policy for each
resource.
The Access Control Service initially queries all connected Infranet Enforcers for version
information. If ScreenOS Release 6.1 or greater is detected, the Access Control Service
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
Access Control Service 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 Access Control Service 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
Each time the Infranet Enforcer and Access Control Service establish a new connection
with each other, the Access Control Service 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 Access
Control Service, you must refresh the policies on the Access Control Service so that the
Access Control Service uses the new policies, otherwise , the Access Control Service
continues to use the older policies until the next time it disconnects from and reconnects
to the Infranet Enforcer.
Related
Documentation
•
Understanding IPsec Routing Policy Configuration Options on page 28
•
Configuring Junos Enforcer IPsec Routing Policies
•
Setting Up ScreenOS Enforcer IPsec Routing Policies on page 90
Copyright © 2014, Juniper Networks, Inc.
27
ScreenOS Enforcer Feature Guide
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 28
•
Configuration Summary on page 28
•
Advanced Configuration Options on page 29
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 Access Control Service), 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.
Configuration Summary
Table 4: Configuration Topics
Topic
Details
Connection
The Infranet Enforcer and the Access Control Service must be connected before you use the A
Enforcer.
28
Copyright © 2014, Juniper Networks, Inc.
Chapter 5: IPsec
Table 4: Configuration Topics (continued)
Topic
Details
IPsec access server on ScreenOS Enforcer
You cannot establish an IPsec tunnel if IAS (IPsec access server) is enabled on the ScreenOS
command 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, see
http://www.juniper.net/techpubs/en_US/release-independent/screenos/information
Multiple interfaces
If you configure IPsec enforcement for an Infranet Enforcer that has multiple interfaces in the
gateway, VPN, and tunnel policy for each interface. To distinguish the tunnel policies, the Acc
policy in the VPN column on UAC > Infranet Enforcer > Enforcer Policies after you click Save Ch
Dynamic IPsec routing policies
If you are using ScreenOS Release 6.1 or later you can configure the Infranet Enforcer to dyna
you create a ScreenOS source IP policy with a source and destination zone that matches the
source IP policy. Dynamic IPsec routing policies are not supported on the Junos Enforcer.
Default encryption settings on the ScreenOS Enforcer
When you use the Access Control Service to configure IPsec on the Infranet Enforcer, the Acc
default IPsec encryption settings: NoPFS, ESP, 3DES, and SHA1. You can, however, change th
Web UI.
Bi-directional VPN policy
To connect from a computer inside the protected network back to the endpoint, you can crea
CLI commands
To include the CLI commands that the Access Control Service sends to the Infranet Enforcer in
Trace option (select System > Log/Monitoring > Events > Settings).
Junos Enforcer zone limitation
On the Junos Enforcer, only one IPsec VPN tunnel per “from-zone” to “to-zone” is supported.
Troubleshooting
To troubleshoot your IPsec configuration, you can view the Event logs. You can also view IPse
IPsec Diagnostics in OAC.
Advanced Configuration Options
Topic
Details
IP address
exceptions
Do not use IPsec for the Access Control Service, the Infranet Enforcer, and networks where your endpoints
are located. 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 for
the IP addresses assigned to Access Control Service, Infranet Enforcer, and the endpoints.
Copyright © 2014, Juniper Networks, Inc.
29
ScreenOS Enforcer Feature Guide
Topic
Details
UDP encapsulation
and virtual adapters
For maximum inter-operability with other third-party IPsec clients, select both Always use UDP
encapsulation and Always use a virtual adapter. When both options are selected, Network address
translation (NAT) is simulated even if a NAT device is not present. We recommend that you select both
options or neither option. For example, if an endpoint contains two network interfaces, such as a wired
and 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 the
network where the Infranet Enforcer is installed, then the user cannot access the protected resource
through either interface without a virtual adapter. Because the Access Control Service does not
automatically install a virtual adapter unless a NAT device is detected, enable the Always use a virtual
adapter option to simulate NAT and force the use of a virtual adapter for this use case.
Related
Documentation
•
Using the Access Control Service User Interface to Create Basic ScreenOS Enforcer
IPsec Policies on page 89
•
Setting Up ScreenOS Enforcer IPsec Routing Policies on page 90
•
Configuring Junos Enforcer IPsec Routing Policies
•
Configuring IPsec Routing Policies on page 51
•
Using IP Address Pool Policies for IPsec in a NAT Environment on page 31
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 Access Control Service), 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.
30
Copyright © 2014, Juniper Networks, Inc.
Chapter 5: IPsec
Related
Documentation
•
Before you Begin on page 31
•
Configuring IPsec Routing Policies on page 51
Before you Begin
Topic
Details
IP address
exceptions
Do not use IPsec for the Access Control Service, the Infranet Enforcer, and networks where your endpoints
are located. 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 for
the IP addresses assigned to Access Control Service, Infranet Enforcer, and the endpoints.
UDP encapsulation
and virtual adapters
For maximum inter-operability with other third-party IPsec clients, select both Always use UDP
encapsulation and Always use a virtual adapter. When both options are selected, Network address
translation (NAT) is simulated even if a NAT device is not present. We recommend that you select both
options or neither option. For example, if an endpoint contains two network interfaces, such as a wired
and 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 the
network where the Infranet Enforcer is installed, then the user cannot access the protected resource
through either interface without a virtual adapter. Because the Access Control Service does not
automatically install a virtual adapter unless a NAT device is detected, enable the Always use a virtual
adapter option to simulate NAT and force the use of a virtual adapter for this use case.
Related
Documentation
•
Configuring IPsec Routing Policies on page 51
•
Using IP Address Pool Policies for IPsec in a NAT Environment on page 31
Using IP Address Pool Policies for IPsec in a NAT Environment
The Access Control Service 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 Access Control Service 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 Access Control Service and Infranet Enforcer must be
located on the other side of the devices.
Copyright © 2014, Juniper Networks, Inc.
31
ScreenOS Enforcer Feature Guide
Also note the following if you are using NAT:
•
NAT is not supported between the Access Control Service and Infranet Enforcer.
•
If there is a NAT device between the endpoint and the Access Control Service, 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 Access Control Service.
If NAT is not detected, the client uses the endpoint’s physical IP address when creating
the IPsec tunnel to the Infranet Enforcer. The Access Control Service does not allocate
an IP address from the pool.
Figure 6 on page 32 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 Access Control Service to assign a unique, routable, virtual IP address
to each endpoint.
Figure 6: Using an IP Address Pool in a NAT Environment
The following sequence of events occur when the Access Control Service and a Juniper
client (OAC or Pulse) use an IPsec tunnel through a NAT device:
32
•
When the client connects to the Access Control Service and authenticates the user,
the client returns the endpoint’s source IP address that is used to access the Infranet
Enforcer to the Access Control Service. The Access Control Service 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.
Copyright © 2014, Juniper Networks, Inc.
Chapter 5: IPsec
•
During the IKE exchange, the Infranet Enforcer detects the source IP address of the
endpoint and sends that IP address to the Access Control Service.
•
The Access Control Service 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 Access Control Service determines that there is a NAT device between the
endpoint and the Infranet Enforcer. The Access Control Service automatically provisions
an IP address from an IP address pool policy that you configured (for example,
10.11.0.10-100). The Access Control Service assigns the IP address to the endpoint
based on the IP address pool policy that applies to the user’s role. The Access Control
Service 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 Access Control Service allocates one IP address for the duration of each client
session, which lasts as long as the client is connected to the Access Control Service. After
a session ends, the Access Control Service can reuse the allocated address for a different
endpoint.
When the Access Control Service 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 Access Control Service checks all of the inner IPs allocated from IP address
pools for the endpoint. For each IP address, the Access Control Service 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.
Related
Documentation
•
Understanding IP Address Pool Policies on page 33
•
Configuring an IP Address Pool Policy on page 52
Understanding IP Address Pool Policies
Topic
Details
Multiple Infranet Enforcers
If you are using multiple Infranet Enforcers across a LAN, make sure that
the IP address pool contains addresses that are valid for each Infranet
Enforcer.
Multiple unclustered Access Control Service servers
If you are using multiple unclustered Access Control Service servers
across a LAN, make sure that the IP address pool contains addresses
that are unique for each host. The endpoint is assigned an virtual IP
address for each unclustered server to which OAC connects.
Copyright © 2014, Juniper Networks, Inc.
33
ScreenOS Enforcer Feature Guide
IP address conflicts
Make sure that the IP pool addresses do not conflict with addresses of
hosts that the endpoint might access.
Deleting IP addresses in an IP pool
If you change or delete the IP addresses in an IP address pool, you must
delete all user sessions in order to stop using those addresses. To delete
all user sessions, select System > Status > Active Users and click Delete
All.
Number of available IP addresses
Be sure to specify a sufficient number of addresses in the IP address
pool for all of the endpoints in your deployment. When all of the
addresses in the pool are assigned to endpoints, additional endpoints
cannot obtain a virtual IP address and are blocked from accessing
protected resources. The Access Control Service logs a message in the
Event log when an IP address cannot be assigned to an endpoint.
Related
Documentation
•
Using IP Address Pool Policies for IPsec in a NAT Environment on page 31
•
Configuring an IP Address Pool Policy on page 52
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 Access
Control Service. 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.
Related
Documentation
34
•
Setting Up an Infranet Enforcer in Transparent Mode on page 77
•
Configuring Source Interface Policies on page 54
Copyright © 2014, Juniper Networks, Inc.
CHAPTER 6
Bidirectional VPN Policies
•
Using ScreenOS Enforcer Bidirectional VPN Policies on page 35
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:
Related
Documentation
•
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 93
Copyright © 2014, Juniper Networks, Inc.
35
ScreenOS Enforcer Feature Guide
36
Copyright © 2014, Juniper Networks, Inc.
CHAPTER 7
Resource Access Policies
•
About Resource Access Policies on page 37
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 Access Control Service pushes the policies to the Infranet Enforcer when the Infranet
Enforcer first connects to the Access Control Service 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 Access Control Service 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.
Copyright © 2014, Juniper Networks, Inc.
37
ScreenOS Enforcer Feature Guide
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 Access
Policy
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
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.
Related
Documentation
38
•
Configuring Resource Access Policies on page 57
•
Infranet Enforcer Policies Overview on page 4
Copyright © 2014, Juniper Networks, Inc.
CHAPTER 8
Auth Tables
•
Understanding Infranet Enforcer Auth Tables on page 39
•
Understanding Dynamic Auth Table Allocation on page 39
Understanding Infranet Enforcer Auth Tables
The Infranet Enforcer holds auth tables for valid sessions on the Access Control Service.
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 Access
Control Service, 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.
Related
Documentation
•
Understanding Dynamic Auth Table Allocation on page 39
•
Configuring Dynamic Auth Table Allocation on page 61
•
Configuring Auth Table Mapping Policies for Source IP Enforcement on page 61
•
Configuring Auth Table Mapping Policies on page 63
Understanding Dynamic Auth Table Allocation
You can use the dynamic auth table allocation feature to push auth table entries to the
Infranet Enforcer only when a user attempts to access a protected resource. This is more
efficient than the Auth Table Mapping Policies option, which requires administrators to
provision auth table entries for authenticated users whether they are accessing resources
Copyright © 2014, Juniper Networks, Inc.
39
ScreenOS Enforcer Feature Guide
or not. 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.
When dynamic auth table allocation is used and a user attempts to access a protected
resource, the Infranet Enforcer does not yet have an auth table entry for the user, so it
sends a drop notification to the Access Control Service to prompt it to send an auth table
entry. Unlike captive portal redirect, which only occurs when the user sends HTTP traffic,
drop notifications are triggered by any type of traffic for which the destination is a
protected resource.
After the user disconnects, the Infranet Enforcer automatically expires the auth table
entry.
NOTE: On the Junos Enforcer, whenever traffic matches a security policy
that includes an application-services uac-policy statement, then the firewall
sends a drop notification to the Access Control Service if there is no auth
table entry associated with that traffic. This applies in the captive portal use
case, and for all policies that include the application-services uac-policy
statement.
However, this behavior changes if user role firewall is configured. When a
match source-identity statement is included in any policy within a zone pair
(source zone + destination zone), user and role information must be retrieved
before policy lookup can proceed. (If all policies in the zone pair are set to
match source-identity any, or have no match source-identity state, user and
role information is not required and the five standard match criteria are used
for policy lookup.) Therefore, for any zone pair in which a security policy is
configured that contains a match source-identity statement, the firewall sends
a drop notification for all traffic matching that source and destination zone,
whether or not the traffic matches the specific security policy containing the
match source-identity statement. This can result in an unexpected number
of drop notifications if a single zone contains a mix of protected and
unprotected resources.
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.
The following requirements and limitations apply:
40
•
Dynamic auth table allocation is supported for all deployments with Junos Enforcer
and with ScreenOS Enforcers running ScreenOS 6.1 or later.
•
Dynamic auth table allocation does not work with HTTP traffic if the captive portal
feature is configured to redirect user traffic to an external web server other than the
Access Control Service. The Access Control Service must be aware of a user
login/session before it can provision an auth table entry.
Copyright © 2014, Juniper Networks, Inc.
Chapter 8: Auth Tables
•
If you configure dynamic auth table allocation on the Access Control Service, and the
DNS server for the network is behind the Infranet Enforcer, endpoints might occasionally
experience DNS time-out issues before resources are provisioned.
•
Dynamic auth table allocation is required to use IF-MAP Federation.
One scenario in which static auth tables are more practical is a deployment that forces
every endpoint to go through a single Infranet Enforcer for all access. In this case, static
auth tables can reduce overall traffic between Access Control Service servers 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.
Related
Documentation
•
Configuring Dynamic Auth Table Allocation on page 61
Copyright © 2014, Juniper Networks, Inc.
41
ScreenOS Enforcer Feature Guide
42
Copyright © 2014, Juniper Networks, Inc.
PART 2
Configuration
•
IC Series Device on page 45
•
Certificates on page 47
•
ScreenOS on page 49
•
IPsec on page 51
•
Resource Access Policies on page 57
•
Auth Tables and Mapping Policies on page 61
Copyright © 2014, Juniper Networks, Inc.
43
ScreenOS Enforcer Feature Guide
44
Copyright © 2014, Juniper Networks, Inc.
CHAPTER 9
IC Series Device
•
Configuring Overlapping IP Addresses on page 45
Configuring Overlapping IP Addresses
To configure overlapping vsys IP addresses with an Infranet Enforcer with vsys mapping:
NOTE: Before you perform this configuration, you must first add Infranet
Enforcer vsys and VLANs.
1.
To map a vsys with a VLAN, in the admin console, select UAC > Infranet Enforcer >
VYSYS Mapping.
2. Under Mapping with vsys, select an available vsys. Select an available VLAN.
3. Click Save Changes.
To configure overlapping vsys IP addresses with IF-MAP Federation using the
administrative domain:
1.
Select UAC > Infranet Enforcer > VYSYS Mapping.
2. Under Mapping with Administrative Domain, select an available vsys. Select an
administrative domain.
3. Click Save Changes.
To configure overlapping vsys IP addresses with the Infranet Enforcer and IF-MAP
Federation using the administrative domain and vsys mapping:
1.
Select System > IF-MAP Federation > Administrative Domain.
2. Under Mapping with Administrative Domain, select an available VLAN. Select an
administrative domain.
3. Click Save Changes.
Copyright © 2014, Juniper Networks, Inc.
45
ScreenOS Enforcer Feature Guide
NOTE: Administrators should note the following when dealing with
overlapping IP addresses:
Related
Documentation
46
•
•
Overlapping IP address configurations are not supported in environments
with mixed deployments of SRX and ISG devices.
•
Two VLANs with overlapping addresses should not be configured to the
same vsys.
•
For overlapping vsys IP addresses with IF-MAP Federation using the
administrative domain, both the IF-MAP client and server should have
identical Administrative Domain - VLAN mappings. If there is a mismatch,
authentication table entries on the firewall may not update correctly for
federated users who become local users on the IC to which the firewall is
connected.
•
IDP is not supported with overlapping IP addresses.
Understanding Deployments with ScreenOS Enforcer Virtual Systems on page 14
Copyright © 2014, Juniper Networks, Inc.
CHAPTER 10
Certificates
•
Configuring Certificate Authority Server Settings on page 47
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.
Copyright © 2014, Juniper Networks, Inc.
47
ScreenOS Enforcer Feature Guide
•
•
Related
Documentation
48
•
•
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.
Using Certificate-Based Security with Infranet Enforcer Deployments on page 9
Copyright © 2014, Juniper Networks, Inc.
CHAPTER 11
ScreenOS
•
Configuring the ScreenOS Connection on page 49
Configuring the ScreenOS Connection
The ScreenOS Enforcer connects to the Access Control Service 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 Access
Control Service 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 Access Control Service 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 Access Control
Service. The Access Control Service uses the serial number to determine which ScreenOS
Enforcer is attempting to connect, and the Access Control Service uses the NACN
password to authenticate the ScreenOS Enforcer. The Access Control Service then begins
communicating with the ScreenOS Enforcer using SSH.
To configure the Access Control Service to connect to the Infranet Enforcer:
1.
Select UAC > Infranet Enforcer > 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.
Copyright © 2014, Juniper Networks, Inc.
49
ScreenOS Enforcer Feature Guide
6. Select No 802.1X from the Location Group list if you are not using an Infranet Enforcer
as an 802.1X RADIUS client. This is the typical setting.
7. Click Save Changes.
When you finish configuring the Infranet Enforcer, the Infranet Enforcer attempts to
connect to the Access Control Service. If the connection is successful, a green dot is
displayed next to the Infranet Enforcer icon under Enforcer Status select System > Status
> Overview. The Infranet Enforcer IP address is also displayed in UAC > Infranet Enforcer
> Connection.
NOTE: To initiate a connection immediately after you finish configuring the
Infranet Enforcer, restart the system services by clicking Maintenance > System
> Platform > Restart Services.
Related
Documentation
50
•
Using Certificate-Based Security with Infranet Enforcer Deployments on page 9
•
Binding an Interface to a Security Zone on a ScreenOS Enforcer on page 71
•
ScreenOS Enforcer Configuration Overview on page 3
Copyright © 2014, Juniper Networks, Inc.
CHAPTER 12
IPsec
•
Configuring IPsec Routing Policies on page 51
•
Configuring an IP Address Pool Policy on page 52
•
Configuring Source Interface Policies on page 54
•
Configuring ScreenOS Enforcer IPsec Encryption Settings on page 55
Configuring IPsec Routing Policies
To configure an IPsec routing policy:
1.
Select UAC > Infranet Enforcer > IPsec Routing.
2. Click New Policy.
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 Access
Control Service 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.
Copyright © 2014, Juniper Networks, Inc.
51
ScreenOS Enforcer Feature Guide
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 Access Control Service 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 Access Control Service. 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 to all roles OTHER THAN those selected below—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.
12. Click Save Changes.
Related
Documentation
•
Setting Up ScreenOS Enforcer IPsec Routing Policies on page 90
•
Configuring Junos Enforcer IPsec Routing Policies
Configuring an IP Address Pool Policy
To configure an IP address pool policy:
1.
Select UAC > Infranet Enforcer > IP Address Pools.
2. Click New Policy.
3. On the New Policy page:
a. For Name, enter a name to label this IP address pool policy.
52
Copyright © 2014, Juniper Networks, Inc.
Chapter 12: IPsec
b. (Optional) For Description, enter a description.
4. For IP address pool, specify IP addresses or a range of IP addresses 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
IP Address Range
Description
a.b.c.d
A single IP address
a.b.c.d-e.f.g.h
All IP addresses from the first address to the last address, inclusive
a.b.c.d-f.g.h
An abbreviated form that specifies the range a.b.c.d through a.f.g.h
a.b.c.d-g.h
An abbreviated form that specifies the range a.b.c.d through a.b.g.h
a.b.c.d-h
An abbreviated form that specifies the range a.b.c.d through a.b.c.h
a.b.c.d/mask
All addresses in a network
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.
6. In the Roles section, specify:
•
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.
•
Policy applies to all roles OTHER THAN those selected below—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.
7. Click Save Changes.
Copyright © 2014, Juniper Networks, Inc.
53
ScreenOS Enforcer Feature Guide
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
http://www.juniper.net/techpubs/en_US/release-independent/screenos/information-products/pathway-pages/screenos/product/index.html
.
Related
Documentation
•
Using IP Address Pool Policies for IPsec in a NAT Environment on page 31
•
Understanding IP Address Pool Policies on page 33
Configuring Source Interface Policies
To configure a source interface policy:
1.
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 New Policy.
6. On the New Policy page:
a. For Name, enter a name to label this source interface policy.
b. (Optional) For Description, enter a description.
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
9. In the Roles section, specify:
•
54
Policy applies to ALL roles—To apply this source interface policy to all users.
Copyright © 2014, Juniper Networks, Inc.
Chapter 12: IPsec
•
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.
10. Click Save Changes.
Related
Documentation
•
Understanding ScreenOS Enforcer Source Interface Policies on page 34
•
Setting Up an Infranet Enforcer in Transparent Mode on page 77
Configuring ScreenOS Enforcer IPsec Encryption Settings
When you use the Access Control Service to configure IPsec on the Infranet Enforcer, the
Access Control Service 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
Copyright © 2014, Juniper Networks, Inc.
55
ScreenOS Enforcer Feature Guide
It does not matter what preshared seed you use for the IKE gateway because the Access
Control Service 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 Access Control Service 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
the Concepts & Examples ScreenOS Reference Guide: Volume 5, Virtual Private Networks
or the ScreenOS CLI Reference Guide.
Related
Documentation
56
•
Setting Up ScreenOS Enforcer IPsec Routing Policies on page 90
Copyright © 2014, Juniper Networks, Inc.
CHAPTER 13
Resource Access Policies
•
Configuring Resource Access Policies on page 57
•
Specifying Resources for User Access Control on page 58
Configuring Resource Access Policies
To configure Infranet Enforcer resource access policies:
1.
Select UAC > Enforcer > Resource Access Policy.
2. Click New Policy.
3. On the New Policy page:
a. For Name, enter a name to label this Infranet Enforcer resource access policy.
b. (Optional) For Description, enter a description.
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.
Copyright © 2014, Juniper Networks, Inc.
57
ScreenOS Enforcer Feature Guide
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. To enforce the policies, you must create
corresponding policies on the ScreenOS Enforcer. If the Access Control Service 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.
10. Click Save Changes.
Related
Documentation
•
About Resource Access Policies on page 37
Specifying Resources for User Access Control
When you create Host Enforcer policies (for OAC only) and Infranet Enforcer resource
access policies, you must specify the resources to which the policy applies.
Policy evaluation requires that the resources listed in a policy’s resources list follow a
canonical format. This section describes the canonical formats available for specifying
resources in Host Enforcer policies or resource access policies.
When a user attempts to access a resource, the system compares the request with the
resources specified in the corresponding policies, starting with the first policy in the policy
list. When the system matches a request, it then evaluates policy constraints and returns
the appropriate action (no further policies are evaluated). If no policy applies, then the
58
Copyright © 2014, Juniper Networks, Inc.
Chapter 13: Resource Access Policies
appliance performs the default action for the policy, which is some cases may be to deny
access by taking no action.
When specifying server resources for resource policies, the consider following guidelines:
protocol://IP address/net-mask:[ports]
The components are:
•
Protocol (optional)—Possible case-insensitive values:
•
tcp
•
tcp_in and tcp_out (Host Enforcer policies only)
•
udp
•
udp_in and udp_out (Host Enforcer policies only)
•
cmp
•
icmp://*:*
The only allowed ICMP configuration in a Host Enforcer policy is: icmp://*:* That is, you
cannot specify icmp://ip-addr/net-mask:port as you can for the other protocols.
If the protocol is missing, then all protocols are assumed. If a protocol is specified, then
the delimiter “://” is required. No special characters are allowed.
•
IP address/net-mask—The IP address is required, but the netmask is optional. You
can use an asterisk (*)to specify all IP addresses.
•
Host (required)—Possible values:
Table 6: DNS Hostname Special Characters
*
Matches all characters.
%
Matches any character except dot (.).
?
Matches exactly one character.
•
Ports (optional)—Possible values:
Table 7: Port Possible Values
*
Matches all ports; no other special characters are allowed.
port[,port]*
A comma-delimited list of single ports. Valid port numbers are 1- 65535.
[port1]-[port2]
A range of ports, from port1 through port2, inclusive.
You can mix port lists and port ranges. For example: 80,443,8080-8090.
Copyright © 2014, Juniper Networks, Inc.
59
ScreenOS Enforcer Feature Guide
If the port is missing, then the default port 80 is assigned for http, and 443 is assigned
for https. If a port is specified, then the delimite colon r “:” is required. For example:
tcp://10.10.149.149:22,23
tcp://10.11.0.10:80
udp://10.11.0.10:*
Related
Documentation
60
•
About Resource Access Policies on page 37
•
Configuring Resource Access Policies on page 57
•
Using Host Enforcer Policies
Copyright © 2014, Juniper Networks, Inc.
CHAPTER 14
Auth Tables and Mapping Policies
•
Configuring Dynamic Auth Table Allocation on page 61
•
Configuring Auth Table Mapping Policies for Source IP Enforcement on page 61
•
Configuring Auth Table Mapping Policies on page 63
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
Default Policy or specify an Enforcer for which you do not want to configure this feature.
2. Click Save Changes.
3. Configure a source IP policy for all traffic, whether source IP or IPsec.
Related
Documentation
•
Understanding Dynamic Auth Table Allocation on page 39
Configuring Auth Table Mapping Policies for Source IP Enforcement
NOTE: If you are using the Junos Enforcer or ScreenOS Release 6.1 or later
on the ScreenOS Enforcer, and you have permitted dynamic auth table
allocation, you do not need to configure auth table mapping policies. You
can use dynamic auth table allocation.
The Access Control Service configuration includes one default auth table mapping policy.
When the default auth table mapping policy is enabled, the Access Control Service
pushes one auth table entry for each authenticated user to all Infranet Enforcer devices
connected to the Access Control Service. 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.
Copyright © 2014, Juniper Networks, Inc.
61
ScreenOS Enforcer Feature Guide
Figure 7 on page 62 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 Access Control Service 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 7: 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 Access Control Service 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
62
Copyright © 2014, Juniper Networks, Inc.
Chapter 14: Auth Tables and Mapping Policies
need to create auth table mapping policies for the endpoints that use source IP
enforcement.
With ScreenOS Release 6.2 or later, the Access Control Service 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.
Related
Documentation
•
Understanding Infranet Enforcer Auth Tables on page 39
Configuring Auth Table Mapping Policies
To configure auth table mapping policies:
1.
Select UAC > Enforcer > Auth Table Mapping.
2. Select the default auth table mapping policy called Default Policy and click Delete.
3. On the New Policy page:
a. For Name, enter a name to label this auth table mapping policy.
b. (Optional) For Description, enter a description.
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.
Copyright © 2014, Juniper Networks, Inc.
63
ScreenOS Enforcer Feature Guide
•
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 Access Control Service 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 .
6. Click Save Changes.
Related
Documentation
64
•
Understanding Infranet Enforcer Auth Tables on page 39
•
Understanding Dynamic Auth Table Allocation on page 39
Copyright © 2014, Juniper Networks, Inc.
PART 3
Administration
•
Certificates on page 67
•
Interfaces on page 71
•
Route Mode on page 73
•
Transparent Mode on page 77
•
IC Series Device on page 81
•
Redirect Policy on page 83
•
Captive Portal on page 87
•
IPsec on page 89
•
Bidirectional VPN Policies on page 93
Copyright © 2014, Juniper Networks, Inc.
65
ScreenOS Enforcer Feature Guide
66
Copyright © 2014, Juniper Networks, Inc.
CHAPTER 15
Certificates
•
Setting Up Certificates for the Access Control Service and Infranet Enforcer on page 67
•
Creating a CA and Signing the Server Certificate Using OpenSSL on page 68
•
Importing the Certificate Into the Infranet Enforcer on page 70
Setting Up Certificates for the Access Control Service and Infranet Enforcer
To set up certificates for the Access Control Service 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 Access Control
Service by selecting System > Configuration > Certificates > Device Certificates.
•
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. To associate the certificate with the external or virtual port, perform these steps:
•
Select System > Configuration > Certificates > Device Certificates 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 system should
associate with the certificate. You can choose internal or external ports and primary
Copyright © 2014, Juniper Networks, Inc.
67
ScreenOS Enforcer Feature Guide
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 Access Control Service’s server
certificate into the Infranet Enforcer.
NOTE: To prevent your Web browser’s security warning from appearing each
time you sign in, import the certificate of the CA that signed the Access Control
Service’s server certificate into your browser’s list of trusted root certification
authorities.
NOTE: If you later import a different server certificate and CA certificate, you
might need to initiate a new connection to use them. To initiate a new
connection, select Maintenance > System > Platform > Restart Services. The
Infranet Enforcer connects to the Access Control Service and validates the
new certificate.
Related
Documentation
•
Creating a CA and Signing the Server Certificate Using OpenSSL on page 68
•
Importing the Certificate Into the Infranet Enforcer on page 70
•
Configuring Certificate Authority Server Settings on page 47
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 \openssl
C: md certs
C: cd certs
C: md demoCA
C: md demoCA\newcerts
C: 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.
68
Copyright © 2014, Juniper Networks, Inc.
Chapter 15: Certificates
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 = optional
stateOrProvinceName = optional
organizationName = match
organizationalUnitName = optional
commonName = supplied
emailAddress = 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 1024
Loading 'screen' into random state - done
Generating 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: MA
Locality Name: Boston
Organization Name: XYZ
Org. Unit Name: IT
Common Name: ca.xyz.com
e-mail Address: user@xyz.com
To create and sign a CSR from the Web UI:
1.
Select System > Configuration > Certificates > Device Certificates in the left navigation
bar.
2. Click New CSR. The new Certificate Signing Request page is displayed.
3. Enter the required information. For example:
Country Name: US
State or Province Name: MA
Locality Name: Boston
Copyright © 2014, Juniper Networks, Inc.
69
ScreenOS Enforcer Feature Guide
Organization Name: XYZ
Org. Unit Name: IT
Common Name: ic.xyz.com
e-mail Address: user@xyz.com
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 Access Control Service and
the CA certificate into the Infranet Enforcer.
Related
Documentation
•
Importing the Certificate Into the Infranet Enforcer on page 70
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.
Related
Documentation
70
•
Setting Up Certificates for the IC Series and Infranet Enforcer on page 67
Copyright © 2014, Juniper Networks, Inc.
CHAPTER 16
Interfaces
•
Binding an Interface to a Security Zone on a ScreenOS Enforcer on page 71
•
Binding the Physical Interface on page 72
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 8 on page 72 shows a typical setup for a ScreenOS Enforcer Integrated Security
Gateway 2000 (ISG 2000).
NOTE: Slot numbering varies by platform, and interface numbering varies
by module type. For slot numbering and interface information refer to the
user 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 8 on page 72 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 Access Control
Service (not shown) can reside in any security zone. If you place the Access Control
Service 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 Access Control Service.
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
.
Copyright © 2014, Juniper Networks, Inc.
71
ScreenOS Enforcer Feature Guide
In Figure 8 on page 72 the endpoints reside in the Untrust zone, and the protected
resources reside in the Trust zone. Port numbering is dependent on chassis configuration.
Figure 8: Binding a Physical Interface to a Security Zone
Related
Documentation
•
Binding the Physical Interface on page 72
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.
ScreenOS Web UI
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
Related
Documentation
72
•
ScreenOS Enforcer Configuration Overview on page 3
Copyright © 2014, Juniper Networks, Inc.
CHAPTER 17
Route Mode
•
Setting Up an Infranet Enforcer in Route Mode on page 73
•
Creating a Route Mode Instance with the ScreenOS Enforcer on page 74
Setting Up an Infranet Enforcer in Route Mode
The Access Control Service can reside on either side of the Infranet Enforcer. If the Access
Control Service 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 Access Control Service 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 Access Control Service 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 Access Control Service. 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.
Copyright © 2014, Juniper Networks, Inc.
73
ScreenOS Enforcer Feature Guide
3. Import the certificate of the CA that signed the Access Control Service’s server
certificate 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 SSL certificate into the Juniper security device.
The certificate of the CA that signed the Access Control Service’s certificate must be
imported on the Infranet Enforcer because the Infranet Enforcer must be able to trust
the Access Control Service 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 Access Control Service’s certificate, the
Infranet Enforcer must have the certificate of the CA that signed the Access Control
Service’s certificate.
4. Create an instance of the Access Control Service on the Juniper security device.
5. Enable SSH.
6. Verify routing from the Access Control Service to the untrust interface.
7. Ensure that both the Infranet Enforcer and the Access Control Service have the correct
time. If possible, use a Network Time Protocol (NTP) server to set the date and time
of both appliances.
Related
Documentation
•
Creating a Route Mode Instance with the ScreenOS Enforcer on page 74
Creating a Route Mode 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 74
•
Web UI on page 75
•
CLI on page 76
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:
74
Copyright © 2014, Juniper Networks, Inc.
Chapter 17: Route Mode
•
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
Certificate Security Administration.
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
Web UI
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.
Copyright © 2014, Juniper Networks, Inc.
75
ScreenOS Enforcer Feature Guide
c. Select CA from the show list.
d. Click Server Settings and make sure Check Method 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
Related
Documentation
76
•
Configuring the ScreenOS Connection on page 49
•
Viewing the Configuration of an IC Series Device on the ScreenOS Enforcer on page 81
Copyright © 2014, Juniper Networks, Inc.
CHAPTER 18
Transparent Mode
•
Setting Up an Infranet Enforcer in Transparent Mode on page 77
•
Creating a Transparent Mode Instance with the ScreenOS Enforcer on page 78
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
Access Control Service. 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 Access Control Service can also reside in either zone. If the Access Control Service
resides in a zone different from the endpoints, configure a policy that allows traffic to
the endpoints through the ScreenOS Enforcer.
Copyright © 2014, Juniper Networks, Inc.
77
ScreenOS Enforcer Feature Guide
3. Import the certificate of the CA that signed the Access Control Service’s server
certificate into the ScreenOS Enforcer.
Do not import the Access Control Service 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 Access Control Service on the ScreenOS Enforcer.
5. Enable SSH.
6. Verify routing from the Access Control Service 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 Access Control Service.
7. Ensure that both the Infranet Enforcer and the Access Control Service have the correct
time. If possible, use a Network Time Protocol (NTP) server to set the date and time
of both appliances.
Related
Documentation
•
Creating a Transparent Mode Instance with the ScreenOS Enforcer on page 78
•
Viewing the Configuration of an IC Series Device on the ScreenOS Enforcer on page 81
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 78
•
CLI on page 79
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
78
Copyright © 2014, Juniper Networks, Inc.
Chapter 18: Transparent Mode
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 to operate in Transparent (Layer 2) mode, all interfaces
must be in a Layer 2 zone, such as v1-trust or in the null zone. Interfaces cannot
remain 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 ip manageable
unset interface vlan1 manage ping
unset interface vlan1 manage telnet
unset interface vlan1 manage snmp
unset interface vlan1 manage web
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
Related
Documentation
•
ScreenOS Enforcer Configuration Overview on page 3
•
Configuring the ScreenOS Connection on page 49
•
Setting Up an Infranet Enforcer in Transparent Mode on page 77
Copyright © 2014, Juniper Networks, Inc.
79
ScreenOS Enforcer Feature Guide
80
Copyright © 2014, Juniper Networks, Inc.
CHAPTER 19
IC Series Device
•
Viewing the Access Control Service Configuration on the ScreenOS Enforcer on page 81
Viewing the Access Control Service Configuration 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 81
•
Web UI on page 81
•
CLI on page 82
Configuration Details Displayed
You can view the configuration of an Access Control Service instance through the Web
UI and the CLI. You can view the following information:
•
Name of the Access Control Service instance
•
IP address or domain name of the Access Control Service
•
Port number ( always 11122)
•
Timeout (60 seconds by default)
•
Source interface
The Web UI also allows you to view the NACN password.
Web UI
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.
Copyright © 2014, Juniper Networks, Inc.
81
ScreenOS Enforcer Feature Guide
CLI
To view configuration information at the CLI, type the following command:
1.
Related
Documentation
82
get infranet controller name controller1
•
ScreenOS Enforcer Configuration Overview on page 3
•
Setting Up an Infranet Enforcer in Route Mode on page 73
•
Setting Up an Infranet Enforcer in Transparent Mode on page 77
Copyright © 2014, Juniper Networks, Inc.
CHAPTER 20
Redirect Policy
•
Creating a Redirect Policy on the Infranet Enforcer on page 83
•
Creating a Redirect Policy on the ScreenOS Enforcer on page 85
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 Access Control Service, or to
an IP address or domain name that you specify in a redirect URL.
After a user signs in to the Access Control Service and the user’s endpoint system
meets the requirements of the Access Control Service’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 Access Control Service, or to an IP
address or domain name that you specify in a redirect URL.
After a user signs in to the Access Control Service, 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
Copyright © 2014, Juniper Networks, Inc.
83
ScreenOS Enforcer Feature Guide
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 ScreenOS Web UI
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 Access Control Services (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-auth
redirect-unauthenticated
84
Copyright © 2014, Juniper Networks, Inc.
Chapter 20: Redirect Policy
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
Creating a Redirect Policy on the ScreenOS Enforcer
From the ScreenOS Web UI
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 Access Control
Service 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 Access Control Service 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 Access Control Service.
NOTE: In the Redirect URL string, you can omit the ?target=%dest-url%
string. For example:
http://server1.company.com
If you do not include the ?target=%dest-url% string, the user must manually
open a new browser window and enter the protected resource URL again
after 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”.
Copyright © 2014, Juniper Networks, Inc.
85
ScreenOS Enforcer Feature Guide
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 the Web 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-auth
redirect-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 Access Control Service 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.
Related
Documentation
86
•
Understanding the Infranet Enforcer Captive Portal Feature on page 19
•
Before Configuring Captive Portal on page 20
Copyright © 2014, Juniper Networks, Inc.
CHAPTER 21
Captive Portal
•
Overriding the Default Redirection Destination for Captive Portal on page 87
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 Access Control Service using
HTTPS. To perform the redirection, the Infranet Enforcer uses the IP address or domain
name that you specified when you configured the Access Control Service 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 Access Control Services
in a cluster, and the current Access Control Service becomes disconnected, the ScreenOS
Enforcer automatically redirects HTTP traffic to the next active Access Control Service
in its configuration list. The ScreenOS Enforcer redirects traffic to only one Access Control
Service at a time.
The Access Control Service domain name that you specify when configuring the Access
Control Service instance in the ScreenOS Enforcer must match the Access Control Service
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, and the ScreenOS Enforcer is configured to connect
to the Access Control Service’s physical IP addresses.
•
You want to redirect traffic to a Web server instead of to the Access Control Service.
•
If, because of split DNS or IP routing restrictions at your site, the ScreenOS Enforcer
uses a different address for the Access Control Service than endpoints, you must specify
the domain name or IP address that endpoints must use to access the Access Control
Service.
Copyright © 2014, Juniper Networks, Inc.
87
ScreenOS Enforcer Feature Guide
By default, the ScreenOS Enforcer also encodes and forwards to the Access Control
Service the protected resource URL that the user entered. The Access Control Service
uses the protected resource URL to help users navigate to the protected resource. The
manner in which the Access Control Service 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 Access Control Service 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 Access Control Service 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.
88
Copyright © 2014, Juniper Networks, Inc.
CHAPTER 22
IPsec
•
Using the Access Control Service User Interface to Create Basic ScreenOS Enforcer
IPsec Policies on page 89
•
Setting Up ScreenOS Enforcer IPsec Routing Policies on page 90
Using the Access Control Service User Interface to Create Basic ScreenOS Enforcer
IPsec 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 Access Control Service 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. Select UAC > Infranet Enforcer > Connection and 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 Access Control Service 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
Copyright © 2014, Juniper Networks, Inc.
89
ScreenOS Enforcer Feature Guide
in the source zone of the policy. The Access Control Service uses the source interface
number and the ID of the destination zone to uniquely name each of these objects.
4. To configure the Access Control Service 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.
Related
Documentation
•
Setting Up ScreenOS Enforcer IPsec Routing Policies on page 90
•
Configuring Junos Enforcer IPsec Routing Policies
Setting Up ScreenOS Enforcer IPsec Routing Policies
In this example, you use the Access Control Service 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 Access Control Service 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 ike gateway $infra-gw-5-2 dial-up $infra-g-5-2 Aggr outgoing-interface ethernet2 seedpreshare
ARANDOMSTRING 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 from Untrust 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.
90
Copyright © 2014, Juniper Networks, Inc.
Chapter 22: IPsec
Related
Documentation
•
Configuring ScreenOS Enforcer IPsec Encryption Settings on page 55
Copyright © 2014, Juniper Networks, Inc.
91
ScreenOS Enforcer Feature Guide
92
Copyright © 2014, Juniper Networks, Inc.
CHAPTER 23
Bidirectional VPN Policies
•
Creating a ScreenOS Bidirectional VPN Policy on page 93
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 Access Control Service, create the IPsec (dial-up VPN) policy on the UAC
> 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 Modify matching 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 Modify matching bidirectional VPN policy check box.
b. Click Advanced.
c. Clear the Authentication check box on the Advanced Policy Settings page.
d. Click OK.
Related
Documentation
•
Using ScreenOS Enforcer Bidirectional VPN Policies on page 35
Copyright © 2014, Juniper Networks, Inc.
93
ScreenOS Enforcer Feature Guide
94
Copyright © 2014, Juniper Networks, Inc.