Junos® OS Adaptive Services Interfaces Feature

Junos® OS
Adaptive Services Interfaces Feature Guide for
Routing Devices
Modified: 2018-03-01
Copyright © 2018, Juniper Networks, Inc.
Juniper Networks, Inc.
1133 Innovation Way
Sunnyvale, California 94089
USA
408-745-2000
www.juniper.net
Juniper Networks, the Juniper Networks logo, Juniper, and Junos are registered trademarks of Juniper Networks, Inc. and/or its affiliates in
the United States and other countries. All other trademarks may be 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 OS Adaptive Services Interfaces Feature Guide for Routing Devices
Copyright © 2018 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/. By downloading, installing or using such software, you agree to the terms and conditions of that
EULA.
ii
Copyright © 2018, Juniper Networks, Inc.
Table of Contents
About the Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxvii
Documentation and Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxvii
Supported Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxvii
Using the Examples in This Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxvii
Merging a Full Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxviii
Merging a Snippet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxviii
Documentation Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxix
Documentation Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xli
Requesting Technical Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xli
Self-Help Online Tools and Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . xli
Opening a Case with JTAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xlii
Part 1
Overview
Chapter 1
Adaptive Services Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Adaptive Services Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Packet Flow Through the Adaptive Services or Multiservices PIC . . . . . . . . . . . . . . 5
Chapter 2
Adaptive Services Configuration Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Understanding Service Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Configuring Service Sets to be Applied to Services Interfaces . . . . . . . . . . . . . . . . . 9
Configuring Interface Service Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Configuring Next-Hop Service Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Determining Traffic Direction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Interface Style Service Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Next-Hop Style Service Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Configuring Service Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Configuring Service Set Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Configuring Service Interface Pools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Enabling Services PICs to Accept Multicast Traffic . . . . . . . . . . . . . . . . . . . . . . . . . 17
Applying Filters and Services to Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Configuring Service Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Example: Configuring Service Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Configuring AS or Multiservices PIC Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Examples: Configuring Services Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Configuring the Address and Domain for Services Interfaces . . . . . . . . . . . . . . . . 24
Configuring System Logging for Service Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Tracing Services PIC Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Configuring the Adaptive Services Log Filename . . . . . . . . . . . . . . . . . . . . . . 28
Configuring the Number and Size of Adaptive Services Log Files . . . . . . . . . . 29
Configuring Access to the Log File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Copyright © 2018, Juniper Networks, Inc.
iii
Adaptive Services Interfaces Feature Guide for Routing Devices
Configuring a Regular Expression for Lines to Be Logged . . . . . . . . . . . . . . . . 29
Configuring the Trace Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Configuring Fragmentation Control for MS-DPC and MS-PIC Service
Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Chapter 3
Plug-in Adaptive Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
URL Filtering Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
URL Filter Database File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
URL Filter Profile Caveats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Configuring URL Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Exchanging Data More Efficiently Using TCP Fast Open . . . . . . . . . . . . . . . . . . . . 38
Configuring TFO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Three Modes for TFO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Using NAT and TFO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Part 2
Translating IP Addresses Using NAT
Chapter 4
NAT Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Junos Address Aware Network Addressing Overview . . . . . . . . . . . . . . . . . . . . . . . 45
Benefits of NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
NAT Concept and Facilities Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
IPv4-to-IPv4 Basic NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Basic NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
NAPT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Deterministic NAPT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Static Destination NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Twice NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
IPv6 NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Application-Level Gateway (ALG) Support . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
NAT-PT with DNS ALG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Dynamic NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Stateful NAT64 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
464XLAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Dual-Stack Lite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Junos Address Aware Network Addressing Line Card Support . . . . . . . . . . . . 51
Junos OS Carrier-Grade NAT Implementation Overview . . . . . . . . . . . . . . . . . . . . 52
Carrier-Grade NAT Feature Comparison for Junos Address Aware by Type of
Interface Card . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Chapter 5
NAT Configuration Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Network Address Translation Configuration Overview . . . . . . . . . . . . . . . . . . . . . . 59
Configuring Source and Destination Addresses Network Address Translation
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Configuring Pools of Addresses and Ports for Network Address Translation
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Configuring NAT Pools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Preserve Range and Preserve Parity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Specifying Destination and Source Prefixes Without Configuring a Pool . . . . 63
iv
Copyright © 2018, Juniper Networks, Inc.
Table of Contents
Network Address Translation Rules Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Configuring Match Direction for NAT Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Configuring Match Conditions in NAT Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Configuring Actions in NAT Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Configuring Translation Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Configuring NAT Rules for IPsec Passthrough for Non-NAT-T Peers . . . . . . . 70
Configuring Service Sets for Network Address Translation . . . . . . . . . . . . . . . . . . . 71
Carrier-Grade NAT Implementation: Best Practices . . . . . . . . . . . . . . . . . . . . . . . . 73
Use Round-Robin Address-Allocation When Using APP with the
MS-DPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Use the EIM Feature Only When Needed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Define Port Block Allocation Block Sizes Based on Expected Number of User
Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Considerations When Changing Port Block Allocation Configuration on
Running Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Do Not Allocate NAT Pools That Are Larger Than Needed . . . . . . . . . . . . . . . 77
MS-MPC and MS-MIC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
MS-DPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Configure System Logging for NAT Only When Needed . . . . . . . . . . . . . . . . . 78
Limit the Impact of Missing IP Fragments . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Do Not Use Configurations Prone to Packet Routing Loops . . . . . . . . . . . . . . 80
Inactivity Timeouts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Enable Dump on Flow Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Chapter 6
Avoiding IPv4 Exhaustion Using Junos Address Aware Network Addressing
and Stateful NAT64 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Sample IPv6 Transition Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Example 1: IPv4 Depletion with a Non-IPv6 Access Network . . . . . . . . . . . . . 85
Example 2: IPv4 Depletion with an IPv6 Access Network . . . . . . . . . . . . . . . . 86
Example 3: IPv4 Depletion for Mobile Networks . . . . . . . . . . . . . . . . . . . . . . . 87
Configuring Stateful NAT64 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Chapter 7
Hiding Private Networks Using Static Source NAT . . . . . . . . . . . . . . . . . . . . . 91
Configuring Static Source Translation in IPv4 Networks . . . . . . . . . . . . . . . . . . . . . 91
Configuring the NAT Pool and Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Configuring the Service Set for NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Configuring Trace Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Sample Configuration - Static Source NAT Using a Static Pool With An
Address Prefix And An Address Range . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Sample Configuration - Static Source Nat for One-To-One Mapping Between
a Private Subnet and a Public Subnet . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Configuring Static Source Translation in IPv6 Networks . . . . . . . . . . . . . . . . . . . . 98
Configuring the NAT Pool and Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Configuring the Service Set for NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Configuring Trace Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Example: Configuring Basic NAT44 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Example: Configuring NAT for Multicast Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Rendezvous Point Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Router 1 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Copyright © 2018, Juniper Networks, Inc.
v
Adaptive Services Interfaces Feature Guide for Routing Devices
Chapter 8
Making Private Servers Available Using Static Destination NAT . . . . . . . . 109
Configuring Static Destination Address Translation in IPv4 Networks . . . . . . . . . 109
Chapter 9
Allowing Components of a Private Network to Share a Single Address
Using NAPT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Configuring Address Pools for Network Address Port Translation (NAPT)
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Round-Robin Allocation for NAPT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Sequential Allocation for NAPT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Preserve Parity and Preserve Range for NAPT . . . . . . . . . . . . . . . . . . . . . . . . . 117
Address Pooling and Endpoint Independent Mapping for NAPT . . . . . . . . . . 117
Address Pooling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Endpoint Independent Mapping and Endpoint Independent Filtering . . 119
Secured Port Block Allocation for NAPT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Secured Port Block Allocation for NAPT . . . . . . . . . . . . . . . . . . . . . . . . . 120
Interim Logging for Port Block Allocation . . . . . . . . . . . . . . . . . . . . . . . . 120
Comparison of NAPT Implementation Methods . . . . . . . . . . . . . . . . . . . . . . 120
Configuring NAPT in IPv4 Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Configuring NAPT in IPv6 Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Example: Configuring NAT with Port Translation . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Example: NAPT Configuration on the MS-MPC With an Interface Service Set . . 129
Example: Dynamic Source NAT as a Next-Hop Service . . . . . . . . . . . . . . . . . . . . 134
Chapter 10
Mapping Addresses and Ports With Deterministic NAT . . . . . . . . . . . . . . . . 137
Deterministic NAPT Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Benefits of Deterministic NAPT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Understanding Deterministic NAPT Algorithms . . . . . . . . . . . . . . . . . . . . . . . 138
Deterministic NAPT Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Configuring Deterministic NAPT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Configuring the NAT Pool for Deterministic NAPT . . . . . . . . . . . . . . . . . . . . . 143
Configuring the NAT Rule for for Deterministic NAPT . . . . . . . . . . . . . . . . . . 145
Configuring the Service Set for Deterministic NAT . . . . . . . . . . . . . . . . . . . . . 146
Chapter 11
Securing Traffic Using NAT-PT and ALGs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
ALGs Available for Junos OS Address Aware NAT . . . . . . . . . . . . . . . . . . . . . . . . . 147
Configuring NAT-PT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Configuring the DNS ALG Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Configuring the NAT Pool and NAT Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Configuring the Service Set for NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
Configuring Trace Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Example: Configuring NAT-PT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Chapter 12
Providing IPv4 Connectivity Across IPv6-Only Network Using
464XLAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
464XLAT Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Benefits of 464XLAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Configuring 464XLAT Provider-Side Translater for IPv4 Connectivity Across
IPv6-Only Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
vi
Copyright © 2018, Juniper Networks, Inc.
Table of Contents
Chapter 13
Reducing Traffic and Bandwidth Requirements Using Port Control
Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
Port Control Protocol Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
Benefits of Port Control Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
Port Control Protocol Version 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
Configuring Port Control Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
Configuring PCP Server Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
Configuring a PCP Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
Configuring a Service Set to Apply PCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
SYSLOG Message Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Example: Configuring Port Control Protocol with NAPT44 . . . . . . . . . . . . . . . . . 184
Chapter 14
Automatically Assigning Ports Using Secured Port Block Allocation . . . . . 191
Secured Port Block Allocation for NAPT44 and NAT64 Overview . . . . . . . . . . . . 191
Benefits of Secured Port Block Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
Interim Logging for Secured Port Block Allocation . . . . . . . . . . . . . . . . . . . . . . . . 192
Benefits of Iterim Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
Guidelines for Configuring Interim Logging for Secured Port Block Allocation . . . 193
Guidelines for Configuring Secured Port Block Allocation . . . . . . . . . . . . . . . . . . 195
Configuring Secured Port Block Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
Chapter 15
Connecting Specific Ports and Addresses Using Port Forwarding . . . . . . . 201
Port Forwarding Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
Benefits of Port Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
Configuring Port Forwarding for Static Destination Address Translation . . . . . . 202
Configuring Port Forwarding Without Destination Address Translation . . . . . . . 205
Example: Configuring Port Forwarding with Twice NAT . . . . . . . . . . . . . . . . . . . . 207
Chapter 16
Allocating a Few Public Addresses to Many Private Hosts Using Dynamic
NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
Configuring Dynamic Address-Only Source Translation in IPv4 Networks . . . . . . 211
Example: Dynamic Source NAT as a Next-Hop Service . . . . . . . . . . . . . . . . . . . . 215
Example: Assigning Addresses from a Dynamic Pool for Static Use . . . . . . . . . . . 217
Chapter 17
Achieving Line-Rate, Low-Latency Translations Using Inline NAT . . . . . . . 219
Inline Network Address Translation Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
Benefits of Inline NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
Example: Configuring Inline Network Address Translation—Interface-Based
Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
Example: Configuring Inline Network Address Translation—Route-Based
Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
Chapter 18
Removing Address Dependency Using Network Prefix Translation for
IPv6 Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
Stateless Source Network Prefix Translation for IPv6 Overview . . . . . . . . . . . . . 237
Benefits of Stateless Source Network Prefix Translation . . . . . . . . . . . . . . . 237
NPTv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
Guidelines for Configuring Stateless Source Network Prefix Translation . . . . . . 239
Interoperation of Functionalities with Network Prefix Translation for IPv6 . . . . . 240
Address Mapping Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
Internal to External Translation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
Copyright © 2018, Juniper Networks, Inc.
vii
Adaptive Services Interfaces Feature Guide for Routing Devices
External to Internal Translation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
Checksum-Neutral Translation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
Multihoming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
Hairpinning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
Load Balancing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
ICMPv6 for NPTv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
Working of NPTv6 with Interface-Style and Next Hop-Style Service Sets . . . . . 242
Example: Achieving Address Independence By Configuring Stateless Network
Prefix Translation in IPv6 Networks by Using Interface-Style Service
Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
Example: Achieving Address Independence By Configuring Stateless Network
Prefix Translation in IPv6 Networks by Using Next-Hop -Style Service
Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
Chapter 19
Monitoring NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
Configuring NAT Session Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
Monitoring NAT Pool Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
Using the Enterprise-Specific Utility MIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
Using the Enterprise-Specific Utility MIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
Populating the Enterprise-Specific Utility MIB with Information . . . . . . . . . 259
Stopping the SLAX Script with the CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
Clearing the Utility MIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
Recovering from an Abnormal SLAX Script Exit or a SLAX Script Exit with
the CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
Part 3
Transitioning to IPv6 Using Softwires
Chapter 20
Softwires Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
Tunneling Services for IPv4-to-IPv6 Transition Overview . . . . . . . . . . . . . . . . . . 269
6to4 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
Basic 6to4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
6to4 Anycast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
6to4 Provider-Managed Tunnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
DS-Lite Softwires—IPv4 over IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
6rd Softwires—IPv6 over IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
Chapter 21
Softwires Configuration Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
Configuring Softwire Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
Configuring Service Sets for Softwire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
Chapter 22
Transitioning to IPv6 Using 6to4 Softwires . . . . . . . . . . . . . . . . . . . . . . . . . . 279
Configuring a 6to4 Provider-Managed Tunnel . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
viii
Copyright © 2018, Juniper Networks, Inc.
Table of Contents
Chapter 23
Transitioning to IPv6 Using DS-Lite Softwires . . . . . . . . . . . . . . . . . . . . . . . 283
Configuring a DS-Lite Softwire Concentrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
Configuring IPv6 Multicast Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
Example: Basic DS-Lite Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
Example: Configuring DS-Lite and 6rd in the Same Service Set . . . . . . . . . . . . . . 291
Protecting CGN Devices Against Denial of Service (DOS) Attacks . . . . . . . . . . . 299
Mapping Refresh Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
EIF Inbound Flow Limit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
DS-Lite Subnet Limitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
DS-Lite Per Subnet Limitation Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
Configuring DS-Lite Per Subnet Session Limitation to Prevent Denial of
Service Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
Chapter 24
Transitioning to IPv6 Using 6rd Softwires . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
Configuring a 6rd Softwire Concentrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
Configuring Stateful Firewall Rules for 6rd Softwire . . . . . . . . . . . . . . . . . . . . . . 304
Example: Basic 6rd Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305
High Availability and Load Balancing for 6rd Softwires . . . . . . . . . . . . . . . . . . . . . 311
Load Balancing a 6rd Domain Across Multiple Services PICs . . . . . . . . . . . . . 311
Example: Load Balancing a 6rd Domain Across Multiple Services PICs . . . . 311
Configuring High Availability for 6rd Using 6rd Anycast . . . . . . . . . . . . . . . . . 316
Configuring Inline 6rd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317
Configuring the Bandwidth for Inline Services . . . . . . . . . . . . . . . . . . . . . . . . 317
Configuring the Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318
Configuring the Softwire Concentrator and Rule . . . . . . . . . . . . . . . . . . . . . . 319
Configuring the Service Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
Configuring the Routing Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
Inline 6rd and 6to4 Configuration Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
Examples: 6rd and 6to4 Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322
Example: 6rd with Interface-Style Service Set Configuration . . . . . . . . . . . . 322
Example: 6rd with Next-Hop-Style Service Set Configuration . . . . . . . . . . . 323
Example: 6rd Anycast Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
Example: Hairpinning Between 6rd Domains Configuration . . . . . . . . . . . . . 326
Example: 6to4 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328
Chapter 25
Monitoring and Troubleshooting Softwires . . . . . . . . . . . . . . . . . . . . . . . . . . 331
Ping and Traceroute for DS-Lite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
Monitoring Softwire Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
Monitoring CGN, Stateful Firewall, and Softwire Flows . . . . . . . . . . . . . . . . . . . . 333
Part 4
Enabling Traffic to Pass Securely Using ALGs
Chapter 26
ALG Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337
ALG Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337
Supported ALGs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337
ALG Support Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
Basic TCP ALG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340
Basic UDP ALG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340
BOOTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
DCE RPC Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
Copyright © 2018, Juniper Networks, Inc.
ix
Adaptive Services Interfaces Feature Guide for Routing Devices
DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
FTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
Gatekeeper RAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342
H323 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342
ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
IIOP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
IKE ALG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
NetBIOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
NetShow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
ONC RPC Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
PPTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
RealAudio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
Sun RPC and RPC Portmap Services . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
RTSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
SQLNet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
TFTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
Traceroute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
UNIX Remote-Shell Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
Winframe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349
Juniper Networks Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349
Examples: Referencing the Preset Statement from the Junos OS Default
Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360
ALGs Available for Junos OS Address Aware NAT . . . . . . . . . . . . . . . . . . . . . . . . 362
Chapter 27
ALGs Configuration Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367
Configuring Application Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367
Configuring Application Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367
Configuring an Application Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368
Configuring the Network Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370
Configuring the ICMP Code and Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372
Configuring Source and Destination Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . 373
Configuring the Inactivity Timeout Period . . . . . . . . . . . . . . . . . . . . . . . . . . . 376
Configuring an IKE ALG Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376
Configuring SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377
SIP ALG Interaction with Network Address Translation . . . . . . . . . . . . . 378
Junos OS SIP ALG Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384
Configuring an SNMP Command for Packet Matching . . . . . . . . . . . . . . . . . 385
Configuring an RPC Program Number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385
Configuring the TTL Threshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385
Configuring a Universal Unique Identifier . . . . . . . . . . . . . . . . . . . . . . . . . . . 385
Examples: Configuring Application Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . 386
Verifying the Output of ALG Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387
FTP Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387
Sample Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387
FTP System Log Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388
Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388
x
Copyright © 2018, Juniper Networks, Inc.
Table of Contents
Troubleshooting Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389
RTSP ALG Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389
Sample Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390
Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390
Troubleshooting Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390
System Log Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392
System Log Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392
System Log Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392
ICMP, Ping, and Traceroute ALGs for MS-MICs and MS-MPCs . . . . . . . . . . . . . . 393
Monitoring Port Control Protocol Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394
Part 5
Securing Content Using Junos Network Secure and IDS
Chapter 28
Junos Network Secure Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399
Junos Network Secure Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399
Stateful Firewall Support for Application Protocols . . . . . . . . . . . . . . . . . . . 400
Stateful Firewall Anomaly Checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400
Chapter 29
Junos Network Secure Configuration Overview . . . . . . . . . . . . . . . . . . . . . . 403
Configuring Stateful Firewall Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403
Configuring Match Direction for Stateful Firewall Rules . . . . . . . . . . . . . . . . 405
Configuring Match Conditions in Stateful Firewall Rules . . . . . . . . . . . . . . . 405
Configuring Actions in Stateful Firewall Rules . . . . . . . . . . . . . . . . . . . . . . . . 407
Configuring IP Option Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407
Configuring Stateful Firewall Rule Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408
Examples: Configuring Stateful Firewall Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . 409
Example: BOOTP and Broadcast Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412
Example: Configuring Layer 3 Services and the Services SDK on Two PICs . . . . . 413
Example: Virtual Routing and Forwarding (VRF) and Service Configuration . . . 427
Chapter 30
IDS Configuration on MS-DPC Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429
Understanding SYN Cookie Protection on an MS-DPC . . . . . . . . . . . . . . . . . . . . 429
Configuring IDS Rules on an MS-DPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 430
Configuring Match Direction for IDS Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . 431
Configuring Match Conditions in IDS Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 432
Configuring Actions in IDS Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433
Configuring IDS Rule Sets on an MS-DPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438
Examples: Configuring IDS Rules on an MS-DPC . . . . . . . . . . . . . . . . . . . . . . . . . 439
Chapter 31
Network Attack Protection Configuration on MS-MPC . . . . . . . . . . . . . . . . 443
Understanding Network Attack Protection on an MS-MPC or MS-MIC . . . . . . . 443
Network Probing Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444
ICMP Address Sweep . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444
TCP Port Scans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444
Network Flooding Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444
ICMP Flood . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444
TCP SYN Flood . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445
UDP Flood . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445
Copyright © 2018, Juniper Networks, Inc.
xi
Adaptive Services Interfaces Feature Guide for Routing Devices
Suspicious Packet Pattern Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445
ICMP Fragmentation Attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445
ICMP Large Packet Attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446
IP Bad Option Attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446
IP Teardrop Attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446
Land Attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446
TCP SYN Fragment Attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446
TCP WinNuke Attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446
Header Anomaly Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447
ICMP Ping of Death Attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447
IP Unknown Protocol Attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447
TCP No Flag Attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447
TCP SYN FIN Attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447
TCP FIN No ACK Attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447
Configuring Protection Against Network Attacks on an MS-MPC or MS-MIC . . . 448
Configuring Protection Against Network Probing, Network Flooding, and
Suspicious Pattern Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448
Configuring IDS Rule Name and Direction . . . . . . . . . . . . . . . . . . . . . . . 448
Configuring Session Limits for Subnets . . . . . . . . . . . . . . . . . . . . . . . . . 449
Configuring Session Limits Independent of the Protocol . . . . . . . . . . . 450
Configuring ICMP Address Sweep Protection . . . . . . . . . . . . . . . . . . . . . 451
Configuring TCP Port Scanner Protection . . . . . . . . . . . . . . . . . . . . . . . . 451
Configuring ICMP Flooding Protection . . . . . . . . . . . . . . . . . . . . . . . . . . 452
Configuring UDP Flooding Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . 452
Configuring TCP SYN Flooding Protection . . . . . . . . . . . . . . . . . . . . . . . 453
Configuring ICMP Fragmentation Protection . . . . . . . . . . . . . . . . . . . . . 454
Configuring ICMP Large Packet Protection . . . . . . . . . . . . . . . . . . . . . . 454
Configuring IP Bad Options Protection . . . . . . . . . . . . . . . . . . . . . . . . . . 454
Configuring Land Attack Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455
Configuring TCP SYN Fragment Protection . . . . . . . . . . . . . . . . . . . . . . 455
Configuring WinNuke Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455
Configuring the Service Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455
Configuring Protection Against Header Anomaly Attacks . . . . . . . . . . . . . . 456
Configuring Logging of Network Attack Protection Packet Drops on an MS-MPC
or MS-MIC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456
Chapter 32
Monitoring Junos Network Secure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457
Monitoring Stateful Firewall Conversations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457
Monitoring CGN, Stateful Firewall, and Softwire Flows . . . . . . . . . . . . . . . . . . . . 457
Monitoring Global Stateful Firewall Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . 458
Part 6
Creating Secure Tunnels Using Junos VPN Site Secure
Chapter 33
Junos VPN Site Secure Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461
Understanding Junos VPN Site Secure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461
IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461
Security Associations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462
IKE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462
Non-Support for NAT-T . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462
xii
Copyright © 2018, Juniper Networks, Inc.
Table of Contents
Comparison of IPsec on ES PICs and Junos VPN Site Secure on Multiservices
LIne Cards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463
Authentication Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464
Encryption Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465
IPsec Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466
IPsec Multipath Forwarding with UDP Encapsulation . . . . . . . . . . . . . . . . . . . . . 468
Supported IPsec and IKE Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 469
IPSec Terms and Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471
Chapter 34
Junos VPN Site Secure Configuration Overview . . . . . . . . . . . . . . . . . . . . . . 475
Minimum Security Association Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . 475
Minimum Manual SA Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475
Minimum Dynamic SA Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476
Configuring Security Associations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477
Configuring Manual Security Associations . . . . . . . . . . . . . . . . . . . . . . . . . . . 477
Configuring the Direction for IPsec Processing . . . . . . . . . . . . . . . . . . . . 478
Configuring the Protocol for a Manual IPsec SA . . . . . . . . . . . . . . . . . . . 479
Configuring the Security Parameter Index . . . . . . . . . . . . . . . . . . . . . . . 479
Configuring the Auxiliary Security Parameter Index . . . . . . . . . . . . . . . 480
Configuring Authentication for a Manual IPsec SA . . . . . . . . . . . . . . . . 480
Configuring Encryption for a Manual IPsec SA . . . . . . . . . . . . . . . . . . . . 481
Configuring Dynamic Security Associations . . . . . . . . . . . . . . . . . . . . . . . . . 482
Clearing Security Associations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 482
Example: Configuring Manual SAs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483
Configuring IKE Proposals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498
Configuring the Authentication Algorithm for an IKE Proposal . . . . . . . . . . 499
Configuring the Authentication Method for an IKE Proposal . . . . . . . . . . . . 500
Configuring the Diffie-Hellman Group for an IKE Proposal . . . . . . . . . . . . . 500
Configuring the Encryption Algorithm for an IKE Proposal . . . . . . . . . . . . . . 501
Configuring the Lifetime for an IKE SA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 502
Example: Configuring an IKE Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 502
Configuring IKE Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503
Configuring the IKE Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504
Configuring the Mode for an IKE Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505
Configuring the Proposals in an IKE Policy . . . . . . . . . . . . . . . . . . . . . . . . . . 505
Configuring the Preshared Key for an IKE Policy . . . . . . . . . . . . . . . . . . . . . . 506
Configuring the Local Certificate for an IKE Policy . . . . . . . . . . . . . . . . . . . . 506
Configuring a Certificate Revocation List . . . . . . . . . . . . . . . . . . . . . . . . 507
Configuring the Description for an IKE Policy . . . . . . . . . . . . . . . . . . . . . . . . 507
Configuring Local and Remote IDs for IKE Phase 1 Negotiation . . . . . . . . . . 507
Enabling Invalid SPI Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 508
Example: Configuring an IKE Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 508
Configuring IPsec Proposals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 509
Configuring the Authentication Algorithm for an IPsec Proposal . . . . . . . . . 510
Configuring the Description for an IPsec Proposal . . . . . . . . . . . . . . . . . . . . . 512
Configuring the Encryption Algorithm for an IPsec Proposal . . . . . . . . . . . . . 512
Configuring the Lifetime for an IPsec SA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513
Configuring the Protocol for a Dynamic SA . . . . . . . . . . . . . . . . . . . . . . . . . . 514
Copyright © 2018, Juniper Networks, Inc.
xiii
Adaptive Services Interfaces Feature Guide for Routing Devices
Configuring IPsec Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514
Configuring the Description for an IPsec Policy . . . . . . . . . . . . . . . . . . . . . . . 515
Configuring Perfect Forward Secrecy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515
Configuring the Proposals in an IPsec Policy . . . . . . . . . . . . . . . . . . . . . . . . . 516
IPsec Policy for Dynamic Endpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517
Example: Configuring an IPsec Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517
Configuring IPsec Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 518
Configuring Match Direction for IPsec Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 519
Configuring Match Conditions in IPsec Rules . . . . . . . . . . . . . . . . . . . . . . . . 520
Configuring Actions in IPsec Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 521
Enabling IPsec Packet Fragmentation . . . . . . . . . . . . . . . . . . . . . . . . . . 522
Configuring Destination Addresses for Dead Peer Detection . . . . . . . . . 522
Configuring or Disabling IPsec Anti-Replay . . . . . . . . . . . . . . . . . . . . . . 524
Enabling System Log Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524
Specifying the MTU for IPsec Tunnels . . . . . . . . . . . . . . . . . . . . . . . . . . 525
Configuring IPsec Rule Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525
Service Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 526
Configuring IPsec Service Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 526
Configuring the Local Gateway Address for IPsec Service Sets . . . . . . . . . . 527
IKE Addresses in VRF Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 527
Clearing SAs When Local Gateway Address or MS-MPC or MS-MIC
Goes Down . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 528
Configuring IKE Access Profiles for IPsec Service Sets . . . . . . . . . . . . . . . . . 528
Configuring Certification Authorities for IPsec Service Sets . . . . . . . . . . . . . 529
Configuring or Disabling Antireplay Service . . . . . . . . . . . . . . . . . . . . . . . . . . 529
Clearing the Do Not Fragment Bit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 530
Configuring Passive-Mode Tunneling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 531
Configuring the Tunnel MTU Value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 532
Configuring IPsec Multipath Forwarding with UDP Encapsulation . . . . . . . . 533
Disabling NAT-T on MX Series Routers for Handling NAT with IPsec-Protected
Packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534
Tracing Junos VPN Site Secure Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535
Disabling IPsec Tunnel Endpoint in Traceroute . . . . . . . . . . . . . . . . . . . . . . . 536
Tracing IPsec PKI Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 537
Multitask Example: Configuring IPsec Services . . . . . . . . . . . . . . . . . . . . . . . . . . 538
Configuring the IKE Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 538
Configuring the IKE Policy (and Referencing the IKE Proposal) . . . . . . . . . . 539
Configuring the IPsec Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 540
Configuring the IPsec Policy (and Referencing the IPsec Proposal) . . . . . . . 541
Configuring the IPsec Rule (and Referencing the IKE and IPsec Policies) . . 541
Configuring IPsec Trace Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543
Configuring the Access Profile (and Referencing the IKE and IPsec
Policies) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543
Configuring the Service Set (and Referencing the IKE Profile and the IPsec
Rule) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544
Example: Configuring Junos VPN Site Secure on MS-MIC and MS-MPC . . . . . . 546
Chapter 35
Enhancing Security with Static IPSec over VRF . . . . . . . . . . . . . . . . . . . . . . 559
Example: Configuring Statically Assigned IPsec Tunnels over a VRF Instance . . 559
xiv
Copyright © 2018, Juniper Networks, Inc.
Table of Contents
Chapter 36
Dynamically Assigning Tunnels Using Junos VPN Site Secure . . . . . . . . . . 567
Configuring Dynamic Endpoints for IPsec Tunnels . . . . . . . . . . . . . . . . . . . . . . . . 567
Authentication Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 568
Implicit Dynamic Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 568
Reverse Route Insertion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 569
Configuring an IKE Access Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 569
Referencing the IKE Access Profile in a Service Set . . . . . . . . . . . . . . . . . . . . 571
Configuring the Interface Identifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 571
Default IKE and IPsec Proposals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 572
Distributing Endpoint IPsec Tunnels Among Services Interfaces . . . . . . . . . 572
Requesting for and Installing a Digital Certificates on Your Router . . . . . . . . . . . 574
Requesting a Digital Certificate—Manual Process . . . . . . . . . . . . . . . . . . . . . 574
Example: Configuring Dynamically Assigned Policy Based Tunnels . . . . . . . . . . 576
Example: Configuring IKE Dynamic SAs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 582
Example: IKE Dynamic SA Configuration with Digital Certificates . . . . . . . . . . . 599
Chapter 37
Enabling IPsec for the Services SDK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 625
Configuring Junos VPN Site Secure or IPSec VPN . . . . . . . . . . . . . . . . . . . . . . . . 625
Part 7
Alleviating Congestion and Controlling Service Using CoS
Chapter 38
Class of Service Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 629
Class of Service Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 629
Chapter 39
Class of Service Configuration Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 631
Restrictions and Cautions for CoS Configuration on Services Interfaces . . . . . . . 631
Configuring CoS Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 632
Configuring Match Direction for CoS Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 633
Configuring Match Conditions In CoS Rules . . . . . . . . . . . . . . . . . . . . . . . . . 633
Configuring Actions in CoS Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 634
Configuring Application Profiles for Use as CoS Rule Actions . . . . . . . . 635
Configuring Reflexive, Revert, and Reverse CoS Rule Actions . . . . . . . . 636
Configuring CoS Session Creation When Packet Received in Non-Matching
Direction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 636
Example: Configuring CoS Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 637
Configuring CoS Rule Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 638
Examples: Configuring CoS on Services Interfaces . . . . . . . . . . . . . . . . . . . . . . . 638
Chapter 40
Configuring Class of Service on LSQ Interfaces . . . . . . . . . . . . . . . . . . . . . . . 641
Link Services Configuration for Junos Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . 641
Configuring CoS Scheduling Queues on Logical LSQ Interfaces . . . . . . . . . . . . . 642
Configuring Scheduler Buffer Size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 644
Configuring Scheduler Priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 644
Configuring Scheduler Shaping Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 644
Configuring Drop Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 645
Configuring CoS Fragmentation by Forwarding Class on LSQ Interfaces . . . . . . 646
Configuring Link Services and CoS on Services PICs . . . . . . . . . . . . . . . . . . . . . . 648
Oversubscribing Interface Bandwidth on LSQ Interfaces . . . . . . . . . . . . . . . . . . . 651
Examples: Oversubscribing an LSQ Interface . . . . . . . . . . . . . . . . . . . . . . . . 655
Copyright © 2018, Juniper Networks, Inc.
xv
Adaptive Services Interfaces Feature Guide for Routing Devices
Configuring Guaranteed Minimum Rate on LSQ Interfaces . . . . . . . . . . . . . . . . . 656
Example: Configuring Guaranteed Minimum Rate . . . . . . . . . . . . . . . . . . . . 659
Part 8
Configuring Inter-Chassis MS-MPC and MS-MIC Redundancy
for NAT and Stateful Firewall
Chapter 41
Configuring Inter-Chassis MS-MPC and MS-MIC Redundancy for NAT and
Stateful Firewall (Release 16.1 and later) . . . . . . . . . . . . . . . . . . . . . . . . . . . 663
Configuring Inter-chassis MS-MPC and MS-MIC Redundancy for NAT and Stateful
Firewall Overview (Release 16.1 and later) . . . . . . . . . . . . . . . . . . . . . . . . . . 663
Inter-Chassis Stateful Synchronization for Long Lived NAT and Stateful Firewall
Flows (MS-MPC, MS-MIC) Overview (Release 16.1 and later) . . . . . . . . . . . 664
Configuring Inter-Chassis Stateful Synchronization for Long Lived NAT and
Stateful Firewall Flows (MS-MPC, MS-MIC) (Release 16.1 and later) . . . . . 665
Example: Inter-Chassis Stateful Synchronization for Long-Lived NAT and Stateful
Firewall Flows (MS-MIC, MS-MPC) (Release 16.1 and later) . . . . . . . . . . . . 667
Service Redundancy Daemon Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 676
Introduction to the Service Redundancy Daemon . . . . . . . . . . . . . . . . . . . . . 677
Service Redundancy Daemon Components . . . . . . . . . . . . . . . . . . . . . . . . . 677
Service Redundancy Daemon Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . 678
Service Redundancy Daemon Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 678
Configuring the Service Redundancy Daemon . . . . . . . . . . . . . . . . . . . . . . . . . . . 679
Configuring Redundancy Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 680
Configuring Redundancy Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 681
Configuring Redundancy Set and Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . 683
Configuring Routing Policies Supporting Redundancy . . . . . . . . . . . . . . . . . 684
Configuring Service Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 685
Using Service Redundancy Daemon Scripts to View and Change the Status of
a Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 685
Chapter 42
Configuring Inter-Chassis Stateful Synchronization for NAT and Stateful
Firewall (Release 15.1 and earlier) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 687
Inter-Chassis High Availability for MS-MIC and MS-MPC (Release 15.1 and
earlier) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 687
Inter-Chassis High Availability for Stateful Firewall and NAPT44 Overview
(MS-MIC, MS-MPC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 687
Configuring Inter-Chassis High Availability for Stateful Firewall and NAPT44
(MS-MPC, MS-MIC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 689
Example: Inter-Chassis Stateful High Availability for NAT and Stateful
Firewall (MS-MIC, MS-MPC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 690
Part 9
Configuring Interface Redundancy and Bundling on LSQ
Interfaces
Chapter 43
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 703
Layer 2 Service Package Capabilities and Interfaces . . . . . . . . . . . . . . . . . . . . . . 703
xvi
Copyright © 2018, Juniper Networks, Inc.
Table of Contents
Chapter 44
Configuring Interface Redundancy with SONET APS and Virtual
Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 705
Configuring LSQ Interface Redundancy Across Multiple Routers Using SONET
APS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 705
Configuring the Association between LSQ and SONET Interfaces . . . . . . . 706
Configuring SONET APS Interoperability with Cisco Systems FRF.16 . . . . . . 707
Restrictions on APS Redundancy for LSQ Interfaces . . . . . . . . . . . . . . . . . . 707
Configuring LSQ Interface Redundancy in a Single Router Using SONET APS . . 708
Configuring LSQ Interface Redundancy in a Single Router Using Virtual
Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 708
Configuring Redundant Paired LSQ Interfaces . . . . . . . . . . . . . . . . . . . . . . . 709
Restrictions on Redundant LSQ Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . 710
Configuring Link State Replication for Redundant Link PICs . . . . . . . . . . . . . . 711
Examples: Configuring Redundant LSQ Interfaces for Failure Recovery . . . . 713
Chapter 45
Enabling Bundling on LSQ Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 719
Inline MLPPP for WAN Interfaces Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 719
Reserving Bundle Bandwidth for Link-Layer Overhead on LSQ Interfaces . . . . . . 721
Configuring Multiclass MLPPP on LSQ Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . 722
Enabling Inline LSQ Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 724
Configuring LSQ Interfaces as NxT1 or NxE1 Bundles Using MLPPP . . . . . . . . . . 726
Example: Configuring an LSQ Interface as an NxT1 Bundle Using MLPPP . . 729
Configuring LSQ Interfaces as NxT1 or NxE1 Bundles Using FRF.16 . . . . . . . . . . . . 731
Example: Configuring an LSQ Interface as an NxT1 Bundle Using FRF.16 . . . 735
Configuring LSQ Interfaces as NxT1 or NxE1 Bundles Using FRF.15 . . . . . . . . . . . . 737
Configuring LSQ Interfaces for Single Fractional T1 or E1 Interfaces Using MLPPP
and LFI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 738
Example: Configuring an LSQ Interface for a Fractional T1 Interface Using
MLPPP and LFI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 741
Configuring LSQ Interfaces for Single Fractional T1 or E1 Interfaces Using
FRF.12 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 743
Examples: Configuring an LSQ Interface for a Fractional T1 Interface Using
FRF.12 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 746
Configuring LSQ Interfaces for T3 Links Configured for Compressed RTP over
MLPPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 750
Configuring LSQ Interfaces as T3 or OC3 Bundles Using FRF.12 . . . . . . . . . . . . . . 752
Configuring LSQ Interfaces for ATM2 IQ Interfaces Using MLPPP . . . . . . . . . . . . 754
Part 10
Distributing Traffic Among Next-Hop Servers with Traffic Load
Balancer
Chapter 46
Configuring Traffic Load Balancer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 759
Traffic Load Balancer Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 759
Traffic Load Balancer Application Description . . . . . . . . . . . . . . . . . . . . . . . 759
Traffic Load Balancer Modes of Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 760
Transparent Mode Layer 2 Direct Server Return . . . . . . . . . . . . . . . . . . . 760
Translated Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 760
Transparent Mode Layer 3 Direct Server Return . . . . . . . . . . . . . . . . . . . 761
Traffic Load Balancer Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 761
Copyright © 2018, Juniper Networks, Inc.
xvii
Adaptive Services Interfaces Feature Guide for Routing Devices
Traffic Load Balancer Application Components . . . . . . . . . . . . . . . . . . . . . . 762
Servers and Server Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 762
Server Health Monitoring — Single Health Check and Dual Health
Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 762
Virtual Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 764
Traffic Load Balancer Configuration Limits . . . . . . . . . . . . . . . . . . . . . . . . . . 764
Configuring TLB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 765
Loading the TLB Service Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 765
Configuring a TLB Instance Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 766
Configuring Interface and Routing Information . . . . . . . . . . . . . . . . . . . . . . . 766
Configuring Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 767
Configuring Network Monitoring Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 768
Configuring Server Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 769
Configuring Virtual Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 770
Configuring Tracing for the Health Check Monitoring Function . . . . . . . . . . . 772
Part 11
Enabling Load Balancing and High Availability Using Multiservices
Interfaces
Chapter 47
Enabling Load Balancing and High Availability Using Multiservices
Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 777
Understanding Aggregated Multiservices Interfaces . . . . . . . . . . . . . . . . . . . . . . . 777
Aggregated Multiservices Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 777
IPv6 Traffic on AMS Interfaces Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 780
Member Failure Options and High Availability Settings . . . . . . . . . . . . . . . . 782
Warm Standby Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 783
Configuring Aggregated Multiservices Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . 784
Configuring Load Balancing on AMS Infrastructure . . . . . . . . . . . . . . . . . . . . . . . 786
Configuring AMS Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 786
Configuring High Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 787
Load Balancing Network Address Translation Flows . . . . . . . . . . . . . . . . . . 788
Configuring Warm Standby for Services Interfaces . . . . . . . . . . . . . . . . . . . . . . . 789
Example: Configuring an Aggregated Multiservices Interface (AMS) . . . . . . . . . 789
Example: Configuring Next-Hop Style Services on an Aggregated Multiservices
Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 795
Example: Configuring Static Source Translation on AMS Infrastructure . . . . . . . 798
Part 12
Handling VoIP and Layer 2 Traffic
Chapter 48
Handling VoIP Traffic Using Voice Services . . . . . . . . . . . . . . . . . . . . . . . . . . 803
Voice Services Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 803
Configuring Services Interfaces for Voice Services . . . . . . . . . . . . . . . . . . . . . . . . 804
Configuring the Logical Interface Address for the MLPPP Bundle . . . . . . . . 804
Configuring Compression of Voice Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . 805
Configuring Delay-Sensitive Packet Interleaving . . . . . . . . . . . . . . . . . . . . . 806
Example: Configuring Compression of Voice Traffic . . . . . . . . . . . . . . . . . . . 806
Configuring Encapsulation for Voice Services . . . . . . . . . . . . . . . . . . . . . . . . . . . 807
xviii
Copyright © 2018, Juniper Networks, Inc.
Table of Contents
Configuring Network Interfaces for Voice Services . . . . . . . . . . . . . . . .
Configuring Voice Services Bundles with MLPPP Encapsulation . .
Configuring the Compression Interface with PPP Encapsulation .
Examples: Configuring Voice Services . . . . . . . . . . . . . . . . . . . . . . . . . .
Chapter 49
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
808
808
808
809
Tunneling PPP Packets Across a Network Using Layer 2 Tunneling . . . . . 813
Layer 2 Tunneling Protocol Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 813
L2TP Services Configuration Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 814
L2TP Minimum Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 815
Configuring L2TP Tunnel Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 817
Configuring Access Profiles for L2TP Tunnel Groups . . . . . . . . . . . . . . . . . . . 817
Configuring the Local Gateway Address and PIC . . . . . . . . . . . . . . . . . . . . . . 818
Configuring Window Size for L2TP Tunnels . . . . . . . . . . . . . . . . . . . . . . . . . . 818
Configuring Timers for L2TP Tunnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 819
Hiding Attribute-Value Pairs for L2TP Tunnels . . . . . . . . . . . . . . . . . . . . . . . . 819
Configuring System Logging of L2TP Tunnel Activity . . . . . . . . . . . . . . . . . . 819
Configuring the Identifier for Logical Interfaces that Provide L2TP Services . . . . 821
Example: Configuring Multilink PPP on a Shared Logical Interface . . . . . . . . 821
AS PIC Redundancy for L2TP Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 823
Examples: Configuring L2TP Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 824
Tracing L2TP Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 827
Part 13
Configuration Statements and Operational Commands
Chapter 50
Configuration Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 833
adaptive-services-pics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 844
address (Interfaces) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 845
address (Services NAT Pool) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 846
address-allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 847
address-pooling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 847
address-range . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 848
aggregation (IDS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 849
allow-ip-options (Services Stateful Firewall) . . . . . . . . . . . . . . . . . . . . . . . . . . . 850
allow-ip-options (IDS MS-MPC and MS-MIC) . . . . . . . . . . . . . . . . . . . . . . . . . . . 851
allow-ipv6-extension-header (IDS MS-MPC and MS-MIC) . . . . . . . . . . . . . . . . 852
allow-multicast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 853
allow-overlapping-nat-pools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 853
anti-replay-window-size (Services IPsec VPN) . . . . . . . . . . . . . . . . . . . . . . . . . . 854
anti-replay-window-size (Services Service Set) . . . . . . . . . . . . . . . . . . . . . . . . . 855
app-mapping-timeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 856
application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 857
application-protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 858
application-profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 860
application-set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 861
application-sets (Services CoS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 861
application-sets (IDS MS-DPC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 862
application-sets (PCP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 862
application-sets (Services NAT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 863
application-sets (Services Stateful Firewall) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 863
applications (Services ALGs) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 864
Copyright © 2018, Juniper Networks, Inc.
xix
Adaptive Services Interfaces Feature Guide for Routing Devices
applications (Services CoS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 864
applications (IDS MS-DPC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 865
applications (PCP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 865
applications (Services NAT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 866
applications (Services Stateful Firewall) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 866
authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 867
authentication-algorithm (Services IKE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 868
authentication-algorithm (Services IPsec) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 869
authentication-method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 871
auxiliary-spi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 872
backup-remote-gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 872
bundle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 873
by-destination (IDS MS-DPC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 874
by-destination (IDS MS-MPC and MS-MIC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 875
by-pair (IDS MS-DPC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 876
by-protocol (IDS MS-MPC and MS-MIC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 877
by-source (IDS MS-DPC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 879
by-source (IDS MS-MPC and MS-MIC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 880
bypass-traffic-on-exceeding-flow-limits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 881
bypass-traffic-on-pic-failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 882
cgn-pic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 882
child-inactivity-timeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 883
cisco-interoperability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 883
class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 884
clat-prefix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 885
clear-dont-fragment-bit (Interfaces GRE Tunnels) . . . . . . . . . . . . . . . . . . . . . . . 886
clear-dont-fragment-bit (Services IPsec VPN) . . . . . . . . . . . . . . . . . . . . . . . . . . 887
clear-dont-fragment-bit (Services NAT Options) . . . . . . . . . . . . . . . . . . . . . . . . 887
clear-dont-fragment-bit (Services Service Set) . . . . . . . . . . . . . . . . . . . . . . . . . 888
clear-ike-sas-on-pic-restart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 888
clear-ipsec-sas-on-pic-restart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 889
compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 889
compression-device (Interfaces) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 890
copy-dont-fragment-bit (Services IPsec VPN) . . . . . . . . . . . . . . . . . . . . . . . . . . 890
copy-dont-fragment-bit (Services Set) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 891
cos-rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 891
data (FTP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 892
dead-peer-detection (Services IPsec VPN) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 893
description (Services IPsec VPN) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 893
destination-address (Services CoS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 894
destination-address (IDS MS-DPC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 894
destination-address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 895
destination-address (PCP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 895
destination-address (Services NAT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 896
destination-address (Services Stateful Firewall) . . . . . . . . . . . . . . . . . . . . . . . . . 897
destination-address-range (IDS MS-DPC)) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 898
destination-address-range (PCP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 899
destination-address-range (Services NAT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 900
destination-address-range (Services Stateful Firewall) . . . . . . . . . . . . . . . . . . . 901
xx
Copyright © 2018, Juniper Networks, Inc.
Table of Contents
destination-pool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 901
destination-port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 902
destination-port (PCP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 903
destination-port range . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 903
destination-prefix (IDS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 904
destination-prefix (Services NAT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 904
destination-prefix-ipv6 (IDS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 905
destination-prefix-list (PCP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 906
destination-prefix-list (Services CoS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 906
destination-prefix-list (Services IDS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 907
destination-prefix-list (Services NAT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 908
destination-prefix-list (Services Stateful Firewall) . . . . . . . . . . . . . . . . . . . . . . . 909
destined-port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 909
deterministic-port-block-allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 910
dh-group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 911
dial-options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 912
direction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 913
disable-natt (Services IPsec VPN) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 914
dns-alg-pool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 915
dns-alg-prefix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 915
drop-member-traffic (Aggregated Multiservices) . . . . . . . . . . . . . . . . . . . . . . . . 916
ds-lite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 917
dscp (Services CoS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 918
dynamic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 919
ecmp-alb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 920
ei-mapping-timeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 921
eif-flow-limit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 921
enable-rejoin (aggregated Multiservices) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 922
encapsulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 923
encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 924
encryption-algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 926
establish-tunnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 927
f-max-period . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 928
facility-override (Service Sets) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 929
facility-override (System Log Reporting) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 930
family (Aggregated Multiservices) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 931
family (Interfaces) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 932
family (Voice Services) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 933
filtering-type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 934
force-entry (IDS MS-DPC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 934
forwarding-class (Services PIC Classifiers) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 935
forwarding-class (Services CoS Fragmentation Properties) . . . . . . . . . . . . . . . . 936
fragment-limit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 937
fragment-threshold (Forwarding Class Maps) . . . . . . . . . . . . . . . . . . . . . . . . . . 938
fragment-threshold (Interfaces LSQ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 939
fragmentation-map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 940
fragmentation-maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 941
from (Services CoS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 942
from (IDS MS-DPC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 943
Copyright © 2018, Juniper Networks, Inc.
xxi
Adaptive Services Interfaces Feature Guide for Routing Devices
from (PCP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 944
from . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 945
from (Services NAT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 946
from (Services Stateful Firewall) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 947
ftp (Services CoS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 948
gate-timeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 949
group (Traffic Load Balancer) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 950
gw-interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 951
hash-keys (Aggregated Multiservices) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 952
hash-keys (Interfaces) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 955
header-integrity-check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 956
hello-interval (L2TP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 957
hide-avps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 958
high-availability-options (Aggregated Multiservices) . . . . . . . . . . . . . . . . . . . . . 959
hint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 960
host (L2TP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 961
host (service-set) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 962
hot-standby . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 963
icmp-code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 964
icmp-fragment-check (IDS MS-MPC and MS-MIC) . . . . . . . . . . . . . . . . . . . . . . 964
icmp-large-packet-check (IDS MS-MPC and MS-MIC) . . . . . . . . . . . . . . . . . . . 965
icmp-type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 965
ids-rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 966
ids-rule-sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 966
ignore-entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 967
ike . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 968
ike-access-profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 969
inactivity-timeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 970
initiate-dead-peer-detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 970
input (Interfaces) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 971
instance (Traffic Load Balancer) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 972
interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 974
interface-service (Services Interfaces) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 975
interfaces (Aggregated Multiservices) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 976
interfaces (Voice Services) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 977
interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 978
ipsec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 979
ipsec-inside-interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 980
ipsec-vpn-options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 981
ipsec-vpn-rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 982
ipv6-multicast-interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 983
l2tp-access-profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 983
land-attack-check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 984
land-attack-check (IDS MS-MPC and MS-MIC) . . . . . . . . . . . . . . . . . . . . . . . . . 985
learn-sip-register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 986
lifetime-seconds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 987
link-layer-overhead . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 988
limit-ports-per-address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 988
load-balance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 989
xxii
Copyright © 2018, Juniper Networks, Inc.
Table of Contents
load-balancing-options (Aggregated Multiservices) . . . . . . . . . . . . . . . . . . . . . . 990
load-balancing-options (Service Set) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 992
local-certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 993
local-gateway (IPSec) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 993
local-gateway (L2TP LNS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 994
local-id . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 995
log-prefix (L2TP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 995
log-prefix (Services) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 996
logging (Services) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 996
logging (IDS MS-DPC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 997
lsq-failure-options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 997
manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 998
many-to-one (Aggregated Multiservices) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 999
mapping-refresh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1000
mapping-timeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1001
mapping-type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1002
match-direction (Services CoS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1002
match-direction (IDS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1003
match-direction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1003
match-direction (Services NAT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1004
match-direction (PCP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1004
match-direction (Services Stateful Firewall) . . . . . . . . . . . . . . . . . . . . . . . . . . . 1005
match-rules-on-reverse-flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1005
max-drop-flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1006
max-flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1007
max-session-creation-rate (Service Set) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1008
max-sessions-per-subscriber . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1009
maximum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1009
maximum-contexts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1010
maximum-send-window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1011
member-failure-options (Aggregated Multiservices) . . . . . . . . . . . . . . . . . . . . . 1012
member-interface (Aggregated Multiservices) . . . . . . . . . . . . . . . . . . . . . . . . . . 1014
message-rate-limit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1015
mlfr-uni-nni-bundles-inline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1016
mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1017
mss (IDS MS-DPC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1018
multi-link-layer-2-inline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1018
multilink-class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1019
multilink-max-classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1020
nat-keepalive (Services IPsec VPN) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1020
nat-options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1021
nat-rule-sets (Service Set) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1022
nat-rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1022
next-hop-service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1023
no-anti-replay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1024
no-anti-replay (Services Service Set) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1025
no-fragmentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1026
no-ipsec-tunnel-in-traceroute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1027
no-nat-traversal (Services IPsec VPN) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1027
Copyright © 2018, Juniper Networks, Inc.
xxiii
Adaptive Services Interfaces Feature Guide for Routing Devices
no-per-unit-scheduler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1028
no-termination-request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1028
no-translation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1029
one-to-one (Aggregated Multiservices) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1030
output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1031
overload-pool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1031
overload-prefix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1032
passive-mode-tunneling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1033
pba-interim-logging-interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1034
pcp-rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1034
pcp-server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1035
per-unit-scheduler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1036
perfect-forward-secrecy (Services) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1038
pgcp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1039
pgcp-rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1039
pic-boot-timeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1040
policy (Services IKE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1041
policy (IPsec) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1042
pool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1043
pool (Service Interface) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1044
port (Services NAT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1045
port (Services Voice) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1047
port (System Log Messsages) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1047
port-forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1048
port-forwarding-mappings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1049
ports-per-session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1049
post-service-filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1050
ppp-access-profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1051
pre-shared-key (Services IKE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1051
preserve-interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1052
primary (Adaptive Services Interfaces) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1053
primary (Link Services IQ PIC Interfaces) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1053
profile (Traffic Load Balancer) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1054
profile (URL Filter) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1056
proposal (Services IKE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1057
proposal (Services IPsec VPN) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1058
proposals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1058
protocol (Applications) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1059
protocol (IPsec) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1060
ptsp-rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1061
queues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1061
real-service (Traffic Load Balancer) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1062
reassembly-timeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1063
receive-window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1064
redistribute-all-traffic (Aggregated Multiservices) . . . . . . . . . . . . . . . . . . . . . . . 1065
redundancy-event (Services Redundancy Daemon) . . . . . . . . . . . . . . . . . . . . . 1066
redundancy-options (Adaptive Services Interfaces) . . . . . . . . . . . . . . . . . . . . . 1067
redundancy-options (Aggregated Multiservices) . . . . . . . . . . . . . . . . . . . . . . . . 1068
redundancy-options (Link Services IQ PIC Interfaces) . . . . . . . . . . . . . . . . . . . . 1069
xxiv
Copyright © 2018, Juniper Networks, Inc.
Table of Contents
redundancy-options (MS-MIC, MS-MPC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1070
redundancy-policy (Services Redundancy Daemon) . . . . . . . . . . . . . . . . . . . . . 1071
redundancy-set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1072
redundancy-set-id (Service Set) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1073
reflexive | revert | reverse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1074
rejoin-timeout (Aggregated Multiservices) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1075
remote-gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1076
remote-id . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1077
remotely-controlled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1077
respond-bad-spi (Services IKE Policy) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1078
retransmit-interval (Services) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1079
rpc-program-number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1080
routing-engine-services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1081
rtp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1082
rule (Services CoS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1083
rule (IDS MS-DPC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1084
rule (IDS MS-MPC and MS-MIC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1086
rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1088
rule (PCP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1090
rule (Services NAT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1091
rule (Services Stateful Firewall) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1093
rule (Softwire) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1094
rule-set (Services CoS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1095
rule-set (Services IDS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1095
rule-set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1096
rule-set (Services NAT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1096
rule-set (Services Stateful Firewall) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1097
rule-set (Softwire) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1097
secondary (Adaptive Services Interfaces) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1098
secondary (Link Services IQ PIC Interfaces) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1098
secure-nat-mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1099
secured-port-block-allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1100
server (pcp) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1102
service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1104
service-domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1105
service-filter (Interfaces) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1106
service-interface (Services Interfaces) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1106
service-interface (L2TP Processing) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1107
service-interface-pools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1108
service-set (Interfaces) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1108
service-set (Services) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1109
service-set-options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1112
services (NAT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1113
session-limit (IDS MS-DPC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1114
session-limit (IDS MS-MPC and MS-MIC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1115
set-dont-fragment-bit (Services Set) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1117
set-dont-fragment-bit (Services IPsec VPN) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1118
sip-call-hold-timeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1119
sip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1120
Copyright © 2018, Juniper Networks, Inc.
xxv
Adaptive Services Interfaces Feature Guide for Routing Devices
snmp-command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1121
snmp-trap-thresholds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1122
softwire-concentrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1124
softwire-options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1125
softwire-rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1126
source-address (PCP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1127
source-address (Service Sets) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1128
source-address (Services CoS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1129
source-address (IDS MS-DPC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1129
source-address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1130
source-address (Services NAT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1130
source-address (Services Stateful Firewall) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1131
source-address-range (IDS MS-DPC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1132
source-address-range (PCP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1133
source-address-range (Services NAT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1134
source-address-range (Services Stateful Firewall) . . . . . . . . . . . . . . . . . . . . . . . 1135
source-pool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1135
source-port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1136
source-prefix (IDS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1137
source-prefix (Services NAT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1138
source-prefix-ipv6 (IDS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1139
source-prefix-list (PCP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1140
source-prefix-list (Services CoS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1140
source-prefix-list (Services IDS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1141
source-prefix-list (Services NAT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1141
source-prefix-list (Services Stateful Firewall) . . . . . . . . . . . . . . . . . . . . . . . . . . . 1142
spi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1143
stateful-firewall-rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1144
stateful-nat64 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1144
syslog (Services CoS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1145
syslog (IDS MS-DPC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1145
syslog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1146
syslog (Services L2TP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1147
syslog (Services NAT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1147
syslog (Services Service Set) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1148
syslog (Services Stateful Firewall) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1149
syn-cookie (IDS MS-DPC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1150
tcp-fast-open . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1151
tcp-mss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1152
tcp-non-syn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1153
tcp-syn-defense (IDS MS-MPC and MS-MIC) . . . . . . . . . . . . . . . . . . . . . . . . . . . 1154
tcp-syn-fragment-check (IDS MS-MPC and MS-MIC) . . . . . . . . . . . . . . . . . . . . 1154
tcp-winnuke-check (IDS MS-MPC and MS-MIC) . . . . . . . . . . . . . . . . . . . . . . . . 1155
template (URL Filter) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1156
term (Services CoS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1158
term (IDS MS-DPC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1159
term . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1161
term (IDS MS-MPC and MS-MIC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1163
term (PCP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1165
xxvi
Copyright © 2018, Juniper Networks, Inc.
Table of Contents
term (Services NAT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1166
term (Services Stateful Firewall) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1167
term (URL Filter) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1168
then (Services CoS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1169
then (IDS MS-DPC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1170
then (IDS MS-MPC and MS-MIC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1172
then . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1174
then (Services NAT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1175
then (PCP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1176
then (Services Stateful Firewall) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1177
threshold (Services IPsec) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1178
threshold (Services Logging and SYN-Cookie Defenses) . . . . . . . . . . . . . . . . . . 1179
traceoptions (Health Check Monitoring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1180
traceoptions (Security PKI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1182
traceoptions (Services IPsec VPN) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1184
traceoptions (Services L2TP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1186
traceoptions (Services Logging) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1190
traceoptions (Traffic Load Balancer) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1192
traceoptions (Services Redundancy Daemon) . . . . . . . . . . . . . . . . . . . . . . . . . . 1194
traffic-load-balance (Traffic Load Balancer) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1196
translated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1197
transport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1198
trigger-link-failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1198
translated-port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1199
translation-type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1200
trusted-ca . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1202
ttl-threshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1202
tunnel-group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1203
tunnel-mtu (Services IPsec VPN) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1204
tunnel-mtu (Services Service Set) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1205
tunnel-timeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1206
udp-encapsulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1207
unit (Aggregated Multiservices) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1208
unit (Interfaces) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1209
unit (Voice Services) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1210
url-filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1211
url-filter-profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1212
uuid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1213
v6rd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1214
version (IKE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1215
video . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1216
video (Application Profile) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1216
virtual-service (Traffic Load Balancer) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1217
voice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1219
voice (Application Profile) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1219
warm-standby . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1220
Copyright © 2018, Juniper Networks, Inc.
xxvii
Adaptive Services Interfaces Feature Guide for Routing Devices
Chapter 51
Operational Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1221
clear services cos statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1225
clear services crtp statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1226
clear services ids . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1227
clear services ids destination-table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1228
clear services ids pair-table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1229
clear services ids source-table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1230
clear services inline nat pool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1231
clear services inline nat statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1232
clear services inline softwire statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1233
clear services ipsec-vpn certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1234
clear services ipsec-vpn ike security-associations . . . . . . . . . . . . . . . . . . . . . . . 1235
clear services ipsec-vpn ipsec security-associations . . . . . . . . . . . . . . . . . . . . . 1236
clear services ipsec-vpn ipsec statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1237
clear services l2tp destination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1238
clear services l2tp destination statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1240
clear services l2tp multilink . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1241
clear services l2tp session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1242
clear services l2tp session statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1245
clear services l2tp tunnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1247
clear services l2tp tunnel statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1249
clear services nat flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1251
clear services nat mappings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1253
clear services nat mappings app . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1255
clear services nat mappings eim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1257
clear services nat mappings pcp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1259
clear services redundancy-set last-saved-state id . . . . . . . . . . . . . . . . . . . . . . . 1261
clear security pki ca-certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1262
clear security pki certificate-request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1263
clear security pki crl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1264
clear security pki key-pair . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1265
clear security pki local-certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1266
clear services service-set statistics ids drops . . . . . . . . . . . . . . . . . . . . . . . . . . . 1267
clear services service-sets statistics ids session-limits counters . . . . . . . . . . . . 1268
clear services service-sets statistics integrity-drops . . . . . . . . . . . . . . . . . . . . . . 1269
clear services service-sets statistics packet-drops . . . . . . . . . . . . . . . . . . . . . . . 1270
clear services service-sets statistics syslog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1271
clear services sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1272
clear services stateful-firewall flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1275
clear services stateful-firewall sip-call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1278
clear services stateful-firewall sip-register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1281
clear services stateful-firewall statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1284
request interface revert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1285
request interface (revert | switchover) (Adaptive Services) . . . . . . . . . . . . . . . . 1286
request interface switchover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1288
request security pki ca-certificate enroll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1289
request security pki ca-certificate load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1290
request security pki ca-certificate verify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1291
request security pki crl load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1292
xxviii
Copyright © 2018, Juniper Networks, Inc.
Table of Contents
request security pki generate-certificate-request . . . . . . . . . . . . . . . . . . . . . . . . 1293
request security pki generate-key-pair . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1295
request security pki local-certificate enroll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1296
request security pki local-certificate generate-self-signed . . . . . . . . . . . . . . . . 1298
request security pki local-certificate load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1299
request security pki local-certificate verify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1300
request services ipsec-vpn ipsec switch tunnel . . . . . . . . . . . . . . . . . . . . . . . . . . 1301
request services redundancy-set trigger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1302
request services url-filter delete gencfg-data . . . . . . . . . . . . . . . . . . . . . . . . . . . 1303
request services url-filter force dns-resolution . . . . . . . . . . . . . . . . . . . . . . . . . . 1304
request services url-filter update url-filter-database file . . . . . . . . . . . . . . . . . . 1305
request services url-filter validate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1306
show interfaces (Adaptive Services) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1307
show interfaces (Link Services IQ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1315
show interfaces (Redundant Adaptive Services) . . . . . . . . . . . . . . . . . . . . . . . . 1339
show interfaces (Redundant Link Services IQ) . . . . . . . . . . . . . . . . . . . . . . . . . . 1341
show interfaces load-balancing (Aggregated Multiservices) . . . . . . . . . . . . . . . 1355
show interfaces redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1359
show security pki ca-certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1362
show security pki certificate-request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1366
show security pki crl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1368
show security pki local-certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1371
show services alg conversations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1374
show services alg statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1380
show services cos statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1392
show services crtp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1395
show services crtp flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1398
show services ha detail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1400
show services ha statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1402
show services ids . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1407
show services inline nat pool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1415
show services inline nat statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1417
show services inline softwire statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1420
show services ipsec-vpn certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1423
show services ipsec-vpn ike security-associations . . . . . . . . . . . . . . . . . . . . . . . 1426
show services ipsec-vpn ipsec security-associations . . . . . . . . . . . . . . . . . . . . . 1431
show services ipsec-vpn ipsec statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1436
show services link-services cpu-usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1440
show services l2tp multilink . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1444
show services l2tp radius . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1448
show services l2tp session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1452
show services l2tp summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1461
show services l2tp tunnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1467
show services l2tp user . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1473
show services nat deterministic-nat internal-host . . . . . . . . . . . . . . . . . . . . . . . 1477
show services nat deterministic-nat nat-port-block . . . . . . . . . . . . . . . . . . . . . . 1479
show services nat ipv6-multicast-interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . 1480
show services nat mappings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1482
show services nat pool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1487
Copyright © 2018, Juniper Networks, Inc.
xxix
Adaptive Services Interfaces Feature Guide for Routing Devices
show services pcp statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1493
show services redundancy-group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1496
show services service-sets cpu-usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1504
show services service-sets memory-usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1506
show services service-set statistics ids drops . . . . . . . . . . . . . . . . . . . . . . . . . . . 1508
show services service-sets statistics ids session-limits counters . . . . . . . . . . . . 1515
show services service-sets statistics integrity-drops . . . . . . . . . . . . . . . . . . . . . . 1521
show services service-sets statistics packet-drops . . . . . . . . . . . . . . . . . . . . . . 1525
show services service-sets statistics syslog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1527
show services service-sets statistics tcp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1532
show services service-sets statistics tcp-mss . . . . . . . . . . . . . . . . . . . . . . . . . . . 1533
show services service-sets summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1534
show services sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1536
show services sessions (Aggregated Multiservices) . . . . . . . . . . . . . . . . . . . . . . 1544
show services sessions analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1551
show services softwire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1555
show services softwire flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1557
show services softwire statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1560
show services stateful-firewall conversations . . . . . . . . . . . . . . . . . . . . . . . . . . 1566
show services stateful-firewall flow-analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1571
show services stateful-firewall flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1575
show services stateful-firewall sip-call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1581
show services stateful-firewall sip-register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1586
show services stateful-firewall statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1590
show services stateful-firewall statistics application-protocol sip . . . . . . . . . . 1599
show services stateful-firewall subscriber-analysis . . . . . . . . . . . . . . . . . . . . . . 1602
show services subscriber analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1605
show services traffic-load-balance statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . 1608
show services url-filter dns-resolution profile . . . . . . . . . . . . . . . . . . . . . . . . . . . 1619
show services url-filter dns-resolution-statistics profile template . . . . . . . . . . . 1622
show services url-filter statistics profile template . . . . . . . . . . . . . . . . . . . . . . . . 1627
xxx
Copyright © 2018, Juniper Networks, Inc.
List of Figures
Part 1
Overview
Chapter 1
Adaptive Services Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Figure 1: Packet Flow Through the Adaptive Services or MultiServices PIC . . . . . . . 6
Part 2
Translating IP Addresses Using NAT
Chapter 4
NAT Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Figure 2: Dynamic NAT Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Figure 3: Stateful NAT64 Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Figure 4: 464XLAT Wireline Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Figure 5: 464XLAT Wireless Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Figure 6: DS-Lite Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Chapter 6
Avoiding IPv4 Exhaustion Using Junos Address Aware Network Addressing
and Stateful NAT64 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Figure 7: IPv4 Depletion Solution - IPv4 Access Network . . . . . . . . . . . . . . . . . . . 86
Figure 8: IPv4 Depletion Solution - IPv6 Access Network . . . . . . . . . . . . . . . . . . . 86
Chapter 7
Hiding Private Networks Using Static Source NAT . . . . . . . . . . . . . . . . . . . . . 91
Figure 9: Configuring NAT for Multicast Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Chapter 11
Securing Traffic Using NAT-PT and ALGs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Figure 10: Configuring DNS ALGs with NAT-PT Network Topology . . . . . . . . . . . 158
Chapter 12
Providing IPv4 Connectivity Across IPv6-Only Network Using
464XLAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Figure 11: 464XLAT Wireline Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Figure 12: 464XLAT Wireless Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Chapter 13
Reducing Traffic and Bandwidth Requirements Using Port Control
Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
Figure 13: Basic PCP NAPT44 Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
Figure 14: PCP with DS-Lite Plain Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
Figure 15: PCP with NAPT44 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
Chapter 17
Achieving Line-Rate, Low-Latency Translations Using Inline NAT . . . . . . . 219
Figure 16: Supported Inline NAT Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
Figure 17: Inline Source NAT Using an MX Series Device with an MPC . . . . . . . . . 221
Figure 18: Interface-Based Inline Source NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
Figure 19: Inline Source NAT Using an MX Series Device with an MPC . . . . . . . . . 228
Figure 20: Route-Based Inline Source NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
Copyright © 2018, Juniper Networks, Inc.
xxxi
Adaptive Services Interfaces Feature Guide for Routing Devices
Part 3
Transitioning to IPv6 Using Softwires
Chapter 20
Softwires Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
Figure 21: 6rd Softwire Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
Chapter 23
Transitioning to IPv6 Using DS-Lite Softwires . . . . . . . . . . . . . . . . . . . . . . . 283
Figure 22: DS-Lite Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
Part 6
Creating Secure Tunnels Using Junos VPN Site Secure
Chapter 33
Junos VPN Site Secure Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461
Figure 23: AH Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466
Figure 24: ESP Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467
Figure 25: IPsec with One Forwarding Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468
Figure 26: Appended UDP Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468
Figure 27: IPsec with Multiple Forwarding Paths . . . . . . . . . . . . . . . . . . . . . . . . . 469
Chapter 34
Junos VPN Site Secure Configuration Overview . . . . . . . . . . . . . . . . . . . . . . 475
Figure 28: Manual SA Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484
Figure 29: IPsec VPN Tunnel Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 547
Chapter 36
Dynamically Assigning Tunnels Using Junos VPN Site Secure . . . . . . . . . . 567
Figure 30: IPsec Dynamic Endpoint Tunneling Topology . . . . . . . . . . . . . . . . . . . 577
Figure 31: IKE Dynamic SAs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583
Figure 32: MS PIC IKE Dynamic SA Topology Diagram . . . . . . . . . . . . . . . . . . . . 600
Part 8
Configuring Inter-Chassis MS-MPC and MS-MIC Redundancy
for NAT and Stateful Firewall
Chapter 41
Configuring Inter-Chassis MS-MPC and MS-MIC Redundancy for NAT and
Stateful Firewall (Release 16.1 and later) . . . . . . . . . . . . . . . . . . . . . . . . . . . 663
Figure 33: Stateful Sync Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 665
Chapter 42
Configuring Inter-Chassis Stateful Synchronization for NAT and Stateful
Firewall (Release 15.1 and earlier) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 687
Figure 34: Inter-Chassis High Availability Topology . . . . . . . . . . . . . . . . . . . . . . . 688
Part 9
Configuring Interface Redundancy and Bundling on LSQ
Interfaces
Chapter 45
Enabling Bundling on LSQ Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 719
Figure 35: Inline MLPPP for WAN Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 720
Part 10
Distributing Traffic Among Next-Hop Servers with Traffic Load
Balancer
Chapter 46
Configuring Traffic Load Balancer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 759
Figure 36: TLB Topology for Transparent Mode . . . . . . . . . . . . . . . . . . . . . . . . . . 760
Figure 37: TLB Topology for Translated Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . 761
xxxii
Copyright © 2018, Juniper Networks, Inc.
List of Tables
About the Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxvii
Table 1: Notice Icons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxix
Table 2: Text and Syntax Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xl
Part 1
Overview
Chapter 2
Adaptive Services Configuration Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Table 3: System Log Message Severity Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Table 4: Adaptive Services Tracing Flags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Chapter 3
Plug-in Adaptive Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Table 5: URL Filter Database File Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Part 2
Translating IP Addresses Using NAT
Chapter 4
NAT Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Table 6: Carrier-Grade NAT—Feature Comparison by Platform . . . . . . . . . . . . . . . 53
Table 7: Carrier-Grade NAT Translation Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Chapter 9
Allowing Components of a Private Network to Share a Single Address
Using NAPT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Table 8: Comparison of NAPT Implementation Methods . . . . . . . . . . . . . . . . . . . 120
Chapter 10
Mapping Addresses and Ports With Deterministic NAT . . . . . . . . . . . . . . . . 137
Table 9: Deterministic NAPT Commit Constraints . . . . . . . . . . . . . . . . . . . . . . . . 142
Chapter 11
Securing Traffic Using NAT-PT and ALGs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Table 10: ALGs Available for NAT by Type of Interface Card . . . . . . . . . . . . . . . . . 148
Chapter 19
Monitoring NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
Table 11: Arguments for services-oids.slax Script . . . . . . . . . . . . . . . . . . . . . . . . . 263
Part 4
Enabling Traffic to Pass Securely Using ALGs
Chapter 26
ALG Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337
Table 12: ALGs Supported by Junos OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337
Table 13: RealAudio Product Port Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
Table 14: Supported RPC Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
Table 15: ALGs Available for NAT by Type of Interface Card . . . . . . . . . . . . . . . . . 362
Chapter 27
ALGs Configuration Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367
Table 16: Application Protocols Supported by Services Interfaces . . . . . . . . . . . 368
Table 17: Network Protocols Supported by Services Interfaces . . . . . . . . . . . . . . . 371
Table 18: ICMP Codes and Types Supported by Services Interfaces . . . . . . . . . . 372
Copyright © 2018, Juniper Networks, Inc.
xxxiii
Adaptive Services Interfaces Feature Guide for Routing Devices
Table 19: Port Names Supported by Services Interfaces . . . . . . . . . . . . . . . . . . . 373
Table 20: Requesting Messages with NAT Table . . . . . . . . . . . . . . . . . . . . . . . . . 382
Part 5
Securing Content Using Junos Network Secure and IDS
Chapter 29
Junos Network Secure Configuration Overview . . . . . . . . . . . . . . . . . . . . . . 403
Table 21: IP Option Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408
Part 6
Creating Secure Tunnels Using Junos VPN Site Secure
Chapter 33
Junos VPN Site Secure Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461
Table 22: Statement Equivalents for ES and AS Interfaces . . . . . . . . . . . . . . . . . 463
Chapter 36
Dynamically Assigning Tunnels Using Junos VPN Site Secure . . . . . . . . . . 567
Table 23: Default IKE and IPsec Proposals for Dynamic Negotiations . . . . . . . . . 572
Part 10
Distributing Traffic Among Next-Hop Servers with Traffic Load
Balancer
Chapter 46
Configuring Traffic Load Balancer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 759
Table 24: TLB Configuration Limits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 764
Table 25: Trace Flags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 773
Part 11
Enabling Load Balancing and High Availability Using Multiservices
Interfaces
Chapter 47
Enabling Load Balancing and High Availability Using Multiservices
Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 777
Table 26: Key Configuration Statements Used in this Example . . . . . . . . . . . . . . 792
Part 12
Handling VoIP and Layer 2 Traffic
Chapter 49
Tunneling PPP Packets Across a Network Using Layer 2 Tunneling . . . . . 813
Table 27: System Log Message Severity Levels . . . . . . . . . . . . . . . . . . . . . . . . . . 820
Part 13
Configuration Statements and Operational Commands
Chapter 50
Configuration Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 833
Table 28: Hash Keys Supported for AMS for Service Applications . . . . . . . . . . . 953
Table 29: Behavior of Member Interface After One Multiservices PIC Fails . . . . 1012
Table 30: Behavior of Member Interface After Two Multiservices PICs Fail . . . . 1013
Chapter 51
Operational Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1221
Table 31: clear services nat flows Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . 1251
Table 32: clear services nat mappings Output Fields . . . . . . . . . . . . . . . . . . . . . 1253
Table 33: clear services nat mappings app Output Fields . . . . . . . . . . . . . . . . . . 1255
Table 34: clear services nat mappings eim Output Fields . . . . . . . . . . . . . . . . . . 1258
Table 35: clear services nat mappings pcp Output Fields . . . . . . . . . . . . . . . . . . 1259
Table 36: clear services sessions Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . 1274
Table 37: clear services stateful-firewall flows Output Fields . . . . . . . . . . . . . . . 1276
Table 38: clear services stateful-firewall sip-call Output Fields . . . . . . . . . . . . 1280
xxxiv
Copyright © 2018, Juniper Networks, Inc.
List of Tables
Table 39: clear services stateful-firewall sip-register Output Fields . . . . . . . . . 1283
Table 40: Adaptive Services and Redundant Adaptive Services show interfaces
Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1307
Table 41: show interfaces (Link Services IQ) Output Fields . . . . . . . . . . . . . . . . . 1316
Table 42: show interfaces (Redundant Link Services IQ) Output Fields . . . . . . 1342
Table 43: Aggregated Multiservices show interfaces load-balancing Output
Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1355
Table 44: show interfaces redundancy Output Fields . . . . . . . . . . . . . . . . . . . . . 1359
Table 45: show security pki ca-certificate Output Fields . . . . . . . . . . . . . . . . . . 1362
Table 46: show security pki certificate-request Output Fields . . . . . . . . . . . . . . 1366
Table 47: show security pki crl Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . 1368
Table 48: show security pki local-certificate Output Fields . . . . . . . . . . . . . . . . . 1371
Table 49: show services alg conversations Output Fields . . . . . . . . . . . . . . . . . . 1375
Table 50: show services alg statistics Output Fields . . . . . . . . . . . . . . . . . . . . . . 1381
Table 51: show services cos statistics Output Fields . . . . . . . . . . . . . . . . . . . . . . 1392
Table 52: show services crtp Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1395
Table 53: show services crtp flows Output Fields . . . . . . . . . . . . . . . . . . . . . . . . 1398
Table 54: show services ha detail Output Fields . . . . . . . . . . . . . . . . . . . . . . . . 1400
Table 55: show services ha statistics Output Fields . . . . . . . . . . . . . . . . . . . . . . 1402
Table 56: show services ids Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1408
Table 57: show services inline nat pool Output Fields . . . . . . . . . . . . . . . . . . . . . 1415
Table 58: show services inline nat statistics Output Fields . . . . . . . . . . . . . . . . . 1417
Table 59: show services inline softwire statistics Output Fields . . . . . . . . . . . . 1420
Table 60: show services ipsec-vpn certificates Output Fields . . . . . . . . . . . . . . 1423
Table 61: show services ipsec-vpn ike security-associations Output Fields . . . . 1426
Table 62: show services ipsec-vpn ipsec security-associations Output Fields . . 1431
Table 63: show services ipsec-vpn ipsec statistics Output Fields . . . . . . . . . . . 1436
Table 64: show services link-services cpu-usage Output Fields . . . . . . . . . . . . 1440
Table 65: show services l2tp multilink Output Fields . . . . . . . . . . . . . . . . . . . . . 1444
Table 66: show services l2tp radius Output Fields . . . . . . . . . . . . . . . . . . . . . . . 1448
Table 67: show services l2tp session Output Fields . . . . . . . . . . . . . . . . . . . . . . 1453
Table 68: show services l2tp summary Output Fields . . . . . . . . . . . . . . . . . . . . . 1461
Table 69: show services l2tp tunnel Output Fields . . . . . . . . . . . . . . . . . . . . . . . 1468
Table 70: show services l2tp user Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . 1473
Table 71: show services nat deterministic-nat internal-host Output Fields . . . . 1477
Table 72: show services nat deterministic-nat nat-port-block Output Fields . . 1479
Table 73: show services nat ipv6-multicast-interfaces Output Fields . . . . . . . . 1480
Table 74: show services nat mappings Output Fields . . . . . . . . . . . . . . . . . . . . . 1483
Table 75: show services nat pool Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . 1488
Table 76: show services pcp statistics Output Fields . . . . . . . . . . . . . . . . . . . . . 1493
Table 77: show services redundancy-group Output Fields . . . . . . . . . . . . . . . . . 1496
Table 78: show services service-sets cpu-usage Output Fields . . . . . . . . . . . . . 1504
Table 79: show services service-sets memory-usage Output Fields . . . . . . . . . 1506
Table 80: show services service-set statistics ids drops Output Fields . . . . . . . 1508
Table 81: show services service-sets statistics ids session-limits counters Output
Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1515
Table 82: show services service-sets integrity-drops Output Fields . . . . . . . . . . 1521
Table 83: show services service-sets packet-drops Output Fields . . . . . . . . . . . 1525
Table 84: show services service-sets statistics syslog Output Fields . . . . . . . . . 1527
Copyright © 2018, Juniper Networks, Inc.
xxxv
Adaptive Services Interfaces Feature Guide for Routing Devices
Table 85: show services service-sets statistics tcp-mss Output Fields . . . . . . . 1533
Table 86: show services service-sets summary Output Fields . . . . . . . . . . . . . . 1534
Table 87: show services sessions Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . 1539
Table 88: show services sessions Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . 1546
Table 89: show services sessions analysis Output Fields . . . . . . . . . . . . . . . . . . 1551
Table 90: show-services-softwire Output Fields . . . . . . . . . . . . . . . . . . . . . . . . 1555
Table 91: show services softwire flows Output Fields . . . . . . . . . . . . . . . . . . . . . 1558
Table 92: command-name Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1560
Table 93: show services stateful-firewall conversations Output Fields . . . . . . . 1568
Table 94: show services stateful-firewall flow-analysis Output Fields . . . . . . . . 1571
Table 95: show services stateful-firewall flows Output Fields . . . . . . . . . . . . . . 1577
Table 96: show services stateful-firewall sip-call Output Fields . . . . . . . . . . . . 1583
Table 97: show services stateful-firewall sip-register Output Fields . . . . . . . . . 1588
Table 98: show services stateful-firewall statistics Output Fields . . . . . . . . . . 1590
Table 99: show services stateful-firewall statistics application-protocol-sip
Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1599
Table 100: show services stateful-firewall subscriber-analysis Output Fields . . 1602
Table 101: show services subscriber analysis Output Fields . . . . . . . . . . . . . . . . 1605
Table 102: show services traffic-load-balance statistics Output Fields . . . . . . 1609
Table 103: show services url-filter dns-resolution profile Output Fields . . . . . . . 1619
Table 104: show services url-filter dns-resolution-statistics profile template
Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1622
Table 105: show services url-filter statistics profile template Output Fields . . . 1627
xxxvi
Copyright © 2018, Juniper Networks, Inc.
About the Documentation
•
Documentation and Release Notes on page xxxvii
•
Supported Platforms on page xxxvii
•
Using the Examples in This Manual on page xxxvii
•
Documentation Conventions on page xxxix
•
Documentation Feedback on page xli
•
Requesting Technical Support on page xli
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:
•
M Series
•
MX Series
•
T Series
Using the Examples in This Manual
If you want to use the examples in this manual, you can use the load merge or the load
merge relative command. These commands cause the software to merge the incoming
configuration into the current candidate configuration. The example does not become
active until you commit the candidate configuration.
Copyright © 2018, Juniper Networks, Inc.
xxxvii
Adaptive Services Interfaces Feature Guide for Routing Devices
If the example configuration contains the top level of the hierarchy (or multiple
hierarchies), the example is a full example. In this case, use the load merge command.
If the example configuration does not start at the top level of the hierarchy, the example
is a snippet. In this case, use the load merge relative command. These procedures are
described in the following sections.
Merging a Full Example
To merge a full example, follow these steps:
1.
From the HTML or PDF version of the manual, copy a configuration example into a
text file, save the file with a name, and copy the file to a directory on your routing
platform.
For example, copy the following configuration to a file and name the file ex-script.conf.
Copy the ex-script.conf file to the /var/tmp directory on your routing platform.
system {
scripts {
commit {
file ex-script.xsl;
}
}
}
interfaces {
fxp0 {
disable;
unit 0 {
family inet {
address 10.0.0.1/24;
}
}
}
}
2. Merge the contents of the file into your routing platform configuration by issuing the
load merge configuration mode command:
[edit]
user@host# load merge /var/tmp/ex-script.conf
load complete
Merging a Snippet
To merge a snippet, follow these steps:
1.
From the HTML or PDF version of the manual, copy a configuration snippet into a text
file, save the file with a name, and copy the file to a directory on your routing platform.
For example, copy the following snippet to a file and name the file
ex-script-snippet.conf. Copy the ex-script-snippet.conf file to the /var/tmp directory
on your routing platform.
commit {
xxxviii
Copyright © 2018, Juniper Networks, Inc.
About the Documentation
file ex-script-snippet.xsl; }
2. Move to the hierarchy level that is relevant for this snippet by issuing the following
configuration mode command:
[edit]
user@host# edit system scripts
[edit system scripts]
3. Merge the contents of the file into your routing platform configuration by issuing the
load merge relative configuration mode command:
[edit system scripts]
user@host# load merge relative /var/tmp/ex-script-snippet.conf
load complete
For more information about the load command, see CLI Explorer.
Documentation Conventions
Table 1 on page xxxix defines notice icons used in this 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.
Tip
Indicates helpful information.
Best practice
Alerts you to a recommended use or implementation.
Table 2 on page xl defines the text and syntax conventions used in this guide.
Copyright © 2018, Juniper Networks, Inc.
xxxix
Adaptive Services Interfaces Feature Guide for Routing Devices
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
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.
< > (angle brackets)
Encloses optional keywords or variables.
stub <default-metric metric>;
| (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.
Text like this
[edit]
root@# set system domain-name
domain-name
(string1 | string2 | string3)
[edit]
routing-options {
static {
route default {
nexthop address;
retain;
}
}
}
GUI Conventions
xl
Copyright © 2018, Juniper Networks, Inc.
About the Documentation
Table 2: Text and Syntax Conventions (continued)
Convention
Description
Examples
Bold text like this
Represents graphical user interface (GUI)
items you click or select.
•
In the Logical Interfaces box, select
All Interfaces.
•
To cancel the configuration, click
Cancel.
> (bold right angle bracket)
Separates levels in a hierarchy of menu
selections.
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 provide feedback by using either of the following
methods:
•
Online feedback rating system—On any page of the Juniper Networks TechLibrary site
at http://www.juniper.net/techpubs/index.html, simply click the stars to rate the content,
and use the pop-up form to provide us with information about your experience.
Alternately, you can use the online feedback form at
http://www.juniper.net/techpubs/feedback/.
•
E-mail—Send your comments to techpubs-comments@juniper.net. Include the document
or topic name, URL or page number, and software 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 Partner Support Service
support contract, 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:
Copyright © 2018, Juniper Networks, Inc.
xli
Adaptive Services Interfaces Feature Guide for Routing Devices
•
Find CSC offerings: http://www.juniper.net/customers/support/
•
Search for known bugs: https://prsearch.juniper.net/
•
Find product documentation: http://www.juniper.net/documentation/
•
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:
http://kb.juniper.net/InfoCenter/
•
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://entitlementsearch.juniper.net/entitlementsearch/
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.
xlii
Copyright © 2018, Juniper Networks, Inc.
PART 1
Overview
•
Adaptive Services Overview on page 3
•
Adaptive Services Configuration Overview on page 7
•
Plug-in Adaptive Services on page 33
Copyright © 2018, Juniper Networks, Inc.
1
Adaptive Services Interfaces Feature Guide for Routing Devices
2
Copyright © 2018, Juniper Networks, Inc.
CHAPTER 1
Adaptive Services Overview
•
Adaptive Services Overview on page 3
•
Packet Flow Through the Adaptive Services or Multiservices PIC on page 5
Adaptive Services Overview
MultiServices PICs and MultiServices Dense Port Concentrators (MS-DPCs) provide
adaptive services interfaces, which allow you to coordinate multiple services on a single
PIC by configuring a set of services and applications. MultiServices PICs and MS-DPCs
offer a special range of services you configure in one or more service sets.
The MultiServices PIC is available in three versions, the MultiServices 100, the
MultiServices 400, and the MultiServices 500, which differ in memory size and
performance. All versions offer enhanced performance in comparison with AS PICs.
MultiServices PICs are supported on M Series and T Series routers except M20 routers.
The MultiServices DPC is available for MX Series routers; it includes a subset of the
functionality supported on the MultiServices PIC. Currently the MultiServices DPC supports
the following Layer 3 services: stateful firewall, NAT, IDS, IPsec, active flow monitoring,
RPM, and generic routing encapsulation (GRE) tunnels (including GRE key and
fragmentation); it also supports graceful Routing Engine switchover (GRES) and Dynamic
Applicaton Awareness for Junos OS. For more information about supported packages,
see Enabling Service Packages.
It is also possible to group several Multiservices PICs into an aggregated Multiservices
(AMS) system. An AMS configuration eliminates the need for separate routers within a
system. The primary benefit of having an AMS configuration is the ability to support load
balancing of traffic across multiple services PICs. Starting with Junos OS 11.4, all MX
Series routers will support high availability (HA) and Network Address Translation (NAT)
on AMS infrastructure. See “Configuring Load Balancing on AMS Infrastructure” on page 786
for more information.
NOTE: The MultiServices PICs are polling based and not interrupt based; as
a result, a high value in the show chassis pic “Interrupt load average” field may
not mean that the PIC has reached its maximum limit of processing.
Copyright © 2018, Juniper Networks, Inc.
3
Adaptive Services Interfaces Feature Guide for Routing Devices
The following services are configured within a service set and are available only on
adaptive services interfaces:
•
Stateful firewall—A type of firewall filter that considers state information derived from
previous communications and other applications when evaluating traffic.
•
Network Address Translation (NAT)—A security procedure for concealing host
addresses on a private network behind a pool of public addresses.
•
Intrusion detection service (IDS)—A set of tools for detecting, redirecting, and preventing
certain kinds of network attack and intrusion.
•
IP Security (IPsec)—A set of tools for configuring manual or dynamic security
associations (SAs) for encryption of data traffic.
•
Class of service (CoS)—A subset of CoS functionality for services interfaces, limited
to DiffServ code point (DSCP) marking and forwarding-class assignment. CoS BA
classification is not supported on services interfaces.
The configuration for these services comprises a series of rules that you can arrange in
order of precedence as a rule set. Each rule follows the structure of a firewall filter, with
a from statement containing input or match conditions and a then statement containing
actions to be taken if the match conditions are met.
The following services are also configured on the MultiServices PICs and MS-DPCs, but
do not use the rule set definition:
•
Layer 2 Tunneling Protocol (L2TP)—A tool for setting up secure tunnels using
Point-to-Point Protocol (PPP) encapsulation across Layer 2 networks.
•
Link Services Intelligent Queuing (LSQ)—Interfaces that support Junos OS
class-of-service (CoS) components, link fragmentation and interleaving (LFI) (FRF.12),
Multilink Frame Relay (MLFR) user-to-network interface (UNI) network-to-network
interface (NNI) (FRF.16), and Multilink PPP (MLPPP).
•
Voice services—A feature that uses the Compressed Real-Time Transport Protocol
(CRTP) to enable voice over IP traffic to use low-speed links more effectively.
In addition, Junos OS includes the following tools for configuring services:
•
Application protocols definition—Allows you to configure properties of application
protocols that are subject to processing by router services, and group the application
definitions into application sets.
•
Service-set definition—Allows you to configure combinations of directional rules and
default settings that control the behavior of each service in the service set.
NOTE: Logging of adaptive services interfaces messages to an external
server by means of the fxp0 port is not supported on M Series routers. The
architecture does not support system logging traffic out of a management
interface. Instead, access to an external server is supported on a Packet
Forwarding Engine interface.
4
Copyright © 2018, Juniper Networks, Inc.
Chapter 1: Adaptive Services Overview
Related
Documentation
•
Understanding Services PICs
•
Packet Flow Through the Adaptive Services or Multiservices PIC on page 5
•
Enabling Service Packages
•
Services Configuration Procedure
•
Supported Platforms
Packet Flow Through the Adaptive Services or Multiservices PIC
You can optionally configure service sets to be applied at one of the following three
points while the packets transit the router:
•
An interface service set applied at the inbound interface.
•
A next-hop service set applied at the forwarding table.
•
An interface service set applied at the outbound interface.
The packet flow is as follows, graphically displayed in Figure 1 on page 6. (You can
configure a service set as either an interface service set or a next-hop service set.)
1.
Packets enter the router on the inbound interface.
2. A policer, filter, service filter, service set, postservice filter, and input forwarding-table
filter are applied sequentially to the traffic; these are all optional items in the
configuration. If an interface service set is applied, the packets are forwarded to the
AS or MultiServices PIC for services processing and then sent back to the Packet
Forwarding Engine; if a service filter is also applied, only packets matching the service
filter are sent to the PIC. The optional postservice filter is applied and postprocessing
takes place.
3. A next-hop service set can be applied to the VPN routing and forwarding (VRF) table
or to inet.0. If it is applied, packets are sent to the PIC for services processing and sent
back to the Packet Forwarding Engine.
NOTE: For NAT, the next-hop service set can only be applied to the VRF
table. For all other services, the next-hop service set can be applied to
either the VRF table or to inet.0.
4. On the output interface, an output filter, output policer, and interface service set can
be applied sequentially to the traffic if you have configured any of these items. If an
interface service set is applied, the traffic is forwarded to the PIC for processing and
sent back to the Packet Forwarding Engine, which then forwards the traffic.
5. Packets exit the router.
Copyright © 2018, Juniper Networks, Inc.
5
Adaptive Services Interfaces Feature Guide for Routing Devices
Figure 1: Packet Flow Through the Adaptive Services or MultiServices PIC
NOTE: When an AS PIC experiences persistent back pressure as a result of
high traffic volume for 3 seconds, the condition triggers an automatic core
dump and reboot of the PIC to help clear the blockage. A system log message
at level LOG_ERR is generated. This mechanism applies to both Layer 2 and
Layer 3 service packages.
Related
Documentation
6
•
Understanding Services PICs
•
Adaptive Services Overview on page 3
•
Supported Platforms
•
Services Configuration Procedure
Copyright © 2018, Juniper Networks, Inc.
CHAPTER 2
Adaptive Services Configuration Overview
•
Understanding Service Sets on page 7
•
Configuring Service Sets to be Applied to Services Interfaces on page 9
•
Configuring Service Rules on page 14
•
Configuring Service Set Limitations on page 15
•
Configuring Service Interface Pools on page 16
•
Enabling Services PICs to Accept Multicast Traffic on page 17
•
Applying Filters and Services to Interfaces on page 17
•
Example: Configuring Service Sets on page 19
•
Configuring AS or Multiservices PIC Redundancy on page 20
•
Examples: Configuring Services Interfaces on page 22
•
Configuring the Address and Domain for Services Interfaces on page 24
•
Configuring System Logging for Service Sets on page 26
•
Tracing Services PIC Operations on page 28
•
Configuring Fragmentation Control for MS-DPC and MS-PIC Service
Interfaces on page 30
Understanding Service Sets
Junos OS enables you to create service sets that define a collection of services to be
performed by an Adaptive Services interface (AS) or Multiservices line cards (MS-DPC,
MS-MIC, and MS-MPC). You can configure the service set either as an interface-style
service set or as a next-hop-style service set.
An interface service set is used as an action modifier across an entire interface. You can
use an interface-style service set when you want to apply services to packets passing
through an interface.
A next-hop service set is a route-based method of applying a particular service. Only
packets destined for a specific next hop are serviced by the creation of explicit static
routes. This configuration is useful when services need to be applied to an entire virtual
private network (VPN) routing and forwarding (VRF) table, or when routing decisions
determine that services need to be performed. When a next-hop service is configured,
the service interface is considered to be a two-legged module with one leg configured
Copyright © 2018, Juniper Networks, Inc.
7
Adaptive Services Interfaces Feature Guide for Routing Devices
to be the inside interface (inside the network) and the other configured as the outside
interface (outside the network).
To configure service sets, include the following statements at the [edit services] hierarchy
level:
[edit services]
service-set service-set-name {
(ids-rules rule-names | ids-rule-sets rule-set-name);
(ipsec-vpn-rules rule-names | ipsec-vpn-rule-sets rule-set-name);
max-session-creation-rate max-setup-rate;
(nat-rules rule-names | nat-rule-sets rule-set-name);
(pgcp-rules rule-names | pgcp-rule-sets rule-set-name);
(ptsp-rules rule-names | ptsp-rule-sets rule-set-name);
(stateful-firewall-rules rule-names | stateful-firewall-rule-sets rule-set-name);
allow-multicast;
extension-service service-name {
provider-specific rules;
}
interface-service {
service-interface interface-name;
}
ipsec-vpn-options {
anti-replay-window-size bits;
clear-dont-fragment-bit;
ike-access-profile profile-name;
local-gateway address;
no-anti-replay;
passive-mode-tunneling;
trusted-ca [ ca-profile-names ];
tunnel-mtu bytes;
}
max-flows number;
next-hop-service {
inside-service-interface interface-name.unit-number;
outside-service-interface interface-name.unit-number;
service-interface-pool name;
}
syslog {
host hostname {
services severity-level;
facility-override facility-name;
log-prefix prefix-value;
}
}
}
adaptive-services-pics {
traceoptions {
file filename <files number> <match regex> <size size> <(world-readable |
no-world-readable)>;
flag flag;
}
}
logging {
traceoptions {
8
Copyright © 2018, Juniper Networks, Inc.
Chapter 2: Adaptive Services Configuration Overview
file filename <files number> <match regex> <size size> <(world-readable |
no-world-readable)>;
flag flag;
}
}
Related
Documentation
•
Configuring Service Sets to be Applied to Services Interfaces on page 9
•
Configuring Service Rules on page 14
•
Configuring IPsec Service Sets on page 526
•
Configuring Service Set Limitations on page 15
•
Configuring System Logging for Service Sets on page 26
•
Enabling Services PICs to Accept Multicast Traffic on page 17
•
Tracing Services PIC Operations on page 28
•
Example: Configuring Service Sets on page 19
Configuring Service Sets to be Applied to Services Interfaces
You configure a services interface to specify the adaptive services interface on which the
service is to be performed. Services interfaces are used with either of the service set types
described in the following sections.
•
Configuring Interface Service Sets on page 9
•
Configuring Next-Hop Service Sets on page 11
•
Determining Traffic Direction on page 12
Configuring Interface Service Sets
An interface service set is used as an action modifier across an entire interface. To
configure the services interface, include the interface-service statement at the
[edit services service-set service-set-name] hierarchy level:
[edit services service-set service-set-name]
interface-service {
service-interface interface-name;
}
Only the device name is needed, because the router software manages logical unit
numbers automatically. The services interface must be an adaptive services interface
for which you have configured unit 0 family inet at the [edit interfaces interface-name
hierarchy level.
When you have defined and grouped the service rules by configuring the service-set
definition, you can apply services to one or more interfaces installed on the router. When
you apply the service set to an interface, it automatically ensures that packets are directed
to the PIC.
Copyright © 2018, Juniper Networks, Inc.
9
Adaptive Services Interfaces Feature Guide for Routing Devices
To associate a defined service set with an interface, include a service-set statement with
the input or output statement at the [edit interfaces interface-name unit logical-unit-number
family inet service] hierarchy level:
[edit interfaces interface-name unit logical-unit-number family inet service]
input {
service-set service-set-name <service-filter filter-name>;
post-service-filter filter-name;
}
output {
service-set service-set-name <service-filter filter-name>;
}
If a packet is entering the interface, the match direction is input. If a packet is leaving the
interface, the match direction is output. The service set retains the input interface
information even after services are applied, so that functions such as filter-class
forwarding and destination class usage (DCU) that depend on input interface information
continue to work.
You configure the same service set on the input and output sides of the interface. You
can optionally include filters associated with each service set to refine the target and
additionally process the traffic. If you include the service-set statement without a
service-filter definition, the router software assumes the match condition is true and
selects the service set for processing automatically.
NOTE: If you configure service sets with filters, they must be configured on
the input and output sides of the interface.
You can include more than one service set definition on each side of the interface. If you
include multiple service sets, the router software evaluates them in the order in which
they appear in the configuration. The system executes the first service set for which it
finds a match in the service filter and ignores the subsequent definitions. A maximum of
six service sets can be applied to an interface. When you apply multiple service sets to
an interface, you must also configure and apply a service filter to the interface.
An additional statement allows you to specify a filter for processing the traffic after the
input service set is executed. To configure this type of filter, include the post-service-filter
statement at the [edit interfaces interface-name unit logical-unit-number family inet service
input] hierarchy level:
post-service-filter filter-name;
The post-service-filter statement is not supported when the service interface is on an
MS-MIC or MS-MPC.
For an example, see “Example: Configuring Service Sets” on page 19.
10
Copyright © 2018, Juniper Networks, Inc.
Chapter 2: Adaptive Services Configuration Overview
NOTE: With interface-style service sets that are configured with Junos OS
extension-provide packages, the traffic fails to get serviced when the ingress
interface is part of a VRF instance and the service interface is not part of the
same VRF instance.
NOTE: When the MultiServices PIC configured for a service set is either
administratively taken offline or undergoes a failure, all the traffic entering
the configured interface with an IDP service set would be dropped without
notification. To avoid this traffic loss, include the bypass-traffic-on-pic-failure
statement at the [edit services service-set service-set-name service-set-options]
hierarchy level. When this statement is configured, the affected packets are
forwarded in the event of a MultiServices PIC failure or offlining, as though
interface-style services were not configured. This issue applies only to Junos
Application Aware (previously known as Dynamic Application Awareness)
configurations using IDP service sets. This forwarding feature worked only
with the Packet Forwarding Engine (PFE) initially. Starting with Junos OS
Release 11.3, the packet-forwarding feature is extended to packets generated
by the Routing Engine for bypass service sets as well.
Configuring Next-Hop Service Sets
A next-hop service set is a route-based method of applying a particular service. Only
packets destined for a specific next hop are serviced by the creation of explicit static
routes. This configuration is useful when services need to be applied to an entire virtual
private network (VPN) routing and forwarding (VRF) table, or when routing decisions
determine that services need to be performed.
When a next-hop service is configured, the AS or Multiservices PIC is considered to be a
two-legged module with one leg configured to be the inside interface (inside the network)
and the other configured as the outside interface (outside the network).
NOTE: You can create IFL indexes greater than 8000 only if the interface
service set is not configured.
To configure the domain, include the service-domain statement at the [edit interfaces
interface-name unit logical-unit-number] hierarchy level:
service-domain (inside | outside);
The service-domain setting must match the configuration for the next-hop service inside
and outside interfaces. To configure the inside and outside interfaces, include the
next-hop-service statement at the [edit services service-set service-set-name] hierarchy
level. The interfaces you specify must be logical interfaces on the same AS PIC. You
cannot configure unit 0 for this purpose, and the logical interface you choose must not
be used by another service set.
Copyright © 2018, Juniper Networks, Inc.
11
Adaptive Services Interfaces Feature Guide for Routing Devices
next-hop-service {
inside-service-interface interface-name.unit-number;
outside-service-interface interface-name.unit-number;
}
Traffic on which the service is applied is forced to the inside interface using a static route.
For example:
routing-options {
static {
route 10.1.2.3 next-hop sp-1/1/0.1;
}
}
After the service is applied, traffic exits by way of the outside interface. A lookup is then
performed in the Packet Forwarding Engine (PFE) to send the packet out of the AS or
Multiservices PIC.
The reverse traffic enters the outside interface, is serviced, and sent to the inside interface.
The inside interface forwards the traffic out of the AS or Multiservices PIC.
Determining Traffic Direction
When you configure next-hop service sets, the AS PIC functions as a two-part interface,
in which one part is the inside interface and the other part is the outside interface. The
following sequence of actions takes place:
1.
To associate the two parts with logical interfaces, you configure two logical interfaces
with the service-domain statement, one with the inside value and one with the outside
value, to mark them as either an inside or outside service interface.
2. The router forwards the traffic to be serviced to the inside interface, using the next-hop
lookup table.
3. After the service is applied, the traffic exits from the outside interface. A route lookup
is then performed on the packets to be sent out of the router.
4. When the reverse traffic returns on the outside interface, the applied service is undone;
for example, IPsec traffic is decrypted or NAT addresses are unmasked. The serviced
packets then emerge on the inside interface, the router performs a route lookup, and
the traffic exits the router.
A service rule’s match direction, whether input, output, or input/output, is applied with
respect to the traffic flow through the AS PIC, not through a specific inside or outside
interface.
When a packet is sent to an AS PIC, packet direction information is carried along with it.
This is true for both interface style and next-hop style service sets.
Interface Style Service Sets
Packet direction is determined by whether a packet is entering or leaving any Packet
Forwarding Engine interface (with respect to the forwarding plane) on which the
interface-service statement is applied. This is similar to the input and output direction
for stateless firewall filters.
12
Copyright © 2018, Juniper Networks, Inc.
Chapter 2: Adaptive Services Configuration Overview
The match direction can also depend on the network topology. For example, you might
route all the external traffic through one interface that is used to protect the other
interfaces on the router, and configure various services on this interface specifically.
Alternatively, you might use one interface for priority traffic and configure special services
on it, but not care about protecting traffic on the other interfaces.
Next-Hop Style Service Sets
Packet direction is determined by the AS PIC interface used to route packets to the AS
PIC. If you use the inside-interface statement to route traffic, then the packet direction
is input. If you use the outside-interface statement to direct packets to the AS PIC, then
the packet direction is output.
The interface to which you apply the service sets affects the match direction. For example,
apply the following configuration:
sp-1/1/0 unit 1 service-domain inside;
sp-1/1/0 unit 2 service-domain outside;
If you configure match-direction input, you include the following statements:
[edit]
services service-set test1 next-hop-service inside-service-interface sp-1/0/0.1;
services service-set test1 next-hop-service outside-service-interface sp-1/0/0.2;
services ipsec-vpn rule test-ipsec-rule match-direction input;
routing-options static route 10.0.0.0/24 next-hop sp-1/1/0.1;
If you configure match-direction output, you include the following statements:
[edit]
services service-set test2 next-hop-service inside-service-interface sp-1/0/0.1;
services service-set test2 next-hop-service outside-service-interface sp-1/0/0.2;
services ipsec-vpn rule test-ipsec-rule match-direction output;
routing-options static route 10.0.0.0/24 next-hop sp-1/1/0.2;
The essential difference between the two configurations is the change in the match
direction and the static routes’ next hop, pointing to either the AS PIC's inside or outside
interface.
Related
Documentation
•
Understanding Service Sets on page 7
•
Configuring Service Rules on page 14
•
Configuring IPsec Service Sets on page 526
•
Configuring Service Set Limitations on page 15
•
Configuring System Logging for Service Sets on page 26
•
Example: Configuring Service Sets on page 19
Copyright © 2018, Juniper Networks, Inc.
13
Adaptive Services Interfaces Feature Guide for Routing Devices
Configuring Service Rules
You specify the collection of rules and rule sets that constitute the service set. The router
performs rule sets in the order in which they appear in the configuration. You can include
only one rule set for each service type. You configure the rule names and content for each
service type at the [edit services name] hierarchy level for each type:
•
You configure intrusion detection service (IDS) rules at the [edit services ids] hierarchy
level; for more information, see “Configuring IDS Rules on an MS-DPC” on page 430 for
MS-DPC cards and “Configuring Protection Against Network Attacks on an MS-MPC
or MS-MIC” on page 448 for MS-MPC cards.
•
You configure IP Security (IPsec) rules at the [edit services ipsec-vpn] hierarchy level;
for more information, see “Understanding Junos VPN Site Secure” on page 461..
•
You configure Network Address Translation (NAT) rules at the [edit services nat]
hierarchy level; for more information, see “Junos Address Aware Network Addressing
Overview” on page 45..
•
You configure packet-triggered subscribers and policy control (PTSP) rules at the [edit
services ptsp] hierarchy level; for more information, see Configuring PTSP Service Rules.
•
You configure softwire rules for DS-Lite or 6rd softwires at the [edit services softwire]
hierarchy level; for more information, see “Configuring Softwire Rules” on page 275.
•
You configure stateful firewall rules at the [edit services stateful-firewall] hierarchy
level; for more information, see “Configuring Stateful Firewall Rules” on page 403.
To configure the rules and rule sets that constitute a service set, include the following
statements at the [edit services service-set service-set-name] hierarchy level:
([ ids-rules rule-names ] |ids-rule-sets rule-set-name);
([ ipsec-vpn-rules rule-names ] | ipsec-vpn-rule-sets rule-set-name);
([ nat-rules rule-names ] | nat-rule-sets rule-set-name);
([ pgcp-rules rule-names] | pgcp-rule-sets rule-set-name);
([softwire-rules rule-names] | softwire-rule-sets rule-set-name);
([ stateful-firewall-rules rule-names ] | stateful-firewall-rule-sets rule-set-name);
For each service type, you can include one or more individual rules, or one rule set.
If you configure a service set with IPsec rules, it must not contain rules for any other
services. You can, however, configure another service set containing rules for the other
services and apply both service sets to the same interface.
14
Copyright © 2018, Juniper Networks, Inc.
Chapter 2: Adaptive Services Configuration Overview
NOTE: You can also include Junos Application Aware (previously known as
Dynamic Application Awareness) functionality within service sets. To do this,
you must include an idp-profile statement at the [edit services service-set]
hierarchy level, along with application identification (APPID) rules, and, as
appropriate, application-aware access list (AACL) rules and a
policy-decision-statistics-profile. Only one service sets can be applied to a
single interface when Junos Application Aware functionality is used. For more
information, see “Configuring IDS Rules on an MS-DPC” on page 430, APPID
Overview, and Application Aware Services Interfaces Feature Guide for Routing
Devices.
Related
Documentation
•
Understanding Service Sets on page 7
•
Configuring Service Sets to be Applied to Services Interfaces on page 9
•
Configuring Service Set Limitations on page 15
•
Configuring System Logging for Service Sets on page 26
Configuring Service Set Limitations
You can set the following limitations on service set capacity:
•
You can limit the maximum number of flows allowed per service set. To configure the
maximum value, include the max-flows statement at the [edit services service-set
service-set-name] hierarchy level:
[edit services service-set service-set-name]
max-flows number;
The max-flows statement permits you to assign a single flow limit value. For IDS service
sets only, you can specify various types of flow limits with a finer degree of control. For
more information, see the description of the session-limit statement in “Configuring
IDS Rule Sets on an MS-DPC” on page 438.
NOTE: When an aggregated multiservices (AMS) interface is configured
as the service interface for a service set, the max-flow value configured for
the service set is applied to each of the member interfaces in the AMS
interface. That is, if you have configured 1000 as the max-flow value for a
service set that uses an AMS interface with four active member interfaces,
each of the member interfaces can handle 1000 flows each, resulting in
an effective max-flow value of 4000.
•
You can limit the maximum segment size (MSS) allowed by the Transmission Control
Protocol (TCP). To configure the maximum value, include the tcp-mss statement at
the [edit services service-set service-set-name] hierarchy level:
[edit services service-set service-set-name]
Copyright © 2018, Juniper Networks, Inc.
15
Adaptive Services Interfaces Feature Guide for Routing Devices
tcp-mss number;
The TCP protocol negotiates an MSS value during session connection establishment
between two peers. The MSS value negotiated is primarily based on the MTU of the
interfaces to which the communicating peers are directly connected to. However in
the network, due to variation in link MTU on the path taken by the TCP packets, some
packets that are still well within the MSS value may be fragmented when the concerned
packet's size exceeds the link's MTU.
If the router receives a TCP packet with the SYN bit and MSS option set and the MSS
option specified in the packet is larger than the MSS value specified by the tcp-mss
statement, the router replaces the MSS value in the packet with the lower value
specified by the tcp-mss statement. The range for the tcp-mss mss-value parameter
is from 536 through 65535.
To view statistics of SYN packets received and SYN packets whose MSS value, is
modified, issue the show services service-sets statistics tcp-mss operational mode
command. For more information on this topic, see the Junos OS Administration Library.
•
You can limit the session setup rate per service set for an MS-MPC. To configure the
maximum setup rate allowed, include the max-session-creation-rate statement at the
[edit services service-set service-set-name] hierarchy level:
[edit services service-set service-set-name]
max-session-creation-rate max-setup-rate;
The maximum session setup rate is the maximum number of session setups allowed
per second. After this rate is reached, any additional session setup attempts are
dropped.
The range for the max-session-creation-rate max-setup-rate is 1 through 429,496,729.
If you do not include the max-session-creation-rate statement, the session setup rate
is not limited.
Related
Documentation
•
Understanding Service Sets on page 7
•
Configuring Service Sets to be Applied to Services Interfaces on page 9
•
Configuring Service Rules on page 14
•
Configuring System Logging for Service Sets on page 26
Configuring Service Interface Pools
To configure a service interface pool, include the following statements at the [edit services
service-interface-pools] hierarchy level:
[edit services service-interface-pools]
pool pool-name {
interface interface-name.unit-number;
}
16
Copyright © 2018, Juniper Networks, Inc.
Chapter 2: Adaptive Services Configuration Overview
Related
Documentation
•
Configuring Service Sets to be Applied to Services Interfaces on page 9
Enabling Services PICs to Accept Multicast Traffic
To allow multicast traffic to be sent to the Adaptive Services or Multiservices PIC, include
the allow-multicast statement at the [edit services service-set service-set-name] hierarchy
level. If this statement is not included, multicast traffic is dropped by default. This
statement applies only to multicast traffic using a next-hop service set; interface service
set configuration is not supported. Only unidirectional flows are created for multicast
packets.
Related
Documentation
•
Understanding Service Sets on page 7
•
Configuring Service Sets to be Applied to Services Interfaces on page 9
•
Configuring Service Rules on page 14
•
Example: Configuring Service Sets on page 19
•
Example: Configuring NAT for Multicast Traffic on page 104
Applying Filters and Services to Interfaces
When you have defined and grouped the service rules by configuring the service-set
definition, you can apply services to one or more interfaces on the router. To associate
a defined service set with an interface, include the service-set statement with the input
or output statement at the [edit interfaces interface-name unit logical-unit-number family
inet service] hierarchy level:
[edit interfaces interface-name unit logical-unit-number family inet service]
input {
service-set service-set-name <service-filter filter-name>;
post-service-filter filter-name;
}
output {
service-set service-set-name <service-filter filter-name>;
}
NOTE: When you enable services on an interface, reverse-path forwarding
is not supported. You cannot configure services on the management interface
(fxp0) or the loopback interface (lo0).
You can configure different service sets on the input and output sides of the interface.
However, for service sets with bidirectional service rules, you must include the same
service set definition in both the input and output statements. Any service set you include
in the service statement must be configured with the interface-service statement at the
[edit services service-set service-set-name] hierarchy level; for more information, see
“Configuring Service Sets to be Applied to Services Interfaces” on page 9.
Copyright © 2018, Juniper Networks, Inc.
17
Adaptive Services Interfaces Feature Guide for Routing Devices
NOTE: If you configure an interface with an input firewall filter that includes
a reject action and with a service set that includes stateful firewall rules, the
router executes the input firewall filter before the stateful firewall rules are
run on the packet. As a result, when the Packet Forwarding Engine sends an
Internet Control Message Protocol (ICMP) error message out through the
interface, the stateful firewall rules might drop the packet because it was
not seen in the input direction.
Possible workarounds are to include a forwarding-table filter to perform the
reject action, because this type of filter is executed after the stateful firewall
in the input direction, or to include an output service filter to prevent the
locally generated ICMP packets from going to the stateful firewall service.
Configuring Service Filters
You can optionally include filters associated with each service set to refine the target
and additionally process the traffic. If you include the service-set statement without a
service-filter definition, the router software assumes that the match condition is true and
selects the service set for processing automatically.
To configure service filters, include the firewall statement at the [edit] hierarchy level:
firewall {
family inet {
service-filter filter-name {
term term-name {
from {
match-conditions;
}
then {
action;
action-modifiers;
}
}
}
}
}
NOTE: You must specify inet as the address family to configure a service
filter.
You configure service filters in a similar way to firewall filters. Service filters have the
same match conditions as firewall filters, but the following specific actions:
18
•
count—Add the packet to a counter total.
•
log—Log the packet.
•
port-mirror—Port-mirror the packet.
•
sample—Sample the packet.
Copyright © 2018, Juniper Networks, Inc.
Chapter 2: Adaptive Services Configuration Overview
•
service—Forward the packet for service processing.
•
skip—Omit the packet from service processing.
For more information about configuring firewall filters, see the Routing Policies, Firewall
Filters, and Traffic Policers Feature Guide.
You can also include more than one service set definition on each side of the interface.
If you include multiple service sets, the router software evaluates them in the order
specified in the configuration. It executes the first service set for which it finds a match
in the service filter and ignores the subsequent definitions.
An additional statement allows you to specify a filter for processing the traffic after the
input service set is executed. To configure this type of filter, include the post-service-filter
statement at the [edit interfaces interface-name unit logical-unit-number family inet service
input] hierarchy level:
post-service-filter filter-name;
NOTE: The software performs postservice filtering only when it has selected
and executed a service set. If the traffic does not meet the match criteria for
any of the configured service sets, the postservice filter is ignored. The
post-service-filter statement is not supported when the service interface is
on an MS-MIC or MS-MPC.
For an example of applying a service set to an interface, see “Examples: Configuring
Services Interfaces” on page 22.
For more information on applying filters to interfaces, see the Junos OS Network Interfaces
Library for Routing Devices. For general information on filters, see the Routing Policies,
Firewall Filters, and Traffic Policers Feature Guide.
NOTE: After NAT processing is applied to packets, they are not subject to
output service filters. The service filters affect only untranslated traffic.
Related
Documentation
•
Understanding Services PICs
•
Configuring Service Sets to be Applied to Services Interfaces on page 9
•
Examples: Configuring Services Interfaces on page 22
Example: Configuring Service Sets
Apply two service sets, my-input-service-set and my-output-service-set, on an
interface-wide basis. All traffic has my-input-service-set applied to it. After the service
set is applied, additional filtering is done using my_post_service_input_filter.
[edit interfaces fe-0/1/0]
unit 0 {
Copyright © 2018, Juniper Networks, Inc.
19
Adaptive Services Interfaces Feature Guide for Routing Devices
family inet {
service {
input {
service-set my-input-service-set;
post-service-filter my_post_service_input_filter;
}
output {
service-set my-output-service-set;
}
}
}
}
Related
Documentation
•
Understanding Service Sets on page 7
•
Configuring Service Sets to be Applied to Services Interfaces on page 9
Configuring AS or Multiservices PIC Redundancy
You can configure AS or Multiservices PIC redundancy on M Series and T Series routers,
except TX Matrix routers, that have multiple AS or Multiservices PICs. To configure
redundancy, you specify a redundancy services PIC (rsp) interface in which the primary
PIC is active and a secondary PIC is on standby. If the primary PIC fails, the secondary
PIC becomes active, and all service processing is transferred to it. If the primary AS or
Multiservices PIC is restored, it remains on standby and does not preempt the secondary
PIC; you need to manually restore the services to the primary PIC. To determine which
PIC is currently active, issue the show interfaces redundancy command.
Failover to the secondary PIC occurs under the following conditions:
•
The primary PIC, FPC, or Packet Forwarding Engine goes down, resets, or is physically
removed from the router.
•
The PIC or FPC is taken offline using the request chassis pic fpc-slot slot-number pic-slot
slot-number offline or request chassis fpc slot slot-number offline command. For more
information, see the CLI Explorer.
•
The driver watchdog timer expires.
•
The request interface switchover command is issued. For more information, see the CLI
Explorer.
NOTE: Adaptive Services and Multiservices PICs in Layer-2 mode (running
Layer 2 services) are not rebooted when a MAC flow-control situation is
detected.
20
Copyright © 2018, Juniper Networks, Inc.
Chapter 2: Adaptive Services Configuration Overview
NOTE: When you perform a switchover from a primary PIC to a secondary
or standby PIC or a revert operation by issuing request interfaces (revert |
switchover) command for redundancy services PICs (rsp), the PIC that was
previously the active PIC before the switchover or reversion is automatically
rebooted. The reboot of the PIC that was previously active and functioning
as the primary PIC does not disrupt traffic forwarding.
The physical interface type rsp specifies the pairings between primary and secondary sp
interfaces to enable redundancy. To configure an AS or Multiservices PIC as the backup,
include the redundancy-options statement at the [edit interfaces rspnumber] hierarchy
level:
[edit interfaces rspnumber]
redundancy-options {
primary sp-fpc/pic/port;
secondary sp-fpc/pic/port;
hot-standby;
}
For the rsp interface, number can be from 0 through 15.
NOTE: You can include a similar redundancy configuration for Link Services
IQ (LSQ) PICs at the [edit interfaces rlsqnumber] hierarchy level. For more
information, see “Configuring LSQ Interface Redundancy in a Single Router
Using Virtual Interfaces” on page 708.
The following constraints apply to redundant AS or Multiservices PIC configurations:
•
The services supported in redundancy configurations include stateful firewall, NAT,
IDS, and IPsec. Services mounted on the AS or Multiservices PIC that use interface
types other than sp- interfaces, such as tunneling and voice services, are not supported.
For information on flow monitoring redundancy, see Configuring Services Interface
Redundancy on M and T Series Routers using Flow Monitoring.
NOTE: For IPsec functionality, the router no longer needs to renegotiate
security associations (SAs) during warm standby PIC switchover. Instead,
the warm standby feature has been made stateful by periodically setting
a checkpoint between the working state of the PIC and the Routing Engine,
which should lessen the downtime during switchover. If you prefer to retain
the earlier behavior, you can include the clear-ipsec-sas-on-pic-restart
statement at the [edit services ipsec-vpn] hierarchy level. If you enable this
capability, the router renegotiates the IPsec SAs on warm standby PIC
switchover. For more information, see “Configuring Security Associations”
on page 477.
•
We recommend that you pair the same model type in RSP configurations, such as two
ASMs or two AS2 PICs. If you pair unlike models, the two PICs may perform differently.
Copyright © 2018, Juniper Networks, Inc.
21
Adaptive Services Interfaces Feature Guide for Routing Devices
Related
Documentation
•
You can specify an AS or Multiservices PIC (sp interface) as the primary for only one
rsp interface.
•
An sp interface can be a secondary for multiple rsp interfaces. However, the same sp
interface cannot be configured as a primary interface in one rsp configuration and as
a secondary in another configuration.
•
When the secondary PIC is active, if another primary PIC that is paired with it in an rsp
configuration fails, no failover takes place.
•
When you configure an AS or Multiservices PIC within a redundant configuration, the
sp interface cannot have any configured services. Apply the configurations at the [edit
interfaces rspnumber] hierarchy level, using, for example, the unit and services-options
statements. Exceptions include the multiservice-options statement used in flow
monitoring configurations, which can be configured separately for the primary and
secondary sp interfaces, and the traceoptions statement.
•
All the operational mode commands that apply to sp interfaces also apply to rsp
interfaces. You can issue show commands for the rsp interface or the primary and
secondary sp interfaces.
•
If a secondary PIC fails while it is in use, the rsp interface returns to the “ not present”
state. If the primary PIC comes up later, service is restored to it.
•
For redundant Multiservices (rms-) interfaces, similar to the configuration of other
bundle interfaces, the properties of the Multiservices (ms-) member interfaces, such
as the logical unit and the address family, are inherited from the underlying rmsinterface. If you previously configured the member ms- interface properties separately,
and attempt to configure the rms- interface properties by using the relevant statements
at the [edit interfaces rmsnumber] hierarchy level, an error occurs when you perform a
commit check operation. You must configure the properties of interfaces that are part
of the rms- interface only by using the statements at the [edit interfaces rmsnumber]
hierarchy level.
•
Understanding Services PICs
•
Examples: Configuring Services Interfaces on page 22
•
Example: Configuring an Aggregated Multiservices Interface (AMS) on page 789
Examples: Configuring Services Interfaces
Apply the my-service-set service set on an interface-wide basis. All traffic that is accepted
by my_input_filter has my-input-service-set applied to it. After the service set is applied,
additional filtering is done using the my_post_service_input_filter filter.
[edit interfaces fe-0/1/0]
unit 0 {
family inet {
filter {
input my_input_filter;
output my_output_filter;
}
22
Copyright © 2018, Juniper Networks, Inc.
Chapter 2: Adaptive Services Configuration Overview
service {
input {
service-set my-input-service-set;
post-service-filter my_post_service_input_filter;
}
output {
service-set my-output-service-set;
}
}
}
}
Configure two redundancy interfaces, rsp0 and rsp1, and associated services.
[edit interfaces]
rsp0 {
redundancy-options {
primary sp-0/0/0;
secondary sp-1/3/0;
}
unit 0 {
family inet;
}
unit 30 {
family inet;
service-domain inside;
}
unit 31 {
family inet;
service-domain outside;
}
}
rsp1 {
redundancy-options {
primary sp-0/1/0;
secondary sp-1/3/0;
}
unit 0 {
family inet;
}
unit 20 {
family inet;
service-domain inside;
}
unit 21 {
family inet;
service-domain outside;
}
}
[edit services]
service-set null-sfw-with-nat {
stateful-firewall-rules allow-all;
nat-rules rule1;
next-hop-service {
inside-service-interface rsp0.30;
outside-service-interface rsp0.31;
Copyright © 2018, Juniper Networks, Inc.
23
Adaptive Services Interfaces Feature Guide for Routing Devices
}
}
[edit routing-instances]
vpna {
interface rsp0.0;
}
Related
Documentation
•
Understanding Services PICs
•
Configuring the Address and Domain for Services Interfaces on page 24
•
Configuring Default Timeout Settings for Services Interfaces
•
Configuring System Logging for Services Interfaces
•
Applying Filters and Services to Interfaces on page 17
•
Example: Configuring an Aggregated Multiservices Interface (AMS) on page 789
Configuring the Address and Domain for Services Interfaces
On the AS or Multiservices PIC, you configure a source address for system log messages
by including the address statement at the [edit interfaces interface-name unit
logical-unit-number family inet] hierarchy level:
address address {
...
}
Assign an IP address to the interface by configuring the address value. The AS or
Multiservices PIC generally supports only IP version 4 (IPv4) addresses configured using
the family inet statement, but IPsec services support IP version 6 (IPv6) addresses as
well, configured using the family inet6 statement.
24
Copyright © 2018, Juniper Networks, Inc.
Chapter 2: Adaptive Services Configuration Overview
NOTE: If you configure the same address on multiple interfaces in the same
routing instance, Junos OS uses only the first configuration, the remaining
address configurations are ignored and can leave interfaces without an
address. Interfaces that do not have an assigned address cannot be used as
a donor interface for an unnumbered Ethernet interface.
For example, in the following configuration the address configuration of
interface xe-0/0/1.0 is ignored:
interfaces {
xe-0/0/0 {
unit 0 {
family inet {
address 192.168.1.1/24;
}
}
}
xe-0/0/1 {
unit 0 {
family inet {
address 192.168.1.1/24;
}
}
}
For more information on configuring the same address on multiple interfaces,
see Configuring the Interface Address.
For information on other addressing properties you can configure that are not specific to
service interfaces, see the Junos OS Network Interfaces Library for Routing Devices.
The service-domain statement specifies whether the interface is used within the network
or to communicate with remote devices. The software uses this setting to determine
which default stateful firewall rules to apply, and to determine the default direction for
service rules. To configure the domain, include the service-domain statement at the [edit
interfaces interface-name unit logical-unit-number] hierarchy level:
service-domain (inside | outside);
If you are configuring the interface in a next-hop service-set definition, the service-domain
setting must match the configuration for the inside-service-interface and
outside-service-interface statements; for more information, see “Configuring Service Sets
to be Applied to Services Interfaces” on page 9.
Related
Documentation
•
Configuring Default Timeout Settings for Services Interfaces
•
Configuring System Logging for Services Interfaces
•
Examples: Configuring Services Interfaces on page 22
•
Example: Configuring an Aggregated Multiservices Interface (AMS) on page 789
Copyright © 2018, Juniper Networks, Inc.
25
Adaptive Services Interfaces Feature Guide for Routing Devices
Configuring System Logging for Service Sets
You specify properties that control how system log messages are generated for the
service set. These values override the values configured at the [edit interfaces
interface-name services-options] hierarchy level.
To configure service-set-specific system logging values, include the syslog statement at
the [edit services service-set service-set-name] hierarchy level:
syslog {
host hostname {
class class-name
facility-override facility-name;
log-prefix prefix-value;
port port-number
services severity-level;
source-address source-address
}
}
Configure the host statement with a hostname or an IP address that specifies the system
log target server. The hostname local directs system log messages to the Routing Engine.
For external system log servers, the hostname must be reachable from the same routing
instance to which the initial data packet (that triggered session establishment) is
delivered. You can specify only one system logging hostname. The source-address
parameter is supported on the ms, rms, and mams interfaces.
Starting in Junos OS Release 17.4R1, you can configure up to a maximum of four system
log servers (combination of local system log hosts and remote system log collectors)
for each service set under [edit services service-set service-set-name] hierarchy level.
NOTE: Junos OS does not support the exporting of system log messages to
an external system log server through the fxp.0 interface; this is because the
high transmission rate of system log messages and the limited bandwidth
of the fxp.0 interface can cause several problems. The external system log
server must be reachable through a routable interface.
Table 3 on page 26 lists the severity levels that you can specify in configuration statements
at the [edit services service-set service-set-name syslog host hostname] hierarchy level.
The levels from emergency through info are in order from highest severity (greatest effect
on functioning) to lowest.
Table 3: System Log Message Severity Levels
26
Severity Level
Description
any
Includes all severity levels
emergency
System panic or other condition that causes the router to stop functioning
Copyright © 2018, Juniper Networks, Inc.
Chapter 2: Adaptive Services Configuration Overview
Table 3: System Log Message Severity Levels (continued)
Severity Level
Description
alert
Conditions that require immediate correction, such as a corrupted system
database
critical
Critical conditions, such as hard drive errors
error
Error conditions that generally have less serious consequences than errors in
the emergency, alert, and critical levels
warning
Conditions that warrant monitoring
notice
Conditions that are not errors but might warrant special handling
info
Events or non-error conditions of interest
We recommend setting the system logging severity level to error during normal operation.
To monitor PIC resource usage, set the level to warning. To gather information about an
intrusion attack when an intrusion detection system error is detected, set the level to
notice for a specific service set. To debug a configuration or log NAT functionality, set
the level to info.
For more information about system log messages, see the System Log Explorer.
To select the class of messages to be logged to the specified system log host, include
the class statement at the [edit services service-set service-set-name syslog host hostname]
hierarchy level:
class class-name;
To use one particular facility code for all logging to the specified system log host, include
the facility-override statement at the [edit services service-set service-set-name syslog
host hostname] hierarchy level:
facility-override facility-name;
The supported facilities are: authorization, daemon, ftp, kernel, user, and local0 through
local7.
To specify a text prefix for all logging to this system log host, include the log-prefix
statement at the [edit services service-set service-set-name syslog host hostname] hierarchy
level:
log-prefix prefix-value;
Related
Documentation
•
Understanding Service Sets on page 7
•
Configuring Service Sets to be Applied to Services Interfaces on page 9
•
Tracing Services PIC Operations on page 28
Copyright © 2018, Juniper Networks, Inc.
27
Adaptive Services Interfaces Feature Guide for Routing Devices
Tracing Services PIC Operations
Tracing operations track all adaptive services operations and record them in a log file.
The logged error descriptions provide detailed information to help you solve problems
faster.
By default, no events are traced. If you include the traceoptions statement at the [edit
services adaptive-services-pics] or [edit services logging] hierarchy level, the default
tracing behavior is the following:
•
Important events are logged in a file called serviced located in the /var/log directory.
•
When the file serviced reaches 128 kilobytes (KB), it is renamed serviced.0, then
serviced.2, and so on, until there are three trace files. Then the oldest trace file
(serviced.2) is overwritten. (For more information about how log files are created, see
the System Log Explorer.)
•
Log files can be accessed only by the user who configures the tracing operation.
You cannot change the directory (/var/log) in which trace files are located. However,
you can customize the other trace file settings by including the following statements:
file filename <files number> <match regular-expression> <size size> <world-readable |
no-world-readable>;
flag {
all;
command-queued;
config;
handshake;
init;
interfaces;
mib;
removed-client;
show;
}
You include these statements at the [edit services adaptive-services-pics traceoptions]
or [edit services logging traceoptions] hierarchy level.
These statements are described in the following sections:
•
Configuring the Adaptive Services Log Filename on page 28
•
Configuring the Number and Size of Adaptive Services Log Files on page 29
•
Configuring Access to the Log File on page 29
•
Configuring a Regular Expression for Lines to Be Logged on page 29
•
Configuring the Trace Operations on page 29
Configuring the Adaptive Services Log Filename
By default, the name of the file that records trace output is serviced. You can specify a
different name by including the file statement at the [edit services adaptive-services-pics
traceoptions] or [edit services logging traceoptions] hierarchy level:
28
Copyright © 2018, Juniper Networks, Inc.
Chapter 2: Adaptive Services Configuration Overview
file filename;
Configuring the Number and Size of Adaptive Services Log Files
By default, when the trace file reaches 128 kilobytes (KB) in size, it is renamed filename.0,
then filename.1, and so on, until there are three trace files. Then the oldest trace file
(filename.2) is overwritten.
You can configure the limits on the number and size of trace files by including the following
statements at the [edit services adaptive-services-pics traceoptions] or [edit services
logging traceoptions] hierarchy level:
file <filename> files number size size;
For example, set the maximum file size to 2 MB, and the maximum number of files to 20.
When the file that receives the output of the tracing operation (filename) reaches 2 MB,
filename is renamed filename.0, and a new file called filename is created. When the new
filename reaches 2 MB, filename.0 is renamed filename.1 and filename is renamed
filename.0. This process repeats until there are 20 trace files. Then the oldest file
(filename.19) is overwritten by the newest file (filename.0).
The number of files can be from 2 through 1000 files. The file size of each file can be from
10 KB through 1 gigabyte (GB).
Configuring Access to the Log File
By default, log files can be accessed only by the user who configures the tracing operation.
To specify that any user can read all log files, include the file world-readable statement
at the [edit services adaptive-services-pics traceoptions] or [edit services logging
traceoptions] hierarchy level:
file <filename> world-readable;
To explicitly set the default behavior, include the file no-world-readable statement at the
[edit services adaptive-services-pics traceoptions] or [edit services logging traceoptions]
hierarchy level:
file <filename> no-world-readable;
Configuring a Regular Expression for Lines to Be Logged
By default, the trace operation output includes all lines relevant to the logged events.
You can refine the output by including the match statement at the [edit services
adaptive-services-pics traceoptions file filename] or [edit services logging traceoptions]
hierarchy level and specifying a regular expression (regex) to be matched:
file <filename> match regular-expression;
Configuring the Trace Operations
By default, if the traceoptions configuration is present, only important events are logged.
You can configure the trace operations to be logged by including the following statements
Copyright © 2018, Juniper Networks, Inc.
29
Adaptive Services Interfaces Feature Guide for Routing Devices
at the [edit services adaptive-services-pics traceoptions] or [edit services logging
traceoptions] hierarchy level:
flag {
all;
configuration;
routing-protocol;
routing-socket;
snmp;
}
Table 4 on page 30 describes the meaning of the adaptive services tracing flags.
Table 4: Adaptive Services Tracing Flags
Flag
Description
Default Setting
all
Trace all operations.
Off
command-queued
Trace command enqueue events.
Off
config
Log reading of the configuration at the
[edit services] hierarchy level.
Off
handshake
Trace handshake events.
Off
init
Trace initialization events.
Off
interfaces
Trace interface events.
Off
mib
Trace GGSN SNMP MIB events.
Off
removed-client
Trace client cleanup events.
Off
show
Trace CLI command servicing.
Off
To display the end of the log, issue the show log serviced | last operational mode
command:
[edit]
user@host# run show log serviced | last
Related
Documentation
•
Understanding Service Sets on page 7
•
Configuring Service Sets to be Applied to Services Interfaces on page 9
•
Configuring System Logging for Service Sets on page 26
Configuring Fragmentation Control for MS-DPC and MS-PIC Service Interfaces
Two configuration options are available to prevent excessive consumption of
computational CPU cycles on a services PIC caused by the handling of large numbers of
30
Copyright © 2018, Juniper Networks, Inc.
Chapter 2: Adaptive Services Configuration Overview
fragmented packets. Such fragment handling can be exploited in DOS attacks. The
fragment-limit option establishes a maximum number of fragments for a packet. When
this number is exceeded, the packet is dropped. The reassembly-timeout specifies the
maximum time from the receipt of the first and latest fragments in a packet. When the
number is exceeded, the packet is dropped.
To configure fragmentation control for MS-DPC and MS-PIC service interfaces:
1.
In configuration mode, go to the [edit interfaces interface-name services-options
hierarchy level.
edit interfaces interface-name services-options
2. Configure the fragment limit.
[ edit services interface-name services-options]
set fragment-limit number-of-fragments
3. Configure the reassembly timeout.
[ edit services interface-name services-options]
set reassembly-timeout number-of-fragments
Copyright © 2018, Juniper Networks, Inc.
31
Adaptive Services Interfaces Feature Guide for Routing Devices
32
Copyright © 2018, Juniper Networks, Inc.
CHAPTER 3
Plug-in Adaptive Services
•
URL Filtering Overview on page 33
•
Configuring URL Filtering on page 36
•
Exchanging Data More Efficiently Using TCP Fast Open on page 38
•
Configuring TFO on page 39
URL Filtering Overview
Starting in Junos OS Release 17.2, you can use URL filtering to determine which Web
content is not accessible to users.
Components of this feature include the following:
•
URL filter database file
•
Configuration of one or more templates (up to eight per profile)
•
URL Filter Plug-in (jservices-urlf)
•
URL filtering daemon (url-filterd)
The URL filter database file is stored on the Routing Engine and contains all the blacklisted
URLs. Configured templates define which traffic to monitor, what criteria to match, and
which actions to take. You configure the templates and the location of the URL filter
database file in the profile statement at the [edit services url-filter profile profile-name]
hierarchy level.
Starting in Junos OS Release 17.2R2 and 17.4R1, you can disable the filtering of HTTP
traffic that contains an embedded IP address (for example, http:/10.1.1.1) belonging to a
blacklisted domain name in the URL filter database.
To enable the URL filtering feature, you must configure jservices-urlf as the package-name
at the [edit chassis fpc slot-number pic pic-number adaptive-services service-package
extension-provider] hierarchy level. Once enabled, jservices-urlf maintains the URL filtering
profile and receives all traffic to be filtered, the filtering criteria, and the action to be taken
on the filtered traffic.
The URL filtering daemon (url-filterd), which also resides on the Routing Engine, resolves
the domain name of each URL in the URL filter database to a list of IPv4 and IPv6
addresses. It then downloads the list of IP addresses to the service PIC, which runs
Copyright © 2018, Juniper Networks, Inc.
33
Adaptive Services Interfaces Feature Guide for Routing Devices
jservices-urlf. Then url-filterd interacts with the Dynamic Firewall process (dfwd) to
install filters on the Packet Forwarding Engine to punt the selected traffic from the Packet
Forwarding Engine to the service PIC.
As new HTTP and HTTPS traffic reaches the router, a decision is made based on the
information in the URL filter database file. The filtering rules are checked and either the
router accepts the traffic and passes it on or blocks the traffic. If the traffic is blocked,
one of the following configured actions is taken:
•
An HTTP redirect is sent to the user.
•
A custom page is sent to the user.
•
An HTTP status code is sent to the user.
•
A TCP reset is sent.
Accept is also an option. In this case, the traffic is not blocked.
For more details on the URL filtering feature, see the following sections:
•
URL Filter Database File on page 34
•
URL Filter Profile Caveats on page 35
URL Filter Database File
The URL filter database file contains entries of URLs and IP addresses. Create the URL
filter database file in the format indicated in Table 5 on page 34 and locate it on the
Routing Engine in the /var/db/url-filterd directory.
Table 5: URL Filter Database File Format
Entry
Description
Example
FQDN
Fully qualified domain name.
www.badword.com/jjj/bad.jpg
URL
Full string URL without the Layer
7 protocol.
www.yahoo.com/*badword*/
IPv4 address
HTTP request on a specific IPv4
address.
10.1.1.199
IPv6 address
HTTP request on a specific IPv6
address.
1::1
You must specify a custom URL filter database at the [edit services url-filter profile
profile-name] hierarchy level. If needed, you can also assign a custom URL filter database
file with any template. If you do configure a URL filter database file at the [edit services
url-filter profile profile-name template template-name] hierarchy level, that database
takes precedence over the database configured at the profile level.
34
Copyright © 2018, Juniper Networks, Inc.
Chapter 3: Plug-in Adaptive Services
If you change the contents of the URL filter database file, use the request services url-filter
update command. Other commands to help maintain the URL filter database file include
the following:
•
request services url-filter delete
•
request services url-filter force
•
request services url-filter validate
URL Filter Profile Caveats
The URL filter profile consists of from one to eight templates. Each template consists of
a set of configured logical interfaces where traffic is monitored for URL filtering and one
or more terms.
A term is a set of match criteria with actions to be taken if the match criteria is met. You
must configure at least one term to configure URL filtering. Each term consists of a from
statement and a then statement, where the from statement defines the source IP prefixes
and destination ports that are monitored. The then statement specifies the action to be
taken. If you omit the from statement, any source IP prefix and any destination port are
considered to match. But you can omit only one from statement per template or per
profile.
Example configuration
of multiple terms
without from
statements
template1 {
client-interfaces [ xe-4/0/3.35 xe-4/0/3.36 ];
server-interfaces xe-4/0/0.31;
dns-source-interface xe-4/0/0.1;
dns-routing-instance data_vr;
routing-instance data_vr2;
dns-server 50.0.0.3;
dns-retries 3;
url-filter-database url_database.txt;
term term1 {
then {
tcp-reset;
}
}
term term2 {
then {
redirect-url www.google.com;
}
}
}
If you omit more than one from statement per template, you will get the following error
message on commit:
URLFD_CONFIG_FAILURE: Configuration not valid:
Cannot have two wild card terms in template template1
error: configuration check-out failed
Copyright © 2018, Juniper Networks, Inc.
35
Adaptive Services Interfaces Feature Guide for Routing Devices
Release History Table
Related
Documentation
Release
Description
17.2R2
Starting in Junos OS Release 17.2R2 and 17.4R1, you can disable the filtering
of HTTP traffic that contains an embedded IP address (for example,
http:/10.1.1.1) belonging to a blacklisted domain name in the URL filter
database.
•
Configuring URL Filtering on page 36
•
request services url-filter update url-filter-database file on page 1305
•
request services url-filter force dns-resolution on page 1304
•
request services url-filter delete gencfg-data on page 1303
•
request services url-filter validate on page 1306
Configuring URL Filtering
URL filtering is configured on a service PIC. The interfaces you are dealing with are services
interfaces (which use the ms prefix) or aggregated multiservices (AMS) interfaces (which
use the ams prefix). For more information on AMS interfaces, see the Adaptive Services
Interfaces Feature Guide for Routing Devices starting with “Understanding Aggregated
Multiservices Interfaces” on page 777.
To configure the URL filtering feature, you must first configure jservices-urlf as the
package-name at the [edit chassis fpc slot-number pic pic-number adaptive-services
service-package extension-provider] hierarchy level. For more information on configuring
the extension-provider package package-name configuration statement, see the package
(Loading on PIC) statement.
A URL filtering profile is a collection of templates. Each template consists of a set of
criteria that defines which URLs are blacklisted and how the recipient is notified.
To configure the URL profile:
1.
Assign a name to the URL profile.
[edit]
user@host# edit services url-filter profile profile-name
2. Configure the URL filter database.
[edit services url-filter profile profile-name]
user@host# set url-filter-database filename
3. Configure one or more templates for the profile.
To configure each template:
a. Name the template.
36
Copyright © 2018, Juniper Networks, Inc.
Chapter 3: Plug-in Adaptive Services
[edit services url-filter profile profile-name]
user@host# set template template-name
b. Go to that new template hierarchy level.
[edit services url-filter profile profile-name]
user@host# edit template template-name
c. Configure the other template criteria.
To see the other template criteria use the set ? command.
[edit services url-filter profile profile-name template template-name]
user@host# set ?
For more information on configuring the template criteria, see the template (URL
Filter) statement.
4. Configure the term information.
Terms are used in filters or routing policies to segment the policy or filter into small
match and action pairs.
a. Name the term.
[edit services url-filter profile profile-name template template-name]
user@host# set term term-name
b. Go to the new term hierarchy level.
[edit services url-filter profile profile-name template template-name]
user@host# edit term term-name
c. Configure the remaining term criteria.
[edit services url-filter profile profile-name template template-name term term-name]
user@host# set ?
For more information on configuring the term criteria, see the term (URL Filter)
statement.
5. Associate the URL profile with a next-hop service set.
NOTE: For URL filtering, you must configure the service set as a next-hop
service set.
[edit]
user@host# set services service-set service-set-name url-filter-profile profile-name
user@host# set services service-set service-set-name next-hop-service
inside-service-interface interface-name.unit-number
user@host# set services service-set service-set-name next-hop-service
outside-service-interface interface-name.unit-number
Copyright © 2018, Juniper Networks, Inc.
37
Adaptive Services Interfaces Feature Guide for Routing Devices
NOTE: The service interface can also be of the ams prefix. If you are using
ams interfaces at the [edit services service-set service-set-name] hierarchy
level for the URL filter, you must also configure the load-balancing-options
hash-keys statement at the [edit interfaces ams-interface-name unit number]
hierarchy level. For more information on configuring ams interfaces for
next-hop service sets, see Example: Filtering Web Content on Multiple
Service PICs Using an Aggregated Multiservices Interface.
Related
Documentation
•
Example: Filtering Web Content on Multiple Service PICs Using an Aggregated
Multiservices Interface
•
URL Filtering Overview on page 33
•
Configuring Service Sets to be Applied to Services Interfaces on page 9
Exchanging Data More Efficiently Using TCP Fast Open
TCP Fast Open (TFO) is an update to TCP that saves up to one full round-trip time (RTT)
over the standard three-way connection handshake during a TCP session. TFO support
is for MS-MPC and MS-MIC.
The standard three-way connection handshake involves three sets of send and receive
messages between two hosts and the following exchange of SYN (synchronize) and
ACK (acknowledgement) packets:
1.
Host A sends a TCP SYN packet to Host B. Host B receives it.
2. Host B sends a SYN-ACK packet to Host A. Host A receives it.
3. Host A sends an ACK packet to Host B. Host B receives it.
In standard TCP, although data can be carried in SYN packets, this data cannot be
delivered until the three-way handshake is completed. TFO removes this constraint and
allows data in SYN packets to be delivered to the application, yielding significant latency
improvement.
The key component of TFO is the Fast Open Cookie (cookie), which is a Message
Authentication Code (MAC) tag generated by the server. The client requests a cookie in
one regular TCP connection, then uses it for future TCP connections to exchange data
during the handshake.
The TFO option is used to request or to send a TFO cookie. When a cookie is not present
or is empty, the option is used by the client to request a cookie from the server. When the
cookie is present, the option is used to pass the cookie from the server to the client or
from the client back to the server.
The following list outlines how the client requests a TFO cookie:
1.
38
The client sends a SYN with a TFO option that has the cookie field empty.
Copyright © 2018, Juniper Networks, Inc.
Chapter 3: Plug-in Adaptive Services
2. The server generates a cookie and sends it through the TFO option of a SYN-ACK
packet.
3. The client caches the cookie for future TFO connections.
Thereafter, the two devices perform a TFO exchange:
1.
The client sends a SYN with data and the cookie in the TFO option.
2. The server validates the cookie:
•
If the cookie is valid, the server sends a SYN-ACK acknowledging both the SYN and
the data.
The server then delivers the data to the application.
•
Otherwise, the server drops the data and sends a SYN-ACK acknowledging only
the SYN sequence number.
The rest of the connection proceeds like a normal TCP connection. The client can repeat
many TFO operations once it acquires a cookie (until the cookie is expired by the server).
Thus, TFO is useful for applications in which the same client reconnects to the same
server multiple times and exchanges data.
Related
Documentation
•
tcp-fast-open on page 1151
•
Configuring TFO on page 39
Configuring TFO
In this topic, the three modes of TCP Fast Open (TFO) are described and examples given.
The case of using NAT with TFO is also covered.
•
Three Modes for TFO on page 39
•
Using NAT and TFO on page 41
Three Modes for TFO
No configuration is required to use TFO. TFO is enabled by default. In default mode, all
TFO packets are forwarded by the service PIC. Besides the default, there are two other
modes for TFO that you configure through the CLI:
•
Drop TFO—If this mode is set, no TFO packets are forwarded.
•
Disable TFO—If this mode is set, any SYN or SYN ACK packet carrying TFO, data, or
both, will be stripped of the TFO and the data before being forwarded.
The TFO option is enabled per service set. The service set can be either a next-hop service
set or an interface-style service set. Following is an example interface-style service set
configuration:
[edit]
services {
service-set ss2 {
Copyright © 2018, Juniper Networks, Inc.
39
Adaptive Services Interfaces Feature Guide for Routing Devices
stateful-firewall-rules sfw_rule;
interface-service {
service-interface ms-2/3/0;
}
}
stateful-firewall {
rule sfw_rule {
match-direction input-output;
term 0 {
from {
source-address {
any-ipv4;
}
destination-address {
any-ipv4;
}
then {
accept;
}
}
}
}
}
}
In this instance, TFO is enabled by default (no TFO configuration). The output for the
show services service-sets statistics tcp command is as follows:
user@host> show services service-sets statistics tcp
Interface: ms-2/3/0
Service set: ss2
TCP open/close statistics:
TCP first packet non-syn: 0
TCP first packet reset: 0
TCP first packet FIN: 0
TCP non syn discard: 0
TCP extension alloc fail: 0
TFO SYN with cookie request: 1
TFO SYN with cookie: 0
TFO SYN ACK with cookie: 0
TFO packets forwarded: 0
TFO packets dropped: 1
TFO packets stripped: 0
If you drop TFO enabled packets, you have the following configuration and output:
[edit]
services {
service-set ss2 {
service-set-options {
tcp-fast-open drop;
}
stateful-firewall-rules sfw_rule;
interface-service {
service-interface ms-2/3/0;
}
40
Copyright © 2018, Juniper Networks, Inc.
Chapter 3: Plug-in Adaptive Services
}
}
user@host> show services service-sets statistics tcp
Interface: ms-2/3/0
Service set: ss2
TCP open/close statistics:
TCP first packet non-syn: 0
TCP first packet reset: 0
TCP first packet FIN: 0
TCP non syn discard: 0
TCP extension alloc fail: 0
TFO SYN with cookie request: 1
TFO SYN with cookie: 0
TFO SYN ACK with cookie: 0
TFO packets forwarded: 0
TFO packets dropped: 1
TFO packets stripped: 0
If you strip the TFO option, the configuration and output change accordingly:
[edit]
services {
service-set ss2 {
service-set-options {
tcp-fast-open disabled;
}
stateful-firewall-rules sfw_rule;
interface-service {
service-interface ms-2/3/0;
}
}
}
user@host> show services service-sets statistics tcp
Interface: ms-2/3/0
Service set: ss2
TCP open/close statistics:
TCP first packet non-syn: 0
TCP first packet reset: 0
TCP first packet FIN: 0
TCP non syn discard: 0
TCP extension alloc fail: 0
TFO SYN with cookie request: 1
TFO SYN with cookie: 0
TFO SYN ACK with cookie: 0
TFO packets forwarded: 0
TFO packets dropped: 0
TFO packets stripped: 1
Using NAT and TFO
If NAT is configured in the service set and you are using TFO, you should configure
address-pooling paired (APP). APP allows a private IP address to be mapped to the
same public IP address from a NAT pool for all its sessions.
Copyright © 2018, Juniper Networks, Inc.
41
Adaptive Services Interfaces Feature Guide for Routing Devices
If you do not configure APP, NAT can give a different IP address to the client from the
same NAT pool than the one it sent to the server before. The server does not recognize
the IP address, drops the TFO option, and replies with SYN ACK and the data the client
sent is not acknowledged. Therefore, even though the connection is successful and no
packet is lost, the benefit of TFO is lost. But if client comes back with the same IP address,
the server recognizes it and acknowledges the data. Therefore, always enable APP with
a high mapping timeout value with TFO.
To configure APP:
1.
Configure APP:
set services nat rule rule-name term term-name then translated address-pooling paired
2. Configure a high mapping timeout value:
set services nat pool nat-pool-name mapping-timeout seconds
Related
Documentation
42
•
tcp-fast-open on page 1151
Copyright © 2018, Juniper Networks, Inc.
PART 2
Translating IP Addresses Using NAT
•
NAT Overview on page 45
•
NAT Configuration Overview on page 59
•
Avoiding IPv4 Exhaustion Using Junos Address Aware Network Addressing and Stateful
NAT64 on page 85
•
Hiding Private Networks Using Static Source NAT on page 91
•
Making Private Servers Available Using Static Destination NAT on page 109
•
Allowing Components of a Private Network to Share a Single Address Using
NAPT on page 115
•
Mapping Addresses and Ports With Deterministic NAT on page 137
•
Securing Traffic Using NAT-PT and ALGs on page 147
•
Providing IPv4 Connectivity Across IPv6-Only Network Using 464XLAT on page 173
•
Reducing Traffic and Bandwidth Requirements Using Port Control Protocol on page 177
•
Automatically Assigning Ports Using Secured Port Block Allocation on page 191
•
Connecting Specific Ports and Addresses Using Port Forwarding on page 201
•
Allocating a Few Public Addresses to Many Private Hosts Using Dynamic
NAT on page 211
•
Achieving Line-Rate, Low-Latency Translations Using Inline NAT on page 219
•
Removing Address Dependency Using Network Prefix Translation for IPv6
Traffic on page 237
•
Monitoring NAT on page 257
Copyright © 2018, Juniper Networks, Inc.
43
Adaptive Services Interfaces Feature Guide for Routing Devices
44
Copyright © 2018, Juniper Networks, Inc.
CHAPTER 4
NAT Overview
•
Junos Address Aware Network Addressing Overview on page 45
•
Junos OS Carrier-Grade NAT Implementation Overview on page 52
•
Carrier-Grade NAT Feature Comparison for Junos Address Aware by Type of Interface
Card on page 53
Junos Address Aware Network Addressing Overview
Junos Address Aware Network Addressing provides Network Address Translation (NAT)
functionality for translating IP addresses. This is particularly important because the
Internet Assigned Numbers Authority (IANA) allocated the last large block of IPv4
addresses in early 2011.
This topic includes the following sections:
•
Benefits of NAT on page 45
•
NAT Concept and Facilities Overview on page 46
•
IPv4-to-IPv4 Basic NAT on page 47
•
Deterministic NAPT on page 48
•
Static Destination NAT on page 48
•
Twice NAT on page 48
•
IPv6 NAT on page 48
•
Application-Level Gateway (ALG) Support on page 49
•
NAT-PT with DNS ALG on page 49
•
Dynamic NAT on page 49
•
Stateful NAT64 on page 50
•
464XLAT on page 50
•
Dual-Stack Lite on page 51
•
Junos Address Aware Network Addressing Line Card Support on page 51
Benefits of NAT
NAT supports a wide range of networking goals, including:
Copyright © 2018, Juniper Networks, Inc.
45
Adaptive Services Interfaces Feature Guide for Routing Devices
•
Concealing a set of host addresses on a private network behind a pool of public
addresses to protect the host addresses from direct targeting in network attacks and
to avoid IPv4 address exhaustion
•
Providing the tools to transition to IPv6 based on business requirements and to ensure
uninterrupted subscriber and service growth
•
Providing IPv4–IPv6 coexistence
NAT Concept and Facilities Overview
Junos Address Aware Network Addressing provides carrier-grade NAT (CGN) for IPv4
and IPv6 networks, and facilitates the transit of traffic between different types of
networks.
Junos Address Aware Network Addressing supports a diverse set of NAT translation
options:
46
•
Static-source translation—Allows you to hide a private network. It features a one-to-one
mapping between the original address and the translated address; the mapping is
configured statically. For more information, see “Basic NAT” on page 47.
•
Deterministic NAPT—Eliminates the need for address translation logging by ensuring
that the original source IPv4 or IPv6 address and port always map to the same post-NAT
IPv4 address and port range.
•
Dynamic-source translation—Includes two options: dynamic address-only source
translation and Network Address Port Translation (NAPT):
•
Dynamic address-only source translation—A NAT address is picked up dynamically
from a source NAT pool and the mapping from the original source address to the
translated address is maintained as long as there is at least one active flow that
uses this mapping. For more information, see “Dynamic NAT” on page 49.
•
NAPT—Both the original source address and the source port are translated. The
translated address and port are picked up from the corresponding NAT pool. For
more information, see “NAPT” on page 47.
•
Static destination translation—Allows you to make selected private servers accessible.
It features a one-to-one mapping between the translated address and the destination
address; the mapping is configured statically. For more information, see “Static
Destination NAT” on page 48.
•
Protocol translation—Allows you to assign addresses from a pool on a static or dynamic
basis as sessions are initiated across IPv4 or IPv6 boundaries. For more information,
see “Configuring NAT-PT” on page 150, “NAT-PT with DNS ALG” on page 49, and
“Stateful NAT64” on page 50.
•
Encapsulation of IPv4 packets into IPv6 packets using softwires—Enables packets to
travel over softwires to a carrier-grade NAT endpoint where they undergo source-NAT
processing to hide the original source address. For more information, see “Tunneling
Services for IPv4-to-IPv6 Transition Overview” on page 269.
Copyright © 2018, Juniper Networks, Inc.
Chapter 4: NAT Overview
Junos Address Aware Network Addressing supports NAT functionality described in IETF
RFCs and Internet drafts, as shown in “Supported NAT and SIP Standards” in Standards
Reference.
NOTE: Not all types of NAT are supported on all interface types. See
“Carrier-Grade NAT Feature Comparison for Junos Address Aware by Type
of Interface Card” on page 53, which lists features available on supported
interfaces.
IPv4-to-IPv4 Basic NAT
Basic Network Address Translation or Basic NAT is a method by which IP addresses are
mapped from one group to another, transparent to end users. Network Address Port
Translation or NAPT is a method by which many network addresses and their TCP/UDP
ports are translated into a single network address and its TCP/UDP ports. Together,
these two operations, referred to as traditional NAT, provide a mechanism to connect a
realm with private addresses to an external realm with globally unique registered
addresses.
Traditional NAT, specified in RFC 3022, Traditional IP Network Address Translator, is fully
supported by Junos Address Aware Network Addressing. In addition, NAPT is supported
for source addresses.
Basic NAT
With Basic NAT, a block of external addresses is set aside for translating addresses of
hosts in a private domain as they originate sessions to the external domain. For packets
outbound from the private network, Basic NAT translates source IP addresses and related
fields such as IP, TCP, UDP, and ICMP header checksums. For inbound packets, Basic
NAT translates the destination IP address and the checksums listed above.
NAPT
Use NAPT to enable the components of the private network to share a single external
address. NAPT translates the transport identifier (for example, TCP port number, UDP
port number, or ICMP query ID) of the private network into a single external address.
NAPT can be combined with Basic NAT to use a pool of external addresses in conjunction
with port translation.
For packets outbound from the private network, NAPT translates the source IP address,
source transport identifier (TCP/UDP port or ICMP query ID), and related fields, such as
IP, TCP, UDP, and ICMP header checksums. For inbound packets, NAPT translates the
destination IP address, the destination transport identifier, and the IP and transport
header checksums.
On MX Series routers with MS-MICs and MS-MPCs, if you configure a NAPT44 NAT rule
and the source IP address of a spoofed packet is equal to the NAT pool and the NAT rule
match condition fails, the packet is continuously looped between the services PIC and
the Packet Forwarding Engine. We recommend that you manually clear the session and
create a filter to block NAT pool IP spoofing under such conditions.
Copyright © 2018, Juniper Networks, Inc.
47
Adaptive Services Interfaces Feature Guide for Routing Devices
Deterministic NAPT
Use deterministic NAPT44 to ensure that the original source IPv4 address and port always
map to the same post-NAT IPv4 address and port range, and that the reverse mapping
of a given translated external IPv4 address and port are always mapped to the same
internal IP address. This eliminates the need for address translation logging. Starting in
Junos OS Release 17.4R1, deterministic NAPT64 is supported on the MS-MPC and MS-MIC.
Deterministic NAPT64 ensures that the original source IPv6 address and port always
map to the same post-NAT IPv4 address and port range, and that the reverse mapping
of a given translated external IPv4 address and port are always mapped to the same
internal IPv6 address.
Static Destination NAT
Use static destination NAT to translate the destination address for external traffic to an
address specified in a destination pool. The destination pool contains one address and
no port configuration.
For more information about static destination NAT, see RFC 2663, IP Network Address
Translator (NAT) Terminology and Considerations.
Twice NAT
In Twice NAT, both the source and destination addresses are subject to translation as
packets traverse the NAT router. The source information to be translated can be either
address only or address and port. For example, you would use Twice NAT when you are
connecting two networks in which all or some addresses in one network overlap with
addresses in another network (whether the network is private or public). In traditional
NAT, only one of the addresses is translated.
To configure Twice NAT, you must specify both a destination address and a source
address for the match direction, pool or prefix, and translation type.
You can configure application-level gateways (ALGs) for ICMP and traceroute under
stateful firewall, NAT, or class-of-service (CoS) rules when Twice NAT is configured in
the same service set. These ALGs cannot be applied to flows created by the Packet
Gateway Control Protocol (PGCP). Twice NAT does not support other ALGs. By default,
the Twice NAT feature can affect IP, TCP, and UDP headers embedded in the payload
of ICMP error messages.
Twice NAT, specified in RFC 2663, IP Network Address Translator (NAT) Terminology and
Considerations, is fully supported by Junos Address Aware Network Addressing.
IPv6 NAT
IPv6-to-IPv6 NAT (NAT66), defined in Internet draft draft-mrw-behave-nat66-01,
IPv6-to-IPv6 Network Address Translation (NAT66), is fully supported by Junos Address
Aware Network Addressing.
48
Copyright © 2018, Juniper Networks, Inc.
Chapter 4: NAT Overview
Application-Level Gateway (ALG) Support
Junos Address Aware Network Addressing supports a number of ALGs. You can use NAT
rules to filter incoming traffic based on ALGS. For more information, see “Network Address
Translation Rules Overview” on page 63.
NAT-PT with DNS ALG
NAT-PT and Domain Name System (DNS) ALG are used to facilitate communication
between IPv6 hosts and IPv4 hosts. Using a pool of IPv4 addresses, NAT-PT assigns
addresses from that pool to IPv6 nodes on a dynamic basis as sessions are initiated
across IPv4 or IPv6 boundaries. Inbound and outbound sessions must traverse the same
NAT-PT router so that it can track those sessions. RFC 2766, Network Address Translation
- Protocol Translation (NAT-PT), recommends the use of NAT-PT for translation between
IPv6-only nodes and IPv4-only nodes, and not for IPv6-to-IPv6 translation between IPv6
nodes or IPv4-to-IPv4 translation between IPv4 nodes.
DNS is a distributed hierarchical naming system for computers, services, or any resource
connected to the Internet or a private network. The DNS ALG is an application-specific
agent that allows an IPv6 node to communicate with an IPv4 node and vice versa.
When DNS ALG is employed with NAT-PT, the DNS ALG translates IPv6 addresses in
DNS queries and responses to the corresponding IPv4 addresses and vice versa. IPv4
name-to-address mappings are held in the DNS with “A” queries. IPv6 name-to-address
mappings are held in the DNS with “AAAA” queries.
NOTE: For IPv6 DNS queries, use the do-not-translate-AAAA-query-to-A-query
statement at the [edit applications application application-name] hierarchy
level.
Dynamic NAT
Dynamic NAT flow is shown in Figure 2 on page 49.
Figure 2: Dynamic NAT Flow
Public IPv4
aggregation
Local host
IPv4 end user
NAT
CGN
IPv4
Destination host
Dynamic NAT
g017571
IPv4 CPE
With dynamic NAT, you can map a private IP address (source) to a public IP address
drawing from a pool of registered (public) IP addresses. NAT addresses from the pool
are assigned dynamically. Assigning addresses dynamically also allows a few public IP
addresses to be used by several private hosts, in contrast with an equal-sized pool required
by source static NAT.
For more information about dynamic address translation, see RFC 2663, IP Network
Address Translator (NAT) Terminology and Considerations.
Copyright © 2018, Juniper Networks, Inc.
49
Adaptive Services Interfaces Feature Guide for Routing Devices
Stateful NAT64
Stateful NAT64 flow is shown in Figure 3 on page 50.
Figure 3: Stateful NAT64 Flow
Public IPv4
aggregation
IPv6 CPE
Local host
CGN
g017572
IPv6
Destination host
IPv4
NAT64
Stateful NAT64 is a mechanism to move to an IPv6 network and at the same time deal
with IPv4 address depletion. By allowing IPv6-only clients to contact IPv4 servers using
unicast UDP, TCP, or ICMP, several IPv6-only clients can share the same public IPv4
server address. To allow sharing of the IPv4 server address, NAT64 translates incoming
IPv6 packets into IPv4 (and vice versa).
When stateful NAT64 is used in conjunction with DNS64, no changes are usually required
in the IPv6 client or the IPv4 server. DNS64 is out of scope of this document because it
is normally implemented as an enhancement to currently deployed DNS servers.
Stateful NAT64, specified in RFC 6146, Stateful NAT64: Network Address and Protocol
Translation from IPv6 Clients to IPv4 Servers, is fully supported by Junos Address Aware
Network Addressing.
464XLAT
Starting in Junos OS Release 17.1R1, you can configure a 464XLAT Provider-Side Translater
(PLAT). This is supported only on MS-MICs and MS-MPCs. 464XLAT provides a simple
and scalable technique for an IPv4 client with a private address to connect to an IPv4
host over an IPv6 network. 464XLAT only suports IPv4 in the client-server model, so it
does not support IPv4 peer-to-peer communication or inbound IPv4 connections.
A customer-side translator (CLAT), which is not a Juniper Networks product, translates
the IPv4 packet to IPv6 by embedding the IPv4 source and destination addresses in IPv6
/96 prefixes, and sends the packet over an IPv6 network to the PLAT. The PLAT translates
the packet to IPv4, and sends the packet to the IPv4 host over an IPv4 network (see
Figure 4 on page 50).
Figure 4: 464XLAT Wireline Flow
IPv6
IPv6
IPv6 Native
IPv4 Private
IPv6
CLAT
IPv6
Internet
PLAT
MX Series
device
IPv4
Internet
IPv4
192.168.1.2
50
IPv4
198.51.100.1
g043573
464XLAT
Copyright © 2018, Juniper Networks, Inc.
Chapter 4: NAT Overview
XLAT464 provides the advantages of not having to maintain an IPv4 network and not
having to assign additional public IPv4 addresses.
The CLAT can reside on the end user mobile device in an IPv6-only mobile network,
allowing mobile network providers to roll out IPv6 for their users and support IPv4-only
applications on mobile devices (see Figure 5 on page 51).
Figure 5: 464XLAT Wireless Flow
IPv6
Mobile
device
PLAT
MX Series
device
IPv6 Native
IPv6
Internet
CLAT
IPv4
Internet
464XLAT
function
IPv4
192.168.1.2
g043572
IPv6
IPv4
198.51.100.1
Dual-Stack Lite
Dual-stack lite (DS-Lite) flow is shown in Figure 6 on page 51.
Figure 6: DS-Lite Flow
DS-Lite IPv4 in IPv6 tunnel
IPv4
Destination host
IPv6
Destination host
IPv4 end-user
IPv6
AFTR/CGN
NAT44
IPv6 end user
g017570
Local host
DS-Lite employs IPv4-over-IPv6 tunnels to cross an IPv6 access network to reach a
carrier-grade IPv4-IPv4 NAT. This facilitates the phased introduction of IPv6 on the
Internet by providing backward compatibility with IPv4.
DS-Lite is supported on MX series routers with MS-DPCs and on M Series routers with
MS-100, MS-400, and MS-500 MultiServices PICS. Starting in Junos OS release 17.4R1,
DS-Lite is supported on MX Series routers with MS-MPCs and MS-MICs.
Junos Address Aware Network Addressing Line Card Support
Junos Address Aware Network Addressing technologies are available on the following
line cards:
•
MultiServices Dense Port Concentrator (MS-DPC)
•
MS-100, MS-400, and MS-500 MultiServices PICS
Copyright © 2018, Juniper Networks, Inc.
51
Adaptive Services Interfaces Feature Guide for Routing Devices
•
MultiServices Modular Port Concentrator (MS-MPC) and MultiServices Modular
Interface Card (MS-MIC)
•
Modular Port Concentrators (inline NAT).
For a listing of the specific NAT types supported on each type of card, see “Carrier-Grade
NAT Feature Comparison for Junos Address Aware by Type of Interface Card” on page 53.
Release History Table
Related
Documentation
Release
Description
17.4R1
Starting in Junos OS Release 17.4R1, deterministic NAPT64 is supported on
the MS-MPC and MS-MIC.
17.4R1
Starting in Junos OS release 17.4R1, DS-Lite is supported on MX Series routers
with MS-MPCs and MS-MICs.
17.1R1
Starting in Junos OS Release 17.1R1, you can configure a 464XLAT
Provider-Side Translater (PLAT).
•
Carrier-Grade NAT Feature Comparison for Junos Address Aware by Type of Interface
Card on page 53
•
ALGs Available for Junos OS Address Aware NAT on page 147
Junos OS Carrier-Grade NAT Implementation Overview
Junos OS enables you to implement and scale a Carrier-Grade Network Address
Translation (CGNAT) solution based on the type of services interfaces used for your
implementation:
52
•
MultiServices Denser Port Concentrator (MS-DPC)—The layer 3 services package is
used to configure NAT for MS-DPC adaptive services PICs. This solution provides the
NAT functionality described in “Junos Address Aware Network Addressing Overview”
on page 45.
•
MS-100, MS-400, and MS-500 MultiServices PICS—The layer 3 services package is
used to configure NAT for multiservices PICs. This solution provides the NAT
functionality described in “Junos Address Aware Network Addressing Overview” on
page 45.
•
MultiServices Modular Port Concentrator (MS-MPC) and MultiServices Modular
Interface Card (MS-MIC)—MS-MPCs and MS-MICs are pre-configured to enable
configuration of carrier-grade NAT. This solution provides the NAT functionality
described in “Junos Address Aware Network Addressing Overview” on page 45.
•
Inline NAT for Modular Port Concentrator (MPC) Line Cards)—Inline NAT leverages
the services capabilities of MPC line cards, allowing a cost-effective implementation
of NAT functionality on the data plane, as described in “Inline Network Address
Translation Overview” on page 219.
Copyright © 2018, Juniper Networks, Inc.
Chapter 4: NAT Overview
Related
Documentation
•
Carrier-Grade NAT Feature Comparison for Junos Address Aware by Type of Interface
Card on page 53
•
Carrier-Grade NAT Implementation: Best Practices on page 73
•
Example: Configuring Basic NAT44 on page 102
Carrier-Grade NAT Feature Comparison for Junos Address Aware by Type of Interface
Card
Table 6 on page 53 summarizes feature differences among the Junos OS carrier-grade
NAT implementations.
Starting in Junos OS release 17.2R1, inline NAT is supported on the MPC5E and MPC6E.
Starting in Junos OS release 17.4R1, inline NAT is supported on the MPC7E, MPC8E, and
MPC9E.
Table 6: Carrier-Grade NAT—Feature Comparison by Platform
MS-DPC
MS-400
MS-MPC
MPC1, MPC2, MPC3,
MPC5E, MPC6E, MPC7E,
MPC8E, and MPC9E
Feature
MS-500
MS-MIC
Inline NAT
Static Source NAT
yes
yes
yes
Dynamic Source NAT Address Only
yes
yes
no
Dynamic Source NAT - NAPT
Port Translation with Secured
Port Block Allocation
yes
yes (Dynamic Source NAT NAPT Port Translation with
Secured Port Block Allocation
supported for MS-MPC and
MS-MIC starting in Junos OS
Release 14.2R2)
no
Dynamic Source NAT NAPT44 Port Translation with
Deterministic Port Block
Allocation
yes
yes (Dynamic Source NAT NAPT44 Port Translation
with Deterministic Port Block
Allocation supported for
MS-MPC and MS-MIC
starting in Junos OS release
17.3R1, in Junos OS release
14.2R7 and later 14.2 releases,
in 15.1R3 and later 15.1
releases, and in 16.1R5 and
later 16.1 releases)
no
MS-100
Copyright © 2018, Juniper Networks, Inc.
53
Adaptive Services Interfaces Feature Guide for Routing Devices
Table 6: Carrier-Grade NAT—Feature Comparison by Platform (continued)
MS-DPC
MS-400
MS-MPC
MPC1, MPC2, MPC3,
MPC5E, MPC6E, MPC7E,
MPC8E, and MPC9E
Feature
MS-500
MS-MIC
Inline NAT
Dynamic Source NAT NAPT64 Port Translation with
Deterministic Port Block
Allocation
No
yes (Dynamic Source NAT NAPT64 Port Translation
with Deterministic Port Block
Allocation supported for
MS-MPC and MS-MIC
starting in Junos OS release
17.4R1)
No
Static Destination NAT
yes
yes
yes
MS-100
NOTE: Destination NAT can
be implemented indirectly.
See “Inline Network Address
Translation Overview” on
page 219
Twice NAT
yes
yes (Twice NAT supported for
MS-MPC and MS-MIC
starting in Junos OS Release
15.1R1)
yes
NOTE: Twice NAT can be
implemented indirectly. See
“Inline Network Address
Translation Overview” on
page 219
NAPT - Preserve Parity and
Range
yes
yes (NAPT - Preserve Parity
and Range supported for
MS-MPC and MS-MIC
starting in Junos OS release
15.1R1)
no
NAPT - APP/EIF/EIM
yes
yes
no
IKE ALG
no
yes (Starting in Junos OS
Release 14.2R7, 15.1R5, 16.1R2,
and 17.1R1)
no
Stateful NAT64
yes
yes
no
Stateful NAT64 with
APP/EIM/EIF
no
yes
no
54
Copyright © 2018, Juniper Networks, Inc.
Chapter 4: NAT Overview
Table 6: Carrier-Grade NAT—Feature Comparison by Platform (continued)
MS-DPC
MS-400
MS-MPC
MPC1, MPC2, MPC3,
MPC5E, MPC6E, MPC7E,
MPC8E, and MPC9E
Feature
MS-500
MS-MIC
Inline NAT
Stateful NAT64 with ALGs
no
yes
no
DS-Lite
yes
yes (DS-Lite supported for
MS-MPC and MS-MIC
starting in Junos OS release
17.4R1)
no
6rd
yes
no
no
6to4
yes
no
no
464XLAT
no
yes (starting in Junos OS
Release 17.1R1)
no
Overlap Address Across NAT
Pool
yes
yes
no
Port Control Protocol
yes
yes (Port Control Protocol
with NAPT44 is supported for
MS-MPC and MS-MIC
starting in Junos OS Release
17.4R1. PCP with DS-Lite is
not supported.)
no
CGN-PIC
yes
no
no
AMS Support
no
yes
no
Port forwarding
yes
yes (Port forwarding is
supported for MS-MPC and
MS-MIC starting in Junos OS
Release 17.4R1.)
no
No translation
yes
yes (No translation supported
for MS-MPC and MS-MIC
starting in Junos OS Release
15.1R1)
yes
MS-100
•
FTP
•
IKE
•
TFTP
•
SIP
•
RTSP
•
PPPT
Copyright © 2018, Juniper Networks, Inc.
55
Adaptive Services Interfaces Feature Guide for Routing Devices
Table 7 on page 56 summarizes availability of translation types by type of line card.
Table 7: Carrier-Grade NAT Translation Types
MS-DPC
MS-400
MS-MPC
MPC1, MPC2, MPC3,
MPC5E, MPC6E, MPC7E,
MPC8E, and MPC9E
Translation Type
MS-500
MS-MIC
Inline NAT
basic-nat44
yes
yes
yes
basic-nat66
yes
no
no
basic-nat-pt
yes
no
no
deterministic-napt44
yes
yes (deterministic-napt44
supported for MS-MPC and
MS-MIC starting in Junos OS
release 17.3R1, in Junos OS
release 14.2R7 and later 14.2
releases, in 15.1R3 and later
15.1 releases, and in 16.1R5
and later 16.1 releases)
no
deterministic-napt64
no
yes (deterministic-napt64
supported for MS-MPC and
MS-MIC starting in Junos OS
release 17.4R1)
no
dnat-44
yes
yes
no
dynamic-nat44
yes
yes
no
napt-44
yes
yes
no
napt-66
yes
no
no
napt-pt
yes
no
no
stateful-nat464
no
yes (starting in Junos OS
Release 17.1R1)
no
stateful-nat64
yes
yes
no
twice-basic-nat-44
yes
yes (twice-dynamic-nat-44
supported for MS-MPC and
MS-MIC starting in Junos OS
Release 15.1R1)
yes (twice-basic-nat-44
supported for inline NAT
starting in Junos OS Release
15.1R1)
MS-100
56
Copyright © 2018, Juniper Networks, Inc.
Chapter 4: NAT Overview
Table 7: Carrier-Grade NAT Translation Types (continued)
MS-DPC
MS-400
MS-MPC
MPC1, MPC2, MPC3,
MPC5E, MPC6E, MPC7E,
MPC8E, and MPC9E
Translation Type
MS-500
MS-MIC
Inline NAT
twice-dynamic-nat-44
yes
yes (twice-dynamic-nat-44
supported for MS-MPC and
MS-MIC starting in Junos OS
Release 15.1R1)
no
twice-dynamic-napt-44
yes
yes (twice-dynamic-napt-44
supported for MS-MPC and
MS-MIC starting in Junos OS
Release 15.1R1)
no
MS-100
Copyright © 2018, Juniper Networks, Inc.
57
Adaptive Services Interfaces Feature Guide for Routing Devices
Release History Table
Related
Documentation
58
•
Release
Description
17.4R1
Starting in Junos OS release 17.4R1, inline NAT is supported on the MPC7E,
MPC8E, and MPC9E.
17.4R1
Dynamic Source NAT - NAPT64 Port Translation with Deterministic Port
Block Allocation supported for MS-MPC and MS-MIC
17.4R1
DS-Lite supported for MS-MPC and MS-MIC
17.4R1
deterministic-napt64 supported for MS-MPC and MS-MIC
17.4.R1
Port forwarding is supported for MS-MPC and MS-MIC
17.2R1
Starting in Junos OS release 17.2R1, inline NAT is supported on the MPC5E
and MPC6E.
17.1R4
Port Control Protocol with NAPT44 is supported for MS-MPC and MS-MIC
17.1R1
464XLAT
17.1R1
stateful-nat464
15.1R1
Twice NAT supported for MS-MPC and MS-MIC
15.1R1
NAPT - Preserve Parity and Range supported for MS-MPC and MS-MIC
15.1R1
No translation supported for MS-MPC and MS-MIC
15.1R1
twice-dynamic-nat-44 supported for MS-MPC and MS-MIC
15.1R1
twice-basic-nat-44 supported for inline NAT
15.1R1
twice-dynamic-nat-44 supported for MS-MPC and MS-MIC
15.1R1
twice-dynamic-napt-44 supported for MS-MPC and MS-MIC
14.2R7
Dynamic Source NAT - NAPT44 Port Translation with Deterministic Port
Block Allocation supported for MS-MPC and MS-MIC
14.2R7
IKE ALG
14.2R7
deterministic-napt44 supported for MS-MPC and MS-MIC
14.2R2
Dynamic Source NAT - NAPT Port Translation with Secured Port Block
Allocation supported for MS-MPC and MS-MIC
Junos OS Carrier-Grade NAT Implementation Overview on page 52
Copyright © 2018, Juniper Networks, Inc.
CHAPTER 5
NAT Configuration Overview
•
Network Address Translation Configuration Overview on page 59
•
Configuring Source and Destination Addresses Network Address Translation
Overview on page 60
•
Configuring Pools of Addresses and Ports for Network Address Translation
Overview on page 61
•
Network Address Translation Rules Overview on page 63
•
Configuring Service Sets for Network Address Translation on page 71
•
Carrier-Grade NAT Implementation: Best Practices on page 73
Network Address Translation Configuration Overview
To configure network address translation (NAT), complete the following high-level steps:
1.
Configure the source and destination addresses. For more information, see “Configuring
Source and Destination Addresses Network Address Translation Overview” on page 60.
2. Define the addresses or prefixes, address ranges, and ports used for NAT. For more
information, see “Configuring Pools of Addresses and Ports for Network Address
Translation Overview” on page 61
3. If applicable, configure the address pools for network address port translation (NAPT).
For more information, see “Configuring Address Pools for Network Address Port
Translation (NAPT) Overview” on page 115.
4. Configure the NAT rules. Within the rules, include match directions, match conditions,
actions, and translation types. For more information, see “Network Address Translation
Rules Overview” on page 63.
5. Configure service sets for NAT processing. Within each service set, define the interfaces
for handling inbound and outbound traffic and a NAT rule or ruleset. For more
information, see “Configuring Service Sets for Network Address Translation” on page 71.
Copyright © 2018, Juniper Networks, Inc.
59
Adaptive Services Interfaces Feature Guide for Routing Devices
Related
Documentation
•
Junos Address Aware Network Addressing Overview on page 45
•
Carrier-Grade NAT Feature Comparison for Junos Address Aware by Type of Interface
Card on page 53
Configuring Source and Destination Addresses Network Address Translation Overview
You must configure a specific address, a prefix, or the address-range boundaries:
•
The following addresses, while valid in inet.0, cannot be used for NAT translation:
•
0.0.0.0/32
•
127.0.0.0/8 (loopback)
•
128.0.0.0/16 (martian)
•
191.255.0.0/16 (martian)
•
192.0.0.0/24 (martian)
•
223.255.255.0/24 (martian)
•
224.0.0.0/4 (multicast)
•
240.0.0.0/4 (reserved)
•
255.255.255.255 (broadcast)
The addresses that are specified as valid in the inet.0 routing table and not supported
for NAT translation are orlonger match filter types. You cannot specify any regions
within such address prefixes in a NAT pool.
60
•
On MX Series routers with MS-MPCs and MS-MICs, if you configure a NAT address
pool with a prefix length that is equal to or greater than /16, the PIC does not contain
sufficient memory to provision the configured pool. Also, memory utilization problems
might occur if you attempt to configure many pools whose combined total IP addresses
exceed /16. In such circumstances, a system logging message is generated stating that
the NAT pool name is failed to be created and that the service set is not activated. On
MS-MPCs and MS-MICs, you must not configure NAT pools with prefix lengths greater
than or equal to /16.
•
You can specify one or more IPv4 address prefixes in the pool statement and in the
from clause of the NAT rule term. This enables you to configure source translation from
a private subnet to a public subnet without defining a rule term for each address in the
subnet. Destination translation cannot be configured by this method. For more
information, see Examples: Configuring NAT Rules.
•
When you configure static source NAT, the address prefix size you configure at the [edit
services nat pool pool-name] hierarchy level must be larger than the source-address
prefix range configured at the [edit services nat rule rule-name term term-name from]
hierarchy level. The source-address prefix range must also map to a single subnet or
Copyright © 2018, Juniper Networks, Inc.
Chapter 5: NAT Configuration Overview
range of IPv4 or IPv6 addresses in the pool statement. Any pool addresses that are
not used by the source-address prefix range are left unused. Pools cannot be shared.
•
When you configure a NAT address pool prefix size with the address statement at the
[edit services nat pool nat-pool-name] hierarchy level, the subnet and broadcast
addresses are not included in the list of usable IP addresses. For example, if you use
address 10.11.12.0/28 in a NAT pool, the addresses 10.11.12.0 (subnet address) and
10.11.12.15 (broadcast address) are not available.
NOTE: When you include a NAT configuration that changes IP addresses, it
might affect forwarding path features elsewhere in your router configuration,
such as source class usage (SCU), destination class usage (DCU), filter-based
forwarding, or other features that target specific IP addresses or prefixes.
NAT configuration might also affect routing protocol operation, because the
protocol peering, neighbor, and interface addresses can be altered when
routing protocols packets transit the Adaptive Services (AS) or Multiservices
PIC.
Related
Documentation
•
Junos Address Aware Network Addressing Overview on page 45
Configuring Pools of Addresses and Ports for Network Address Translation Overview
•
Configuring NAT Pools on page 61
•
Preserve Range and Preserve Parity on page 62
•
Specifying Destination and Source Prefixes Without Configuring a Pool on page 63
Configuring NAT Pools
You can use the pool statement to define the addresses (or prefixes), address ranges,
and ports used for Network Address Translation (NAT). To configure the information,
include the pool statement at the [edit services nat] hierarchy level.
Starting in Junos OS Release 14.2, configure the NAT pool as follows. Starting in Junos
OS Release 16.1, the limit-ports-per-address statement is supported.
[edit services nat]
pool nat-pool-name {
address ip-prefix</prefix-length>;
address-range low minimum-value high maximum-value;
limit-ports-per-address number;
port {
automatic (sequential | random-allocation);
range low minimum-value high maximum-value random-allocation;
preserve-parity;
preserve-range {
}
}
Copyright © 2018, Juniper Networks, Inc.
61
Adaptive Services Interfaces Feature Guide for Routing Devices
In Junos OS Release 14.1 and earlier, configure the NAT pool as follows:
[edit services nat]
pool nat-pool-name {
address ip-prefix</prefix-length>;
address-range low minimum-value high maximum-value;
port (automatic | range low minimum-value high maximum-value);
preserve-parity;
preserve-range {
}
}
To configure pools for traditional NAT, specify either a destination pool or a source pool.
With static source NAT and dynamic source NAT, you can specify multiple IPv4 addresses
(or prefixes) and IPv4 address ranges. Up to 32 prefixes or address ranges (or a
combination) can be supported within a single pool.
With static destination NAT, you can also specify multiple address prefixes and address
ranges in a single term. Multiple destination NAT terms can share a destination NAT pool.
However, the netmask or range for the from address must be smaller than or equal to
the netmask or range for the destination pool address. If you define the pool to be larger
than required, some addresses will not be used. For example, if you define the pool size
as 100 addresses and the rule specifies only 80 addresses, the last 20 addresses in the
pool are not used.
For constraints on specific translation types, see “Network Address Translation Rules
Overview” on page 63.
With source static NAT, the prefixes and address ranges cannot overlap between separate
pools.
In an address range, the low value must be a lower number than the high value. When
multiple address ranges and prefixes are configured, the prefixes are depleted first,
followed by the address ranges.
When you specify a port for dynamic source NAT, address ranges are limited to a
maximum of 65,000 addresses, for a total of (65,000 x 65,535) or 4,259,775,000 flows.
A dynamic NAT pool with no address port translation supports up to 65,535 addresses.
There is no limit on the pool size for static source NAT.
Preserve Range and Preserve Parity
You can configure your carrier-grade NAT (CGN) to preserve the range or parity of the
packet source port when it allocates a source port for an outbound connection. You can
configure the preserve parity and preserve range options under the NAT pool definition
by including the preserve-range and preserve-parity configuration statements at the [edit
services nat pool poolname port] hierarchy level.
Preserving range and preserving parity are supported on MX series routers with MS-DPCs
and on M Series routers with MS-100, MS-400, and MS-500 MultiServices PICS.
Preserving range and preserving parity are supported on MX series routers with MS-MPCs
and MS-MICs starting in Junos OS release 15.1R1.
62
Copyright © 2018, Juniper Networks, Inc.
Chapter 5: NAT Configuration Overview
•
Preserve range—RFC 4787, Network Address Translation (NAT) Behavioral Requirements
for Unicast UDP, defines two ranges: 0 through 1023, and 1024 through 65,535. When
the preserve-range knob is configured and the incoming port falls into one of these
ranges, CGN allocates a port from that range only. However, if there is no available
port in the range, the port allocation request fails and that session is not created. The
failure is reflected on counters and system logging, but no Internet Control Message
Protocol (ICMP) message is generated. If this knob is not configured, allocation is based
on the configured port range without regard to the port range that contains the incoming
port. The exception is some application-level gateways (ALGs), such as hello, that
have special zones.
•
Preserve parity—When the preserve-parity knob is configured, CGN allocates a port
with the same even or odd parity as the incoming port. If the incoming port number is
odd or even, the outgoing port number should correspondingly be odd or even. If a port
number of the desired parity is not available, the port allocation request fails, the
session is not created, and the packet is dropped.
Specifying Destination and Source Prefixes Without Configuring a Pool
You can directly specify the destination or source prefix used in NAT without configuring
a pool.
To configure the information, include the rule statement at the [edit services nat] hierarchy
level:
[edit services nat]
rule rule-name {
term term-name {
then {
translated {
destination-prefix prefix;
}
}
}
}
Release History Table
Release
Description
16.1
Starting in Junos OS Release 16.1, the limit-ports-per-address statement
is supported.
14.2
Starting in Junos OS Release 14.2, configure the NAT pool as follows.
Network Address Translation Rules Overview
To configure a NAT rule, include the rule rule-name statement at the [edit services nat]
hierarchy level:
[edit services nat]
rule rule-name {
match-direction (input | output);
Copyright © 2018, Juniper Networks, Inc.
63
Adaptive Services Interfaces Feature Guide for Routing Devices
term term-name {
from {
application-sets set-name;
applications [ application-names ];
destination-address (address | any-unicast) <except>;
destination-address-range low minimum-value high maximum-value <except>;
destination-prefix-list list-name <except>;
source-address (address | any-unicast) <except>;
source-address-range low minimum-value high maximum-value <except>;
source-prefix-list list-name <except>;
}
then {
no-translation;
translated {
address-pooling paired;
clat-prefix clat-prefix;
destination-pool nat-pool-name;
destination-prefix destination-prefix;
dns-alg-pool dns-alg-pool;
dns-alg-prefix dns-alg-prefix;
filtering-type endpoint-independent;
mapping-type endpoint-independent;
overload-pool overload-pool-name;
overload-prefix overload-prefix;
source-pool nat-pool-name;
source-prefix source-prefix;
translation-type {
(basic-nat-pt | basic-nat44 | basic-nat66 | dnat-44 | dynamic-nat44 | napt-44 |
napt-66 | napt-pt | stateful-nat464 | stateful-nat64 | twice-basic-nat-44 |
twice-dynamic-nat-44 | twice-napt-44);
}
}
syslog;
}
}
}
Each rule must include a match-direction statement that specifies the direction in which
the match is applied.
In addition, each NAT rule consists of a set of terms, similar to a firewall filter. A term
consists of the following:
•
from statement—Specifies the match conditions and applications that are included
and excluded.
•
then statement—Specifies the actions and action modifiers to be performed by the
router software.
The following sections explain how the components of NAT rules:
64
•
Configuring Match Direction for NAT Rules on page 65
•
Configuring Match Conditions in NAT Rules on page 65
•
Configuring Actions in NAT Rules on page 66
Copyright © 2018, Juniper Networks, Inc.
Chapter 5: NAT Configuration Overview
•
Configuring Translation Types on page 68
•
Configuring NAT Rules for IPsec Passthrough for Non-NAT-T Peers on page 70
Configuring Match Direction for NAT Rules
Each rule must include a match-direction statement that specifies the direction in which
the match is applied. To configure where the match is applied, include the match-direction
statement at the [edit services nat rule rule-name] hierarchy level:
[edit services nat rule rule-name]
match-direction (input | output);
The match direction is used with respect to the traffic flow through the Multiservices
DPC and Multiservices PICs. When a packet is sent to the PIC, direction information is
carried along with it. The packet direction is determined based on the following criteria:
•
With an interface service set, packet direction is determined by whether a packet is
entering or leaving the interface on which the service set is applied.
•
With a next-hop service set, packet direction is determined by the interface used to
route the packet to the Multiservices DPC or Multiservices PIC. If the inside interface
is used to route the packet, the packet direction is input. If the outside interface is used
to direct the packet to the PIC or DPC, the packet direction is output. For more
information about inside and outside interfaces, see “Configuring Service Sets to be
Applied to Services Interfaces” on page 9.
•
On the Multiservices DPC and Multiservices PIC, a flow lookup is performed. If no flow
is found, rule processing is performed. All rules in the service set are considered. During
rule processing, the packet direction is compared against rule directions. Only rules
with direction information that matches the packet direction are considered.
Configuring Match Conditions in NAT Rules
To configure NAT match conditions, include the from statement at the [edit services nat
rule rule-name term term-name] hierarchy level:
[edit services nat rule rule-name term term-name]
from {
application-sets set-name;
applications [ application-names ];
destination-address (address | any-unicast) <except>;
destination-address-range low minimum-value high maximum-value <except>;
destination-prefix-list list-name <except>;
source-address (address | any-unicast) <except>;
source-address-range low minimum-value high maximum-value <except>;
source-prefix-list list-name <except>;
}
To configure traditional NAT, you can use the destination address, a range of destination
addresses, the source address, or a range of source addresses as a match condition, in
the same way that you would configure a firewall filter; for more information, see the
Routing Policies, Firewall Filters, and Traffic Policers Feature Guide.
Alternatively, you can specify a list of source or destination prefixes by including the
prefix-list statement at the [edit policy-options] hierarchy level and then including either
Copyright © 2018, Juniper Networks, Inc.
65
Adaptive Services Interfaces Feature Guide for Routing Devices
the destination-prefix-list or source-prefix-list statement in the NAT rule. For an example,
see “Examples: Configuring Stateful Firewall Rules” on page 409.
If the translation-type statement in the then statement of the NAT rule is set to
stateful-nat-64, the range specified by the destination-address-range or the
destination-prefix-list in the from statement must be within the range specified by the
destination-prefix statement in the then statement.
If at least one NAT term within a NAT rule has the address pooling paired (APP)
functionality enabled (by including the address-pooling statement at the [edit services
nat rule rule-name term term-name then translated] hierarchy level, all the other terms in
the NAT rule that use the same NAT address pool as the address pool for the term with
APP enabled must have APP enabled. Otherwise, if you add a NAT rule term without
enabling APP to a rule that contains other terms with APP enabled, all the terms with
APP enabled in a NAT rule drop traffic flows that match the specified criteria in the NAT
rule.
For MX Series routers with MS-MICs and MS-MPCs, although the address pooling paired
(APP) functionality is enabled within a NAT rule (by including the address-pooling
statement at the [edit services nat rule rule-name term term-name then translated]
hierarchy level), it is a characteristic of a NAT pool. Such a NAT pool for which APP is
enabled cannot be shared with NAT rules that do not have APP configured.
When configuring NAT, if any traffic is destined for the following addresses and does not
match a NAT flow or NAT rule, the traffic is dropped:
•
Addresses specified in the from destination-address statement when you are using
destination translation
•
Addresses specified in the source NAT pool when you are using source translation
Configuring Actions in NAT Rules
To configure NAT actions, include the then statement at the [edit services nat rule
rule-name term term-name] hierarchy level:
[edit services nat]
rule rule-name {
term term-name {
from {
destination-address-range low minimum-value high maximum-value <except>;
destination-prefix-list list-name <except>;
}
then {
destination-prefix destination-prefix;
}
[edit services nat rule rule-name term term-name]
then {
no-translation;
syslog;
translated {
clat-prefix clat-prefix;
destination-pool nat-pool-name;
66
Copyright © 2018, Juniper Networks, Inc.
Chapter 5: NAT Configuration Overview
destination-prefix destination-prefix;
source-pool nat-pool-name;
source-prefix source-prefix;
translation-type (basic-nat-pt | basic-nat44 | basic-nat66 | dnat-44 | dynamic-nat44
| napt-44 | napt-66 | napt-pt | stateful-nat464 | stateful-nat64 | twice-basic-nat-44
| twice-dynamic-nat-44 | twice-napt-44);
}
}
}
•
The no-translation statement allows you to specify addresses that you want excluded
from NAT.
The no-translation statement is supported on MX series routers with MS-DPCs and on
M Series routers with MS-100, MS-400, and MS-500 MultiServices PICS. The
no-translation statement is supported on MX series routers with MS-MPCs and MS-MICs
starting in Junos OS release 15.1R1.
•
The system log statement enables you to record an alert in the system logging facility.
•
The destination-pool, destination-prefix, source-pool, and source-prefix statements
specify addressing information that you define by including the pool statement at the
[edit services nat] hierarchy level; for more information, see “Configuring Pools of
Addresses and Ports for Network Address Translation Overview” on page 61.
•
The translation-type statement specifies the type of NAT used for source or destination
traffic. The options are basic-nat-pt, basic-nat44, basic-nat66, dnat-44, dynamic-nat44,
napt-44, napt-66, napt-pt, stateful-nat464, stateful-nat64, twice-basic-nat-44,
twice-dynamic-nat-44, and twice-napt-44.
NOTE: In Junos OS Release 13.2 and earlier, the following restriction was not
enforced by the CLI: if the translation-type statement in the then statement
of a NAT rule was set to stateful-nat-64, the range specified by the
destination-address-range or the destination-prefix-list in the from statement
needed to be within the range specified by the destination-prefix statement
in the then statement. Starting in Junos OS Release 13.3R1, this restriction is
enforced.
Copyright © 2018, Juniper Networks, Inc.
67
Adaptive Services Interfaces Feature Guide for Routing Devices
Configuring Translation Types
The implementation details of the nine options of the translation-type statement are as
follows:
•
basic-nat44—This option implements the static translation of source IP addresses
without port mapping. You must configure the from source-address statement in the
match condition for the rule. The size of the address range specified in the statement
must be the same as or smaller than the source pool. You must specify either a source
pool or a destination prefix. The referenced pool can contain multiple addresses but
you cannot specify ports for translation.
NOTE: In an interface service set, all packets destined for the source
address specified in the match condition are automatically routed to the
services PIC, even if no service set is associated with the interface.
NOTE: Prior to Junos OS Release 11.4R3, you could only use a source NAT
pool in a single service set. As of Junos OS Release 11.4R3 and subsequent
releases, you can reuse a source NAT pool in multiple service sets.
•
basic-nat66—This option implements the static translation of source IP addresses
without port mapping in IPv6 networks. The configuration is similar to the basic-nat44
implementation, but with IPv6 addresses.
The basic-nat66 option is not available if you are using MS-MPCs or MS-MICs.
•
basic-nat-pt—This option implements translation of addresses of IPv6 hosts, as they
originate sessions to the IPv4 hosts in an external domain and vice versa. This option
is always implemented with DNS ALG. You must define the source and destination
pools of IPv4 addresses. You must configure one rule and define two terms. Configure
the IPv6 addresses in the from statement in both term statements. In the then statement
of the first term within the rule, reference both the source and destination pools and
configure dns-alg-prefix. Configure the source prefix in the then statement of the second
term within the same rule.
The basic-nat-pt option is not available if you are using MS-MPCs or MS-MICs.
•
deterministic-napt44—This option implements algorithm-based allocation of blocks
of destination ports and IP address. This ensures that an incoming (source) IP address
and port always map to the same destination IP address and port, thus eliminating
the need for the address translation logging. When you use deterministic-napt44, you
must also use deterministic-port-block-allocation at the [edit services nat pool poolname
port] hierarchy level.
The deterministic-napt44 option is supported on MX series routers with MS-DPCs and
on M Series routers with MS-100, MS-400, and MS-500 MultiServices PICS. The
deterministic-napt44 option if you are using MX Series routers with MS-MPCs or
68
Copyright © 2018, Juniper Networks, Inc.
Chapter 5: NAT Configuration Overview
MS-MICs is supported only in Junos OS release 14.2R7 and later 14.2 releases and in
release 15.1R3 and later 15.1 releases.
•
dnat-44—This option implements static translation of destination IP addresses without
port mapping. The size of the pool address space must be greater than or equal to the
destination address space. You must specify a name for the destination pool statement.
The referenced pool can contain multiple addresses, ranges, or prefixes, as long as the
number of NAT addresses in the pool is larger than the number of destination addresses
in the from statement. You must include exactly one destination-address value at the
[edit services nat rule rule-name term term-name from] hierarchy level; if it is a prefix,
the size must be less than or equal to the pool prefix size. Any addresses in the pool
that are not matched in the value remain unused, because a pool cannot be shared
among multiple terms or rules.
•
dynamic-nat44—This option implements dynamic translation of source IP addresses
without port mapping. You must specify a source-pool. The referenced pool must
include an address configuration (for address-only translation).
The dynamic-nat44 address-only option supports translating up to 16,777,216 addresses
to a smaller size pool. The requests from the source address range are assigned to the
addresses in the pool until the pool is used up, and any additional requests are rejected.
A NAT address assigned to a host is used for all concurrent sessions from that host.
The address is released to the pool only after all the sessions for that host expire. This
feature enables the router to share a few public IP addresses between several private
hosts. Because all the private hosts might not simultaneously create sessions, they
can share a few public IP addresses.
•
napt-44—This option implements dynamic translation of source IP addresses with
port mapping. You must specify a name for the source-pool statement. The referenced
pool must include a port configuration. If the port is configured as automatic or a port
range is specified, then it implies that Network Address Port Translation (NAPT) is
used.
•
napt-66—This option implements dynamic address translation of source IP addresses
with port mapping for IPv6 addresses. The configuration is similar to the napt-44
implementation, but with IPv6 addresses.
The napt-66 option is not available if you are using MS-MPCs or MS-MICs.
•
napt-pt—This option implements dynamic address and port translation for source and
static translation of destination IP address. You must specify a name for the source-pool
statement. The referenced pool must include a port configuration (for NAPT).
Additionally, you must configure two rules, one for the DNS traffic and the other for
the rest of the traffic. The rule meant for the DNS traffic should be DNS ALG enabled
and the dns-alg-prefix statement should be configured. Moreover, the prefix configured
in the dns-alg-prefix statement must be used in the second rule to translate the
destination IPv6 addresses to IPv4 addresses.
The napt-pt option is not available if you are using MS-MPCs or MS-MICs.
•
stateful-nat464—This option implements 464XLAT Provider-Side Translater (PLAT)
address translation for source IP addresses and IPv6 prefix removal translation for
destination IPv4 addresses. You must specify the IPv4 addresses used for translation
Copyright © 2018, Juniper Networks, Inc.
69
Adaptive Services Interfaces Feature Guide for Routing Devices
at the [edit services nat pool] hierarchy level. This pool must be referenced in the rule
that translates the IPv6 addresses to IPv4.
The stateful-nat464 option is available only if you are using MS-MPCs or MS-MICs,
and is supported starting in Junos OS Release 17.1R1.
•
stateful-nat64—This option implements dynamic address and port translation for
source IP addresses and prefix removal translation for destination IP addresses. You
must specify the IPv4 addresses used for translation at the [edit services nat pool]
hierarchy level. This pool must be referenced in the rule that translates the IPv6
addresses to IPv4.
•
twice-basic-nat-44—This option implements static source and static destination
translation for IPv4 addresses, thus combining basic-nat44 for source and dnat-44 for
destination addresses.
The twice-basic-nat-44 option is supported on MS-DPCs and MS-100, MS-400, and
MS-500 MultiServices PICS. The twice-basic-nat-44 option is supported on MS-MPCs
and MS-MICs starting in Junos OS Release 15.1R1.
•
twice-dynamic-nat-44—This option implements source dynamic and destination static
translation for IPv4 addresses, combining dynamic-nat44 for source and dnat-44 for
destination addresses.
The twice-dynamic-nat-44 option is supported on MS-DPCs and MS-100, MS-400,
and MS-500 MultiServices PICS. The twice-dynamic-nat-44 option is supported on
MS-MPCs and MS-MICs starting in Junos OS Release 15.1R1.
•
twice-napt-44—This option implements source NAPT and destination static translation
for IPv4 addresses, combining napt-44 for source and dnat-44 for destination addresses.
The twice-napt-44 option is supported on MS-DPCs and MS-100, MS-400, and MS-500
MultiServices PICS. The twice-napt-44 option is supported on MS-MPCs and MS-MICs
starting in Junos OS Release 15.1R1.
For more information on NAT methods, see RFC 2663, IP Network Address Translator
(NAT) Terminology and Considerations.
Configuring NAT Rules for IPsec Passthrough for Non-NAT-T Peers
Starting in Junos OS Release 14.2R7, 15.1R5, 16.1R2, and 17.1R1, you can pass IKEv1 and
IPsec packets through NAPT-44 and NAT64 rules between IPsec peers that are not
NAT-T compliant. Only ESP tunnel mode is supported. This feature is supported only on
MS-MPCs and MS-MICs.
To configure NAT rules for IPsec passthrough for NAPT-44 or NAT64:
1.
Configure an IKE ALG application. See “Configuring Application Properties” on page 367.
2. Add the application to an application set. See “Configuring Application Sets” on
page 367.
70
Copyright © 2018, Juniper Networks, Inc.
Chapter 5: NAT Configuration Overview
3. Configure a NAT pool. See “Configuring Pools of Addresses and Ports for Network
Address Translation Overview” on page 61.
4. Configure the NAT rule:
a. Configure a match direction for the rule. See “Configuring Match Direction for NAT
Rules” on page 65.
b. Configure one of the matching conditions to be the application set for IKE and
IPsec passthrough that you configured in Step 2.
[edit services nat rule rule-name term term-name from]
user@host# set application-sets set-name
c. Configure other match conditions. See “Configuring Match Conditions in NAT Rules”
on page 65.
d. Configure the translation type as NAPT-44 or NAT64.
[edit services nat rule rule-name term term-name then translated]
user@host# set translation-type (napt-44 | stateful-nat64)
e. Configure other NAT actions. See “Configuring Actions in NAT Rules” on page 66.
5. Assign the NAT rule to a service set.
[edit services]
user@host# set service-set service-set-name nat-rules rule-name
Release History Table
Related
Documentation
•
Release
Description
17.1R1
Starting in Junos OS Release 14.2R7, 15.1R5, 16.1R2, and 17.1R1, you can pass
IKEv1 and IPsec packets through NAPT-44 and NAT64 rules between IPsec
peers that are not NAT-T compliant.
Junos Address Aware Network Addressing Overview on page 45
Configuring Service Sets for Network Address Translation
When configuring a service set for NAT processing, make sure you have defined:
•
Service interface(s) for handling inbound and outbound traffic
Copyright © 2018, Juniper Networks, Inc.
71
Adaptive Services Interfaces Feature Guide for Routing Devices
NOTE: Prior to Junos OS Release 11.4R3, you could only use a source NAT
pool in a single service set. As of Junos OS Release 11.4R3 and subsequent
releases, you can reuse a source or destination NAT pool in multiple service
sets, provided that the service interfaces associated with the service sets
are in different virtual routing and forwarding (VRF) instances.
•
For interface style service sets, when a NAT pool is reused in multiple
service sets, the service interfaces used in the interface-service
service-interface option of each service set must be in different VRFs.
•
For next-hop style service sets, when a NAT pool is reused in multiple
service sets, the service interfaces used in the outside-interface option
of each service set must be in different VRFs.
Not adhering to these service interface restrictions will cause multiple
routes to be installed in the same VRF for the same NAT addresses, causing
reverse traffic to be processed incorrectly.
To enable sharing of source NAT pools, include the
allow-overlapping-nat-pools statement at the [edit services nat] hierarchy
level.
•
A NAT rule or ruleset
NOTE: To configure an MS-DPC interface to be used exclusively for
carrier-grade NAT (CGN) or related services (intrusion detection, stateful
firewall, and softwire), include the cgn-pic statement at the [edit interfaces
interface-name services-options] hierarchy level. This allows CGN to access
all of the available memory on the MS-DPC.
To configure a NAT service set:
1.
At the [edit services] hierarchy level, define the service set.
[edit services]
user@host# edit service-set service-set-name
2. Configure either an interface service, which requires a single service interface, or a
next-hop service, which requires an inside and outside service interface.
[edit services service-set service-set-name]
user@host# set interface-service service-interface interface-name
Or
[edit services service-set service-set-name]
user@host# set next-hop-service inside-service-interface interface-name
outside-service-interface interface-name
72
Copyright © 2018, Juniper Networks, Inc.
Chapter 5: NAT Configuration Overview
NOTE: If you have a Trio-based line card (MPC/MIC), you can use an
inline-services interface that was configured on that card, as shown in this
example:
[edit]
user@host# set interfaces si-0/0/0
[edit services service-set s1]
user@host# set interface-service service-interface si-0/0/0
For more information on interface service and next-hop service, see ““Configuring
Service Sets to be Applied to Services Interfaces” on page 9.”
3. Configure a reference to the NAT rules or ruleset to be used with the service set.
[edit services service-set service-set-name]
user@host set nat-rules rule-or-ruleset-name
4. (Optional) For NAT64, specify that the don’t fragment (DF) bit for IPv4 packet headers
is cleared when packet length is less than 1280 bytes.
[edit services service-set service-set-name]
user@host# set nat-options stateful-nat64 clear-dont-fragment-bit
Related
Documentation
•
Configuring Service Sets to be Applied to Services Interfaces on page 9
Carrier-Grade NAT Implementation: Best Practices
The following topics present the best practices for carrier-grade NAT implementation:
•
Use Round-Robin Address-Allocation When Using APP with the MS-DPC on page 74
•
Use the EIM Feature Only When Needed on page 74
•
Define Port Block Allocation Block Sizes Based on Expected Number of User
Sessions on page 75
•
Considerations When Changing Port Block Allocation Configuration on Running
Systems on page 76
•
Do Not Allocate NAT Pools That Are Larger Than Needed on page 77
•
Configure System Logging for NAT Only When Needed on page 78
•
Limit the Impact of Missing IP Fragments on page 79
•
Do Not Use Configurations Prone to Packet Routing Loops on page 80
•
Inactivity Timeouts on page 81
•
Enable Dump on Flow Control on page 83
Copyright © 2018, Juniper Networks, Inc.
73
Adaptive Services Interfaces Feature Guide for Routing Devices
Use Round-Robin Address-Allocation When Using APP with the MS-DPC
BEST PRACTICE: If you are using an MS-DPC and you configure
address-pooling paired (APP) in a NAT rule, you should use round-robin
address allocation for the NAT pool.
The APP feature maps a private IP address to the same public IP address in a NAT pool
for all the NAT sessions for that private IP address.
Sequential address allocation for NAT pools is the default on the MS-DPC, and allocates
all the ports for a public IP address before assigning the next IP address. Sequential
allocation, together with APP, might result in mapping multiple private hosts to the same
public IP address, resulting in fast port exhaustion for a public IP address while other
ports are still available from the remaining IP addresses in the NAT pool.
Round-robin allocation, on the other hand, assigns the next IP address in the NAT pool
to the next private IP address needing translation, reducing the chance that all the ports
for one public IP address are depleted.
For more information about APP and round-robin address allocation, see “Configuring
Address Pools for Network Address Port Translation (NAPT) Overview” on page 115.
NOTE: The MS-MPC and MS-MIC only use round-robin allocation.
The following example shows round-robin address allocation.
[edit services]
nat pool natpool-1 {
port {
automatic;
}
address-allocation round-robin;
mapping-timeout 120;
}
Use the EIM Feature Only When Needed
BEST PRACTICE: Do not use endpoint-independent mapping (EIM) in NAT
rule terms that include Junos ALGs. EIM assigns the same external NAT
address and port for a specific session from a private host, but adds
processing overhead. EIM provides no benefit for any of the Junos ALGs, which
already employ the functionality used by EIM.
BEST PRACTICE: Enable EIM for applications that do reuse the source ports
and rely on a CGNAT device to maintain the same address and port mapping
74
Copyright © 2018, Juniper Networks, Inc.
Chapter 5: NAT Configuration Overview
for all traffic sent to different destinations. For example, use EIM for console
gaming applications such as Xbox and PS4 or applications that use unilateral
self-address fixing methods (UNSAF). See (IETF RFC 3424 IAB Considerations
for Unilateral Self-Address Fixing (UNSAF) Across Network Address
Translation).
For more information about EIM, see “Configuring Address Pools for Network Address
Port Translation (NAPT) Overview” on page 115.
The following example uses the Junos SIP ALG in the NAT rule, so EIM is not used.
[edit services nat]
rule natrule-1 {
match-direction input;
term1 {
from {
applications junos-sip;
}
}
then {
translated {
source-pool natpool-3;
translation-type {
napt-44;
}
address-pooling paired;
}
}
}
Define Port Block Allocation Block Sizes Based on Expected Number of User Sessions
BEST PRACTICE: For secure port block allocation and deterministic port
block allocation, define a port block allocation block size that is 2 to 4 times
larger than the expected average number of active sessions for a user. For
example, if the user is expected to have an average of approximately 200 to
250 NAT sessions active, configuring the block size to 512 or 1024 provides
a liberal allocation.
BEST PRACTICE: If you are rolling out secure port block allocation using the
MX Series as a NAT device and are not sure of your subscriber user profile
and traffic profile, set the port block size to 1024 if you have enough NAT IP
addresses to handle the estimated peak number of private subscribers. The
number of NAT IP addresses times 62 gives you the number of private
subscribers that can be handled with a port block size of 1024 (there are 62
blocks per IP address). Then, closely monitor the MX Series router by using
the show services nat pool detail command to determine whether the block
size needs to be changed.
Copyright © 2018, Juniper Networks, Inc.
75
Adaptive Services Interfaces Feature Guide for Routing Devices
BEST PRACTICE: Be careful not to make the block size too large if the number
of IP addresses you can allocate to the NAT pool is limited. Making a port
block size that is large enough to efficiently assign the blocks to your
subscribers might cause all the port blocks to be tied up.
Secure port block allocation allocates blocks of ports to a particular user for NAT44 or
NAT64. Secure port block allocation limits the number of syslog messages by generating
only one syslog per block of ports.
However, configuring the block size incorrectly can lead to inefficient use of NAT resources
or to performance issues. For example, when a user connects to a website that requires
the establishment of a significant number of sockets for a single HTML page, a
corresponding number of new ports must be allocated. The port block size should be
large enough to prevent continual allocation of new blocks. If the number of concurrent
sessions for a private subscriber exceeds the number of ports available in the active port
block, the other port blocks allocated to the subscriber are scanned for available ports
to use or a new block is allocated from the free block pool for the subscriber. The scanning
of allocated port blocks and allocation of additional blocks can result in delays in setting
up new sessions and loading web pages.
For more information about port block allocation, see “Configuring Secured Port Block
Allocation” on page 197 and “Configuring Deterministic NAPT” on page 143.
The following example sets the port block size to 1024.
[edit services nat]
pool natpool-1 {
address-range low 192.0.2.0 high 192.0.2.10;
port {
automatic;
secure-port-block-allocation {
block-size 1024;
max-blocks-per-user 8;
active-block-timeout 300;
}
}
mapping-timeout 300;
}
Considerations When Changing Port Block Allocation Configuration on Running Systems
BEST PRACTICE: Before changing the secure port block allocation or
deterministic port block configuration on a running system when using an
MS-MPC or MS-MIC, plan for a quick disruption in the NAT sessions. The
change in configuration results in the re-creation of all the current NAT
sessions.
76
Copyright © 2018, Juniper Networks, Inc.
Chapter 5: NAT Configuration Overview
BEST PRACTICE: Before changing the port block allocation configuration on
a running system when using an MS-DPC, plan for a disruption of services.
After changing the configuration, you must reboot the MS-DPC, or if this is
not possible, you must deactivate and reactivate the service set.
Changes to port block allocation configuration include:
•
Changing any NAT pool PBA configuration.
•
Changing a PBA NAT pool to a non-PBA NAT pool.
•
Changing a non-PBA NAT pool to a PBA NAT pool.
For more information about configuring port block allocation, see “Configuring Secured
Port Block Allocation” on page 197 and “Configuring Deterministic NAPT” on page 143.
Do Not Allocate NAT Pools That Are Larger Than Needed
MS-MPC and MS-MIC
BEST PRACTICE: When using NAPT44 as your translation type with the
MS-MIC or MS-MPC, do not configure NAT pools that are larger than needed
for the peak session rate, which would tie up valuable IPv4 resources. Each
conversation includes two sessions, an ingress and egress session. Each
conversation requires one port and each IP address in the pool has a
1024-65535 port range (64K), so the NAT pool size does not need to be larger
than:
peak number of conversations /64K
BEST PRACTICE: When using NAPT44 as your translation type with the
MS-MIC, do not configure NAT pools with more than 128 addresses (a /25
network).
BEST PRACTICE: When using NAPT44 as your translation type with the
MS-MPC, do not configure NAT pools with more than 256 addresses (a /24
network).
The maximum NAT pool size for an MS-MIC is 128 IP addresses because the MS-MIC
supports a maximum of 14 million sessions, or 7 million conversations, which require 7
million ports. A total of 7 million ports are available with 128 IP addresses, with each IP
address having a port range of 1024-65535.
The maximum NAT pool size for each slot on an MS-MPC is 256 IP addresses because
each slot supports a maximum of 30 million sessions, or 15 million conversations, which
Copyright © 2018, Juniper Networks, Inc.
77
Adaptive Services Interfaces Feature Guide for Routing Devices
require 15 million ports. A total of 15 million ports are available with 256 IP addresses,
with each IP address having a port range of 1024-65535.
For more information about configuring NAT pools, see “Configuring Pools of Addresses
and Ports for Network Address Translation Overview” on page 61.
MS-DPC
BEST PRACTICE: When using NAPT44 as your translation type with the
MS-DPC, do not configure NAT pools that are larger than needed for the peak
flow rate, which would tie up valuable IPv4 resources. Each conversation
includes two flows (1 reverse flow for each forward flow). Each conversation
requires one port and each IP address in the pool has a 1024-65535 port
range (64K), so the NAT pool size does not need to be larger than:
peak number of conversations /64K
BEST PRACTICE: When using NAPT44 as your translation type with the
MS-DPC, do not configure NAT pools with more than 64 addresses (a /26
network).
The maximum NAT pool size for an MS-DPC is 64 IP addresses because the MS-DPC
supports a maximum of 8 million flows, or 4 million conversations, which requires a
maximum of 4 million ports. A total of 4 million ports are available with 64 IP addresses,
with each IP address having a port range of 1024-65535. If APP, EIM, and EIF are enabled,
the MS-DPC supports a maximum of 5.8 million flows, or 2.9 million conversations, so
the maximum NAT pool size would be less.
For more information about configuring NAT pools, see “Configuring Pools of Addresses
and Ports for Network Address Translation Overview” on page 61.
Configure System Logging for NAT Only When Needed
BEST PRACTICE: Do not enable system logging per session for secure port
block allocation configurations.
BEST PRACTICE: Do not enable system logging for deterministic NAT
configurations.
BEST PRACTICE: Enable system logging at the service-set level rather than
at the services interface level when possible.
78
Copyright © 2018, Juniper Networks, Inc.
Chapter 5: NAT Configuration Overview
BEST PRACTICE: In production networks, always send the log messages to
an external system log server. This avoids adding CPU load to the Routing
Engine, which occurs when messages are logged locally.
BEST PRACTICE: Specify the system log class to restrict logging to the class
of applications in which you are interested.
BEST PRACTICE: If you configure system logging within a NAT rule term, use
a stateful firewall rule to restrict the traffic that reaches the NAT rule term.
System log messages can negatively affect the performance of the services card,
depending on the frequency of creation and deletion of sessions. All system log messages
created by the services card require CPU processing at the services card, and the system
log messages themselves constitute traffic that is sent across the MX Series router and
competes with user traffic to reach the external log server.
Secure port block allocation removes the need to configure logs per session, because
you know the block and block size and can derive the ports allocated to each user.
Deterministic NAT removes the need to log at all, because all information on port
allocation can be deduced mathematically.
The following example restricts logging to NAT events and sends log messages to the
external log server 203.0.113.4
[edit services service-set S-SET-1]
class {
nat-logs;
}
syslog {
host 203.0.113.4;
}
When you configure system logging within a NAT rule term, all traffic that enters the NAT
rule term generates a log, which can cause excessive logging. This might result in the
logging rate limit being reached, and you would lose logs that you do need.
For more information about configuring system logging for NAT, see “Configuring NAT
Session Logs” on page 257.
Limit the Impact of Missing IP Fragments
BEST PRACTICE: For the services interface that is configured for NAT, limit
the impact of missing or delayed fragments by configuring the following:
•
Copyright © 2018, Juniper Networks, Inc.
Maximum number of fragments for a packet
79
Adaptive Services Interfaces Feature Guide for Routing Devices
•
Maximum wait time for a missing fragment
IP fragments received by the services card configured for NAT are buffered as they arrive.
This allows an integrity check of the completely reassembled packet before the packet
is processed by NAT. Missing or delayed fragments can cause the already received
fragments to be held until the internal buffer is full and they are flushed out, resulting in
CPU usage overhead and reduced traffic forwarding.
Configuring the maximum number of fragments a packet can have and limiting the wait
time for a missing fragment reduces the chance of the internal buffer becoming full.
The following example sets the maximum number of fragments to 10 and the maximum
wait time to 3 seconds.
[edit interfaces ms-0/0/0]
services-options {
fragment-limit 10;
reassembly-timeout 3;
}
Do Not Use Configurations Prone to Packet Routing Loops
BEST PRACTICE: Prevent packet routing loops by ensuring that only the
intended traffic is allowed to reach the services card and be processed by
the service set NAT rule. You can do this by:
•
Configuring a source-address range under the NAT rule when possible.
•
Configuring a firewall filter that accepts only the traffic meant to be serviced
by the NAT rule in a next-hop style service set.
Packet looping between the Packet Forwarding Engine and the services card results in
persistent high CPU usage on the services card. Packet looping can be caused by the
services card receiving traffic from an unexpected private source network. When
unexpected traffic is processed by NAT, a pinhole is created, and in the case of EIF many
pinholes might be created. These pinholes cause routing loops if the return traffic routes
back through the services card.
The following example shows a firewall filter that only allows traffic from 198.51.100.0/24
to reach services interface ms-1/0/0, which is the inside interface for a next-hop service
set.
[edit firewall filter to_be_serviced]
term 1 {
from }
address {
}
198.51.100.0/24;
}
then accept;
80
Copyright © 2018, Juniper Networks, Inc.
Chapter 5: NAT Configuration Overview
}
term 2 {
then disard;
}
[edit interfaces ms-1/0/0]
unit 1 {
family intet {
filter {
output to_be_serviced;
}
}
service-domain inside;
}
For more information about configuring firewall filters, see the Routing Policies, Firewall
Filters, and Traffic Policers Feature Guide.
The following example shows a NAT rule that only processes traffic from 198.51.100.0/24
(other traffic reaches the services interface, but is not processed).
[edit services nat]
rule rule_1 {
match-direction input;
term t1 {
from {
source-address {
198.51.100.0/24;
}
}
then {
translated {
source-pool pool1;
translation-type {
napt-44;
}
}
}
}
}
For more information about configuring NAT rules, see “Network Address Translation
Rules Overview” on page 63.
Inactivity Timeouts
BEST PRACTICE: Set the inactivity timeout only for user-defined applications
that could require the NAT session mapping to remain in memory for longer
than the default NAT inactivity timeout of 30 seconds. For example, an HTTP
or HTTPS banking application may require more than 30 seconds of inactivity
because the user must enter data.
Copyright © 2018, Juniper Networks, Inc.
81
Adaptive Services Interfaces Feature Guide for Routing Devices
BEST PRACTICE: Before making changes to the existing inactivity timeouts,
run the following commands several times during peak hours. Then run the
commands after making the changes, and verify that the changes are not
starving the MX Series router of NAT resources or the services card of memory.
•
show services sessions count
•
show services nat pool detail
•
show services service-sets summary
The following example shows the inactivity timeout being set to 1800 seconds for HTTPS
and HTTP applications.
[edit applications]
application https {
inactivity-timeout 1800;
destination-port 443;
protocol tcp;
}
application http {
inactivity-timeout 1800;
destination-port 443;
protocol tcp;
}
For more information about configuring user-defined applications, see “Configuring
Application Properties” on page 367.
You need to weigh the risks of setting high inactivity timeouts for all traffic. While the
default NAT inactivity timeout of 30 seconds may be too low for some user-defined
applications, setting a timeout value too high can tie up NAT resources. For example,
setting high inactivity timeout values can tie up any TCP session that is inactive just
minutes after it was created. If the TCP session is not cleanly closed by a FIN or RST by
the client or server, the session will sit in memory and tie up the NAT resources assigned
to it until the timeout value expires.
Setting higher inactivity timeouts that impact every UDP and TCP port can be dangerous,
especially with UDP traffic like DNS. Unlike TCP, UDP has no way to end a session other
than timing out, so all UDP sessions would stay active for the full inactivity timeout value.
The following example is not a recommended configuration because it sets high inactivity
timeout values for all TCP and UDP traffic.
[edit applications]
application UDP-All {
protocol UDP;
source-port 1-65535;
inactivity-timeout 3600;
}
application TCP-All {
protocol TCP;
source-port 1-65535;
82
Copyright © 2018, Juniper Networks, Inc.
Chapter 5: NAT Configuration Overview
inactivity-timeout 3600;
}
We do not have specific recommended inactivity timeout values. The proper inactivity
timeout values depend on several factors, including:
•
What applications are used on an end user’s network
For example, Apple has stated that an inactivity timeout of 60 minutes is required for
the following Apple services, which require a long connection lifetime:
•
Apple Push Services: inbound TCP port 5223
•
Exchange Active Sync: inbound TCP port 443
•
MobileMe: inbound TCP ports 5222 and 5223
•
How the NAT solution is being used, for example as a Gi NAT device or as an Enterprise
edge router
•
How large your NAT pools are
•
How much traffic each services card receives during peak loads
•
How much memory you have available
Enable Dump on Flow Control
BEST PRACTICE: Enable the dump-on-flow-control option for any services
card that is processing NAT traffic in a production network. This option detects
when a services card is locked up, writes a core dump that Juniper Networks
can analyze to determine why the card locked up, and recovers the services
card by restarting it.
For the MS-MIC and MS-MPC, set the dump-on-flow-control option under the pcinterface, which is used to send control traffic from the Routing Engine to the services
card. The following example shows the configuration if the services interface is ms-2/1/0.
[edit interfaces pc-2/1/0]
multiservice-options {
flow-control-options {
dump-on-flow-control;
}
}
For the MS-DPC, set the dump-on-flow control option under the sp- interface. The
following example shows the configuration if the services interface is sp-2/1/0.
[edit interfaces sp-2/1/0]
multiservice-options {
flow-control-options {
dump-on-flow-control;
}
}
Copyright © 2018, Juniper Networks, Inc.
83
Adaptive Services Interfaces Feature Guide for Routing Devices
Related
Documentation
84
•
Network Address Translation Configuration Overview on page 59
Copyright © 2018, Juniper Networks, Inc.
CHAPTER 6
Avoiding IPv4 Exhaustion Using Junos
Address Aware Network Addressing and
Stateful NAT64
•
Sample IPv6 Transition Scenarios on page 85
•
Configuring Stateful NAT64 on page 87
Sample IPv6 Transition Scenarios
The Junos OS supports many IPv6 transition scenarios required by Junos OS customers.
The following are selected examples:
•
Example 1: IPv4 Depletion with a Non-IPv6 Access Network on page 85
•
Example 2: IPv4 Depletion with an IPv6 Access Network on page 86
•
Example 3: IPv4 Depletion for Mobile Networks on page 87
Example 1: IPv4 Depletion with a Non-IPv6 Access Network
Figure 7 on page 86 depicts a scenario in which the Internet service provider (ISP) has
not significantly changed its IPv4 network. This approach enables IPv4 hosts to access
the IPv4 Internet and IPv6 hosts to access the IPv6 Internet. A dual-stack host can be
treated as an IPv4 host when it uses the IPv4 access service, and as an IPv6 host when
it uses the IPv6 access service.
Copyright © 2018, Juniper Networks, Inc.
85
Adaptive Services Interfaces Feature Guide for Routing Devices
Figure 7: IPv4 Depletion Solution - IPv4 Access Network
6rd tunnel
IPv4 Internet
Local host
IPv4/Ethernet
6rd
concentrator
MPLS core
Local host
g017568
IPv6 Internet
Two new types of devices must be deployed in this approach: a dual-stack home gateway
and a dual-stack carrier-grade Network Address Translation (NAT). The dual-stack home
gateway integrates IPv4 forwarding and v6-over-v4 tunneling functions. It can also
integrate a v4-v4 NAT function. The dual-stack carrier-grade NAT (CGN) integrates
v6-over-v4 tunneling and carrier-grade v4-v4 NAT functions.
Example 2: IPv4 Depletion with an IPv6 Access Network
In the scenario shown in Figure 8 on page 86, the ISP network is IPv6-only.
Figure 8: IPv4 Depletion Solution - IPv6 Access Network
DS-Lite tunnel
IPv4 Internet
IPv6/Ethernet
CGN (AFTR)
MPLS core
g017569
IPv6 Internet
The dual-stack lite (DS-Lite) solution accommodates IPv6-only ISPs. The best business
model for this approach is that the customer premises equipment (CPE) has integrated
the functions for tunneling IPv6 to an IPv4 backbone, tunneling IPv4 to an IPv6 backbone,
and can automatically detect which solution is required.
Not all customers of a given ISP must switch from IPv4 access to IPv6 access
simultaneously; in fact, transition can be managed better by switching groups of
86
Copyright © 2018, Juniper Networks, Inc.
Chapter 6: Avoiding IPv4 Exhaustion Using Junos Address Aware Network Addressing and Stateful NAT64
customers (for example, all those connected to a single point of presence) on an
incremental basis. Such an incremental approach should prove easier to plan, schedule,
and execute than an across-the-board conversion.
Example 3: IPv4 Depletion for Mobile Networks
The complexity of mobile networks necessitates a flexible migration approach to ensure
minimal disruption and maximum backward compatibility during transition. NAT64 can
be used to enable IPv6 devices to communicate to IPv4 hosts without modifying the
clients.
Configuring Stateful NAT64
To configure stateful NAT64, you must configure a rule at the [edit services nat] hierarchy
level for translating the source address dynamically and the destination address statically.
BEST PRACTICE: When you configure the service set that includes your NAT
rule, include the set stateful-nat64 clear-dont-fragment-bit at the [edit services
service-set service-set-name] hierarchy level.This clears the DF (don't
fragment) bit in order to prevent unnecessary creation of an IPv6
fragmentation header when translating IPv4 packets that are less than 1280
bytes. RFC 6145, IP/ICMP Translation Algorithm, provides a full discussion of
the use of the DF flag to control generation of fragmentation headers. For
more information on service sets for NAT, see “Configuring Service Sets for
Network Address Translation” on page 71.
To configure stateful NAT64:
1.
In configuration mode, go to the [edit services nat] hierarchy level.
[edit]
user@host# edit services nat
2. Define the pool of source addresses to be used for dynamic translation.
[edit services nat]
user@host# set pool pool name address source addresses
user@host# set pool pool name port source ports
For example:
[edit services nat]
user@host# set pool src-pool-nat64 address 203.0.113.0/24
user@host# set pool src-pool-nat64 port automatic
Copyright © 2018, Juniper Networks, Inc.
87
Adaptive Services Interfaces Feature Guide for Routing Devices
NOTE: Starting in Junos OS release 14.2, the sequential option is introduced
to enable you to configure sequential allocation of ports. The sequential
and random-allocation options available with the port automatic statement
at the [edit services nat pool nat-pool-name] hierarchy level are mutually
exclusive. You can include the sequential option for sequential allocation
and the random-allocation option for random delegation of ports. By
default, sequential allocation of ports takes place if you include only the
port automatic statement at the [edit services nat pool nat-pool- name]
hierarchy level. The auto option is hidden and is deprecated in Junos OS
Release 14.2 and later, and is only maintained for backward compatibility.
It might be removed completely in a future software release.
3. Define a NAT rule for translating the source addresses. Set the match-direction
statement of the rule as input. Then define a term that uses stateful-nat64 as the
translation type for translating the addresses of the pool defined in the previous step.
[edit services nat]
user@host# set rule rule name match-direction input
user@host# set rule rule name term term name from source-address source address
user@host# set rule rule name term term name from destination-address destination
address
user@host# set rule rule name term term name then translated source-pool pool name
user@host# set rule rule name term term name then translated destination-prefix
destination prefix
user@host# set rule rule name term term name then translated translation-type
stateful-nat64
For example:
[edit services nat]
user@host# set rule stateful-nat64 match-direction input
user@host# set rule stateful-nat64 term t1 from source-address 2001:DB8::0/96
user@host# set rule stateful-nat64 term t1 from destination-address 64:FF9B::/96
user@host# set rule stateful-nat64 term t1 then translated source-pool src-pool-nat64
user@host# set rule stateful-nat64 term t1 then translated destination-prefix
64:FF9B::/96
user@host# set rule stateful-nat64 term t1 then translated translation-type
stateful-nat64
The following example configures dynamic source address (IPv6-to-IPv4) and static
destination address (IPv6-to-IPv4) translation.
[edit services]
user@host# show
nat {
pool src-pool-nat64 {
address 203.0.113.0/24;
port {
automatic;
}
}
rule stateful-nat64 {
88
Copyright © 2018, Juniper Networks, Inc.
Chapter 6: Avoiding IPv4 Exhaustion Using Junos Address Aware Network Addressing and Stateful NAT64
match-direction input;
term t1 {
from {
source-address {
2001:db8::0/96;
}
destination-address {
64:ff9b::/96;
}
}
then {
translated {
source-pool src-pool-nat64;
destination-prefix 64:ff9b::/96;
translation-type {
stateful-nat64;
}
}
}
}
}
}
service-set sset-nat64 {
nat-options {
stateful-nat64 {
clear-dont-fragment-bit;
}
}
service-set-options;
nat-rules stateful-nat64;
interface-service {
service-interface ms-0/1/0;
}
}
Copyright © 2018, Juniper Networks, Inc.
89
Adaptive Services Interfaces Feature Guide for Routing Devices
NOTE: If you configure two NAT64 rules and associate them with the same
service set, along with stateful firewall rules, and apply the service set on
two VLAN-tagged interfaces, for traffic that is transmitted matching both
the NAT rules, the traffic that is destined to the second NAT rule is dropped.
In such a scenario, traffic flows are not dropped on the Routing Engine. This
behavior of traffic drop by the second NAT rule is expected. With Junos OS
Extension-Provider packages installed on a device, because
endpoint-independent mapping (EIM) is not supported, EIM per VLAN or per
NAT rule term. The second session, which is dropped by the second NAT rule
in the configuration scenario described here, is not created owing to the
following sequence of events:
1.
The first packet matching either rule creates an EIM and a session.
2. The second packet matches the EIM entry because the second packet is
sent with the same source IP address and port as the first packet (but
with a different destination address).
This condition causes allocation (reuse) of the same public IP address and
port to the second packet as the first packet. The reverse flow for this session
has the same 5-tuple data as the reverse flow of the first session. This
behavior causes flow addition failure because a duplicate flow in the same
service set is not permitted.
To work around this problem, disable EIM in both the NAT rules, which causes
both the sessions to be established and processed correctly. Alternatively,
to avoid this problem, specify the NAT rules on different service-sets
configured on different units of the media interface with EIM enabled to
successfully establish both the sessions.
Release History Table
90
Release
Description
14.2
Starting in Junos OS release 14.2, the sequential option is introduced to
enable you to configure sequential allocation of ports.
Copyright © 2018, Juniper Networks, Inc.
CHAPTER 7
Hiding Private Networks Using Static
Source NAT
•
Configuring Static Source Translation in IPv4 Networks on page 91
•
Configuring Static Source Translation in IPv6 Networks on page 98
•
Example: Configuring Basic NAT44 on page 102
•
Example: Configuring NAT for Multicast Traffic on page 104
Configuring Static Source Translation in IPv4 Networks
To configure the translation type as basic-nat44, you must configure the NAT pool and
rule, service set with service interface, and trace options. This topic includes the following
tasks:
•
Configuring the NAT Pool and Rule on page 91
•
Configuring the Service Set for NAT on page 94
•
Configuring Trace Options on page 95
•
Sample Configuration - Static Source NAT Using a Static Pool With An Address Prefix
And An Address Range on page 96
•
Sample Configuration - Static Source Nat for One-To-One Mapping Between a Private
Subnet and a Public Subnet on page 97
Configuring the NAT Pool and Rule
To configure the NAT pool, rule, and term:
1.
In configuration mode, go to the [edit services nat] hierarchy level.
[edit]
user@host# edit services nat
2. Configure the NAT pool with an address.
[edit services nat]
user@host# set pool pool name address address
In the following example, the pool name is src_pool and the address is 10.10.10.2/32.
[edit services nat]
Copyright © 2018, Juniper Networks, Inc.
91
Adaptive Services Interfaces Feature Guide for Routing Devices
user@host# set pool src_pool address 10.10.10.2/32
3. Configure the NAT rule and the match direction.
[edit services nat]
user@host# set rule rule-name match-direction match-direction
In the following example, the NAT rule name is rule-basic-nat44 and the match
direction is input.
[edit services nat]
user@host# set rule rule-basic-nat44 match-direction input
4. Configure the source address in the from statement.
[edit services nat]
user@host# set rule rule-basic-nat44 term term-name from from
In the following example, the term name is t1 and the input condition is source-address
3.1.1.2/32.
[edit services nat]
user@host# set rule rule-basic-nat44 term t1 from source-address 3.1.1.2/32
5. Configure the NAT term action and properties of the translated traffic.
[edit services nat]
user@host# set rule rule-basic-nat44 term t1 then term-action translated-property
In the following example, the term action is translated and the property of the
translated traffic is source-pool src_pool.
[edit services nat]
user@host# set rule rule-basic-nat44 term t1 then translated source-pool src_pool
6. Configure the translation type.
[edit services nat]
user@host# set rule rule-basic-nat44 term t1 then translated translation-type
translation-type
In the following example, the translation type is basic-nat44.
[edit services nat]
user@host# set rule rule-basic-nat44 term t1 then translated translation-type
basic-nat44
7. Verify the configuration by using the show command at the [edit services nat] hierarchy
level.
[edit services]
user@host# show
nat {
pool src_pool {
address 10.10.10.2/32;
}
rule rule-basic-nat44 {
92
Copyright © 2018, Juniper Networks, Inc.
Chapter 7: Hiding Private Networks Using Static Source NAT
match-direction input;
term t1 {
from {
source-address {
3.1.1.2/32;
}
}
then {
translated {
source-pool src_pool;
translation-type {
basic-nat44;
}
}
}
}
}
}
NOTE: If you don’t configure a stateful firewall (SFW) rule for your traffic,
then each packet is subjected to the following default stateful firewall rule:
•
Allow any valid packets from inside to outside.
•
Create forward and return flow based on packets 5-tuple.
•
Allow only valid packets matching return flows from outside to inside.
The stateful firewall’s packet validity checks are described in the Stateful
Firewall Anomaly Checking in “Junos Network Secure Overview” on page 399.
When a packets pass stateful firewall validity checking but are not matched
by a NAT rule, they are not translated and may be forwarded if the NAT node
has a valid route to the packets’ destination IP addresses.
NOTE: When you add or delete a parameter in the from statement (NAT rule
term match condition) at the [edit services service-set service-set-name
nat-rules rule-name term term- name] hierarchy level, this configuration change
triggers a deletion and addition of the NAT policy (which is equivalent to the
deactivation and activation of a service set) that causes all existing NAT
mappings to be deleted. Because the sessions are not closed owing to the
change in the NAT policy, this behavior causes the mappings to timeout
immediately after the sessions are closed. This behavior is expected and is
applicable only with Junos OS Extension-Provider packages installed on a
device. When a NAT policy is deleted and readded, only EIM mappings are
deleted. This NAT policy change does not deactivate and activate the service
set. We recommend that you deactivate and reactivate the service set in
such scenarios in Junos OS Release 14.2 and earlier.
Copyright © 2018, Juniper Networks, Inc.
93
Adaptive Services Interfaces Feature Guide for Routing Devices
Configuring the Service Set for NAT
To configure the service set for NAT:
1.
In configuration mode, go to the [edit services] hierarchy level.
[edit]
user@host# edit services
2. Configure the service set.
[edit services]
user@host# edit service-set service-set-name
In the following example, the service set name is s1.
[edit services]
user@host# edit service-set s1
3. For the s1 service set, set the reference to the NAT rules configured at the [edit services
nat] hierarchy level.
[edit services service-set s1]
user@host# set nat-rules rule-name
In the following example, the rule name is rule-basic-nat44.
[edit services service-set s1]
user@host# set nat-rules rule-basic-nat44
4. Configure the service interface.
[edit services service-set s1]
user@host# set interface-service service-interface service-interface-name
In the following example, the service interface name is ms-1/2/0.
[edit services service-set s1]
user@host# set interface-service service-interface ms-1/2/0
NOTE: If you have a Trio-based line card, you can configure an
inline-services interface on that card:
[edit]
user@host# set interfaces si-0/0/0
[edit services service-set s1]
user@host# set interface-service service-interface si-0/0/0
5. Verify the configuration by using the show command at the [edit services] hierarchy
level.
[edit services]
user@host# show
service-set s1 {
94
Copyright © 2018, Juniper Networks, Inc.
Chapter 7: Hiding Private Networks Using Static Source NAT
nat-rules rule-basic-nat44;
interface-service {
service-interface ms-1/2/0;
}
}
6. Associate the NAT service set with an xe- interface:
user@host# set interfaces xe-1/1/0 unit 0 family inet address 10.255.247.2/24
user@host# set interfaces xe-1/1/0 unit 0 family inet service input service-set s1
user@host# set interfaces xe-1/1/0 unit 0 family inet service output service-set s1
7. Verify the configuration by using the show command at the [edit interfaces] hierarchy
level.
[edit interfaces]
user@host# show
xe-1/1/0 {
unit 0 {
family inet {
service {
input {
service-set s1;
}
output {
service-set s1;
}
}
address 10.255.247.2/24;
}
}
}
Configuring Trace Options
To configure the trace options:
1.
In configuration mode, go to the [edit services adaptive-services-pics] hierarchy level.
[edit]
user@host# edit services adaptive-services-pics
2. Configure the trace options.
[edit services adaptive-services-pics]
user@host# set traceoptions flag tracing parameter
In the following example, the tracing parameter is all.
[edit services adaptive-services-pics]
user@host# set traceoptions flag all
3. Verify the configuration by using the show command at the [edit services] hierarchy
level.
Copyright © 2018, Juniper Networks, Inc.
95
Adaptive Services Interfaces Feature Guide for Routing Devices
[edit services]
user@host# show
adaptive-services-pics {
traceoptions {
flag all;
}
}
[edit]
user@host# show services
service-set s1 {
nat-rules rule-basic-nat44;
interface-service {
service-interface ms-1/2/0;
}
}
nat {
pool src_pool {
address 10.10.10.2/32;
}
rule rule-basic-nat44 {
match-direction input;
term t1 {
from {
source-address {
3.1.1.2/32;
}
}
then {
translated {
source-pool src_pool;
translation-type {
basic-nat44;
}
}
}
}
}
}
adaptive-services-pics {
traceoptions {
flag all;
}
}
Sample Configuration - Static Source NAT Using a Static Pool With An Address Prefix And An
Address Range
[edit services nat]
pool p1 {
address 30.30.30.252/30;
address-range low 20.20.20.1 high 20.20.20.2;
}
rule r1 {
match-direction input;
term t1 {
from {
source-address {
96
Copyright © 2018, Juniper Networks, Inc.
Chapter 7: Hiding Private Networks Using Static Source NAT
10.10.10.252/30;
}
}
then {
translated {
source-pool p1;
translation-type basic-nat44;
}
}
}
}
Sample Configuration - Static Source Nat for One-To-One Mapping Between a Private Subnet
and a Public Subnet
[edit]
user@host# show services
service-set s1 {
nat-rules rule-basic-nat44;
interface-service {
service-interface ms-1/2/0;
}
}
nat {
pool src_pool {
address 10.10.10.2/32;
}
rule rule-basic-nat44 {
match-direction input;
term t1 {
from {
source-address {
3.1.1.2/32;
}
}
then {
translated {
source-pool src_pool;
translation-type {
basic-nat44;
}
}
}
}
}
}
adaptive-services-pics {
traceoptions {
flag all;
}
}
[edit interfaces]
user@host# show
xe-1/1/0 {
unit 0 {
family inet {
service {
Copyright © 2018, Juniper Networks, Inc.
97
Adaptive Services Interfaces Feature Guide for Routing Devices
input {
service-set s1;
}
output {
service-set s1;
}
}
address 10.255.247.2/24;
}
}
}
Release History Table
Release
Description
14.2
We recommend that you deactivate and reactivate the service set in such
scenarios in Junos OS Release 14.2 and earlier.
Configuring Static Source Translation in IPv6 Networks
To configure the translation type as basic-nat66, you must configure the NAT pool and
rule, service set with service interface, and trace options. The basic-nat66 translation
type is not available if you are using MS-MPCs or MS-MICs.
This topic includes the following tasks:
•
Configuring the NAT Pool and Rule on page 98
•
Configuring the Service Set for NAT on page 100
•
Configuring Trace Options on page 101
Configuring the NAT Pool and Rule
To configure the NAT pool, rule, and term:
1.
In configuration mode, go to the [edit services nat] hierarchy level.
[edit]
user@host# edit services nat
2. Configure the NAT pool with an address.
[edit services nat]
user@host# set pool pool name address address
In the following example, the pool name is src_pool and the address is 10.10.10.2/32.
[edit services nat]
user@host# set pool src_pool address 10.10.10.2/32
3. Configure the NAT rule and the match direction.
[edit services nat]
user@host# set rule rule-name match-direction match-direction
98
Copyright © 2018, Juniper Networks, Inc.
Chapter 7: Hiding Private Networks Using Static Source NAT
In the following example, the rule name is rule-basic-nat66 and the match direction
is input.
[edit services nat]
user@host# set rule rule-basic-nat66 match-direction input
4. Configure the source address in the from statement.
[edit services nat]
user@host# set rule rule-basic-nat66 term term-name from from
In the following, the term name is t1 and the input condition is source-address
2001:db8:10::0/96.
[edit services nat]
user@host# set rule rule-basic-nat66 term t1 from source-address 2001:db8:10::0/96
5. Configure the NAT term action and properties of the translated traffic.
[edit services nat]
user@host# set rule rule-basic-nat66 term t1 then term-action translated-property
In the following example, the term action is translated and the property of the
translated traffic is source-pool src_pool.
[edit services nat]
user@host# set rule rule-basic-nat66 term t1 then translated source-pool src_pool
6. Configure the translation type.
[edit services nat]
user@host# set rule rule-basic-nat66 term t1 then translated translation-type
translation-type
In the following example, the translation type is basic-nat66.
[edit services nat]
user@host# set rule rule-basic-nat66 term t1 then translated translation-type
basic-nat66
7. Verify the configuration by using the show command at the [edit services] hierarchy
level.
[edit services]
user@host# show
nat {
pool src_pool {
address 10.10.10.2/32;
}
rule rule-basic-nat66 {
match-direction input;
term t1 {
from {
source-address {
2001:db8:10::0/96;
}
}
Copyright © 2018, Juniper Networks, Inc.
99
Adaptive Services Interfaces Feature Guide for Routing Devices
then {
translated {
source-pool src_pool;
translation-type {
basic-nat66;
}
}
}
}
}
}
Configuring the Service Set for NAT
To configure the service set for NAT:
1.
In configuration mode, go to the [edit services] hierarchy level.
[edit]
user@host# edit services
2. Configure the service set.
[edit services]
user@host# edit service-set service-set-name
In the following example, the service set name is s1.
[edit services]
user@host# edit service-set s1
3. For the s1 service set, set the reference to the NAT rules configured at the [edit services
nat] hierarchy level.
[edit services service-set s1]
user@host# set nat-rules rule-name
In the following example, the rule name is rule-basic-nat66.
[edit services service-set s1]
user@host# set nat-rules rule-basic-nat66
4. Configure the service interface.
[edit services service-set s1]
user@host# set interface-service service-interface service-interface-name
In the following example, the service interface name is sp-1/2/0.
[edit services service-set s1]
user@host# set interface-service service-interface sp-1/2/0
5. Verify the configuration by using the show command at the [edit services] hierarchy
level.
[edit services]
user@host# show
100
Copyright © 2018, Juniper Networks, Inc.
Chapter 7: Hiding Private Networks Using Static Source NAT
service-set s1 {
nat-rules rule-basic-nat66;
interface-service {
service-interface sp-1/2/0;
}
}
Configuring Trace Options
To configure the trace options at the [edit services adaptive-services-pics] hierarchy level:
1.
In configuration mode, go to the [edit services adaptive-services-pics] hierarchy level.
[edit]
user@host# edit services adaptive-services-pics
2. Configure the trace options.
[edit services adaptive-services-pics]
user@host# set traceoptions flag tracing parameter
In the following example, the tracing parameter is all.
[edit services adaptive-services-pics]
user@host# set traceoptions flag all
3. Verify the configuration by using the show command at the [edit services] hierarchy
level.
[edit services]
user@host# show
adaptive-services-pics {
traceoptions {
flag all;
}
}
The following example configures the translation type as basic-nat66.
[edit]
user@host# show services
service-set s1 {
nat-rules rule-basic-nat66;
interface-service {
service-interface sp-1/2/0;
}
}
nat {
pool src_pool {
address 10.10.10.2/32;
}
rule rule-basic-nat66 {
match-direction input;
term t1 {
from {
source-address {
Copyright © 2018, Juniper Networks, Inc.
101
Adaptive Services Interfaces Feature Guide for Routing Devices
2001:db8:10::0/96/96;
}
}
then {
translated {
source-pool src_pool;
translation-type {
basic-nat66;
}
}
}
}
}
}
adaptive-services-pics {
traceoptions {
flag all;
}
}
Example: Configuring Basic NAT44
This example describes how to implement a basic NAT44 configuration.
•
Requirements on page 102
•
Overview on page 102
•
Configuring Basic NAT44 on page 102
Requirements
This example uses the following hardware and software components:
•
An MX Series 3D Universal Edge router with a Services DPC or an M Series Multiservice
Edge router with a services PIC
•
A domain name server (DNS)
•
Junos OS Release 11.4 or higher
Overview
This example shows a complete CGN NAT44 configuration and advanced options.
Configuring Basic NAT44
Chassis Configuration
Step-by-Step
Procedure
To configure the service PIC (FPC 5 Slot 0) with the Layer 3 service package:
1.
Go to the [edit chassis] hierarchy level.
user@host# edit chassis
2.
Configure the Layer 3 service package.
[edit chassis]
102
Copyright © 2018, Juniper Networks, Inc.
Chapter 7: Hiding Private Networks Using Static Source NAT
user@host# set fpc 5 pic 0 adaptive-services service-package layer-3
Interfaces Configuration
Step-by-Step
Procedure
To configure interfaces to the private network and the public Internet:
1.
Define the interface to the private network.
user@host# edit interfaces ge-1/3/5
[edit interfaces ge-1/3/5]
user@host# set description “Private”
user@host# edit unit 0 family inet
[edit interfaces ge-1/3/5 unit 0 family inet]
user@host# set service input service-set ss2
user@host# set service output service-set ss2
user@host# set address 9.0.0.1/24
2.
Define the interface to the public Internet.
user@host# edit interfaces ge-1/3/6
[edit interfaces ge-1/3/6]
user@host# set description “Public”
user@host# set unit 0 family inet address 128.0.0.1/24
3.
Define the service interface for NAT processing.
user@host# edit interfaces sp-5/0/0
[edit interfaces sp-5/0/0]
user@host# set unit 0 family inet
Copyright © 2018, Juniper Networks, Inc.
103
Adaptive Services Interfaces Feature Guide for Routing Devices
Results
user@host# show interfaces ge-1/3/5
description Private;
unit 0 {
family inet {
service {
input {
service-set sset2;
}
output {
service-set sset2;
}
}
address 9.0.0.1/24;
}
}
}
user@host# show interfaces ge-1/3/6
description Public:;
unit 0 {
family inet {
address 128.0.0.1/24;
}
}
user@host# show interfaces sp-5/0/0
unit 0 {
family inet;
}
Example: Configuring NAT for Multicast Traffic
Figure 9 on page 104 illustrates the network setup for the following configuration, which
allows IP multicast traffic to be sent to the Multiservices PIC.
Figure 9: Configuring NAT for Multicast Traffic
•
Rendezvous Point Configuration on page 104
•
Router 1 Configuration on page 107
Rendezvous Point Configuration
On the rendezvous point (RP), all incoming traffic from the multicast source at
192.168.254.0/27 is sent to the static NAT pool mcast_pool, where its source is translated
to 20.20.20.0/27. The service set nat_ss is a next-hop service set that allows IP multicast
traffic to be sent to the Multiservices DPC or Multiservices PIC. The inside interface on
the PIC is ms-1/1/0.1 and the outside interface is ms-1/1/0.2.
104
Copyright © 2018, Juniper Networks, Inc.
Chapter 7: Hiding Private Networks Using Static Source NAT
[edit services]
nat {
pool mcast_pool {
address 20.20.20.0/27;
}
rule nat_rule_1 {
match-direction input;
term 1 {
from {
source-address 192.168.254.0/27;
}
}
then {
translated {
source-pool mcast_pool;
translation-type basic-nat44;
}
syslog;
}
}
}
service-set nat_ss {
allow-multicast;
nat-rules nat_rule_1;
next-hop-service {
inside-service-interface ms-1/1/0.1;
outside-service-interface ms-1/1/0.2;
}
}
The Gigabit Ethernet interface ge-0/3/0 carries traffic out of the RP to Router 1. The
multiservices interface ms-1/1/0 has two logical interfaces: unit 1 is the inside interface
for next-hop services and unit 2 is the outside interface for next-hop services. Multicast
source traffic comes in on the Fast Ethernet interface fe-1/2/1, which has the firewall filter
fbf applied to incoming traffic.
[edit interfaces]
ge-0/3/0 {
unit 0 {
family inet {
address 10.10.1.1/30;
}
}
}
ms-1/1/0 {
unit 0 {
family inet;
}
unit 1 {
family inet;
service-domain inside;
}
unit 2 {
family inet;
service-domain outside;
Copyright © 2018, Juniper Networks, Inc.
105
Adaptive Services Interfaces Feature Guide for Routing Devices
}
}
fe-1/2/1 {
unit 0 {
family inet {
filter {
input fbf;
}
address 192.168.254.27/27;
}
}
}
Multicast packets can only be directed to the Multiservices DPC or the Multiservices PIC
using a next-hop service set. In the case of NAT, you must also configure a VPN routing
and forwarding instance (VRF). Therefore, the routing instance stage is created as a
“dummy” forwarding instance. To direct incoming packets to stage, you configure
filter-based forwarding through a firewall filter called fbf, which is applied to the incoming
interface fe-1/2/1. A lookup is performed in stage.inet.0, which has a multicast static route
that is installed with the next hop pointing to the PIC’s inside interface. All multicast
traffic matching this route is sent to the PIC.
[edit firewall]
filter fbf {
term 1 {
then {
routing-instance stage;
}
}
}
The routing instance stage forwards IP multicast traffic to the inside interface ms-1/1/0.1
on the Multiservices DPC or Multiservices PIC:
[edit]
routing-instances stage {
instance-type forwarding;
routing-options {
static {
route 224.0.0.0/4 next-hop ms-1/1/0.1;
}
}
}
You enable OSPF and Protocol Independent Multicast (PIM) on the Fast Ethernet and
Gigabit Ethernet logical interfaces over which IP multicast traffic enters and leaves the
RP. You also enable PIM on the outside interface (ms-1/1/0.2) of the next-hop service
set.
[edit protocols]
ospf {
area 0.0.0.0 {
interface fe-1/2/1.0 {
passive;
}
interface lo0.0;
106
Copyright © 2018, Juniper Networks, Inc.
Chapter 7: Hiding Private Networks Using Static Source NAT
interface ge-0/3/0.0;
}
}
pim {
rp {
local {
address 10.255.14.160;
}
}
interface fe-1/2/1.0;
interface lo0.0;
interface ge-0/3/0.0;
interface ms-1/1/0.2;
}
As with any filter-based forwarding configuration, in order for the static route in the
forwarding instance stage to have a reachable next hop, you must configure routing table
groups so that all interface routes are copied from inet.0 to the routing table in the
forwarding instance. You configure routing tables inet.0 and stage.inet.0 as members of
fbf_rib_group, so that all interface routes are imported into both tables.
[edit routing-options]
interface-routes {
rib-group inet fbf_rib_group;
}
rib-groups fbf_rib_group {
import-rib [ inet.0 stage.inet.0 ];
}
multicast {
rpf-check-policy no_rpf;
}
Reverse path forwarding (RPF) checking must be disabled for the multicast group on
which source NAT is applied. You can disable RPF checking for specific multicast groups
by configuring a policy similar to the one in the example that follows. In this case, the
no_rpf policy disables RPF check for multicast groups belonging to 224.0.0.0/4.
[edit policy-options]
policy-statement no_rpf {
term 1 {
from {
route-filter 224.0.0.0/4 orlonger;
}
then reject;
}
}
Router 1 Configuration
The Internet Group Management Protocol (IGMP), OSPF, and PIM configuration on Router
1 is as follows. Because of IGMP static group configuration, traffic is forwarded out
fe-3/0/0.0 to the multicast receiver without receiving membership reports from host
members.
[edit protocols]
Copyright © 2018, Juniper Networks, Inc.
107
Adaptive Services Interfaces Feature Guide for Routing Devices
igmp {
interface fe-3/0/0.0 {
}
}
ospf {
area 0.0.0.0 {
interface fe-3/0/0.0 {
passive;
}
interface lo0.0;
interface ge-7/2/0.0;
}
pim {
rp {
static {
address 10.255.14.160;
}
}
interface fe-3/0/0.0;
interface lo0.0;
interface ge-7/2/0.0;
}
}
The routing option creates a static route to the NAT pool, mcast_pool, on the RP.
[edit routing-options]
static {
route 20.20.20.0/27 next-hop 10.10.1.1;
}
108
Copyright © 2018, Juniper Networks, Inc.
CHAPTER 8
Making Private Servers Available Using
Static Destination NAT
•
Configuring Static Destination Address Translation in IPv4 Networks on page 109
Configuring Static Destination Address Translation in IPv4 Networks
To use destination address translation, the size of the pool address space must be greater
than or equal to the destination address space. You must specify a name for the
destination-pool statement, which can contain multiple addresses, ranges, or prefixes,
as long as the number of NAT addresses in the pool is larger than the number of
destination addresses in the from statement.
To configure destination address translation in IPv4 networks:
1.
In configuration mode, go to the [edit services] hierarchy level.
[edit]
user@host# edit services
2. Configure the service set and the NAT rule.
[edit services]
user@host# set service-set service-set-name nat-rules rule-name
In the following example, the name of the service set is s1 and the name of the NAT
rule is rule-dnat44.
[edit services]
user@host# set service-set s1 nat-rules rule-dnat44
3. Go to the [interface-service] hierarchy level of the service set.
[edit services]
user@host# edit service-set s1 interface-service
4. Configure the service interface.
[edit services service-set s1 interface-service]
user@host# set service-interface service-interface-name
In the following example, the name of the service interface is ms-0/1/0.
Copyright © 2018, Juniper Networks, Inc.
109
Adaptive Services Interfaces Feature Guide for Routing Devices
NOTE: If the service interface is not present in the router, or the specified
interface is not functional, the following command can result in an error.
[edit services service-set s1 interface-service]
user@host# set service-interface ms-0/1/0
5. Go to the [edit services nat] hierarchy level. Issue the following command from the
top of the services hierarchy, or use the top keyword.
[edit services service-set s1]
user@host# top editservices nat
6. Configure the NAT pool with an address.
[edit services nat]
user@host# set pool pool-name address address
In the following example, dest-pool is used as the pool name and 4.1.1.2 as the address.
user@host# set pool dest-pool address 4.1.1.2
7. Configure the rule, match direction, term, and destination address.
[edit services nat]
user@host# set rule rule-name match-direction match-direction term term-name from
destination-address address
In the following example, the name of the rule is rule-dnat44, the match direction is
input, the name of the term is t1, and the address is 20.20.20.20.
[edit services nat]
user@host# set rule rule-dnat44 match-direction input term t1 from
destination-address 20.20.20.20
8. Go to the [edit services nat rule rule-dnat44 term t1] hierarchy level.
[edit services nat]
user@host# edit rule rule-dnat44 term t1
9. Configure the destination pool and the translation type.
[edit services nat rule rule-dnat44 term t1]
user@host# set then translated destination-pool dest-pool-name translation-type
translation-type
In the following example, the destination pool name is dest-pool, and the translation
type is dnat-44.
[edit services nat rule rule-dnat44 term t1]
user@host# set then translated destination-pool dest-pool translation-type dnat-44
110
Copyright © 2018, Juniper Networks, Inc.
Chapter 8: Making Private Servers Available Using Static Destination NAT
10. Go to the [edit services adaptive-services-pics] hierarchy level. In the following
command, the top keyword ensures that the command is run from the top of the
hierarchy.
[edit services nat rule rule-dnat44 term t1]
user@host# top edit services adaptive-services-pics
11. Configure the trace options.
[edit services adaptive-services-pics]
user@host# set traceoptions flag tracing parameter
In the following example, the tracing parameter is configured as all.
[edit services adaptive-services-pics]
user@host# set traceoptions flag all
12. Verify the configuration by using the show command at the [edit services] hierarchy
level.
[edit services]
user@host# show
service-set s1 {
nat-rules rule-dnat44;
interface-service {
service-interface ms-0/1/0;
}
}
nat {
pool dest-pool {
address 4.1.1.2/32;
}
rule rule-dnat44 {
match-direction input;
term t1 {
from {
destination-address {
20.20.20.20/32;
}
}
then {
translated {
destination-pool dest-pool;
translation-type {
dnat-44;
}
}
}
}
}
}
adaptive-services-pics {
traceoptions {
flag all;
}
}
Copyright © 2018, Juniper Networks, Inc.
111
Adaptive Services Interfaces Feature Guide for Routing Devices
The following example configures the translation type as dnat-44.
[edit services]
user@host# show
service-set s1 {
nat-rules rule-dnat44;
interface-service {
service-interface ms-0/1/0;
}
}
nat {
pool dest-pool {
address 4.1.1.2/32;
}
rule rule-dnat44 {
match-direction input;
term t1 {
from {
destination-address {
20.20.20.20/32;
}
}
then {
translated {
destination-pool dest-pool;
translation-type {
dnat-44;
}
}
}
}
}
}
adaptive-services-pics {
traceoptions {
flag all;
}
}
In the following configuration, term1 configures source address translation for traffic from
any private address to any public address. The translation is applied for all services. term2
performs destination address translation for Hypertext Transfer Protocol (HTTP) traffic
from any public address to the server’s virtual IP address. The virtual server IP address
is translated to an internal IP address.
[edit services nat]
rule my-nat-rule {
match-direction input;
term my-term1 {
from {
source-address private;
destination-address public;
}
then {
translated {
source-pool my-pool; # pick address from a pool
translation-type napt-44; # dynamic NAT with port translation
}
112
Copyright © 2018, Juniper Networks, Inc.
Chapter 8: Making Private Servers Available Using Static Destination NAT
}
}
}
rule my-nat-rule2 {
match-direction input;
term my-term2 {
from {
destination-address 192.168.137.3; # my server’s virtual address
application http;
}
then {
translated {
destination-pool nat-pool-name;
translation-type dnat-44; # static destination NAT
}
}
}
}
}
The following configuration performs NAT using the destination prefix 20.20.10.0/32
without defining a pool.
[edit services nat]
rule src-nat {
match-direction input;
term t1 {
from {
destination-address 10.10.10.10/32;
then {
translation-type dnat44;
destination-prefix 20.20.10.0/24;
}
}
}
}
Related
Documentation
•
Configuring Source and Destination Addresses Network Address Translation Overview
on page 60
Copyright © 2018, Juniper Networks, Inc.
113
Adaptive Services Interfaces Feature Guide for Routing Devices
114
Copyright © 2018, Juniper Networks, Inc.
CHAPTER 9
Allowing Components of a Private
Network to Share a Single Address Using
NAPT
•
Configuring Address Pools for Network Address Port Translation (NAPT)
Overview on page 115
•
Configuring NAPT in IPv4 Networks on page 121
•
Configuring NAPT in IPv6 Networks on page 126
•
Example: Configuring NAT with Port Translation on page 128
•
Example: NAPT Configuration on the MS-MPC With an Interface Service Set on page 129
•
Example: Dynamic Source NAT as a Next-Hop Service on page 134
Configuring Address Pools for Network Address Port Translation (NAPT) Overview
With Network Address Port Translation (NAPT), you can configure up to 32 address
ranges with up to 65,536 addresses each.
The port statement specifies port assignment for the translated addresses. To configure
automatic assignment of ports, include the port automatic statement at the [edit services
nat pool nat-pool-name] hierarchy level. By default, sequential allocation of ports occurs.
Starting with Junos OS Release 14.2, you can include the sequential option with the port
automatic statement at the [edit services nat pool nat-pool-name] hierarchy level for
sequenced allocation of ports from the specified range. To configure a specific range of
port numbers, include the port range low minimum-value high maximum-value statement
at the [edit services nat pool nat-pool-name] hierarchy level.
NOTE: When 99% of the total available ports in pool for napt-44 , no new
flows are allowed on that NAT pool.
Starting with Junos OS Release 14.2, the auto option is hidden and is
deprecated, and is only maintained for backward compatibility. It might be
removed completely in a future software release.
Copyright © 2018, Juniper Networks, Inc.
115
Adaptive Services Interfaces Feature Guide for Routing Devices
The Junos OS provides several alternatives for allocating ports:
•
Round-Robin Allocation for NAPT on page 116
•
Sequential Allocation for NAPT on page 116
•
Preserve Parity and Preserve Range for NAPT on page 117
•
Address Pooling and Endpoint Independent Mapping for NAPT on page 117
•
Secured Port Block Allocation for NAPT on page 119
•
Comparison of NAPT Implementation Methods on page 120
Round-Robin Allocation for NAPT
To configure round-robin allocation for NAT pools, include the address-allocation
round-robin configuration statement at the [edit services nat pool pool-name] hierarchy
level. When you use round-robin allocation, one port is allocated from each address in
a range before repeating the process for each address in the next range. After ports have
been allocated for all addresses in the last range, the allocation process wraps around
and allocates the next unused port for addresses in the first range.
•
The first connection is allocated to the address:port 100.0.0.1:3333.
•
The second connection is allocated to the address:port 100.0.0.2:3333.
•
The third connection is allocated to the address:port 100.0.0.3:3333.
•
The fourth connection is allocated to the address:port 100.0.0.4:3333.
•
The fifth connection is allocated to the address:port 100.0.0.5:3333.
•
The sixth connection is allocated to the address:port 100.0.0.6:3333.
•
The seventh connection is allocated to the address:port 100.0.0.7:3333.
•
The eighth connection is allocated to the address:port 100.0.0.8:3333.
•
The ninth connection is allocated to the address:port 100.0.0.9:3333.
•
The tenth connection is allocated to the address:port 100.0.0.10:3333.
•
The eleventh connection is allocated to the address:port 100.0.0.11:3333.
•
The twelfth connection is allocated to the address:port 100.0.0.12:3333.
•
Wraparound occurs and the thirteenth connection is allocated to the address:port
100.0.0.1:3334.
Sequential Allocation for NAPT
With sequential allocation, the next available address in the NAT pool is selected only
when all the ports available from an address are exhausted.
Sequential Allocation can be configured only for the MS-DPC and the MS-100, MS-400,
and MS-500 MultiServices PICS. The MS-MPC and MS-MIC cards use only the round-robin
allocation approach.
116
Copyright © 2018, Juniper Networks, Inc.
Chapter 9: Allowing Components of a Private Network to Share a Single Address Using NAPT
NOTE:
•
This legacy implementation provides backward compatibility and is no
longer a recommended approach.
The NAT pool called napt in the following configuration example uses the sequential
implementation:
pool napt {
address-range low 100.0.0.1 high 100.0.0.3;
address-range low 100.0.0.4 high 100.0.0.6;
address-range low 100.0.0.8 high 100.0.0.10;
address-range low 100.0.0.12 high 100.0.0.13;
port {
range low 3333 high 3334;
}
}
In this example, the ports are allocated starting from the first address in the first
address-range, and allocation continues from this address until all available ports have
been used. When all available ports have been used, the next address (in the same
address-range or in the following address-range) is allocated and all its ports are selected
as needed. In the case of the example napt pool, the tuple address, port 100.0.0.4:3333,
is allocated only when all ports for all the addresses in the first range have been used.
•
The first connection is allocated to the address:port 100.0.0.1:3333.
•
The second connection is allocated to the address:port 100.0.0.1:3334.
•
The third connection is allocated to the address:port 100.0.0.2:3333.
•
The fourth connection is allocated to the address:port 100.0.0.2:3334, and so on.
Preserve Parity and Preserve Range for NAPT
Preserve parity and preserve range options are available for NAPT, and are supported
on MS-DPCs and MS-100, MS-400, and MS-500 MultiServices PICS. Support for
MS-MPCs and MS-MICs starts in Junos OS Release 15.1R1. The following options are
available for NAPT:
•
Preserving parity—Use the preserve-parity command to allocate even ports for packets
with even source ports and odd ports for packets with odd source ports.
•
Preserving range—Use the preserve-range command to allocate ports within a range
from 0 to 1023, assuming the original packet contains a source port in the reserved
range. This applies to control sessions, not data sessions.
Address Pooling and Endpoint Independent Mapping for NAPT
•
Address Pooling on page 118
•
Endpoint Independent Mapping and Endpoint Independent Filtering on page 119
Copyright © 2018, Juniper Networks, Inc.
117
Adaptive Services Interfaces Feature Guide for Routing Devices
Address Pooling
Address pooling, or address pooling paired (APP) ensures assignment of the same
external IP address for all sessions originating from the same internal host. You can use
this feature when assigning external IP addresses from a pool. This option does not affect
port utilization
Address pooling solves the problems of an application opening multiple connections.
For example, when Session Initiation Protocol (SIP) client sends Real-Time Transport
Protocol (RTP) and Real-Time Control Protocol (RTCP) packets, the SIP generally server
requires that they come from the same IP address, even if they have been subject to NAT.
If RTP and RTCP IP addresses are different, the receiving endpoint might drop packets.
Any point-to-point (P2P) protocol that negotiates ports (assuming address stability)
benefits from address pooling paired.
The following are use cases for address pooling:
•
A site that offers instant messaging services requires that chat and their control sessions
come from the same public source address. When the user signs on to chat, a control
session authenticates the user. A different session begins when the user starts a chat
session. If the chat session originates from a source address that is different from the
authentication session, the instant messaging server rejects the chat session, because
it originates from an unauthorized address.
•
Certain websites such as online banking sites require that all connections from a given
host come from the same IP address.
NOTE: Starting with Junos OS Release 14.1, when you deactivate a service-set
that contains address pooling paired (APP) for that service-set, messages
are displayed on the PIC console and the mappings are cleared for that
service-set. These messages are triggered when the deletion of a service-set
commences and again generated when the deletion of the service-set is
completed. The following sample messages are displayed when deletion
starts and ends:
•
Nov 15 08:33:13.974 LOG: Critical] SVC-SET ss1 (iid 5) deactivate/delete:
NAT Mappings and flows deletion initiated
•
Nov 15 08:33:14.674 LOG: Critical] SVC-SET ss1 (iid 5) deactivate/delete:
NAT Mappings and flows deletion completed
In a scaled environment that contains a large number of APP in a service set,
a heavy volume of messages is generated and this process takes some
amount of time. We recommend that you wait until the console messages
indicating the completion of deletion of the service set are completed before
you reactivate the service-set again.
118
Copyright © 2018, Juniper Networks, Inc.
Chapter 9: Allowing Components of a Private Network to Share a Single Address Using NAPT
Endpoint Independent Mapping and Endpoint Independent Filtering
Endpoint independent mapping (EIM) ensures the assignment of the same external
address and port for all connections from a given host if they use the same internal port.
This means if they come from a different source port, you are free to assign a different
external address.
EIM and APP differ as follows:
•
APP ensures assigning the same external IP address.
•
EIM provides a stable external IP address and port (for a period of time) to which
external hosts can connect. Endpoint independent filtering (EIF) controls which external
hosts can connect to an internal host.
NOTE: Starting with Junos OS Release 14.1, when you deactivate a service-set
that contains endpoint independent mapping (EIM) mapping for that
service-set, messages are displayed on the PIC console and the mappings
are cleared for that service-set. These messages are triggered when the
deletion of a service-set commences and again generated when the deletion
of the service-set is completed. The following sample messages are displayed
when deletion starts and ends:
•
Nov 15 08:33:13.974 LOG: Critical] SVC-SET ss1 (iid 5) deactivate/delete:
NAT Mappings and flows deletion initiated
•
Nov 15 08:33:14.674 LOG: Critical] SVC-SET ss1 (iid 5) deactivate/delete:
NAT Mappings and flows deletion completed
In a scaled environment that contains a large number of EIM mappings in a
service set, a heavy volume of messages is generated and this process takes
some amount of time. We recommend that you wait until the console
messages indicating the completion of deletion of the service set are
completed before you reactivate the service-set again.
Secured Port Block Allocation for NAPT
Port block allocation is supported on MX series routers with MS-DPCs and on M Series
routers with MS-100, MS-400, and MS-500 MultiServices PICS. Port block allocation is
supported on MX series routers with MS-MPCs and MS-MICs starting in Junos OS release
14.2R2.
Carriers track subscribers using the IP address (RADIUS or DHCP) log. If they use NAPT,
an IP address is shared by multiple subscribers, and the carrier must track the IP address
and port, which are part of the NAT log. Because ports are used and reused at a very high
rate, tracking subscribers using the log becomes difficult due to the large number of
messages, which are difficult to archive and correlate. By enabling the allocation of ports
Copyright © 2018, Juniper Networks, Inc.
119
Adaptive Services Interfaces Feature Guide for Routing Devices
in blocks, port block allocation can significantly reduce the number of logs, making it
easier to track subscribers.
•
Secured Port Block Allocation for NAPT on page 120
•
Interim Logging for Port Block Allocation on page 120
Secured Port Block Allocation for NAPT
Secured port block allocation can be used for translation types napt-44 and
stateful-nat64.
When allocating blocks of ports, the most recently allocated block is the current active
block. New requests for NAT ports are served from the active block. Ports are allocated
randomly from the current active block.
When you configure secured port block allocation, you can specify the following:
•
block-size
•
max-blocks-per-address
•
active-block-timeout
Interim Logging for Port Block Allocation
With port block allocation we generate one syslog log per set of ports allocated for a
subscriber. These logs are UDP based and can be lost in the network, particularly for
long-running flows. Interim logging triggers re-sending the above logs at a configured
interval for active blocks that have traffic on at least one of the ports of the block.
Interim logging is activated by including the pba-interim-logging-interval statement under
services-options for sp- interfaces.
See Also
•
Configuring Secured Port Block Allocation on page 197
•
Configuring NAT Session Logs on page 257
•
Secured Port Block Allocation for NAPT44 and NAT64 Overview on page 191
Comparison of NAPT Implementation Methods
Table 8 on page 120 provides a feature comparison of available NAPT implementation
methods.
Table 8: Comparison of NAPT Implementation Methods
Feature/Function
Dynamic Port
Allocation
Secured Port Block Allocation
Deterministic Port Block
Allocation
Users per IP
High
Medium
Low
Security Risk
Low
Medium
Medium
Log Utilization
High
Low
None (no logs necessary)
120
Copyright © 2018, Juniper Networks, Inc.
Chapter 9: Allowing Components of a Private Network to Share a Single Address Using NAPT
Table 8: Comparison of NAPT Implementation Methods (continued)
Feature/Function
Dynamic Port
Allocation
Secured Port Block Allocation
Deterministic Port Block
Allocation
Security Risk Reduction
Random allocation
active-block-timeout feature
n/a
Increasing Users per IP
n/a
Configure multiples of smaller port
blocks to maximize users/ public IP
Algorithm-based port
allocation
Configuring NAPT in IPv4 Networks
Network Address Port Translation (NAPT) is a method by which many network addresses
and their TCP/UDP ports are translated into a single network address and its TCP/UDP
ports. This translation can be configured in both IPv4 and IPv6 networks. This section
describes the steps for configuring NAPT in IPv4 networks.
To configure NAPT, you must configure a rule at the [edit services nat] hierarchy level for
dynamically translating the source IPv4 addresses.
To configure the NAPT in IPv4 networks:
1.
In configuration mode, go to the [edit services] hierarchy level.
[edit]
user@host# edit services
2. Configure the service set and NAT rule.
[edit services]
user@host# set service-set service-set-name nat-rules rule-name
In the following example, the name of the service set is s1 and the name of the NAT
rule is rule-napt-44.
[edit services]
user@host# set service-set s1 nat-rules rule-napt-44
3. Go to the [interface-service] hierarchy level of the service set.
[edit services]
user@host# edit service-set s1 interface-service
4. Configure the service interface.
[edit services service-set s1 interface service]
user@host# set service-interface service-interface-name
In the following example, the name of the service interface is ms-0/1/0.
NOTE: If the service interface is not present in the router, or the specified
interface is not functional, the following command can result in an error.
Copyright © 2018, Juniper Networks, Inc.
121
Adaptive Services Interfaces Feature Guide for Routing Devices
[edit services service-set s1 interface service]
user@host# set service-interface ms-0/1/0
5. Go to the [edit services nat] hierarchy level. Issue the command from the top of the
services hierarchy, or use the top keyword.
[edit services service-set s1 interface service]
user@host# top edit services nat
6. Configure the NAT pool with an address.
[edit services nat]
user@host# set pool pool-name address address
In the following example, the name of the pool is napt-pool and the address is
10.10.10.0.
[edit services nat]
user@host# set pool napt-pool address 10.10.10.0
7. Configure the port.
[edit services nat]
user@host# set pool pool-name port port-type
In the following example, the port type is selected as sequential or auto.
[edit services nat]
user@host# set pool napt-pool port automatic
NOTE: Starting in Junos OS Release 14.2, the sequential option is
introduced to enable you to configure sequential allocation of ports. The
sequential and random-allocation options available with the port automatic
statement at the [edit services nat pool nat-pool-name] hierarchy level are
mutually exclusive. You can include the sequential option for sequential
allocation and the random-allocation option for random delegation of
ports. By default, sequential allocation of ports takes place if you include
only the port automatic statement at the [edit services nat pool nat-poolname] hierarchy level. The auto option is hidden and is deprecated in Junos
OS Release 14.2 and later, and is only maintained for backward
compatibility. It might be removed completely in a future software release.
8. Configure the rule and the match direction.
[edit services nat]
user@host# set rule rule-name match-direction match-direction
In the following example, the name of the rule is rule-napt-44 and the match direction
is input.
[edit services nat]
user@host# set rule rule-napt-44 match-direction input
122
Copyright © 2018, Juniper Networks, Inc.
Chapter 9: Allowing Components of a Private Network to Share a Single Address Using NAPT
9. Configure the term, the action for the translated traffic, and the translation type.
[edit services nat]
user@host# set rule rule-name term term-name then translated translated-action
translation-type napt-44
In the following example, the name of the term is t1, the action for the translated traffic
is translated, the name of the source pool is napt-pool, and the translation type is
napt-44.
[edit services nat]
user@host# set rule rule-napt-44 match-direction input term t1 then translated
source-pool napt-pool translation-type napt-44
10. Go to the [edit services adaptive-services-pics] hierarchy level. In the command, the
top keyword ensures that the command is run from the top of the hierarchy.
[edit services nat]
user@host# top edit services adaptive-services-pics
11. Configure the trace options.
[edit services adaptive-services-pics]
user@host# set traceoptions flag tracing parameter
In the following example, the tracing parameter is configured as all.
[edit services adaptive-services-pics]
user@host# set traceoptions flag all
12. Verify the configuration by using the show command at the [edit services] hierarchy
level.
[edit services]
user@host# show
service-set s1 {
nat-rules rule-napt-44;
interface-service {
service-interface ms-0/1/0;
}
}
nat {
pool napt-pool {
address 10.10.10.0/32;
port {
automatic;
}
}
rule rule-napt-44 {
match-direction input;
term t1 {
then {
translated {
source-pool napt-pool;
translation-type {
napt-44;
}
}
Copyright © 2018, Juniper Networks, Inc.
123
Adaptive Services Interfaces Feature Guide for Routing Devices
}
}
}
}
adaptive-services-pics {
traceoptions {
flag all;
}
}
The following example configures the translation type as napt-44.
[edit services]
user@host# show
service-set s1 {
nat-rules rule-napt-44;
interface-service {
service-interface ms-0/1/0;
}
}
nat {
pool napt-pool {
address 10.10.10.0/32;
port {
automatic auto;
}
}
rule rule-napt-44 {
match-direction input;
term t1 {
then {
translated {
source-pool napt-pool;
translation-type {
napt-44;
}
}
}
}
}
}
adaptive-services-pics {
traceoptions {
flag all;
}
}
Dynamic Address
Translation to a Small
Pool with Fallback to
NAT
The following configuration shows dynamic address translation from a large prefix to a
small pool, translating a /24 subnet to a pool of 10 addresses. When the addresses in
the source pool (src-pool) are exhausted, NAT is provided by the NAPT overload pool
(pat-pool).
[edit services nat]
pool src-pool {
address-range low 192.16.2.1 high 192.16.2.10;
}
pool pat-pool {
address-range low 192.16.2.11 high 192.16.2.12;
124
Copyright © 2018, Juniper Networks, Inc.
Chapter 9: Allowing Components of a Private Network to Share a Single Address Using NAPT
port automatic auto;
rule myrule {
match-direction input;
term myterm {
from {
source-address 10.150.1.0/24;
}
then {
translated {
source-pool src-pool;
overload-pool pat-pool;
translation-type napt-44;
}
}
}
}
Dynamic Address
Translation with Small
Pool
The following configuration shows dynamic address translation from a large prefix to a
small pool, translating a /24 subnet to a pool of 10 addresses. Sessions from the first 10
host sessions are assigned an address from the pool on a first-come, first-served basis,
and any additional requests are rejected. Each host with an assigned NAT can participate
in multiple sessions.
[edit services nat]
pool my-pool {
address-range low 10.10.10.1 high 10.10.10.10;
}
rule src-nat {
match-direction input;
term t1 {
from {
source-address 192.168.1.0/24;
}
then {
translated {
translation-type dynamic-nat44;
source-pool my-pool;
}
}
}
}
Copyright © 2018, Juniper Networks, Inc.
125
Adaptive Services Interfaces Feature Guide for Routing Devices
Release History Table
Release
Description
14.2
Starting in Junos OS Release 14.2, the sequential option is introduced to
enable you to configure sequential allocation of ports.
Configuring NAPT in IPv6 Networks
Network Address Port Translation (NAPT) is a method by which many network addresses
and their TCP/UDP ports are translated into a single network address and its TCP/UDP
ports. This translation can be configured in both IPv4 and IPv6 networks. This section
describes the steps for configuring NAPT in IPv6 networks. Configuring NAPT in IPv6
networks is not supported if you are using MS-MPCs or MS-MICs. For information about
configuring NAPT in IPv4 networks, see “Configuring NAPT in IPv4 Networks” on page 121.
To configure NAPT, you must configure a rule at the [edit services nat] hierarchy level for
dynamically translating the source IPv6 addresses.
To configure NAPT in IPv6 networks:
1.
In configuration mode, go to the [edit services nat] hierarchy level.
[edit]
user@host# edit services nat
2. Define the pool of IPv6 source addresses that must be used for dynamic translation.
For NAPT, also specify port numbers when configuring the source pool.
[edit services nat]
user@host# set pool pool name address IPv6 source addresses
user@host# set pool pool name port source ports
For example:
[edit services nat]
user@host# set pool IPV6-NAPT-Pool address 2002::1/96
user@host# set pool IPV6-NAPT-Pool port automatic sequential
3. Define a NAT rule for translating the source addresses. To do this, set the
match-direction statement of the rule as input. In addition, define a term that uses
napt-66 as the translation type for translating the addresses of the pool defined in
the previous step. Note that the napt-66 translation type is supported only on the
MS-DPC, MS-100, MS-400, and MS-500 line cards.
[edit services nat]
user@host# set rule rule name match-direction input
user@host# set rule rule name term term name then translated source-pool pool name
user@host# set rule rule name term term name then translated translation-type napt-66
For example:
[edit services nat]
user@host# set rule IPV6-NAPT-Rule match-direction input
126
Copyright © 2018, Juniper Networks, Inc.
Chapter 9: Allowing Components of a Private Network to Share a Single Address Using NAPT
user@host# set rule IPV6-NAPT-Rule term t1 then translated source-pool
IPV6-NAPT-Pool
user@host# set rule IPV6-NAPT-Rule term t1 then translated translation-type napt-66
4. Enter the up command to navigate to the [edit services] hierarchy level.
[edit services nat]
user@host# up
5. Define a service set to specify the services interface that must be used, and reference
the NAT rule implemented for NAPT translation.
[edit services]
user@host# set service-set service-set name interface- service service-interface
services interface
user@host# set service-set service-set name nat-rules rule name
For example:
[edit services]
user@host# set service-set IPV6-NAPT-ServiceSet interface-service service-interface
sp-0/1/0
user@host# set service-set IPV6-NAPT-ServiceSet nat-rules IPV6-NAPT-Rule
6. Define the trace options for the adaptive services PIC.
[edit services]
user@host# set adaptive-services-pics traceoptions flag tracing parameter
For example:
[edit services]
user@host# set adaptive-services-pics traceoptions flag all
The following example configures dynamic source (address and port) translation or
NAPT for an IPv6 network.
[edit services]
user@host# show
service-set IPV6-NAPT-ServiceSet {
nat-rules IPV6-NAPT-Rule;
interface-service {
service-interface sp-0/1/0;
}
}
nat {
pool IPV6-NAPT-Pool {
address 2002::1/96;
port automatic sequential;
}
rule IPV6-NAPT-Rule {
match-direction input;
term term1 {
then {
translated {
source-pool IPV6-NAPT-Pool;
translation-type {
Copyright © 2018, Juniper Networks, Inc.
127
Adaptive Services Interfaces Feature Guide for Routing Devices
napt-66;
}
}
}
}
}
}
adaptive-services-pics {
traceoptions {
flag all;
}
}
}
Example: Configuring NAT with Port Translation
This example shows how to configure NAT with port translation.
•
Requirements on page 128
•
Overview on page 128
•
Configuring NAT with Port Translation on page 128
Requirements
This example uses the following hardware and software components:
•
An MX Series 3D Universal Edge router with a Services DPC or an M Series Multiservice
Edge router with a services PIC
•
A domain name server (DNS)
•
Junos OS Release 11.4 or higher
Overview
This example shows a complete CGN NAT44 configuration and advanced options.
Configuring NAT with Port Translation
Step-by-Step
Procedure
To configure the service set:
1.
Configure a service set.
user@host# edit services service-set ss2
2.
Specify the NAT rule to be used.
[edit services service-set ss2]
host# set nat-rules r1
3.
Specify the interface service.
[edit services service-set ss2]
host# set interface-service service-interface sp-5/0/0
128
Copyright © 2018, Juniper Networks, Inc.
Chapter 9: Allowing Components of a Private Network to Share a Single Address Using NAPT
Results
user@host# show services service-sets sset2
nat-rules r1;
interface-service {
service-interface sp-5/0/0;
}
Related
Documentation
•
Example: NAPT Configuration on the MS-MPC With an Interface Service Set
This example shows how to configure network address translation with port translation
(NAPT) on an MX series router using a MultiServices Modular Port Concentrator (MS-MPC)
as a services interface card.
•
Requirements on page 129
•
Overview on page 129
•
Configuration on page 129
Requirements
This example uses the following hardware and software components:
•
MX-series router
•
MultiServices Modular Port Concentrator (MS-MPC)
•
Junos OS Release 13.2R1 or higher
Overview
A service provider has chosen an MS-MPC as a platform to provide NAT services to
accommodate new subscribers.
Configuration
To configure NAPT44 using the MS-MPC as a services interface card, perform these
tasks:
CLI Quick
Configuration
•
Configuring Interfaces on page 130
•
Configure an Application Set of Acceptable Application Traffic on page 131
•
Configuring a Stateful Firewall Rule on page 131
•
Configuring NAT Pool and Rule on page 132
•
Configuring the Service Set on page 133
To quickly configure this example, copy the following commands, paste them into a text
file, remove any line breaks, change any details necessary to match your network
Copyright © 2018, Juniper Networks, Inc.
129
Adaptive Services Interfaces Feature Guide for Routing Devices
configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy
level.
set interfaces ge-0/2/0 unit 0 family inet address 10.255.248.2/24
set interfaces xe-1/1/0 unit 0 family inet address 10.255.247.2/24
set interfaces xe-1/1/0 unit 0 family inet service input service-set sset1
set interfaces xe-1/1/0 unit 0 family inet service output service-set sset1
set interfaces ms-3/0/0 unit 0 family inet
set applications application-set accept-algs application junos-http
set applications application-set accept-algs application junos-ftp
set applications application-set accept-algs application junos-tftp
set applications application-set accept-algs application junos-telnet
set applications application-set accept-algs application junos-sip
set applications application-set accept-algs application junos-rtcp
set services stateful-firewall rule sf-rule1 match-direction input-output
set services stateful-firewall rule sf-rule1 term sf-term1 from source-address
10.255.247.0/24
set services stateful-firewall rule sf-rule1 term sf-term1 from application-sets accept-algs
set services stateful-firewall rule sf-rule1 term sf-term1 then accept
set services nat pool napt-pool address 1.1.1.0/24
set services nat pool napt-pool port automatic
* nat rule for napt
set services nat rule nat-rule1 match-direction input
set services nat rule nat-rule1 term nat-term1 from source-address 10.255.247.0/24
set services nat rule nat-rule1 term nat-term1 from application-sets accept-algs
set services nat rule nat-rule1 term nat-term1 then translated source-pool napt-pool
set services nat rule nat-rule1 term nat-term1 then translated translation-type napt-44
* nat rule for basic nat
set services service-set sset1 stateful-firewall-rules sf-rule1
set services service-set sset1 nat-rules nat-rule1
set services service-set sset1 interface-service service-interface ms-3/0/0
Configuring Interfaces
Step-by-Step
Procedure
Configure the interfaces required for NAT processing. You will need the following
interfaces:
•
A customer-facing interface that handles traffic from and to the customer.
•
An internet-facing interface.
•
A services interface that provides NAT and stateful firewall services to the
customer-facing interface
1.
Configure the interface for the customer-facing interface.
user@host# edit
[edit ]
user@host# set interfaces xe-1/1/0 unit 0 family inet address 10.255.247.2/24
user@host# set interfaces xe-1/1/0 unit 0 family inet service input service-set sset1
user@host# set interfaces xe-1/1/0 unit 0 family inet service output service-set sset1
2.
Configure the interface for the Internet-facing interface.
[edit ]
130
Copyright © 2018, Juniper Networks, Inc.
Chapter 9: Allowing Components of a Private Network to Share a Single Address Using NAPT
set interfaces ge-0/2/0 unit 0 family inet address 10.255.248.2/24
3.
Configure the interface for the service set that will connect services to the
customer-facing interface. In our example, the interface resides on an MS-MPC.
[edit ]
user@host# set interfaces ms-3/0/0 unit 0 family inet
Configure an Application Set of Acceptable Application Traffic
Step-by-Step
Procedure
Identify the acceptable applications for incoming traffic.
1.
Specify an application set that contains acceptable incoming application traffic.
user@host# set applications application-set accept-algs application junos-http
user@host# set applications application-set accept-algs application junos-ftp
user@host# set applications application-set accept-algs application junos-tftp
user@host# set applications application-set accept-algs application junos-telnet
user@host# set applications application-set accept-algs application junos-sip
user@host# set applications application-set accept-algs application junos-rtcp
Results
user@host#edit services applications application-set accept-algs
user@host#show
application junos-http;
application junos-ftp;
application junos-tftp;
application junos-telnet;
application junos-sip;
application junos-
Configuring a Stateful Firewall Rule
Step-by-Step
Procedure
Configure a stateful firewall rule that will accept all incoming traffic.
1.
Specify firewall matching for all input and output
user@hos#t set services stateful-firewall rule sf-rule1 match-direction input-output
2.
Identify source-address and acceptable application traffic from the customer-facing
interface.
user@host# set services stateful-firewall rule sf-rule1 term sf-term1 from
source-address 10.255.247.0/24
user@host# set services stateful-firewall rule sf-rule1 term sf-term1 from
application-sets accept-algs
user@host# set services stateful-firewall rule sf-rule1 term sf-term1 then accept
Copyright © 2018, Juniper Networks, Inc.
131
Adaptive Services Interfaces Feature Guide for Routing Devices
Results
user@host# edit services stateful-firewall
user@host# show
rule sf-rule1 {
match-direction input-output;
term sf-term1 {
from {
source-address {
10.255.247.0/24;
}
application-sets accept-algs;
}
then {
accept;
}
}
}
Configuring NAT Pool and Rule
Step-by-Step
Procedure
Configure a NAT pool and rule for address translation with automatic port assignment.
1.
Configure the NAT pool with automatic port assignment.
user@host# set services nat pool napt-pool address 1.1.1.0/24
user@host# set services nat pool napt-pool port automatic auto
2.
Configure a NAT rule that applies translation type napt-44 using the defined NAT
pool.
user@host# set services nat rule nat-rule1 term nat-term1 from application-sets
accept-algs
user@host# set services nat rule nat-rule1 term nat-term1 then translated source-pool
napt-pool
user@host# set services nat rule nat-rule1 term nat-term1 then translated
translation-type napt-44
132
Copyright © 2018, Juniper Networks, Inc.
Chapter 9: Allowing Components of a Private Network to Share a Single Address Using NAPT
Results
user@host#edit services nat
user@host#show
pool napt-pool {
address 1.1.1.0/24;
port {
automatic;
}
}
rule nat-rule1 {
match-direction input;
term nat-term1 {
from {
source-address {
10.255.247.0/24;
}
application-sets accept-algs;
}
then {
translated {
source-pool napt-pool;
translation-type {
napt-44;
}
}
}
}
}
Configuring the Service Set
Step-by-Step
Procedure
Configure an interface type service set.
1.
Specify the NAT and stateful firewall rules that apply to customer traffic.
user@host set services service-set sset1 stateful-firewall-rules sf-rule1
user@host set services service-set sset1 nat-rules bat-rule1
2.
Specify the services interface that applies the rules to customer traffic.
set services service-set sset1 interface-service service-interface ms-3/0/0
Results
Related
Documentation
user@host# edit services service-set sset1
user@host# show
set services service-set sset1 stateful-firewall-rules sf-rule1
set services service-set sset1 nat-rules nat-rule1
set services service-set sset1 interface-service service-interface ms-3/0/0
•
Junos Address Aware Network Addressing Overview on page 45
Copyright © 2018, Juniper Networks, Inc.
133
Adaptive Services Interfaces Feature Guide for Routing Devices
Example: Dynamic Source NAT as a Next-Hop Service
The following example shows dynamic-source NAT applied as a next-hop service:
[edit interfaces]
ge-0/2/0 {
unit 0 {
family mpls;
}
}
sp-1/3/0 {
unit 0 {
family inet;
}
unit 20 {
family inet;
}
unit 32 {
family inet;
}
}
[edit routing-instances]
protected-domain {
interface ge-0/2/0.0;
interface sp-1/3/0.20;
instance-type vrf;
route-distinguisher 10.58.255.17:37;
vrf-import protected-domain-policy;
vrf-export protected-domain-policy;
routing-options {
static {
route 0.0.0.0/0 next-hop sp-1/3/0.20;
}
}
}
[edit policy-options]
policy-statement protected-domain-policy {
term t1 {
then reject;
}
}
[edit services]
stateful-firewall {
rule allow-all {
match-direction input;
term t1 {
then {
accept;
}
}
}
}
nat {
pool my-pool {
134
Copyright © 2018, Juniper Networks, Inc.
Chapter 9: Allowing Components of a Private Network to Share a Single Address Using NAPT
address 10.58.16.100;
port automatic;
}
rule hide-all {
match-direction input;
term t1 {
then {
translated {
source-pool my-pool;
translation-type napt-44;
}
}
}
}
}
service-set null-sfw-with-nat {
stateful-firewall-rules allow-all;
nat-rules hide-all;
next-hop-service {
inside-service-interface sp-1/3/0.20;
outside-service-interface sp-1/3/0.32;
}
}
Copyright © 2018, Juniper Networks, Inc.
135
Adaptive Services Interfaces Feature Guide for Routing Devices
136
Copyright © 2018, Juniper Networks, Inc.
CHAPTER 10
Mapping Addresses and Ports With
Deterministic NAT
•
Deterministic NAPT Overview on page 138
•
Configuring Deterministic NAPT on page 143
Copyright © 2018, Juniper Networks, Inc.
137
Adaptive Services Interfaces Feature Guide for Routing Devices
Deterministic NAPT Overview
You can configure deterministic NAPT44 to ensure that the original source IPv4 address
and port always map to the same post-NAT IPv4 address and port range, and that the
reverse mapping of a given translated external IPv4 address and port are always mapped
to the same internal IPv4 address. You can configure deterministic NAPT64 to ensure
that the original source IPv6 address and port always map to the same post-NAT IPv4
address and port range, and that the reverse mapping of a given translated external IPv4
address and port are always mapped to the same internal IPv6 address. Deterministic
NAPT uses an algorithm-based allocation of blocks of destination ports.
Deterministic NAPT44 is supported on MX series routers with MS-DPCs and on M Series
routers with MS-100, MS-400, and MS-500 MultiServices PICS. Deterministic NAPT 44
is supported for MS-MPCs and MS-MICs starting in Junos OS release 17.3R1, in Junos OS
release 14.2R7 and later 14.2 releases, and in Junos OS release 15.1R3 and later 15.1 releases.
Starting in Junos OS Release 17.4R1, deterministic NAPT64 is supported on the MS-MPC
and MS-MIC.
If the source address in the from clause of a deterministic NAPT rule does not have a
prefix of /32, the network and broadcast addresses in the source address range are not
translated unless you configure include-boundary-addresses.
For detailed information on how to configure deterministic NAPT, see “Configuring
Deterministic NAPT” on page 143.
Benefits of Deterministic NAPT
•
Eliminates the need for address translation logging because an IP address is always
mapped to the same external IP address and port range, and the reverse mapping of
a given translated external IP address and port are always mapped to the same internal
IP address.
Understanding Deterministic NAPT Algorithms
The effectiveness of your implementation of deterministic NAPT depends on your analysis
of your subscriber requirements. The block size you provide indicates how many ports
will be made available for each incoming subscriber address from the range in the from
clause specified in the applicable NAT rule. The allocation algorithm computes an offset
value to determine the outgoing IP address and port. A reverse algorithm is used to derive
the originating subscriber address.
NOTE: In order to track subscribers without using logs, an ISP must use a
reverse algorithm to derive a subscriber (source) addresses from a translated
address.
138
Copyright © 2018, Juniper Networks, Inc.
Chapter 10: Mapping Addresses and Ports With Deterministic NAT
The following variables are used in forward calculation (private subscriber IP address to
public IP address) and reverse calculation (public IP address to private subscriber IP
address):
•
Pr_Prefix—Any pre-NAT IPv4 subscriber address.
•
Pr_Port—Any pre-NAT protocol port.
•
Block_Size—Number of ports configured to be available for each Pr_Prefix.
If block-size is configured as zero, the method for computing the block size is computed
as follows:
block-size = int(64512/ceil[(Nr_Addr_PR_Prefix/Nr_Addr_PU_Prefix)])
where 64512 is the maximum available port range per public IP address.
•
Base_PR_Prefix—First usable pre-NAT IPv4 subscriber address in a from clause of the
NAT rule.
•
Base_PU_Prefix—First usable post-NAT IPv4 subscriber address configured in the NAT
pool.
•
Pu_Port_Range_Start—First usable post-NAT port. This is 1024.
•
Pr_Offset—The offset of the pre-NAT IP address that is being translated from the first
usable pre-NAT IPv4 subscriber address in a from clause of the NAT rule. PR_Offset =
Pr_Prefix – Base_Pr_Prefix.
•
PR_Port_Offset—Offset of the pre-NAT IP address multiplied by the block size.
PR_Port_Offset = Pr_Offset * Block_Size.
•
Pu_Prefix—Post-NAT address for a given Pr_Prefix.
•
Pu_Start_Port—Post-NAT start port for a flow from a given Pr_Prefix
•
Pu_Actual_Port—Post-NAT port seen on a reverse flow.
•
Nr_Addr_PR_Prefix — Number of usable pre-NAT IPv4 subscriber addresses in a from
clause clause of the NAT rule.
•
Nr_Addr_PU_Prefix — Number of usable post-NAT IPv4 addresses configured in the
NAT pool.
•
Rounded_Port_Range_Per_IP — Number of ports available for each post-NAT IP address.
Rounded_Port_Range_Per_IP = ceil[(Nr_Addr_PR_Prefix/Nr_Addr_PU_Prefix)] *
Block_Size.
•
Pu_Offset—Offset of the post-NAT IP address from the first usable post-NAT address.
Pu_Offset = Pu_Prefix – Base_Pu_Prefix.
•
Pu_Port_Offset— Offset of the post-NAT port from 1024 added to the product of the
offset of the post-NAT IP address and the number of ports available for each post-NAT
IP address. Pu_Port_Offset = (Pu_Offset * Rounded_Port_Range_Per_IP) +
(Pu_Actual_Port – Pu_Port_Range_Start).
Algorithm Usage–Assume the following configuration:
services {
Copyright © 2018, Juniper Networks, Inc.
139
Adaptive Services Interfaces Feature Guide for Routing Devices
nat {
pool src-pool {
address-range low 32.32.32.1 high 32.32.32.254;
port {
automatic {
random-allocation;
}
deterministic-block-allocation {
block-size 249;
}
}
}
rule det-nat {
match-direction input;
term t1 {
from {
source-address {
10.1.0.0/16;
}
}
then {
translated {
source-pool src-pool;
translation-type {
deterministic-napt44;
}
}
}
}
Forward Translation
1.
Pr_Offset = Pr_Prefix – Base_Pr_Prefix
2. Pr_Port_Offset = Pr_Offset * Block_Size
3. Rounded_Port_Range_Per_IP = ceil[(Nr_Addr_PR_Prefix/Nr_Addr_PU_Prefix)] *
Block_Size
4. Pu_Prefix = Base_Public_Prefix + floor(Pr_Port_Offset / Rounded_Port_Range_Per_IP)
5. Pu_Start_Port = Pu_Port_Range_Start + (Pr_Port_Offset %
Rounded_Port_Range_Per_IP)
Using the sample configuration and assuming a subscriber flow sourced from
10.1.1.250:5000:
1.
Pr_Offset = 10.1.1.250 – 10.1.0.1 = 505
2. Pr_Port_Offset = 505 * 249 = 125,745
140
Copyright © 2018, Juniper Networks, Inc.
Chapter 10: Mapping Addresses and Ports With Deterministic NAT
3. Rounded_Port_Range_Per_IP = ceil[(65, 533/254)] * 249 = 259 * 249 = 64,491
4. Pu_Prefix = 32.32.32.1 + floor(125,745 /64,491) = 32.32.32.1 +1 =32.32.32.2
5. Pu_Start_Port = 1,024 + (125,745 % 64,491) = 62278
•
10.1.1.250 is translated to 32.32.32.2.
•
The starting port is 62278. There are 249 ports available to the subscriber based
on the configured block size. The available port range spans ports 62278 through
62526 (inclusive).
•
The specific flow 10.1.1.250:5000 randomly assigns any of the ports in its range
because random allocation was specified.
Reverse Translation
1.
Pu_Offset = Pu_Prefix – Base_Pu_Prefix
2. Pu_Port_Offset = (Pu_Offset * Rounded_Port_Range_Per_IP) + (Pu_Actual_Port –
Pu_Port_Range_Start)
3. Subscriber_IP = Base_Pr_Prefix + floor(Pu_Port_Offset / Block_Size)
The reverse translation is determined as follows. Assume a flow returning to
32.32.32.2:62278.
1.
Pu_Offset = 32.32.32.2 – 32.32.32.1 = 1
2. Pu_Port_Offset = (1 * 64,491) + (62,280 - 1024) = 125,747
3. Subscriber_IP = 10.1.0.1 + floor(125,747 / 249) = 10.1.0.1 + 505 = 10.1.1.250
NOTE: In reverse translation, only the original private IP address can be
derived, and not the original port in use. This is sufficiently granular for
law enforcement requirements.
When you have configured deterministic NAPT, you can use the show services nat
deterministic-nat internal-host and show services nat deterministic-nat nat-port-block
commands to show forward and reverse mapping. However, mappings will change if you
reconfigure your deterministic port block allocation block size or the from clause for your
NAT rule. In order to provide historical information on mappings, we recommend that
you write scripts that can show specific mappings for prior configurations.
Copyright © 2018, Juniper Networks, Inc.
141
Adaptive Services Interfaces Feature Guide for Routing Devices
Deterministic NAPT Restrictions
When you configure deterministic NAPT, you must be aware of the following restrictions.
Violation of any restriction results in a commit error. The restrictions and their error
messages are shown in Table 9 on page 142.
Table 9: Deterministic NAPT Commit Constraints
Restriction
Error Message
The total number of deterministic NAT blocks must be greater
than or equal to the from clause addresses configured. This means
that the Rounded_Port_Range_Per_IP value must be less than or
equal to 64,512.
Number of addresses and port blocks combination in the
NAT pool is less than number of addresses in 'from' clause
IPv6 addresses should not be used in deterministic NAT pool/from
clause.
Invalid IP address in pool p1 with translation type
deterministic-napt44
OR
There is already a range configured with v4 address range
The from clause addresses should be same if the same
deterministic NAT pool is used across multiple terms/rules. Only
one from clause address/range should be specified if the same
deterministic NAT pool is used across multiple terms/rules.
With translation-type deterministic-napt44, same 'from'
address/range should be configured if pool is shared by
multiple rules or terms
The from clause must have at least one source address.
With translation-type deterministic-napt44, at least one
non-except 'from' address/range should be configured.
error: configuration check-out failed
There should not be address overlap between except entries in the
from clause addresses.
overlapping address, in the 'from' clause between 'except'
entries
Addresses in a NAT pool used for deterministic NAPT should not
overlap with the addresses in any other NAT pool.
NAT pool det-nat-pool1 overlaps with det-nat-pool used
by service set sset_det-nat error: configuration check-out
failed
A deterministic NAT pool cannot be used with other translation
types. In addition, a deterministic NAT pool cannot be used in both
deterministic NAPT44 and deterministic NAPT64 NAT rules.
Deterministic NAT pool cannot be used with other
translation-types
Deterministic NAPT44 must use a source pool with
deterministic-port-block-allocation configuration.
Deterministic NAPT44 must use a source pool with
deterministic-port-block-allocation configuration
If address-allocation round-robin is configured, a commit results in
display of a warning indicating that this technique is not needed
with translation-type deterministic-napt44 and is ignored.
Address allocation round-robin is not needed with
translation-type deterministic-napt44
The total number of IP addresses assigned to a deterministic NAT
24
pool should be less than or equal to 2 (16777216).
Number of addresses in pool with deterministic-napt44
translation are limited to at most 16777216(2^24)
142
Copyright © 2018, Juniper Networks, Inc.
Chapter 10: Mapping Addresses and Ports With Deterministic NAT
Release History Table
Related
Documentation
•
Release
Description
17.4R1
Starting in Junos OS Release 17.4R1, deterministic NAPT64 is supported
on the MS-MPC and MS-MIC.
17.3R1
Deterministic NAPT 44 is supported for MS-MPCs and MS-MICs starting
in Junos OS release 17.3R1
Configuring Deterministic NAPT on page 143
Configuring Deterministic NAPT
Deterministic NAPT44 is supported on MX series routers with MS-DPCs and on M Series
routers with MS-100, MS-400, and MS-500 MultiServices PICS. Deterministic NAPT44
is supported for MS-MPCs and MS-MICs starting in Junos OS release 17.3R1, in Junos OS
release 14.2R7 and later 14.2 releases, and in Junos OS release 15.1R3 and later 15.1 releases.
Starting in Junos OS Release 17.4R1, deterministic NAPT64 is supported on the MS-MPC
and MS-MIC.
To configure deterministic NAPT, perform the following:
•
Configuring the NAT Pool for Deterministic NAPT on page 143
•
Configuring the NAT Rule for for Deterministic NAPT on page 145
•
Configuring the Service Set for Deterministic NAT on page 146
Configuring the NAT Pool for Deterministic NAPT
To configure the NAT pool for deterministic NAPT:
1.
At the [edit services nat pool poolname] hierarchy level, create a pool.
user@host# edit services nat pool poolname
2. Define the range of addresses to be translated, specifying the upper and lower limits
of the range or an address prefix that describes the range.
[edit services nat pool pba-pool1]
user@host# set address-range low address high address
Or
user@host# set address address-prefix
3. To configure automatic port assignment, specify either sequential or random allocation.
[edit services nat pool pba-pool1]
user@host# set port automatic (sequential | random-allocation)
Copyright © 2018, Juniper Networks, Inc.
143
Adaptive Services Interfaces Feature Guide for Routing Devices
NOTE: Starting in Junos OS Release 14.2R1, the sequential option is
introduced to enable you to configure sequential allocation of ports. The
sequential and random-allocation options available with the port automatic
statement at the [edit services nat pool nat-pool-name] hierarchy level are
mutually exclusive. You can include the sequential option for sequential
allocation and the random-allocation option for random delegation of
ports. By default, sequential allocation of ports takes place if you include
only the port automatic statement at the [edit services nat pool nat-poolname] hierarchy level.
For releases earlier than Junos OS Release 14.2R1, configure automatic
sequential port assignment by using the auto option at the [edit services
nat pool nat-pool-name port automatic] hierarchy level.
4. To configure a range of ports to assign, specify the low and high values for the port.
If you do not configure automatic port assignment, you must configure a range of
ports.
NOTE: If you specify a range of ports to assign, the automatic statement
is ignored.
[edit services nat pool pba-pool1]
user@host# set port range low minimum-value high maximum-value
5. Configure deterministic port block allocation. Specify block-size or accept the default
value of 512.
You can also specify include-boundary-addresses if you want the lowest and highest
addresses (the network and broadcast addresses) in the source address range of a
NAT rule to be translated when the NAT pool is used. If the source address has a prefix
of /32, the lowest and highest address are automatically translated.
[edit services nat pool pba-pool1]
user@host# set port deterministic-port-block-allocation block-size block-size
include-boundary-addresses
For example:
[edit services nat pool pba-pool1]
user@host# set port deterministic-port-block-allocation block-size 256
144
Copyright © 2018, Juniper Networks, Inc.
Chapter 10: Mapping Addresses and Ports With Deterministic NAT
NOTE: In order for deterministic-port-block-allocation configuration
changes to take effect, you must reboot the services PIC whenever you
change any of the following nat pool options:
See Also
•
•
address or address-range
•
port range
•
port deterministic-port-block-allocation block-size
Network Address Translation Configuration Overview on page 59
Configuring the NAT Rule for for Deterministic NAPT
To configure the NAT rule for deterministic NAPT:
1.
Configure the NAT rule name.
[edit services nat]
user@host# set rule rule-name
2. Configure the NAT rule match direction as input.
[edit services nat]
user@host# set rule rule-name match-direction input
3. Specify the addresses that are translated by the NAT rule.
To specify one address:
[edit services nat]
user@host# set rule rule-name term term-name from source-addressaddress
To specify a range of addresses:
[edit services nat]
user@host# set rule rule-name term term-name from source-address-range low
minimum-value high maximum-value
4. Specify the NAT pool that contains the addresses for translated traffic.
[edit services nat]
user@host# set rule rule-name term term-name then translated source-pool
nat-pool-name
5. Configure the translation type as deterministic NAPT44 or deterministic NAPT64.
[edit services nat]
user@host# set rule rule-name term term-name then translation-type
(deterministic-napt44 | deterministic-napt64)
Copyright © 2018, Juniper Networks, Inc.
145
Adaptive Services Interfaces Feature Guide for Routing Devices
Configuring the Service Set for Deterministic NAT
To configure the service set for deterministic NAPT:
1.
Define the service set.
[edit services]
user@host# edit service-set service-set-name
2. Configure either an interface service, which requires a single service interface, or a
next-hop service, which requires an inside and outside service interface.
[edit services service-set service-set-name]
user@host# set interface-service service-interface interface-name
or
[edit services service-set service-set-name]
user@host# set next-hop-service inside-service-interface interface-name
outside-service-interface interface-name
3. Specify the NAT rules or ruleset to be used with the service set.
[edit services service-set service-set-name]
user@host# set nat-rules rule-name
146
Copyright © 2018, Juniper Networks, Inc.
CHAPTER 11
Securing Traffic Using NAT-PT and ALGs
•
ALGs Available for Junos OS Address Aware NAT on page 147
•
Configuring NAT-PT on page 150
•
Example: Configuring NAT-PT on page 157
ALGs Available for Junos OS Address Aware NAT
The following Application Level Gateways (ALGs) listed in Table 10 on page 148 are
supported for NAT processing on the listed platforms.
To view the implementation details (port, protocol, and so on) for these Junos OS default
applications, locate the Junos OS Default ALG Name in the table and then look up the
listed name in the groups. For example, for details about TFTP, look up junos-tftp as
shown.
TIP: The Junos OS provides the junos-alg, which enables other ALGs to
function by handling ALG registrations, causing slow path packets to flow
through registered ALGs, and transferring ALG events to the ALG plug-ins.
The junos-alg ALG is automatically available on the MS-MPC and MS-MIC
platforms and does not require further configuration.
NOTE: The remote shell (RSH) and remote login (rlogin) application layer
gateways (ALGs) are not supported with network address port translation
(NAPT) on MX Series routers with MS-MICs and MS-MPCs.
user@host# show groups junos-defaults applications application junos-tftp
application-protocol tftp;
protocol udp;
destination-port 69;
Table 10 on page 148 summarizes the ALGs available for Junos OS Address Aware NAT
for services interfaces cards.
Copyright © 2018, Juniper Networks, Inc.
147
Adaptive Services Interfaces Feature Guide for Routing Devices
Table 10: ALGs Available for NAT by Type of Interface Card
ALG
MS-DPC
MS-MPC, MS-MIC
Junos OS Default ALG Name
Basic TCP ALG
yes
yes
NOTE: Specific Junos OS ALGs are not
supported. However, a feature called TCP
tracker, available by default, performs segment
ordering and retransmit and connection tracking,
validations for TCP connections.
Basic UDP ALG
yes
yes
NOTE: TCP tracker performs limited integrity
and validation checks for UDP.
BOOTP
yes
no
•
junos-bootpc
•
junos-bootps
•
junos-dce-rpc-portmap
•
junos-dcerpc-endpoint-mapper-service
•
junos-dcerpc-msexchange-directory-nsp
•
junos-dcerpc-msexchange-directory-rfr
•
junos-dcerpc-msexchange-information-store
DCE RPC Services
yes
yes
DNS
yes
yes
•
junos-dns-udp
DNS
yes
no
•
junos-dns-tcp
FTP
yes
yes
•
junos-ftp
Gatekeeper RAS
(Starting in Junos OS
Release 17.1R1)
no
yes
•
junos-h323-ras
H323
no
yes
•
junos-h323
ICMP
yes
yes
•
junos-icmp-all
•
junos-icmp-ping
•
junos-iiop-java
•
junos-iiop-orbix
•
junos-ike
NOTE: In Junos OS Release 14.1
and earlier, ICMP messages are
handled by default, but PING ALG
support is not provided. Starting
In Junos OS 14.2, ICMP messages
are handled by default and PING
ALG support is provided.
IIOP
IKE ALG
yes
no
no
yes
NOTE: Starting in Junos OS
Release 14.2R7, 15.1R5, 16.1R2,
and 17.1R1, the IKE ALG ALG is
supported on MS-MPCs and
MS-MICs.
148
Copyright © 2018, Juniper Networks, Inc.
Chapter 11: Securing Traffic Using NAT-PT and ALGs
Table 10: ALGs Available for NAT by Type of Interface Card (continued)
ALG
MS-DPC
MS-MPC, MS-MIC
Junos OS Default ALG Name
IP
yes
The TCP tracker, available by
default on these platforms,
performs limited integrity and
validation checks.
•
junos-ip
NETBIOS
yes
no
•
junos-netbios-datagram
•
junos-netbios-name-tcp
•
junos-netbios-name-udp
•
junos-netbios-session
NETSHOW
yes
no
•
junos-netshow
PPTP
yes
yes
•
junos-pptp
REALAUDIO
yes
no
•
junos-realaudio
Sun RPC and RPC Port
Map Services
yes
yes
•
junos-rpc-portmap-tcp
•
junos-rpc-portmap-udp
RTSP
yes
yes
•
junos-rtsp
SIP
yes
Yes
•
junos-sip
The SIP callid is not translated in register
messages.
NOTE: SIP sessions are limited to 12 hours (720
minutes) for NAT processing on the MS-MIC and
MS-MPC interface cards. SIP sessions on the
MS-DPC have no time limits.
SNMP
yes
No
•
junos-snmp-get
•
junos-snmp-get-next
•
junos-snmp-response
•
junos-snmp-trap
SQLNET
yes
yes
•
junos-sqlnet
TFTP
yes
yes
•
junos-tftp
Traceroute
yes
yes
•
junos-traceroute
Unix Remote Shell
Service
yes
yes
•
junos-rsh
NOTE: Remote Shell (RSH) ALG
is not supported for network
address port translation (NAPT).
Copyright © 2018, Juniper Networks, Inc.
149
Adaptive Services Interfaces Feature Guide for Routing Devices
Table 10: ALGs Available for NAT by Type of Interface Card (continued)
ALG
MS-DPC
MS-MPC, MS-MIC
Junos OS Default ALG Name
WINFrame
yes
No
•
junos-citrix-winframe
•
junos-citrix-winframe-udp
TALK-UDP
No
Yes
•
junos-talk-udp
MS RPC
No
Yes
•
junos-rpc-portmap-tcp
•
junos-rpc-portmap-udp
•
junos-rpc-services-tcp
•
junos-rpc-services-udp
Release History Table
Related
Documentation
•
Release
Description
17.1R1
Gatekeeper RAS (Starting in Junos OS Release 17.1R1)
14.2R7
Starting in Junos OS Release 14.2R7, 15.1R5, 16.1R2, and 17.1R1, the IKE ALG
ALG is supported on MS-MPCs and MS-MICs.
14.2
Starting In Junos OS 14.2, ICMP messages are handled by default and PING
ALG support is provided.
ALG Descriptions on page 337
Configuring NAT-PT
To configure the translation type as basic-nat-pt, you must configure the DNS ALG
application, the NAT pools and rules, a service set with a service interface, and trace
options. Configuring NAT-PT is not supported if you are using MS-MPCs or MS-MICs.
This topic includes the following tasks:
•
Configuring the DNS ALG Application on page 150
•
Configuring the NAT Pool and NAT Rule on page 151
•
Configuring the Service Set for NAT on page 154
•
Configuring Trace Options on page 155
Configuring the DNS ALG Application
To configure the DNS ALG application:
1.
In configuration mode, go to the [edit applications] hierarchy level.
[edit]
user@host# edit applications
150
Copyright © 2018, Juniper Networks, Inc.
Chapter 11: Securing Traffic Using NAT-PT and ALGs
2. Configure the ALG to which the DNS traffic is destined at the [edit applications]
hierarchy level. Define the application name and specify the application protocol to
use in match conditions in the first NAT rule or term.
[edit applications]
user@host# set application application-name application-protocol application-protocol
In the following example, the application name is dns-alg and application protocol is
dns.
[edit applications]
user@host# set application dns-alg application-protocol dns
3. Verify the configuration by using the show command at the [edit applications] hierarchy
level.
[edit applications]
user@host# show
application dns-alg {
application-protocol dns;
}
Configuring the NAT Pool and NAT Rule
To configure the NAT pool and NAT rule:
1.
In configuration mode, go to the [edit services nat] hierarchy level.
[edit]
user@host# edit services nat
2. Configure the NAT pool and its address.
[edit services nat]
user@host# set pool pool-name address address
In the following example, the name of the NAT pool is p1 and the address is
10.10.10.2/32.
[edit services nat]
user@host# set pool p1 address 10.10.10.2/32
3. Configure the source pool and its address.
[edit services nat]
user@host# set pool source-pool-name address address
In the following example, the name of the source pool is src_pool0 and the source
pool address is 20.1.1.1/32.
[edit services nat]
user@host# set pool src_pool0 address 20.1.1.1/32
4. Configure the destination pool and its address.
[edit services nat]
Copyright © 2018, Juniper Networks, Inc.
151
Adaptive Services Interfaces Feature Guide for Routing Devices
user@host# set pool destination-pool-name address address
In the following example, the name of the destination pool is dst_pool0 and the
destination pool address is 50.1.1.2/32.
[edit services nat]
user@host# set pool dst_pool0 address 50.1.1.2/32
5. Configure the rule and the match direction.
[edit services nat]
user@host# set rule rule-name match-direction match-direction
In the following example, the rule name is rule-basic-nat-pt and the match direction
is input.
[edit services nat]
user@host# set rule basic-nat-pt match-direction input
6. Configure the term and the input conditions for the NAT term.
[edit services nat]
user@host# set rule rule-basic-nat-pt term term from from
In the following example, the term is t1 and the input conditions are source-address
2000::2/128, destination-address 4000::2/128, and applications dns_alg.
[edit services nat]
user@host# set rule rule-basic-nat-pt term t1 from source-address 2000::2/128
[edit services nat]
user@host# set rule rule-basic-nat-pt term t1 from destination-address 4000::2/128
[edit services nat]
user@host# set rule rule-basic-nat-pt term t1 from applications dns_alg
7. Configure the NAT term action and the properties of the translated traffic.
[edit services nat]
user@host# set rule rule-basic-nat-pt term t1 then term-action translated-property
In the following example, the term action is translated and the properties of the
translated traffic are source-pool src_pool0, destination-pool dst_pool0, and
dns-alg-prefix 2001:db8:10::0/96.
[edit services nat]
user@host# set rule rule-basic-nat-pt term t1 then translated source-pool src_pool0
[edit services nat]
user@host# set rule rule-basic-nat-pt term t1 then translated destination-pool
dst_pool0
[edit services nat]
user@host# set rule rule-basic-nat-pt term t1 then translated dns-alg-prefix
2001:db8:10::0/96
8. Configure the translation type.
[edit services nat]
user@host# set rule rule-basic-nat-pt term t1 then translated translation-type
translation-type
152
Copyright © 2018, Juniper Networks, Inc.
Chapter 11: Securing Traffic Using NAT-PT and ALGs
In the following example, the translation type is basic-nat-pt.
[edit services nat]
user@host# set rule rule-basic-nat-pt term t1 then translated translation-type
basic-nat-pt
9. Configure another term and the input conditions for the NAT term.
[edit services nat]
user@host# set rule rule-basic-nat-pt term term-name from from
In the following example, the term name is t2 and the input conditions are
source-address 2000::2/128 and destination-address 2001:db8:10::0/96.
[edit services nat]
user@host# set rule rule-basic-nat-pt term t2 from source-address 2000::2/128
[edit services nat]
user@host# set rule rule-basic-nat-pt term t2 from destination-address
2001:db8:10::0/96
10. Configure the NAT term action and the property of the translated traffic.
[edit services nat]
user@host# set rule rule-basic-nat-pt term t2 then term-action translated-property
In the following example, the term action is translated and the property of the
translated traffic is source-prefix 19.19.19.1/32.
[edit services nat]
user@host# set rule rule-basic-nat-pt term t2 then translated source-prefix
19.19.19.1/32
11. Configure the translation type.
[edit services nat]
user@host# set rule rule-basic-nat-pt term t2 then translated translation-type
translation-type
In the following example, the translation type is basic-nat-pt.
[edit services nat]
user@host# set rule rule-basic-nat-pt term t2 then translated translation-type
basic-nat-pt
12. Verify the configuration by using the show command at the [edit services nat] hierarchy
level.
[edit services nat]
user@host# show
pool p1 {
address 10.10.10.2/32;
}
pool src_pool0 {
address 20.1.1.1/32;
}
pool dst_pool0 {
address 50.1.1.2/32;
Copyright © 2018, Juniper Networks, Inc.
153
Adaptive Services Interfaces Feature Guide for Routing Devices
}
rule rule-basic-nat-pt {
match-direction input;
term t1 {
from {
source-address {
2000::2/128;
}
destination-address {
4000::2/128;
}
applications dns_alg;
}
then {
translated {
source-pool src_pool0;
destination-pool dst_pool0;
dns-alg-prefix 2001:db8:10::0/96;
translation-type {
basic-nat-pt;
}
}
}
}
term t2 {
from {
source-address {
2000::2/128;
}
destination-address {
2001:db8:10::0/96;
}
}
then {
translated {
source-prefix 19.19.19.1/32;
translation-type {
basic-nat-pt;
}
}
}
}
}
Configuring the Service Set for NAT
To configure the service set for NAT:
1.
In configuration mode, go to the [edit services] hierarchy level.
[edit]
user@host# edit services
2. Configure the service set.
[edit services]
user@host# edit service-set service-set-name
154
Copyright © 2018, Juniper Networks, Inc.
Chapter 11: Securing Traffic Using NAT-PT and ALGs
In the following example, the name of the service set is ss_dns.
[edit services]
user@host# edit service-set ss_dns
3. Configure the service set with NAT rules.
[edit services service-set ss_dns]
user@host# set nat-rules rule-name
In the following example, the rule name is rule-basic-nat-pt.
[edit services service-set ss_dns]
user@host# set nat-rules rule-basic-nat-pt
4. Configure the service interface.
[edit services service-set ss_dns]
user@host# set interface-service service-interface service-interface-name
In the following example, the name of service interface is sp-1/2/0.
[edit services service-set ss_dns]
user@host# set interface-service service-interface sp-1/2/0
5. Verify the configuration by using the show services command from the [edit] hierarchy
level.
[edit]
user@host# show services
service-set ss_dns {
nat-rules rule-basic-nat-pt;
interface-service {
service-interface sp-1/2/0;
}
}
Configuring Trace Options
To configure the trace options:
1.
In configuration mode, go to the [edit services adaptive-services-pics] hierarchy level.
[edit]
user@host# edit services adaptive-services-pics
2. Configure the trace options.
[edit services adaptive-services-pics]
user@host# set traceoptions flag tracing parameter
In the following example, the tracing parameter is all.
[edit services adaptive-services-pics]
user@host# set traceoptions flag all
Copyright © 2018, Juniper Networks, Inc.
155
Adaptive Services Interfaces Feature Guide for Routing Devices
3. Verify the configuration by using the show command at the [edit services] hierarchy
level.
[edit services]
user@host# show
adaptive-services-pics {
traceoptions {
flag all;
}
}
The following example configures the translation type as basic-nat-pt.
[edit]
user@host# show services
service-set ss_dns {
nat-rules rule-basic-nat-pt;
interface-service {
service-interface sp-1/2/0;
}
}
nat {
pool p1 {
address 10.10.10.2/32;
}
pool src_pool0 {
address 20.1.1.1/32;
}
pool dst_pool0 {
address 50.1.1.2/32;
}
rule rule-basic-nat-pt {
match-direction input;
term t1 {
from {
source-address {
2000::2/128;
}
destination-address {
4000::2/128;
}
applications dns_alg;
}
then {
translated {
source-pool src_pool0;
destination-pool dst_pool0;
dns-alg-prefix 2001:db8:10::0/96;
translation-type {
basic-nat-pt;
}
}
}
}
term t2 {
from {
source-address {
2000::2/128;
}
156
Copyright © 2018, Juniper Networks, Inc.
Chapter 11: Securing Traffic Using NAT-PT and ALGs
destination-address {
2001:db8:10::0/96;
}
}
then {
translated {
source-prefix 19.19.19.1/32;
translation-type {
basic-nat-pt;
}
}
}
}
}
}
adaptive-services-pics {
traceoptions {
flag all;
}
}
Example: Configuring NAT-PT
A Domain Name System application-level gateway (DNS ALG) is used with Network
Address Translation-Protocol Translation (NAT-PT) to facilitate name-to-address
mapping. You can configure the DNS ALG to map addresses returned in the DNS response
to an IPv6 address. Configuring NAT-PT is not supported if you are using MS-MPCs or
MS-MICs.
When you configure NAT-PT with DNS ALG support, you must configure two NAT rules
or one rule with two terms. In this example, you configure two rules. The first NAT rule
ensures that the DNS query and response packets are translated correctly. For this rule
to work, you must configure a DNS ALG application and reference it in the rule. The second
rule is required to ensure that NAT sessions are destined to the address mapped by the
DNS ALG.
Then, you must configure a service set, and then apply the service set to the interfaces.
This example describes how to configure NAT-PT with DNS ALG:
•
Requirements on page 157
•
Overview and Topology on page 158
•
Configuration of NAT-PT with DNS ALGs on page 159
Requirements
This example uses the following hardware and software components:
•
Junos OS Release 11.2
•
A multiservices interface (ms-)
Copyright © 2018, Juniper Networks, Inc.
157
Adaptive Services Interfaces Feature Guide for Routing Devices
Overview and Topology
The following scenario shows the process of NAT-PT with DNS ALG when a laptop in an
IPv6-only domain requests access to a server in an IPv4-only domain.
Figure 10: Configuring DNS ALGs with NAT-PT Network Topology
Packet header:
SA: 2000::2/128
DA: 4000::2/128
IPv6 Domain
IPv4 Domain
Payload:
Request AAAA record
for
6 www.example.com
DNS Server
50.1.1.1/32
Step 1:
SA: 2000::2/128 translated to 40.1.1.1/32
DA: 4000::2/128 translated to 50.1.1.1/32
Packet header:
SA: 50.1.1.1/32
DA: 40.1.1.1/32
Payload: The AAAA request is translated
to an A request
Payload: A response
www.example.com = 1.1.1.1
Step 2:
SA: 50.1.1.1/32 translated to 4000::2/128
DA: 40.1.1.1/32 translated to 2000:2/128
Laptop address:
2000::2/128
DNS server address:
4000::2/128
Payload: The A response translated
to an IPv6 address
Step 3:
SA: 2000::2/128 translated to 40.1.1.1/32
DA: 10.10.10::1.1.1.1 translated to 1.1.1.1
www.example.com
1.1.1.1
g017486
NAT DNS ALG session
http: session
SA = source address
DA = destination address
The Juniper Networks router in the center of the illustration performs address translation
in two steps. When the laptop requests a session with the www.example.com server that
is in an IPv4-only domain, the Juniper Networks router performs the following:
•
Translates the IPv6 laptop and DNS server addresses into IPv4 addresses.
•
Translates the AAAA request from the laptop into an A request so that the DNS server
can provide the IPv4 address.
When the DNS server responds with the A request, the Juniper Networks router performs
the following:
•
Translates the IPv4 DNS server address back into an IPv6 address.
•
Translates the A request back into a AAAA request so that the laptop now has the
96-bit IPv6 address of the www.example.com server.
After the laptop receives the IPv6 version of the www.example.com server address, the
laptop initiates a second session using the 96-bit IPv6 address to access that server. The
Juniper Networks router performs the following:
158
•
Translates the laptop IPv4 address directly into its IPv4 address.
•
Translates the 96-bit IPv6 www.example.com server address into its IPv4 address.
Copyright © 2018, Juniper Networks, Inc.
Chapter 11: Securing Traffic Using NAT-PT and ALGs
Configuration of NAT-PT with DNS ALGs
To configure NAT-PT with DNS ALG , perform the following tasks:
•
Configuring the Application-Level Gateway on page 159
•
Configuring the NAT Pools on page 160
•
Configuring the DNS Server Session: First NAT Rule on page 161
•
Configuring the HTTP Session: Second NAT Rule on page 164
•
Configuring the Service Set on page 166
•
Configuring the Stateful Firewall Rule on page 168
•
Configuring Interfaces on page 169
Configuring the Application-Level Gateway
Step-by-Step
Procedure
Configure the DNS application as the ALG to which the DNS traffic is destined. The DNS
application protocol closes the DNS flow as soon as the DNS response is received. When
you configure the DNS application protocol, you must specify the UDP protocol as the
network protocol to match in the application definition.
To configure the DNS application:
1.
In configuration mode, go to the [edit applications] hierarchy level.
user@host# edit applications
2.
Define the application name and specify the application protocol to use in match
conditions in the first NAT rule.
[edit applications]
user@host# set application application-name application-protocol protocol-name
For example:
[edit applications]
user@host# set application dns_alg application-protocol dns
3.
Specify the protocol to match, in this case UDP.
[edit applications]
user@host# set application application-name protocol type
For example:
[edit applications]
user@host# set application dns_alg protocol udp
4.
Define the UDP destination port for additional packet matching, in this case the
domain port.
[edit applications]
user@host# set application application-name destination-port value
For example:
Copyright © 2018, Juniper Networks, Inc.
159
Adaptive Services Interfaces Feature Guide for Routing Devices
[edit applications]
user@host# set application dns_alg destination-port 53
Results
[edit applications]
user@host# show
application dns_alg {
application-protocol dns;
protocol udp;
destination-port 53;
}
Configuring the NAT Pools
Step-by-Step
Procedure
In this configuration, you configure two pools that define the addresses (or prefixes) used
for NAT. These pools define the IPv4 addresses that are translated into IPv6 addresses.
The first pool includes the IPv4 address of the source. The second pool defines the IPv4
address of the DNS server. To configure NAT pools:
1.
In configuration mode, go to the [edit services nat] hierarchy level.
user@host# edit services nat
2.
Specify the name of the first pool and the IPv4 source address (laptop).
[edit services nat]
user@host# set pool nat-pool-name address ip-prefix
For example:
[edit services nat]
user@host# set pool pool1 address 40.1.1.1/32
3.
Specify the name of the second pool and the IPv4 address of the DNS server.
[edit services nat]
user@host# set pool nat-pool-name address ip-prefix
For example:
[edit services nat]
user@host# set pool pool2 address 50.1.1.1/32
Results
The following sample output shows the configuration of NAT pools.
[edit services nat]
user@host# show
pool pool1 {
address 40.1.1.1/32;
}
pool pool2 {
160
Copyright © 2018, Juniper Networks, Inc.
Chapter 11: Securing Traffic Using NAT-PT and ALGs
address 50.1.1.1/32;
}
Configuring the DNS Server Session: First NAT Rule
Step-by-Step
Procedure
The first NAT rule is applied to DNS traffic going to the DNS server. This rule ensures that
the DNS query and response packets are translated correctly. For this rule to work, you
must configure a DNS ALG application and reference it in the rule. The DNS application
was configured in “Configuring the DNS ALG Application” on page 150. In addition, you
must specify the direction in which traffic is matched, the source address of the laptop,
the destination address of the DNS server, and the actions to take when the match
conditions are met.
To configure the first NAT rule:
1.
In configuration mode, go to the [edit services nat] hierarchy level.
user@host# edit services nat
2.
Specify the name of the NAT rule.
[edit services nat]
user@host# edit rule rule-name
For example:
[edit services nat]
user@host# edit rule rule1
3.
Specify the name of the NAT term.
[edit services nat rule rule-name]
user@host# edit term term-name
For example:
[edit services nat rule rule1]
user@host# edit term term1
4.
Define the match conditions for this rule.
a. Specify the IPv6 source address of the device (laptop) attempting to access an
IPv4 address.
[edit services nat rule rule-name term term-name]
user@host# set from source-address source-address
For example:
[edit services nat rule rule1 term term1]
user@host# set from source-address 2000::2/128
b. Specify the IPv6 destination address of the DNS server.
[edit services nat rule rule-name term term-name]
user@host# set from destination-address prefix
Copyright © 2018, Juniper Networks, Inc.
161
Adaptive Services Interfaces Feature Guide for Routing Devices
For example:
[edit services nat rule rule1 term term1]
user@host# set from destination-address 4000::2/128
c. Reference the DNS application to which the DNS traffic destined for port 53 is
applied.
[edit services nat rule rule1 term term1]
user@host# set from applications application-name
In this example, the application name configured in the Configuring the DNS
Application step is dns_alg:
[edit services nat rule rule1 term term1]
user@host# set from applications dns_alg
5.
Define the actions to take when the match conditions are met. The source and
destination pools you configured in “Configuring the NAT Pools” on page 160 are
applied here.
a. Apply the NAT pool configured for source translation.
[edit services nat rule rule-name term term-name]
user@host# set then translated source-pool nat-pool-name
For example:
[edit services nat rule rule1 term term1]
user@host# set then translated source-pool pool1
b. Apply the NAT pool configured for destination translation.
[edit services nat rule rule-name term term-name]
user@host# set then translated destination-pool nat-pool-name
For example:
[edit services nat rule rule1 term term1]
user@host# set then translated source-pool pool2
6.
Define the DNS ALG 96-bit prefix for IPv4-to-IPv6 address mapping.
[edit services nat rule rule-name term term-name]
user@host# set then translated dns-alg-prefix dns-alg-prefix
For example:
[edit services nat rule rule1 term term1]
user@host# set then translated dns-alg-prefix 10:10:10::0/96
7.
Specify the type of NAT used for source and destination traffic.
[edit services nat rule rule-name term term-name]
user@host# set then translated translation-type basic-nat-pt
For example:
[edit services nat rule rule1 term term1]
user@host# set then translated translation-type basic-nat-pt
162
Copyright © 2018, Juniper Networks, Inc.
Chapter 11: Securing Traffic Using NAT-PT and ALGs
NOTE: In this example, since NAT is achieved using address-only
translation, the basic-nat-pt translation type is used. To achieve NAT
using address and port translation (NAPT), use the napt-pt translation
type.
8.
Specify the direction in which to match traffic that meets the rule conditions.
[edit services nat rule rule-name]
user@host# set match-direction (input | output)
For example:
[edit services nat rule rule1]
user@host# set match-direction input
9.
Configure system logging to record information from the services interface to the
/var/log directory.
[edit services nat rule rule-name term term-name]
user@host# set then syslog
For example:
[edit services nat rule rule1 term term1]
user@host# set then syslog
Copyright © 2018, Juniper Networks, Inc.
163
Adaptive Services Interfaces Feature Guide for Routing Devices
Results
The following sample output shows the configuration of the first NAT rule that goes to
the DNS server.
[edit services nat]
user@host# show
rule rule1 {
match-direction input;
term term1 {
from {
source-address {
2000::2/128;
}
destination-address {
4000::2/128;
}
applications dns_alg;
}
then {
translated {
source-pool pool1;
destination-pool pool2;
dns-alg-prefix 10:10:10::0/96;
translation-type {
basic-nat-pt;
}
}
syslog;
}
}
}
Configuring the HTTP Session: Second NAT Rule
Step-by-Step
Procedure
The second NAT rule is applied to destination traffic going to the IPv4 server
(www.example.com). This rule ensures that NAT sessions are destined to the address
mapped by the DNS ALG. For this rule to work, you must configure the DNS ALG address
map that correlates the DNS query or response processing done by the first rule with the
actual data sessions processed by the second rule. In addition, you must specify the
direction in which traffic is matched: the IPv4 address for the IPv6 source address (laptop),
the 96-bit prefix to prepend to the IPv4 destination address (www.example.com), and
the translation type.
To configure the second NAT rule:
1.
In configuration mode, go to the following hierarchy level.
user@host# edit services nat
2.
Specify the name of the NAT rule and term.
[edit services nat]
user@host# edit rule rule-name term term-name
For example:
164
Copyright © 2018, Juniper Networks, Inc.
Chapter 11: Securing Traffic Using NAT-PT and ALGs
[edit services nat]
user@host# edit rule rule2 term term1
3.
Define the match conditions for this rule:
a. Specify the IPv6 address of the device attempting to access the IPv4 server.
[edit services nat rule rule-name term term-name]
user@host# set from source-address source-address
For example:
[edit services nat rule rule2 term term1]
user@host# set from source-address 2000::2/128
b. Specify the 96-bit IPv6 prefix to prepend to the IPv4 server address.
[edit services nat rule rule-name term term-name]
user@host# set from destination-address prefix
For example:
[edit services nat rule rule2 term term1]
user@host# set from destination-address 10:10:10::c0a8:108/128
4.
Define the actions to take when the match conditions are met.
•
Specify the prefix for the translation of the IPv6 source address.
[edit services nat rule rule-name term term-name]
user@host# set then translated source-prefix source-prefix
For example:
[edit services nat rule rule2 term term1]
user@host# set then translated source-prefix 19.19.19.1/32
5.
Specify the type of NAT used for source and destination traffic.
[edit services nat rule rule-name term term-name]
user@host# set then translated translation-type basic-nat-pt
For example:
[edit services nat rule rule2 term term1]
user@host# set then translated translation-type basic-nat-pt
NOTE: In this example, since NAT is achieved using address-only
translation, the basic-nat-pt translation type is used. To achieve NAT
using address and port translation (NAPT), you must use the napt-pt
translation type.
6.
Specify the direction in which to match traffic that meets the conditions in the rule.
[edit services nat rule rule-name]
user@host# set match-direction (input | output)
Copyright © 2018, Juniper Networks, Inc.
165
Adaptive Services Interfaces Feature Guide for Routing Devices
For example:
[edit services nat rule rule2]
user@host# set match-direction input
Results
The following sample output shows the configuration of the second NAT rule.
[edit services nat]
user@host# show
rule rule2 {
match-direction input;
term term1 {
from {
source-address {
2000::2/128;
}
destination-address {
10:10:10::c0a8:108/128;
}
}
then {
translated {
source-prefix 19.19.19.1/32;
translation-type {
basic-nat-pt;
}
}
}
}
}
Configuring the Service Set
Step-by-Step
Procedure
This service set is an interface service set used as an action modifier across the entire
services (ms-) interface. Stateful firewall and NAT rule sets are applied to traffic processed
by the services interface.
To configure the service set:
1.
In configuration mode, go to the [edit services] hierarchy level.
user@host# edit services
2.
Define a service set.
[edit services]
user@host# edit service-set service-set-name
For example:
[edit services]
user@host# edit service-set ss
166
Copyright © 2018, Juniper Networks, Inc.
Chapter 11: Securing Traffic Using NAT-PT and ALGs
3.
Specify properties that control how system log messages are generated for the
service set.
[edit services service-set ss]
user@host# set syslog host local services severity-level
The example below includes all severity levels.
[edit services service-set ss]
user@host# set syslog host local services any
4.
Specify the stateful firewall rule included in this service set.
[edit services service-set ss]
user@host# set stateful-firewall-rules rule1 severity-level
The example below references the stateful firewall rule defined in “Configuring the
Stateful Firewall Rule” on page 168.
[edit services service-set ss]
user@host# set stateful-firewall-rules rule1
5.
Define the NAT rules included in this service set.
[edit services service-set ss]
user@host# set nat-rules rule-name
The example below references the two rules defined in this configuration example.
[edit services service-set ss
user@host# set nat-rules rule1
user@host# set nat-rules rule2
6.
Configure an adaptive services interface on which the service is to be performed.
[edit services service-set ss]
user@host# set interface-service service-interface interface-name
For example:
[edit services service-set ss
user@host# interface-service service-interface ms-2/0/0
Only the device name is needed, because the router software manages logical unit
numbers automatically. The services interface must be an adaptive services interface
for which you have configured unit 0 family inet at the [edit interfaces interface-name]
hierarchy level in “Configuring Interfaces” on page 169.
Copyright © 2018, Juniper Networks, Inc.
167
Adaptive Services Interfaces Feature Guide for Routing Devices
Results
The following sample output shows the configuration of the service set.
[edit services]
user@host# show
service-set ss {
syslog {
host local {
services any;
}
}
stateful-firewall-rules rule1;
nat-rules rule1;
nat-rules rule2;
interface-service {
service-interface ms-2/0/0;
}
}
Configuring the Stateful Firewall Rule
Step-by-Step
Procedure
This example uses a stateful firewall to inspect packets for state information derived
from past communications and other applications. The NAT-PT router checks the traffic
flow matching the direction specified by the rule, in this case both input and output. When
a packet is sent to the services (ms-) interface, direction information is carried along with
it.
To configure the stateful firewall rule:
1.
In configuration mode, go to the [edit services stateful firewall] hierarchy level.
user@host# edit services stateful firewall
2.
Specify the name of the stateful firewall rule.
[edit services stateful-firewall]
user@host# edit rule rule-name
For example:
[edit services stateful-firewall]
user@host# edit rule rule1
3.
Specify the direction in which traffic is to be matched.
[edit services stateful-firewall rule rule-name]
user@host# set match-direction (input | input-output | output)
For example:
[edit services stateful-firewall rule rule1]
user@host# set match-direction input-output
4.
Specify the name of the stateful firewall term.
[edit services stateful-firewall rule rule-name]
168
Copyright © 2018, Juniper Networks, Inc.
Chapter 11: Securing Traffic Using NAT-PT and ALGs
user@host# edit term term-name
For example:
[edit services stateful-firewall rule rule1]
user@host# edit term term1
5.
Define the terms that make up this rule.
[edit services stateful-firewall rule rule-name term term-name]
user@host# set then accept
For example:
[edit services stateful-firewall rule rule1 term term1]
user@host# set then accept
Results
The following sample output shows the configuration of the services stateful firewall.
[edit services]
user@host# show
stateful-firewall {
rule rule1 {
match-direction input-output;
term term1 {
then {
accept;
}
}
}
}
Configuring Interfaces
Step-by-Step
Procedure
After you have defined the service set, you must apply services to one or more interfaces
installed on the router. In this example, you configure one interface on which you apply
the service set for input and output traffic. When you apply the service set to an interface,
it automatically ensures that packets are directed to the services (ms-) interface.
To configure the interfaces:
1.
In configuration mode, go to the [edit interfaces] hierarchy level.
user@host# edit interfaces
2.
Configure the interface on which the service set is applied to automatically ensure
that packets are directed to the services (ms-) interface.
a. For IPv4 traffic, specify the IPv4 address.
[edit interfaces]
user@host# set ge-1/0/9 unit 0 family inet address 30.1.1.1/24
b. Apply the service set defined in “Configuring Interfaces” on page 169.
Copyright © 2018, Juniper Networks, Inc.
169
Adaptive Services Interfaces Feature Guide for Routing Devices
[edit interfaces]
user@host# set ge-1/0/9 unit 0 family inet6 service input service-set ss
user@host# set ge-1/0/9 unit 0 family inet6 service output service-set ss
c. For IPv6 traffic, specify the IPv6 address.
[edit interfaces]
user@host# set ge-1/0/9 unit 0 family inet6 address 2000::1/64
3.
Specify the interface properties for the services interface that performs the service.
[edit interfaces]
user@host# set ms-2/0/0 services-options syslog host local services any
user@host# set ms-2/0/0 unit 0 family inet
user@host# set ms-2/0/0 unit 0 family inet6
170
Copyright © 2018, Juniper Networks, Inc.
Chapter 11: Securing Traffic Using NAT-PT and ALGs
Results
The following sample output shows the configuration of the interfaces for this example.
[edit interfaces]
user@host# show
ge-1/0/9 {
unit 0 {
family inet {
address 30.1.1.1/24;
}
family inet6 {
service {
input {
service-set ss;
}
output {
service-set ss;
}
}
address 2000::1/64;
}
}
}
ms-2/0/0 {
services-options {
syslog {
host local {
services any;
}
}
}
unit 0 {
family inet;
family inet6;
}
}
Related
Documentation
•
Junos Address Aware Network Addressing Overview on page 45
•
Configuring NAT-PT on page 150
•
Configuring Service Sets to be Applied to Services Interfaces on page 9
•
Example: Configuring Layer 3 Services and the Services SDK on Two PICs on page 413
•
dns-alg-prefix on page 915
•
dns-alg-pool on page 915
Copyright © 2018, Juniper Networks, Inc.
171
Adaptive Services Interfaces Feature Guide for Routing Devices
172
Copyright © 2018, Juniper Networks, Inc.
CHAPTER 12
Providing IPv4 Connectivity Across
IPv6-Only Network Using 464XLAT
•
464XLAT Overview on page 173
•
Configuring 464XLAT Provider-Side Translater for IPv4 Connectivity Across IPv6-Only
Network on page 174
464XLAT Overview
Starting in Junos OS Release 17.1R1, you can configure a 464XLAT Provider-Side Tranlator
(PLAT). This is supported only on MS-MICs and MS-MPCs. 464XLAT provides a simple
and scalable technique for an IPv4 client with a private address to connect to an IPv4
host over an IPv6 network. 464XLAT only suports IPv4 in the client-server model, so it
does not support IPv4 peer-to-peer communication or inbound IPv4 connections.
XLAT464 provides the advantages of not having to maintain an IPv4 network for this
IPv4 traffic and not having to assign additional public IPv4 addresses.
A customer-side translator (CLAT), which is not a Juniper Networks product, translates
the IPv4 packet to IPv6 by embedding the IPv4 source and destination addresses in IPv6
/96 prefixes, and sends the packet over an IPv6 network to the PLAT. The PLAT translates
the packet to IPv4, and sends the packet to the IPv4 host over an IPv4 network (see
Figure 11 on page 173).
Figure 11: 464XLAT Wireline Flow
IPv6
IPv6
IPv6 Native
IPv4 Private
IPv6
CLAT
IPv6
Internet
PLAT
MX Series
device
IPv4
Internet
464XLAT
IPv4 SRC
192.168.1.2
IPv4 DST
192.51.100.1
Copyright © 2018, Juniper Networks, Inc.
CLAT
translation
PLAT DST prefix
2001:db8:bbbb::/96
IPv4 NAT pool
[192.0.2.1 - 192.0.2.100]
IPv6 SRC
2001:db8:aaaa::192.168.1.2
IPv6 DST
2001:db8:bbbb::198.51.100.1
PLAT
translation
IPv4
198.51.100.1
IPv4 SRC
192.0.2.1
IPv4 DST
192.51.100.1
g043569
IPv4
192.168.1.2
CLAT SRC prefix
2001:db8:aaaa::/96
173
Adaptive Services Interfaces Feature Guide for Routing Devices
The CLAT uses a unique source IPv6 prefix for each end user, and translates the IPv4
source address by embedding it in the IPv6 /96prefix. In Figure 11 on page 173, the CLAT
source IPv6 prefix is 2001:db8:aaaa::/96, and the IPv4 source address 192.168.1.2 is
translated to 2001:db8:aaaa::192.168.1.2. The CLAT translates the IPv4 destination
address by embedding it in the IPv6 /96 prefix of the PLAT (MX Series router). In
Figure 11 on page 173, the PLAT destination IPv6 prefix is 2001:db8:bbbb::/96, so the CLAT
translates the IPv4 destination address 198.51.100.1 to 2001:db8:bbbb::198.51.100.
The CLAT can reside on the end user mobile device in an IPv6-only mobile network,
allowing mobile network providers to roll out IPv6 for their users and support IPv4-only
applications on mobile devices (see Figure 5 on page 51).
Figure 12: 464XLAT Wireless Flow
IPv6
Mobile
device
IPv6 Native
IPv6
Internet
CLAT
function
PLAT
MX Series
device
IPv4
Internet
464XLAT
IPv4
192.168.1.2
IPv4
198.51.100.1
g043572
IPv6
To configure the PLAT on the MX Series router, you create a NAT rule that uses the PLAT
IPv6 prefix for the destination address and destination prefix and uses the NAT translation
type stateful-nat464. For the source address and CLAT prefix in the NAT rule, identify
the IPv6 prefix for the CLAT. The NAT rule must specify a NAT pool that the PLAT uses
for converting the private IPv4 source address to a public IPv4 address.
Benefits of 464XLAT
Related
Documentation
•
No need to maintain an IPv4 transit network
•
No need to assign additional public IPv4 addresses
•
Configuring 464XLAT Provider-Side Translater for IPv4 Connectivity Across IPv6-Only
Network on page 174
Configuring 464XLAT Provider-Side Translater for IPv4 Connectivity Across IPv6-Only
Network
Starting in Junos OS Release 17.1R1, you can configure a 464XLAT Provider-Side Tranlator
(PLAT). This is supported only on MS-MICs and MS-MPCs. 464XLAT provides a simple
and scalable technique for an IPv4 client with a private address to connect to an IPv4
host over an IPv6 network. 464XLAT only suports IPv4 in the client-server model, so it
does not support IPv4 peer-to-peer communication or inbound IPv4 connections.
The following restrictions apply when configuring the PLAT:
•
174
An overload-pool cannot be configured in the NAT rule.
Copyright © 2018, Juniper Networks, Inc.
Chapter 12: Providing IPv4 Connectivity Across IPv6-Only Network Using 464XLAT
•
Different terms in the NAT rule cannot have the same destination-prefix.
To configure the PLAT:
1.
Configure a NAT pool NAT pool that the PLAT uses for converting the private IPv4
source address to a public IPv4 address. See “Configuring Pools of Addresses and
Ports for Network Address Translation Overview” on page 61.
2. Configure a name for a NAT rule.
[edit services nat]
user@host# set rule rule-name
3. Configure a match direction for the rule. See “Configuring Match Direction for NAT
Rules” on page 65.
4. Configure the IPv6 source address prefix. This must be the CLAT IPv6 prefix or contain
the CLAT IPv6 prefix.
[edit services nat rule rule-name term term-name from]
user@host# set source-address address
5. Configure the IPv6 destination address prefix, which must have a length of /96. This
is the PLAT destination IPv6 IP prefix.
[edit services nat rule rule-name term term-name from]
user@host# set destination-address address
6. Specify the NAT pool that the PLAT uses for converting the private IPv4 source address
to a public IPv4 address.
[edit services nat rule rule-name term term-name then translated]
user@host# set source-pool nat-pool-name
7. Specify the CLAT IPv6 source prefix.
[edit services nat rule rule-name term term-name then translated]
user@host# set clat-prefix clat-prefix
8. Configure the IPv6 destination prefix, which must have a length of /96. This is the
PLAT destination IPv6 IP prefix.
[edit services nat rule rule-name term term-name then translated]
user@host# set destination-prefix destination-prefix
9. Configure the translation type as stateful NAT464.
[edit services nat rule rule-name term term-name then translated]
user@host# set translation-type stateful-nat464
10. Enable address pooling paired (APP).
Copyright © 2018, Juniper Networks, Inc.
175
Adaptive Services Interfaces Feature Guide for Routing Devices
[edit services nat rule rule-name term term-name then translated]
user@host# set address-pooling paired.
11. Assign the NAT rule to a service set.
[edit services]
user@host# set service-set service-set-name nat-rules rule-name
Related
Documentation
176
•
464XLAT Overview on page 173
Copyright © 2018, Juniper Networks, Inc.
CHAPTER 13
Reducing Traffic and Bandwidth
Requirements Using Port Control Protocol
•
Port Control Protocol Overview on page 177
•
Configuring Port Control Protocol on page 180
•
Example: Configuring Port Control Protocol with NAPT44 on page 184
Port Control Protocol Overview
Port Control Protocol (PCP) provides a mechanism to control the forwarding of incoming
packets by upstream devices such as NAT44 and firewall devices, and a mechanism to
reduce application keepalive traffic. PCP is supported on the MS-DPC, MS-100, MS-400,
and MS-500 MultiServices PICS. Starting in Junos OS Release 17.4R1, PCP for NAPT44
is also supported on the MS-MPC and MS-MIC. PCP on the MS-MPC and MS-MIC does
not support DS-Lite.
PCP is designed to be implemented in the context of both Carrier-Grade NATs (CGNs)
and small NATs (for example, residential NATs). PCP enables hosts to operate servers
for a long time (as in the case of a webcam) or a short time (for example, while playing
a game or on a phone call) when behind a NAT device, including when behind a CGN
operated by their ISP. PCP enables applications to create mappings from an external IP
address and port to an internal IP address and port. These mappings are required for
successful inbound communications destined to machines located behind a NAT or a
firewall. After a mapping for incoming connections is created, remote computers must
be informed about the IP address and port for the incoming connection. This is usually
done in an application-specific manner.
Junos OS supports PCP version 2 and version 1.
PCP consists of the following components:
•
PCP client—A host or gateway that issues PCP requests to a PCP server in order to
obtain and control resources.
•
PCP server—Typically a CGN gateway or co-located server that receives and processes
PCP requests
Copyright © 2018, Juniper Networks, Inc.
177
Adaptive Services Interfaces Feature Guide for Routing Devices
Junos OS enables configuring PCP servers for mapping flows using NAPT44 capablilites
such as port forwarding and port block allocation. Flows can be processed from these
sources:
•
Traffic containing PCP requests received directly from user equipment, as shown in
Figure 13 on page 178.
Figure 13: Basic PCP NAPT44 Topology
MX 3D Router
UEs with PCP clients
PCP server
Local Host
Internet
g017853
NAPT44
•
Mapping of traffic containing PCP requests added by a router functioning as a DS-Lite
softwire initiator (B4). This mode, known as DS-Lite plain mode, is shown in
Figure 14 on page 178. PCP does not support DS-Lite on the MS-MPC and MS-MIC.
Figure 14: PCP with DS-Lite Plain Mode
MX 3D Router
IPv4 UE
IPv4 in IPv6
AFTR/PCP server
IPv6 Internet
B4
NAPT44
g017854
PCP client
NOTE: Junos OS does not support deterministic port block allocation for
PCP-originated traffic.
Benefits of Port Control Protocol
Many NAT-friendly applications send frequent application-level messages to ensure
their sessions are not being timed out by a NAT device. PCP is used to:
178
•
Reduce the frequency of these NAT keepalive messages
•
Reduce bandwidth on the subscriber's access network
Copyright © 2018, Juniper Networks, Inc.
Chapter 13: Reducing Traffic and Bandwidth Requirements Using Port Control Protocol
•
Reduce traffic to the server
•
Reduce battery consumption on mobile devices
Port Control Protocol Version 2
Starting with Junos OS Release 15.1, Port Control Protocol (PCP) version 2 is supported,
which is in compliance with RFC 6887. PCP provides a mechanism to control the
forwarding of incoming packets by upstream devices such as NAT44, and firewall devices,
and a mechanism to reduce application keep-alive traffic PCP version 2 supports nonce
authentication. PCP allows applications to create mappings from an external IP address
and port to an internal IP address and port. A nonce payload prevents a replay attack. A
nonce payload is sent by default unless it is explicitly disabled. With nonce payload, the
device expects Online Certificate Status Protocol (OCSP) responses to contain a nonce
payload, otherwise the revocation check will fail. If OCSP responders are not capable of
responding with a nonce payload, disable this option.
Client nonce verification for version 2 map requests (for refresh or delete) requires that
the nonce received in the original map request that causes the PCP mapping to be created
is preserved. The version of the initial request that enables the mapping to be created is
also preserved. This behavior of saving the nonce and version parameters denotes that
13 bytes per PCP mapping are used. This slight increase in storage space is not significant
when matched with the current memory usage of a system for a single requested mapping
(taking into account the endpoint-independent mapping (EIM) and endpoint-independent
filtering (EIF) that are created along with it). In a customer deployment, PCP causes EIM
and EIF mappings to represent a fraction of all such mappings.
Until Junos Release 15.1, services PICs support PCP servers on Juniper Networks routers
in accordance with PCP draft version 22 with version 1 message encoding. With PCP being
refined from the draft version as defined in Port Control Protocol (PCP)
draft-ietf-pcp-base-22 (July 2012 expiration) to a finalized, standard version as defined
in RFC 6887 -- Port Control Protocol (PCP), the message encoding changed to version
2 with the addition of a random nonce payload to authenticate peer and map requests
as necessary. Version 1 does not decode messages compliant with version 2 format and
nonce authentication is not supported. In a real-word network environment, with customer
premises equipment (CPE) devices increasingly supporting version 2 only, it is required
to parse and send version 2 messages. Backward compatibility with version 1-supporting
CPE devices is maintained (version negotiation is part of the standard) and authenticates
request nonce payload packets when v2 messages are in use.
The output of the show services pcp statistics command contains the PCP unsupported
version field, which is incremented to indicate whenever the version is not 1 or 2. A new
field, PCP request nonce does not match existing mapping, is introduced to indicate the
number of PCP version 2 requests that were ignored because the nonce payload did not
match the one recorded in the mapping (authentication failed). If version 2 is in use, the
client nonce is used for authentication.
Copyright © 2018, Juniper Networks, Inc.
179
Adaptive Services Interfaces Feature Guide for Routing Devices
Release History Table
Related
Documentation
•
Release
Description
17.4R1
Starting in Junos OS Release 17.4R1, PCP for NAPT44 is also supported on
the MS-MPC and MS-MIC.
15.1
Starting with Junos OS Release 15.1, Port Control Protocol (PCP) version 2
is supported, which is in compliance with RFC 6887.
Configuring Port Control Protocol on page 180
Configuring Port Control Protocol
This topic describes how to configure port control protocol (PCP). PCP is supported on
the MS-DPC, MS-100, MS-400, and MS-500 MultiServices PICS. Starting in Junos OS
Release 17.4R1, PCP for NAPT44 is also supported on the MS-MPC and MS-MIC. PCP on
the MS-MPC and MS-MIC does not support DS-Lite.
Perform the following configuration tasks:
•
Configuring PCP Server Options on page 180
•
Configuring a PCP Rule on page 182
•
Configuring a Service Set to Apply PCP on page 183
•
SYSLOG Message Configuration on page 183
Configuring PCP Server Options
1.
Specify a PCP server name.
user @host# edit services pcp server server-name
2. Set the IPv4 or IPv6 addresses of the server. For PCP DS-Lite, the ipv6-address must
match the address of the AFTR (Address Family Transition Router or softwire
concentrator).
NOTE: PCP does not support DS-Lite on the MS-MPC and MS-MIC.
[edit services pcp server server-name]
user @host# set ipv6-address ipv6-address
or
[edit services pcp server server-name]
user @host# set ipv4-address ipv4-address
3. For PCP DS-Lite, provide the name of the DS-Lite softwire concentrator configuration.
[edit services pcp server server-name]
user @host# set softwire-concentrator softwire-concentrator-name
180
Copyright © 2018, Juniper Networks, Inc.
Chapter 13: Reducing Traffic and Bandwidth Requirements Using Port Control Protocol
4. Specify the minimum and maximum mapping lifetimes for the server.
[edit services pcp server server-name]
user @host# set mapping-lifetime-minimum mapping-lifetime-minimum
user @host# set mapping-lifetime-maximum mapping-lifetime-maximum
5. Specify the time limits for generating short lifetime or long lifetime errors.
[edit services pcp server server-name]
user @host# set short-lifetime-error short-lifetime-error
user @host# set long-lifetime-error long-lifetime-error
6. (Optional)—Enable PCP options on the specified PCP server. The following options
are available—third-party and prefer-failure. The third-party option is required to enable
third-party requests by the PCP client. DS-Lite requires the third-party option. The
prefer-failure option requests generation of an error message when the PCP client
requests a specific IP address/port that is not available, rather than assigning another
available address from the NAT pool. If prefer-failure is not specified NAPT44 assigns
an available address/port from the NAT pool based on the configured NAT options.
[edit services pcp server server-name]
user @host# set pcp-options third-party
user @host# set pcp-options prefer-failure
7. (Optional)—Specify which NAT pool to use for mapping.
[edit services pcp server server-name]
user @host# set nat-options pcp-nat-pool pool-name1 <poolname2...>
NOTE: When you do not explicitly specify a NAT pool for mapping, the
Junos OS performs a partial rule match based on source IP, source port
and protocol; the Junos OS uses the NAT pool configured for the first
matching rule to allocate mappings for PCP.
You must use explicit configuration in order to use multiple NAT pools.
8. (Optional)—Configure the maximum number of mappings per client. The default is
32 and maximum is 128.
[edit services pcp server server-name]
user @host# set max-mappings-per-client max-mappings-per-client
Copyright © 2018, Juniper Networks, Inc.
181
Adaptive Services Interfaces Feature Guide for Routing Devices
Configuring a PCP Rule
A PCP rule is has the same basic options as all service set rules:
•
A term option that allows a single rule to have multiple applications.
•
A from option that identifies the traffic that is subject to the rule.
•
A then option that identifies what action is to be taken. In the case of a PCP rule, this
option Identifies the pcp server that handles selected traffic
1.
Go to the [edit services pcp rule rule-name] hierarchy level and specify match-direction
input.
user @host# edit services pcp rule rule-name
user @host# set match-direction input
2. Go to the [edit services pcp rule rule-name term term-name] hierarchy level and provide
a term name.
user @host# edit term term-name
3. (Optional)—Provide a from option to filter the traffic to be selected for processing by
the rule. When you omit the from option, all traffic handled by the service set’s service
interface is subject to the rule. The following options are available at the [edit services
pcp rule rule-name term term-name from] hierarchy level:
application-sets set-name —Traffic for the application set is processed by the PCP
rule.
applications [ application-name ]—Traffic for the application is processed by the PCP
rule.
destination-address address <except>—Traffic for the destination address or prefix is
processed by the PCP rule. If you include the except option, traffic for the
destination address or prefix is not processed by the PCP rule.
destination-address-range high maximum-value low minimum-value <except>—Traffic
for the destination address range is processed by the PCP rule. If you include the
except option, traffic for the destination address range is not processed by the
PCP rule.
destination-port high maximum-value low minimum-value—Traffic for the destination
port range is processed by the PCP rule.
destination-prefix-list list-name <except>—Traffic for a destination address in the
prefix list is processed by the PCP rule. If you include the except option, traffic for
a destination address in the prefix list is not processed by the PCP rule.
source-address address <except>—Traffic from the source address or prefix is processed
by the PCP rule. If you include the except option, traffic from the source address
or prefix is not processed by the PCP rule.
182
Copyright © 2018, Juniper Networks, Inc.
Chapter 13: Reducing Traffic and Bandwidth Requirements Using Port Control Protocol
source-address-range high maximum-value low minimum-value <except>—Traffic from
the source address range is processed by the PCP rule. If you include the except
option, traffic from the source address range is not processed by the PCP rule.
source-prefix-list list-name <except>—Traffic from a source address in the prefix list
is processed by the PCP rule. If you include the except option, traffic from a source
address in the prefix list is not processed by the PCP rule.
4. Set the then option to identify the target PCP server.
[edit services pcp rule rule-name term term-name]
user @host# set then pcp-server server-name
Configuring a Service Set to Apply PCP
To use PCP, you must provide the rule name (or name of a list of rule names) in the
pcp-rule rule-name option.
1.
Go to the [edit services service-set service-set-name hierarchy level.
user @host# edit services service-set service-set-name
2. If this is a new service set, provide basic service set information, including interface
information and any other rules that may apply.
3. Specify the name of the PCP rule or rule list used to send traffic to the specified PCP
server.
[edit services service-set service-set-name ]
user @host# set pcp-rule rule-name | rule-listname
NOTE: Your service set must also identify any required nat-rule and
softwire-rule.
SYSLOG Message Configuration
A new syslog class, configuration option, pcp-logs, has been provided to control PCP log
generation. It provides the following levels of logging:
•
protocol—All logs related to mapping creation, deletion are included at this level of
logging.
•
protocol-error—–All protocol error related logs (such as mapping refresh failed, PCP
look up failed, mapping creation failed). are included in this level of logging.
See Also
•
system-error—Memory and infrastructure errors are included in this level of logging.
•
Port Control Protocol Overview on page 177
Copyright © 2018, Juniper Networks, Inc.
183
Adaptive Services Interfaces Feature Guide for Routing Devices
Example: Configuring Port Control Protocol with NAPT44
NOTE: PCP is supported on the MS-DPC, MS-100, MS-400, and MS-500
MultiServices PICS. Starting in Junos OS Release 17.4R1, PCP for NATP44 is
also supported on the MS-MPC and MS-MIC.
•
Requirements on page 184
•
Overview on page 184
•
PCP Configuration on page 185
Requirements
Hardware Requirements
•
UEs with PCP clients.
•
An MX 3D Router with an MS-DPC services PIC.
•
Software Requirements
•
Junos OS 13.2
•
Layer-3 Services Package
Overview
An ISP wants to enable UEs with PCP clients to maintain connections to servers without
timing out. The PCP clients generate PCP requests for the type and duration of the
connection they require. Connections may be of a long duration, such as applications
using a webcam, or a shorter duration, such as online games. An MX 3D router provides
a PCP server to interpret PCP client requests, and NAPT44. Figure 15 on page 184 shows
the basic topology for this example.
Figure 15: PCP with NAPT44
MX 3D Router
UEs with PCP clients
PCP server
Local Host
Internet
g017853
NAPT44
184
Copyright © 2018, Juniper Networks, Inc.
Chapter 13: Reducing Traffic and Bandwidth Requirements Using Port Control Protocol
PCP Configuration
CLI Quick
Configuration
To quickly configure this example, copy the following commands, paste them into a text
file, remove any line breaks, change any details necessary to match your network
configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy
level.
set chassis fpc 2 pic 0 adaptive-services service-package layer-3
set interfaces sp-2/0/0 services-options inactivity-timeout 180 cgn-pic
set interfaces sp-2/0/0 unit 0 family inet
set interfaces xe-3/2/0 unit 0 family inet service input service-set sset_0
set interfaces xe-3/2/0 unit 0 family inet service output service-set sset_0
set interfaces xe-3/2/0 unit 0 family inet address 30.0.0.1/24
set interfaces xe-5/0/0 unit 0 family inet address 25.0.0.1/24
set services nat pool pcp-pool address 44.0.0.0/16
set services nat pool pcp-pool port automatic random-allocation address-allocation
round-robin
set services nat pool pcp-pool address-allocation round-robin
set services nat rule pcp-rule match-direction input
set services nat rule pcp-rule term t0 then translated source-pool pcp-pool
translation-type napt-44
set services nat rule pcp-rule term t0 then translated mapping-type endpoint-independent
filtering-type endpoint-independent
set services nat rule pcp-rule term t0 then translated mapping-type endpoint-independent
filtering-type endpoint-independent
set services pcp server pcp-s1 ipv4-address 124.124.124.122 mapping-lifetime-minimum
600 mapping-lifetime-minimum 600
set services pcp server pcp-s1 mapping-lifetime-minimum 600
mapping-lifetime-maximum 86500
set services pcp server pcp-s1 short-lifetime-error 120 long-lifetime-error 1200
set services pcp server pcp-s1 max-mappings-per-client 128 pcp-options third-party
prefer-failure
set services service-set sset_0 pcp-rules r1
set services service-set sset_0 nat-rules pcp-rule
set services service-set sset_0 interface-service service-interface sp-2/0/0.0
Chassis Configuration
Step-by-Step
Procedure
To configure the service PIC (FPC 2 Slot 0) with the Layer 3 service package:
1.
Go to the [edit chassis] hierarchy level.
user@host# edit chassis
2.
Configure the Layer 3 service package.
[edit chassis]
user@host# set fpc 2 pic 0 adaptive-services service-package layer-3
Copyright © 2018, Juniper Networks, Inc.
185
Adaptive Services Interfaces Feature Guide for Routing Devices
Results
user@host# show chassis fpc 2 pic 0
pcp-rules pcp-napt44-rule;
nat-rules pcp-rule;
interface-service {
service-interface sp-2/0/0.0;
}
Interface Configuration
Step-by-Step
Procedure
1.
Configure the services MS-DPC.
user@host# set interfaces sp-2/0/0 services-options inactivity-timeout 180 cgn-pic
user@host# set interfaces sp-2/0/0 unit 0 family inet
2.
Configure the customer-facing interface used for NAT and PCP services.
user@host# set interfaces xe-3/2/0 unit 0 family inet service input service-set
sset_0
user@host# set interfaces xe-3/2/0 unit 0 family inet service output service-set
sset_0
user@host# set interfaces xe-3/2/0 unit 0 family inet address 30.0.0.1/24
3.
Configure the Internet-facing interface.
user@host# set interfaces xe-5/0/0 unit 0 family inet address 25.0.0.1/24
186
Copyright © 2018, Juniper Networks, Inc.
Chapter 13: Reducing Traffic and Bandwidth Requirements Using Port Control Protocol
Results
user@host#
sp-2/0/0 {
services-options {
inactivity-timeout 180;
cgn-pic;
}
unit 0 {
family inet;
}
}
xe-3/2/0 {
unit 0 {
family inet {
service {
input {
service-set sset_0;
}
output {
service-set sset_0;
}
}
address 30.0.0.1/24;
}
}
}
xe-5/0/0 {
unit 0 {
family inet {
address 25.0.0.1/24;
}
}
}
NAT Configuration
Step-by-Step
Procedure
1.
Go the [edit services nat] hierarchy.
user@host# edit services nat
2.
Configure a NAT pool called pcp-pool.
[edit services nat]
user@host# set pool pcp-pool address 44.0.0.0/16
user@host# set pool pcp-pool port automatic random-allocation
user@host# set pool pcp-pool address-allocation round-robin
3.
Configure a NAT rule called pcp-rule.
[edit services nat]
user@host# set rule pcp-rule term t0 then translated source-pool pcp-pool
translation-type napt-44
user@host# set rule pcp-rule term t0 then translated mapping-type
endpoint-independent filtering-type endpoint-independent
Copyright © 2018, Juniper Networks, Inc.
187
Adaptive Services Interfaces Feature Guide for Routing Devices
Results
user@host# show services nat
pool pcp-pool {
address 44.0.0.0/16;
port {
automatic {
random-allocation;
}
}
address-allocation round-robin;
}
rule pcp-rule {
match-direction input;
term t0 {
then {
translated {
source-pool pcp-pool;
translation-type {
napt-44;
}
mapping-type endpoint-independent;
filtering-type {
endpoint-independent;
}
}
}
}
}
PCP Configuration
Step-by-Step
Procedure
To configure the PCP server and PCP rule options.
1.
Go to the edit services pcp hierarchy level for server pcp-s1
user@host# edit services pcp server pcp-s1
2.
Configure the PCP server options.
[edit services pcp server pcp-s1]
user@host# set ipv4-address 124.124.124.122
user@host# set mapping-lifetime-minimum 600
user@host# set mapping-lifetime-maximum 86500
user@host# set short-lifetime-error 120
user@host# set long-lifetime-error 1200
user@host# set max-mappings-per-client 128
user@host# set pcp-options third-party prefer-failure
3.
Create the PCP rule.
[edit services pcp rule pcp-napt44-rule
user@host# edit rule pcp-napt44-rule
4.
Configure the PCP rule options.
[edit services pcp rule pcp-napt44-rule]
188
Copyright © 2018, Juniper Networks, Inc.
Chapter 13: Reducing Traffic and Bandwidth Requirements Using Port Control Protocol
user@host# set match-direction input
user@host# set term t0 then pcp-server pcp-s1
Results
user@host# show services pcp
server pcp-s1 {
ipv4-address 124.124.124.122;
mapping-lifetime-minimum 600;
mapping-lifetime-maximum 86500;
short-lifetime-error 120;
long-lifetime-error 1200;
max-mappings-per-client 128;
pcp-options third-party prefer-failure;
}
rule pcp-napt44-rule {
match-direction input;
term t0 {
then {
pcp-server pcp-s1;
}
}
}
Service Set Configuration
Step-by-Step
Procedure
1.
Create a service set, sset_0, at the edit services service-set hierarchy level.
user@host# edit services service-set sset_0
service-set sset_0 {
pcp-rules pcp-napt44-rule;
nat-rules pcp-rule;
interface-service {
service-interface sp-2/0/0.0;
}
}
2.
Identify the NAT rule associated with the service set.
[edit services service-set sset_0]
user@host# set nat-rules pcp-rule
3.
Identify the PCP rule associated with the service set.
[edit services service-set sset_0]
user@host# set pcp-rules r1
4.
Identify the service interface associated with the service set.
[edit services service-set sset_0]
user@host# set interface-service service-interface sp-2/0/0.0
Copyright © 2018, Juniper Networks, Inc.
189
Adaptive Services Interfaces Feature Guide for Routing Devices
Results
Release History Table
190
user@host# show
pcp-rules pcp-napt44-rule;
nat-rules pcp-rule;
interface-service {
service-interface sp-2/0/0.0;
}
Release
Description
17.4R1
Starting in Junos OS Release 17.4R1, PCP for NATP44 is also supported
on the MS-MPC and MS-MIC.
Copyright © 2018, Juniper Networks, Inc.
CHAPTER 14
Automatically Assigning Ports Using
Secured Port Block Allocation
•
Secured Port Block Allocation for NAPT44 and NAT64 Overview on page 191
•
Interim Logging for Secured Port Block Allocation on page 192
•
Guidelines for Configuring Interim Logging for Secured Port Block Allocation on page 193
•
Guidelines for Configuring Secured Port Block Allocation on page 195
•
Configuring Secured Port Block Allocation on page 197
Secured Port Block Allocation for NAPT44 and NAT64 Overview
Secured port block allocation ensures that when a subscriber requires a port to be
assigned for the first time, a block of ports are allocated to the particular user. Here, a
subscriber is defined uniquely as a private IP address and service set ID. Because the
subscriber has a block of ports assigned to it, all subsequent requests from this subscriber
use ports from the assigned block. A new port block is allocated when the current active
block is exhausted, or after the active port block timeout interval has expired. You can
configure the maximum number of blocks allocated to a user. This behavior of allocation
of NAT ports in blocks is different from the traditional NAT utility where the request for
a port allocates a single port and not a group of ports in a block.
You can use the secured port block allocation mechanism to allocate ports in blocks for
NAPT44 (translation of an IPv4 address to an IPv4 address) and NAT64 (translation of
an IPv6 address to an IPv4 address) types. By using secured port block allocation, the
port usage might be a little inefficient, depending on traffic patterns. Secured port block
allocation is supported on MX series routers with MS-DPCs and on M Series routers with
MS-100, MS-400, and MS-500 MultiServices PICS. Starting in Junos OS release 14.2R2,
secured port block allocation is supported on MX series routers with MS-MPCs and
MS-MICs.
Starting with Junos OS Release 15.1, in an environment in which Junos Address Aware
(carrier-grade NAT) is employed, service providers or carrier operators can monitor and
track the consumption of resources and types of services being utilized by subscribers
or users in an easier and effective manner by using system logging messages recorded
for the allocation of ports to clients. By using IP addresses in RADIUS or DHCP logs,
evaluation of the logs is performed to analyze an determine the services usage and
bandwidth consumption by subscribers. With carrier-grade NAT, because IP addresses
Copyright © 2018, Juniper Networks, Inc.
191
Adaptive Services Interfaces Feature Guide for Routing Devices
are shared by multiple subscribers, examining logs to track the IP addresses and ports
that are part of the system logs might be time-consuming and difficult. Also, because
ports are allocated and released at frequent intervals depending on the logging-in and
closure of subscriber sessions, a large number of logs are triggered for every port allocation
and deallocation. As a result, excessive syslogs render it cumbersome to archive and
correlate the logs to identify a subscriber. You can now allocate ports in blocks, which
reduces the amount of syslogs considerably.
Benefits of Secured Port Block Allocation
•
Reduces the effort to correlate logs to a subscriber
•
Reduces the number of logs
Release History Table
Release
Description
14.2R2
Starting in Junos OS release 14.2R2, secured port block allocation is
supported on MX series routers with MS-MPCs and MS-MICs.
Interim Logging for Secured Port Block Allocation
With port block allocation we generate one syslog log per set of ports allocated for a
subscriber. These logs are UDP based and can be lost in the network, particularly for
long-running flows. Interim logging triggers re-sending the above logs at a configured
interval for active blocks that have traffic on at least one of the ports of the block.
Depending on your network topology, you can set the interval for the port block allocation
logs based on the period of the archive so that at least one log per port block (for an
active flow) in each archive is present.
To configure the interim logging interval at the services interface level, which applies to
all the NAT pools on that ms- interface, include the pba-interim-logging-interval seconds
statement at the [edit interfaces ms-fpc/pic/port services-options] hierarchy level. The
pba-interim-logging-interval option is supported on MX series routers with MS-DPCs and
on M Series routers with MS-100, MS-400, and MS-500 MultiServices PICS. The
pba-interim-logging-interval option is supported on MX series routers with MS-MPCs and
MS-MICs starting in Junos OS release 14.2R2.
Starting in Junos OS Release 15.1R1, you can also configure the interim logging interval
at a NAT pool level. This capability is supported only on MX Series routers with MS-MPCs
and MS-MICs. To configure the interim logging interval at a NAT pool level, include the
interim-logging-interval seconds statement at the [edit services nat pool pool-name port
secured-port-block-allocation] hierarchy level. You can specify a value from 0 through
86400 seconds for the interim logging frequency.
Benefits of Iterim Logging
192
•
Enables you to identify the currently used port blocks
•
Eliminates the need to search and analyze archived logs to identify the internal host
that is using the external IP address and port
Copyright © 2018, Juniper Networks, Inc.
Chapter 14: Automatically Assigning Ports Using Secured Port Block Allocation
Release History Table
Related
Documentation
Release
Description
15.1R1
Starting in Junos OS Release 15.1R1, you can also configure the interim
logging interval at a NAT pool level.
•
Configuring NAT Session Logs on page 257
•
Secured Port Block Allocation for NAPT44 and NAT64 Overview on page 191
Guidelines for Configuring Interim Logging for Secured Port Block Allocation
Observe the following guidelines when you configure the interim logging interval for
secured port block allocation:
•
Interim logging is enabled only when the interim logging functionality is configured.
The pba-interim-logging-interval statement that you can configure at the [edit interfaces
ms-fpc/pic/port services-options] hierarchy level of an ms-interface is provided for
backward compatibility. The pba-interim-logging-interval option is supported on MX
series routers with MS-DPCs and on M Series routers with MS-100, MS-400, and
MS-500 MultiServices PICS. The pba-interim-logging-interval option is supported on
MX series routers with MS-MPCs and MS-MICs starting in Junos OS release 14.2R2.
The interim-logging-interval statement that is available for configuration on the MS-MPC
and MS-MIC starting in Junos OS release 15.1R1 provides interim logging for a specific
NAT pool.
•
If you configure the interim logging capability to be applicable to all PBA pools residing
on that particular services interface and the interim logging capability for a specific
PBA pool, the NAT pool-specific interval takes precedence over the services interface
specific interval. For port blocks allocated from other PBA pools for which interim
logging interval at the NAT pool-level is not configured, the logging interval value as
configured at the ms- interface-level applies.
•
The default value is zero, which denotes no interim logging message is generated.
•
Interim logs are sent any time after the configured period of time in seconds. The
time-difference is not fixed between the logging intervals of two logs.
•
Interim logs are generated for port blocks (both active and inactive) that contain at
least one port in use by a flow which has traffic. No timer controls run on the port blocks
to generate the logs. When a packet is received on a flow, the validation is performed
to generate an interim log. If the conditions are satisfied, an interim log is generated
for that port block. Interim logs are not generated for deleted port blocks.
•
The interim log contains the timestamp of the port block creation in hexadecimal
format (when local time is set, the hexadecimal value provides the time in UTC format).
•
The conversion of the timestamp to UTC format can be performed in the external
syslog server as necessary.
Copyright © 2018, Juniper Networks, Inc.
193
Adaptive Services Interfaces Feature Guide for Routing Devices
194
•
In certain scenarios, it is possible that the timestamp in hexadecimal value and the
actual timestamp in ALLOC messages differ by a couple of seconds. This behavior
occurs because the syslog mechanism contains a slight difference when it reads the
time (as seen in PORT_BLOCK_ALLOC syslog) and the time at which NAT application
reads the time (to update the ALLOC time in the subscriber context). The interim
system log displays the ALLOC time retrieved from the subscriber context.
•
Because these logs are generated on CPU computation and in the fast path, a slight
impact might be observed with fast path performance only when a generation of the
log occurs.
•
Port block creation timestamp in hexadecimal is saved in the
JSERVICES_NAT_PORT_BLOCK_RELEASE message, even if interim logging is not
present.
•
If you define the logging interval when traffic flow is in progress, this functionality takes
effect on existing and new flows. You need not reboot the MIC or activate and deactivate
the service set.
•
If the flows or subscribers are timing out, it denotes that no new packets or traffic flows
are seen for this 5-tuple data or for that particular subscriber. In such a case, interim
logs are not generated.
•
If the interim-logging interval is lower than the inactivity-timeout of the flow, interim
logs are not observed when the flow is timing out and the interim-logging interval has
elapsed. If the interim-logging interval is lower than the subscriber-timeout value,
interim logs are not observed when the subscriber is timing out and the interim-logging
interval has elapsed. For example, if the inactivity-timeout is configured to 2500 seconds
and the interim-logging is configured as 1800 seconds, when the flow is timing out,
there is a point in time when 1800 seconds has elapsed since the last packet was seen
on this flow and no interim log is generated in this case.
•
The interim logs are recorded for those pools that have PBA configured. If pools exist
without the PBA configuration present on the service network processing unit (NPU),
interim logs are not saved even if you enable the interim logging functionality.
•
You can configure only a range of values for the interval at which the logs need to be
generated, such as 0, [1800, 86400].
•
You can enable the generation of syslogs by using the syslog statement at the [edit
system] and [edit services service-sets service-set name nat rule rule-name term
term-name then] hierarchy levels that contain the NAT rules with PBA pools. Interim
logs are not triggered if the recording of syslogs are not enabled on the system.
•
We recommend that you configure the interim-logging interval to be higher than the
inactivity timeout period for established flows. Also, we recommend that you configure
the interim-logging interval to be higher than the subscriber-timeout value. When
endpoint-independent mapping (EIM) is configured, the interim-logging interval must
be higher than the sum of the address pooling paired (APP) timeout and EIM timeout
values.
•
Transmission of logs occurs in clear-text format similar to other log messages that the
services PICs do not encrypt. It is assumed that the transport of logs and the positioning
of the log collector are within a secured realm. Because the messages do not contain
Copyright © 2018, Juniper Networks, Inc.
Chapter 14: Automatically Assigning Ports Using Secured Port Block Allocation
sensitive details such as username or passwords, the messages do not cause any
security or reliability risks. Increased generation of log messages does not cause a
possibility of a flood of logs because the frequency of logging can be configured,
depending on the network topology, traffic levels, and your monitoring needs.
•
The logs for PBA in the microkernel start with the prefix of ASP_*. These logs have
been modified to start with the prefix of JSERVICES_*. The following are examples of
system logs for PBA in the microkernel and with the Junos OS Extension-Provider
packages installed and configured on the device.
Microkernel: 1970-01-01 00:32:36 {nat64}[FWNAT]:ASP_NAT_PORT_BLOCK_ACTIVE:
2001:0:0:0:0:0:0:2 -> 1.1.1.1:1050-1091 0x6f
Junos OS Extension-Provider (eJunos): 1970-01-01 00:32:36
{nat64}[FWNAT]:JSERVICES_NAT_PORT_BLOCK_ACTIVE: 2001:0:0:0:0:0:0:2 ->
1.1.1.1:1050-1091 0x6f
•
Also, you can specify the interim logging interval per NAT pool instead of a global
configuration per MS-PIC, based on whether you want the syslog settings to apply to
all the NAT pools on a device or for a particular NAT pool. For NAT, the member
interfaces must have the jservices-nat package configured. The
JSERVICES_NAT_PORT_BLOCK_ACTIVE system logging message is generated when
you configure interim logging for PBA. The following sample logs denote the log
messages generated with the interim interval set as 1800 seconds. You can notice that
the timestamp between consecutive interim logs is more than 1800 seconds.
1970-01-01 00:01:51 [FWNAT]:JSERVICES_NAT_PORT_BLOCK_ALLOC: 2001:0:0:0:0:0:0:2
-> 1.1.1.1:1050-1091
1970-01-01 00:32:36 {nat64}[FWNAT]:JSERVICES_NAT_PORT_BLOCK_ACTIVE:
2001:0:0:0:0:0:0:2 -> 1.1.1.1:1050-1091 0x6f
1970-01-01 01:03:20 {nat64}[FWNAT]:JSERVICES_NAT_PORT_BLOCK_ACTIVE:
2001:0:0:0:0:0:0:2 -> 1.1.1.1:1050-1091 0x6f
1970-01-01 01:34:04 {nat64}[FWNAT]:JSERVICES_NAT_PORT_BLOCK_ACTIVE:
2001:0:0:0:0:0:0:2 -> 1.1.1.1:1050-1091 0x6f
1970-01-01 02:04:48 {nat64}[FWNAT]:JSERVICES_NAT_PORT_BLOCK_ACTIVE:
2001:0:0:0:0:0:0:2 -> 1.1.1.1:1050-1091 0x6f
Related
Documentation
•
Configuring NAT Session Logs on page 257
•
Secured Port Block Allocation for NAPT44 and NAT64 Overview on page 191
Guidelines for Configuring Secured Port Block Allocation
Keep the following points in mind when you configure secured PBA:
•
Block size is not configurable at the NAT rule level.
•
Increase in setup rate of sessions is not impacted when you configure secured PBA.
•
If a block of a particular size is not available, an out-of-ports message is displayed and
smaller-sized blocks are not allocated alternatively in such a scenario.
•
Addresses in the pool using port-block-allocation method cannot be used in any other
pool.
Copyright © 2018, Juniper Networks, Inc.
195
Adaptive Services Interfaces Feature Guide for Routing Devices
196
•
Port range in the NAT pool must be contiguous.
•
Preserve parity (Allocate ports with same parity as the original port) is not supported
with block-allocation of ports.
•
The limitation on the number of open sessions when the specified threshold is reached
(for intrusion detection services) and the maximum number of blocks that can be
allocated to a user address that is configured for secured PBA are independent
functionalities.
•
The functionality to preserve privileged port range after translation is not supported.
The blocks are assigned from unprivileged port range (1024-65535). For ports in
privileged range, port block allocation method is not applicable.
•
Port usage efficiency is lower when port-block allocation is enabled. PBA does not use
ports from 0-1023 of a NAT IP address.
•
If you configure the automatic port assignment method, which enables sequential
assignment of ports, the port range from 1024 through 65535 is available for allocation
to users.
•
Port blocks can start at any start port that you can configure.
•
The number of ports used is dependent on the block size and the rest of the ports are
not be used.
•
An overloaded pool, which indicates an address pool that can be used if the source
pool becomes exhausted, is not supported with secured PBA.
•
NAT IP addresses of PBA pool must not overlap with any other pool. Although a
validation is not performed to identify whether any overlapping pools exist, you must
ensure that the addresses of a pool that is used for PBA are not used in other pools.
This condition is because some of the users require the overload pool to use the same
IP addresses as that of NAT IP addresses, but a different port range of PBA pool to
support the address pooling paired (APP) functionality.
•
The block-size is fixed per NAT pool and is configurable at the NAT pool level. Multiple
port blocks can be allocated to a private IP address.
•
You can configure the maximum number of blocks per pool per subscriber by including
the max-blocks-per-user max-blocks statement at the [edit services nat pool pool-name
port secured-port-block-allocation] hierarchy level. If a subscriber matches two pools,
that particular user can be allocated a maximum of port blocks that equals the sum
of the maximum number of port blocks for each pool for that subscriber. New requests
for NAT ports arrive from the current active block only.
•
Ports can be allocated randomly from the current active block, which specifies whether
ports should be allocated sequentially or randomly within the port block.
•
A block is active for a timeout interval that you can define by including the
active-block-timeout timeout-seconds at the [edit services nat pool pool-name port
secured-port-block-allocation] hierarchy level. After the timeout period, a new block
is allocated even if ports are available in the active block. The default timeout of an
active block is 120 seconds. When you configure it as 0 (infinite), the active block
transitions to inactive only when it runs out of ports and a new block is allocated.
Copyright © 2018, Juniper Networks, Inc.
Chapter 14: Automatically Assigning Ports Using Secured Port Block Allocation
Related
Documentation
•
If the maximum number of blocks of blocks is exceeded, and a new request is received,
the active block is moved to a block that contains available ports. Any non-active block
without any ports in use is freed to NAT pool.
•
In addition to tracking port blocks assigned to each private IP address, actual ports in
use are also computed and maintained. This metric is used to calculate port usage
efficiency.
•
A syslog message is generated for each block allocation and release. The format of
the message is similar to the messages recorded for individual port allocation and
release.
•
Session setup rate is the same or slightly improved than the existing non-block
allocation setup rate. NAT pool using block-port allocation method can have partial
port ranges. If the address is used for port forwarding, those ports can be removed
from the pool port range. You can configure partial port ranges by using the port range
low minimum-value high maximum-value random-allocation statement at the [edit
services nat pool nat-pool-name] hierarchy level. Port block allocation works in the
same manner as NAPT44 for TCP, UDP, and ICMP traffic.
•
Randomness can be achieved by allocating ports randomly within the block and
changing active block periodically. The block of ports do not contain random ports
(ports within the block are sequential). This capability is supported with aggregated
multiservices (ams) interfaces.
•
The starting port number is calculated differently in the microkernel and in Junos OS
Extension-Provider packages. In the microkernel, the starting or first port is the nearest
multiple of the block size after 1023. In that implementation, more ports are wasted
because ports are wasted at the beginning and the end of the port range depending
on the block size. In Junos OS Extension-Provider packages, the start port of a block
is not restricted to a multiple of the block size. The start port can start at the lower
boundary of the range of the port configured.
•
Configuring NAT Session Logs on page 257
•
Secured Port Block Allocation for NAPT44 and NAT64 Overview on page 191
Configuring Secured Port Block Allocation
Secured port block allocation is supported on MX series routers with MS-DPCs and on
M Series routers with MS-100, MS-400, and MS-500 MultiServices PICS. Secured port
block allocation is supported on MX series routers with MS-MPCs and MS-MICs starting
in Junos OS release 14.2R2. To configure secured port block allocation:
1.
At the [edit services nat pool nat-pool-name] hierarchy level, create a pool.
user@host# edit services nat pool poolname
For example:
user@host# edit services nat pool pba-pool1
Copyright © 2018, Juniper Networks, Inc.
197
Adaptive Services Interfaces Feature Guide for Routing Devices
2. Define the range of addresses to be translated, specifying the upper and lower limits
of the range or an address prefix that describes the range.
[edit services nat pool nat-pool-name]
user@host# set address-range low address high address
Or
user@host# set address address-prefix
For example:
[edit services nat pool pba-pool1]
user@host# set address 203.0.113.0/24
3. Define the range of ports to be used in the translation, or use automatic port
assignment by the Junos OS. You can optionally specify random assignment of ports;
sequential assignment is the default.
[edit services nat pool nat-pool-name]
user@host# set port range low address high address random
Or
user@host# set port automatic random-allocation
For example:
[edit services nat pool pba-pool1]
user@host# set port range low 256 high 511 random
Or
[edit services nat pool pba-pool1]
user@host# set port automatic random-allocation
NOTE: When you configure a port range, the range should be a multiple
of the port block-size value (see Step 4). When the nat pool port range is
not a multiple of the port block-size value, the number of ports or
port-blocks that are effectively available for use is less than the configured
number of ports and port-blocks.
When you configure automatic assignment of ports, the available port
range for allocation is 1024 through 65535. Automatic allocation can result
in no ports being available for use. Use the show services nat pool command
on the Routing Engine after you configure the port block allocation method
to determine the number of ports and port blocks available for allocation
to users.
4. Configure secured port block allocation. Specify active-block-timeout, block-size, and
max-blocks-per-address, or accept the default values for those options.
[edit services nat pool nat-pool-name]
198
Copyright © 2018, Juniper Networks, Inc.
Chapter 14: Automatically Assigning Ports Using Secured Port Block Allocation
user@host# set secured-port-block-allocation active-block-timeout
active-block-timeout block-size block-size max-blocks-per-address
max-blocks-per-address
For example:
[edit services nat pool pba-pool1]
user@host# set secured-port-block-allocation active-block-timeout 120 block-size
256 max-blocks-per-address 12
NOTE: In order for secured-port-block-allocation configuration changes to
take effect, you must reboot the services PIC whenever you change any of
the following nat pool options:
•
nat-pool-name
•
address or address-range
•
port range
•
port secured-port-block-allocation block-size
•
port secured-port-block-allocation max-blocks-per-address.
•
port secured-port-block-allocation active-block-timeout.
•
from hierarchy in the nat rule
NOTE: If you make any configuration changes related to a NAT pool that has
secured port block allocation configured, you must delete the existing NAT
address pool, wait at least 5 seconds, and then configure a new NAT address
pool. We also strongly recommend that you perform this procedure if you
make any changes to the NAT pool configuration, even when secured port
block allocation is not configured.
NOTE: MS-MICs and MS-MPCs support up to a maximum of nine million port
blocks per NPU. If your configuration exceeds this maximum supported
number, one or more service sets might not be activated on that NPU.
Related
Documentation
•
Network Address Translation Configuration Overview on page 59
Copyright © 2018, Juniper Networks, Inc.
199
Adaptive Services Interfaces Feature Guide for Routing Devices
200
Copyright © 2018, Juniper Networks, Inc.
CHAPTER 15
Connecting Specific Ports and Addresses
Using Port Forwarding
•
Port Forwarding Overview on page 201
•
Configuring Port Forwarding for Static Destination Address Translation on page 202
•
Configuring Port Forwarding Without Destination Address Translation on page 205
•
Example: Configuring Port Forwarding with Twice NAT on page 207
Port Forwarding Overview
You can map an external IP address and port with an IP address and port in a private
network. This mapping, called port forwarding, is supported on the MS-DPC, MS-100,
MS-400, and MS-500 MultiServices PICS. Starting in Junos OS Release 17.4R1, port
forwarding is also supported on the MS-MPC and MS-MIC.
Port forwarding allows the destination address and port of a packet to be changed to
reach the correct host in a Network Address Translation (NAT) gateway. The translation
facilitates reaching a host within a masqueraded, typically private, network, based on
the port number on which the packet was received from the originating host. An example
of this type of destination is the host of a public HTTP server within a private network.
You can also configure port forwarding without translating a destination address. Port
forwarding supports endpoint-independent mapping (EIM), endpoint-independent
filltering (EIF), and address pooling paired (APP).
Port forwarding works only with the FTP application-level gateway (ALG), and has no
support for technologies that offer IPv6 services over IPv4 infrastructure, such as IPv6
rapid deployment (6rd) and dual-stack lite (DS-Lite). Port forwarding supports only
dnat-44 and twice-napt-44 on IPv4 networks.
Copyright © 2018, Juniper Networks, Inc.
201
Adaptive Services Interfaces Feature Guide for Routing Devices
Benefits of Port Forwarding
•
Release History Table
Related
Documentation
Allows remote computers, such as public machines on the Internet, to connect to a
non-standard port of a specific computer that is hidden within a private network.
Release
Description
17.4R1
Starting in Junos OS Release 17.4R1, port forwarding is also supported
on the MS-MPC and MS-MIC.
•
Configuring Port Forwarding for Static Destination Address Translation on page 202
•
Configuring Port Forwarding Without Destination Address Translation on page 205
Configuring Port Forwarding for Static Destination Address Translation
You can configure destination address translation with port forwarding. Port forwarding
allows the destination address and port of a packet to be changed to reach the correct
host in a Network Address Translation (NAT) gateway. Port forwarding is supported on
the MS-DPC, MS-100, MS-400, and MS-500 MultiServices PICS. Starting in Junos OS
Release 17.4R1, port forwarding is also supported on the MS-MPC and MS-MIC.
To configure destination address translation with port forwarding:
1.
In configuration mode, go to the [edit services nat] hierarchy level.
[edit]
user@host# edit services nat
2. Configure the NAT pool with an address.
[edit services nat]
user@host# set pool pool-name address address
In the following example, dest-pool is used as the pool name and 192.0.2.2 as the
address.
user@host# set pool dest-pool address 192.0.2.2
3. Configure the rule, match direction, term, and destination address.
[edit services nat]
user@host# set rule rule-name match-direction match-direction term term-name from
destination-address address
In the following example, the name of the rule is rule-dnat44, the match direction is
input, the name of the term is t1, and the address is 198.51.100.20.
[edit services nat]
user@host# set rule rule-dnat44 match-direction input term t1 from
destination-address 198.51.100.20
202
Copyright © 2018, Juniper Networks, Inc.
Chapter 15: Connecting Specific Ports and Addresses Using Port Forwarding
4. Configure the destination port range.
[edit services nat]
user@host# set rule rule-name match-direction match-direction term term-name from
destination-port range high maximum-value low minimum-value
In the following example, the upper port range is 50 and the lower port range is 20.
[edit services nat]
user@host# set rule rule-dnat44 match-direction input term t1 from destination-port
range high 50 low 20
5. Go to the [edit services nat rule rule-name term term-name] hierarchy level.
[edit services nat]
user@host# edit rule rule-name term term-name
6. Configure the destination pool.
[edit services nat rule rule-name term term-name]
user@host# set then translated destination-pool dest-pool-name
In the following example, the destination pool name is dest-pool.
[edit services nat rule rule-dnat44 term t1]
user@host# set then translated destination-pool dest-pool
7. Specify the name of the mapping for port forwarding and configure the translation
type. You can only configure one mapping within a NAT rule term.
[edit services nat rule rule-name term term-name]
user@host# set then port-forwarding-mappings map-name
user@host# set then translated translation-type translation-type
In the following example, the port forwarding mapping name is map1, and the
translation type is dnat-44.
[edit services nat rule rule-dnat44 term t1]
user@host# set then port-forwarding-mappings map1
user@host# set then translated translation-type dnat-44
8. Go to the [edit services nat port-forwarding map-name] hierarchy level.
[edit services nat]
user@host# edit port-forwarding map-name
9. Configure the mapping for port forwarding.
[edit port-forwarding map-name]
user@host# set destined-port port-id
user@host# set translated-port port-id
In the following example, the destination port number that needs to be translated is
23 and the port to which traffic is mapped is 45.
[edit port-forwarding map1]
user@host# set destined-port 23
Copyright © 2018, Juniper Networks, Inc.
203
Adaptive Services Interfaces Feature Guide for Routing Devices
user@host# set translated-port 45
NOTE:
• Multiple port mappings are supported with port forwarding. Up to 32
port maps can be configured for port forwarding.
•
The destination port should not overlap the port range configured for
NAT.
10. Apply the NAT rule to the service set that performs the port mapping.
[edit services service-set service-set-name]
user@host# set nat-rules rule-name
NOTE: On the MS-MPC and MS-MIC, you cannot apply port forwarding
NAT rules to an AMS interface.
11. Verify the configuration by using the show command at the [edit services nat] hierarchy
level.
[edit services]
user@host# show
nat {
pool dest-pool {
address 192.0.2.2/32;
}
rule rule-dnat44 {
match-direction input;
term t1
from {
destination-address {
198.51.100.20/32
}
destination-port {
range low 20 high 50;
}
}
then {
port-forwarding-mappings map1;
translated {
destination-pool dest-pool;
translation-type {
dnat-44;
}
}
}
}
}
port-forwarding map1 {
destined-port 45;
translated-port 23;
}
}
service-set ss1 {
204
Copyright © 2018, Juniper Networks, Inc.
Chapter 15: Connecting Specific Ports and Addresses Using Port Forwarding
nat-rules rule-dnat44;
interface-service {
service-interface sp-10/0/0.0;
}
}
NOTE:
Release History Table
Related
Documentation
•
•
A similar configuration is possible with twice NAT for IPv4. See “Example:
Configuring Port Forwarding with Twice NAT” on page 207.
•
Port forwarding and stateful firewall can be configured together. Stateful
firewall has precedence over port forwarding.
Release
Description
17.4R1
Starting in Junos OS Release 17.4R1, port forwarding is also supported
on the MS-MPC and MS-MIC.
Configuring Port Forwarding Without Destination Address Translation on page 205
Configuring Port Forwarding Without Destination Address Translation
You can configure port forwarding without translating a destination address. Port
forwarding allows the destination port to be changed to reach the correct port in a Network
Address Translation (NAT) gateway. Port forwarding is supported on the MS-DPC,
MS-100, MS-400, and MS-500 MultiServices PICS. Starting in Junos OS Release 17.4R1,
port forwarding is also supported on the MS-MPC and MS-MIC.
To configure port forwarding without destination address translation in IPv4 networks:
1.
In configuration mode, go to the [edit services nat] hierarchy level.
[edit]
user@host# edit services nat
2. Configure the rule, match direction, term name, and any conditions that the traffic
must match before the rule is applied.
[edit services nat]
user@host# set rule rule-name match-direction match-direction term term-name from
match-conditions
In the following example, the name of the rule is rule-port-forwarding, the match
direction is input, the name of the term is t1, and the destination address that must
be matched is 198.51.100.20.
[edit services nat]
user@host# set rule rule-port-forwarding match-direction input term t1 from
destination-address 198.51.100.20
Copyright © 2018, Juniper Networks, Inc.
205
Adaptive Services Interfaces Feature Guide for Routing Devices
3. Go to the [edit services nat rule rule-name term term-name] hierarchy level.
[edit services nat]
user@host# edit rule rule-name term term-name
4. Specify that there is no address translation for this rule.
[edit services nat rule rule-name term term-name]
user@host# set then no-translation
5. Specify the name of the mapping for port forwarding. You can only configure one
mapping within a NAT rule term.
[edit services nat rule rule-name term term-name]
user@host# set then port-forwarding-mappings map-name
In the following example, the port forwarding mapping name is map1.
[edit services nat rule rule-port-forwarding term t1]
user@host# set then port-forwarding-mappings map1
6. Go to the [edit services nat port-forwarding map-name] hierarchy level.
[edit services nat]
user@host# edit port-forwarding map-name
7. Configure the mapping for port forwarding.
[edit port-forwarding map-name]
user@host# set destined-port port-id
user@host# set translated-port port-id
In the following example, the destination port number that needs to be translated is
23 and the port to which traffic is mapped is 45.
[edit port-forwarding map1]
user@host# set destined-port 23
user@host# set translated-port 45
NOTE:
• Multiple port mappings are supported with port forwarding. Up to 32
port maps can be configured for port forwarding.
•
The destination port should not overlap the port range configured for
NAPT.
8. Apply the NAT rule to the service set that performs the port mapping.
[edit services service-set service-set-name]
user@host# set nat-rules rule-name
206
Copyright © 2018, Juniper Networks, Inc.
Chapter 15: Connecting Specific Ports and Addresses Using Port Forwarding
NOTE: On the MS-MPC and MS-MIC, you cannot apply port forwarding
NAT rules to an AMS interface.
9. Verify the configuration by using the show command at the [edit services] hierarchy
level.
[edit services]
user@host# show
nat {
rule rule-port-forwarding {
match-direction input;
term t1 {
then {
port-forwarding-mappings map1;
no-translation
}
}
}
}
port-forwarding map1 {
destined-port 45;
translated-port 23;
}
}
service-set ss2 {
nat-rules rule-port-forwarding;
interface-service {
service-interface sp-10/0/0.0;
}
}
NOTE: Port forwarding and stateful firewall can be configured together.
Stateful firewall has precedence over port forwarding.
Release History Table
Related
Documentation
•
Release
Description
17.4R1
Starting in Junos OS Release 17.4R1, port forwarding is also supported
on the MS-MPC and MS-MIC.
Configuring Port Forwarding for Static Destination Address Translation on page 202
Example: Configuring Port Forwarding with Twice NAT
The following example configures port forwarding with twice-napt-44 as the translation
type. The example also has stateful firewall and multiple port maps configured.
Copyright © 2018, Juniper Networks, Inc.
207
Adaptive Services Interfaces Feature Guide for Routing Devices
Port forwarding is supported on the MS-DPC, MS-100, MS-400, and MS-500 MultiServices
PICS. Starting in Junos OS Release 17.4R1, port forwarding is also supported on the
MS-MPC and MS-MIC.
[edit services]
user@host# show
service-set in {
syslog {
host local {
services any;
}
}
stateful-firewall-rules r;
nat-rules r;
interface-service {
service-interface sp-10/0/0.0;
}
}
stateful-firewall {
rule r {
match-direction input;
term t {
from {
destination-port {
range low 20 high 5000;
}
}
then {
reject;
}
}
}
}
nat {
pool x {
address 203.0.113.2/32;
}
rule r {
match-direction input;
term t {
from {
destination-address {
198.51.100.2/32;
}
destination-port {
range low 10 high 20000;
}
}
then {
port-forwarding-mappings y;
translated {
destination-pool x;
translation-type {
twice-napt-44;
}
}
}
}
}
port-forwarding y {
208
Copyright © 2018, Juniper Networks, Inc.
Chapter 15: Connecting Specific Ports and Addresses Using Port Forwarding
destined-port 45;
translated-port 23;
destined-port 55;
translated-port 33;
destined-port 65;
translated-port 43;
}
}
adaptive-services-pics {
traceoptions {
file sp-trace;
flag all;
}
}
NOTE:
Release History Table
Related
Documentation
•
•
Stateful firewall has precedence over port forwarding. In this example, for
instance, no traffic destined to any port between 20 and 5000 will be
translated.
•
Up to 32 port maps can be configured.
Release
Description
17.4R1
Starting in Junos OS Release 17.4R1, port forwarding is also supported
on the MS-MPC and MS-MIC.
Configuring Port Forwarding for Static Destination Address Translation on page 202
Copyright © 2018, Juniper Networks, Inc.
209
Adaptive Services Interfaces Feature Guide for Routing Devices
210
Copyright © 2018, Juniper Networks, Inc.
CHAPTER 16
Allocating a Few Public Addresses to
Many Private Hosts Using Dynamic NAT
•
Configuring Dynamic Address-Only Source Translation in IPv4 Networks on page 211
•
Example: Dynamic Source NAT as a Next-Hop Service on page 215
•
Example: Assigning Addresses from a Dynamic Pool for Static Use on page 217
Configuring Dynamic Address-Only Source Translation in IPv4 Networks
In IPv4 networks, dynamic address translation (dynamic NAT) is a mechanism to
dynamically translate the destination traffic without port mapping. To use dynamic NAT,
you must specify a source pool name, which includes an address configuration.
To configure dynamic NAT in IPv4 networks:
1.
In configuration mode, go to the [edit services] hierarchy level.
[edit]
user@host# edit services
2. Configure the service set and NAT rule.
[edit services]
user@host# set service-set service-set-name nat-rules rule-name
In the following example, the name of the service set is s1, and the name of the NAT
rule is rule-dynamic-nat44.
[edit services]
user@host# set service-set s1 nat-rules rule-dynamic-nat44
3. Go to the [interface-service] hierarchy level for the service set.
[edit services]
user@host# edit service-set s1 interface-service
4. Configure the service interface.
[edit services service-set s1 interface-service]
user@host# set service-interface service-interface-name
Copyright © 2018, Juniper Networks, Inc.
211
Adaptive Services Interfaces Feature Guide for Routing Devices
In the following example, the name of the service interface is ms-0/1/0.
NOTE: If the service interface is not present in the router, or the specified
interface is not functional, the following command can result in an error.
[edit services service-set s1 interface-service]
user@host# set service-interface ms-0/1/0
5. Go to the [edit services nat] hierarchy level. Issue the following command from the
top of the services hierarchy, or use the top keyword.
[edit services service-set s1 interface-service]
user@host# top editservices nat
6. Configure the NAT pool with an address.
[edit services nat]
user@host# set pool pool-name address address
In the following example, the name of the pool is source-dynamic-pool, and the address
is 10.10.10.0.
[edit services nat]
user@host# set pool source-dynamic-pool address 10.10.10.0
7. Configure the rule, match direction, term, and source address.
[edit services nat]
user@host# set rule rule-name match-direction match-direction term term-name from
source-address address
In the following example, the name of the rule is rule-dynamic-nat44, the match
direction is input, the name of the term is t1, and the source address is 3.1.1.0.
[edit services nat]
user@host# set rule rule-dynamic-nat44 match-direction input term t1 from
source-address 3.1.1.0
8. Go to the [edit rule rule-dynamic-nat-44 term t1] hierarchy level.
[edit services nat]
user@host# edit rule rule-dynamic-nat44 term t1
9. Configure the source pool and the translation type.
[edit services nat rule rule-dynamic-nat44 term t1]
user@host# set then translated source-pool src-pool-name translation-type
translation-type
In the following example, the name of the source pool is source-dynamic-pool and
the translation type is dynamic-nat44.
[edit services nat rule rule-dynamic-nat44 term t1]
212
Copyright © 2018, Juniper Networks, Inc.
Chapter 16: Allocating a Few Public Addresses to Many Private Hosts Using Dynamic NAT
user@host# set then translated source-pool source-dynamic-pool translation-type
dynamic-nat44
10. Go to the [edit services adaptive-services-pics] hierarchy level. In the following
command, the top keyword ensures that the command is run from the top of the
hierarchy.
[edit services nat rule rule-dynamic-nat44 term t1]
user@host# top editservices adaptive-services-pics
11. Configure the trace options.
[edit services adaptive-services-pics]
user@host# set traceoptions flag tracing parameter
In the following example, the tracing parameter is configured as all.
[edit services adaptive-services-pics]
user@host# set traceoptions flag all
12. Verify the configuration by using the show command at the [edit services] hierarchy
level.
[edit services]
user@host# show
service-set s1 {
nat-rules rule-dynamic-nat44;
interface-service {
service-interface ms-0/1/0;
}
}
nat {
pool source-dynamic-pool {
address 10.1.1.0/24;
}
rule rule-dynamic-nat44 {
match-direction input;
term t1 {
from {
source-address {
3.1.1.0/24;
}
}
then {
translated {
destination-pool source-dynamic-pool;
translation-type {
dynamic-nat44;
}
}
}
}
}
}
adaptive-services-pics {
traceoptions {
flag all;
Copyright © 2018, Juniper Networks, Inc.
213
Adaptive Services Interfaces Feature Guide for Routing Devices
}
}
The following example configures the translation type as dynamic-nat44.
[edit services]
user@host# show
service-set s1 {
nat-rules rule-dynamic-nat44;
interface-service {
service-interface ms-0/1/0;
}
}
nat {
pool source-dynamic-pool {
address 10.1.1.0/24;
}
rule rule-dynamic-nat44 {
match-direction input;
term t1 {
from {
source-address {
3.1.1.0/24;
}
}
then {
translated {
destination-pool source-dynamic-pool;
translation-type {
dynamic-nat44;
}
}
}
}
}
}
adaptive-services-pics {
traceoptions {
flag all;
}
}
The following configuration specifies that NAT is not performed on incoming traffic from
the source address 192.168.20.24/32 by providing a NAT rule term t0 that configures
no-translation. Dynamic NAT is performed on all other incoming traffic, as configured by
term t1 of the NAT rule. The no-translation option is supported on MX Series routers with
MS-DPCs and on M Series routers with MS-100, MS-400, and MS-500 MultiServices
PICS. The no-translation option is supported on MX Series routers with MS-MPCs and
MS-MICs starting in Junos OS release 15.1R1.
[edit services nat]
pool my-pool {
address-range low 10.10.10.1 high 10.10.10.16;
port automatic;
}
rule src-nat {
match-direction input;
214
Copyright © 2018, Juniper Networks, Inc.
Chapter 16: Allocating a Few Public Addresses to Many Private Hosts Using Dynamic NAT
term t0 {
from {
source-address 192.168.20.24/32;
}
then {
no-translation;
}
}
term t1 {
then {
translated {
translation-type dynamic-nat44;
source-pool my-pool;
}
}
}
}
The following configuration performs NAT using the source prefix 20.20.10.0/24 without
defining a pool.
[edit services nat]
rule src-nat {
match-direction input;
term t1 {
then {
translation-type dynamic-nat44;
source-prefix 20.20.10.0/24;
}
}
}
The following configuration performs NAT using the destination prefix 20.20.10.0/32
without defining a pool.
[edit services nat]
rule src-nat {
match-direction input;
term t1 {
from {
destination-address 10.10.10.10/32;
then {
translation-type dnat44;
destination-prefix 20.20.10.0/24;
}
}
}
}
Example: Dynamic Source NAT as a Next-Hop Service
The following example shows dynamic-source NAT applied as a next-hop service:
[edit interfaces]
ge-0/2/0 {
unit 0 {
Copyright © 2018, Juniper Networks, Inc.
215
Adaptive Services Interfaces Feature Guide for Routing Devices
family mpls;
}
}
sp-1/3/0 {
unit 0 {
family inet;
}
unit 20 {
family inet;
}
unit 32 {
family inet;
}
}
[edit routing-instances]
protected-domain {
interface ge-0/2/0.0;
interface sp-1/3/0.20;
instance-type vrf;
route-distinguisher 10.58.255.17:37;
vrf-import protected-domain-policy;
vrf-export protected-domain-policy;
routing-options {
static {
route 0.0.0.0/0 next-hop sp-1/3/0.20;
}
}
}
[edit policy-options]
policy-statement protected-domain-policy {
term t1 {
then reject;
}
}
[edit services]
stateful-firewall {
rule allow-all {
match-direction input;
term t1 {
then {
accept;
}
}
}
}
nat {
pool my-pool {
address 10.58.16.100;
port automatic;
}
rule hide-all {
match-direction input;
term t1 {
then {
translated {
source-pool my-pool;
216
Copyright © 2018, Juniper Networks, Inc.
Chapter 16: Allocating a Few Public Addresses to Many Private Hosts Using Dynamic NAT
translation-type napt-44;
}
}
}
}
}
service-set null-sfw-with-nat {
stateful-firewall-rules allow-all;
nat-rules hide-all;
next-hop-service {
inside-service-interface sp-1/3/0.20;
outside-service-interface sp-1/3/0.32;
}
}
Example: Assigning Addresses from a Dynamic Pool for Static Use
The following configuration statically assigns a subset of addresses that are configured
as part of a dynamic pool (dynamic-pool) to two separate static pools (static-pool and
static-pool2).
[edit services nat]
pool dynamic-pool {
address 20.20.10.0/24;
}
pool static-pool {
address-range low 20.20.10.10 high 10.20.10.12;
}
pool static-pool2 {
address 20.20.10.15/32;
}
rule src-nat {
match-direction input;
term t1 {
from {
source-address 30.30.30.0/24;
}
then {
translation-type dynamic-nat44;
source-pool dynamic-pool;
}
}
term t2 {
from {
source-address 10.10.10.2;
}
then {
translation-type basic-nat44;
source-pool static-pool;
}
}
term t3 {
from {
source-address 10.10.10.10;
}
Copyright © 2018, Juniper Networks, Inc.
217
Adaptive Services Interfaces Feature Guide for Routing Devices
then {
translation-type basic-nat44;
source-pool static-pool2;
}
}
}
218
Copyright © 2018, Juniper Networks, Inc.
CHAPTER 17
Achieving Line-Rate, Low-Latency
Translations Using Inline NAT
•
Inline Network Address Translation Overview on page 219
•
Example: Configuring Inline Network Address Translation—Interface-Based
Method on page 221
•
Example: Configuring Inline Network Address Translation—Route-Based
Method on page 228
Inline Network Address Translation Overview
Inline NAT uses the capabilities of the MPC line card, eliminating the need for a services
card for NAT. Consequently, you can achieve line-rate, low-latency address translations
(up to 120 Gbps per slot). The current implementation provides:
•
1:1 static address mapping
•
Bidirectional mapping - source NAT for outbound traffic and destination NAT for
inbound traffic
•
No limit on number of flows
•
Support for Source, destination, and twice NAT, as shown in Figure 16 on page 220. Inline
NAT supports the translation type basic-nat44. Starting in Junos OS Release 15.1R1,
inline NAT also supports twice-basic-nat-44.
Copyright © 2018, Juniper Networks, Inc.
219
Adaptive Services Interfaces Feature Guide for Routing Devices
Figure 16: Supported Inline NAT Types
To configure inline NAT, you define your service interface as type si- (service-inline)
interface. You must also reserve adequate bandwidth for the inline interface. This enables
you to configure both interface or next-hop service-sets used for NAT. The si- interface
serves as a “virtual service PIC”.
NOTE: Only static NAT is supported. Port translation and dynamic NAT are
not supported. An MS-MPC, MS-MIC, MS-DPC, or MS-PIC is still needed for
any stateful-firewall processing and dynamic port translation.
Benefits of Inline NAT
•
Eliminates the need for a services card
•
Supports more NAT flows than a services card
Release History Table
Release
Description
15.1R1
Starting in Junos OS Release 15.1R1, inline NAT also supports
twice-basic-nat-44
Related
Documentation
220
•
Network Address Translation Configuration Overview on page 59
•
Example: Configuring Inline Network Address Translation—Interface-Based Method
on page 221
•
Carrier-Grade NAT Feature Comparison for Junos Address Aware by Type of Interface
Card on page 53
Copyright © 2018, Juniper Networks, Inc.
Chapter 17: Achieving Line-Rate, Low-Latency Translations Using Inline NAT
Example: Configuring Inline Network Address Translation—Interface-Based Method
This configuration example illustrates how to configure interface-based inline network
address translation (NAT) on MX Series devices using si- (service-inline) interfaces with
interface-style service-sets.
This topic covers:
•
Requirements on page 221
•
Overview and Topology on page 221
•
Configuration on page 222
•
Verification on page 226
Requirements
This example uses the following hardware and software components:
•
MX Series router with a Modular Port Concentrator (MPC) line card
•
Junos OS Release 11.4R1 or higher
Overview and Topology
As of Junos OS Release 11.4R1, MPC line cards can perform some services without the
need of a dedicated services card, such as an MS-MPC. Inline services generally provide
better performance than using a services card, however their functionality tends to be
more basic. For example, inline NAT supports only static NAT.
In this example, an MX Series device with an MPC line card provides inline source NAT
services to traffic flowing between two end hosts. The topology for this scenario is shown
in Figure 17 on page 221
Figure 17: Inline Source NAT Using an MX Series Device with an MPC
Request
Src: 10.1.1.2
Dst: 192.168.1.2
Request
Src: 192.0.2.2
Dst: 192.168.1.2
2. MX device performs
request translation
1. Client sends request
192.168.1.2
H1
4. MX device performs
response translation
MX Series
Inside
3. Response from server
Outside
S1
Request
Src: 192.168.1.2
Dst: 192.0.2.2
g200025
10.1.1.2
Request
Src: 192.168.1.2
Dst: 10.1.1.2
As shown in the figure, host H1 sends traffic towards server S1. The MX Series device
performs source NAT to translate H1’s source IP address from 10.1.1.2 to 192.0.2.2. Server
S1 then sends return traffic to host H1 using the destination IP address 192.0.2.2, and the
MX Series device reverts H1’s IP address back to 10.1.1.2.
The following configuration elements are used in this scenario:
Copyright © 2018, Juniper Networks, Inc.
221
Adaptive Services Interfaces Feature Guide for Routing Devices
•
Inline service interface—a virtual interface that resides on the Packet Forwarding Engine
of the MPC. To access services, traffic flows in and out of these si- (service-inline)
interfaces.
•
Service set—defines the service(s) to be performed, and identifies which inline
interface(s) will feed traffic into and out of the service set. There are two ways to
implement service sets:
•
Interface-style—an interface-based method, where packets arriving at an interface
are forwarded through the inline service.
•
Next-hop-style—a route-based method, where static routes are used to forward
packets destined for a specific destination through the inline service.
This example uses the interface-style service set.
•
NAT rule—uses an if-then structure (similar to firewall filters) to define matching
conditions and then apply address translation to the matching traffic.
•
NAT pool—a user-defined set of IP addresses that are used by the NAT rule for
translation.
These elements come together as shown in Figure 18 on page 222
Figure 18: Interface-Based Inline Source NAT
MX Series Device
MPC 0
MPC 1
Interface-style Service Set
NAT
Rule: If Src = 10.1.1.0/24,
then translate
Pool: 192.0.2.0/24
xe-0/0/0
xe-1/0/0
g200030
si-0/0/0.0
Configuration
To configure inline NAT using an interface-style service set, perform these tasks:
CLI Quick
Configuration
•
Enable Inline Services and Create an Inline Interface on page 223
•
Configure NAT Rule and Pool on page 223
•
Configure the (Interface-style) Service Set on page 224
•
Configure Physical Interfaces on page 224
To quickly configure this example, copy the following commands, paste them into a text
file, remove any line breaks, change any details necessary to match your network
configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy
level.
## Enable inline services, create an si- interface, reserve bandwidth ##
set chassis fpc 0 pic 0 inline-services bandwidth 1g
set interfaces si-0/0/0 unit 0 family inet
222
Copyright © 2018, Juniper Networks, Inc.
Chapter 17: Achieving Line-Rate, Low-Latency Translations Using Inline NAT
## Configure a NAT rule and pool ##
set services nat rule SRC-NAT1 match-direction input
set services nat rule SRC-NAT1 term r1 from source-address 10.1.1.0/24
set services nat rule SRC-NAT1 term r1 then translated translation-type basic-nat44
set services nat rule SRC-NAT1 term r1 then translated source-pool p1
set services nat pool p1 address 192.0.2.0/24
## Configure the (interface-style) service set ##
set services service-set INT-STYLE-SS-NAT1 nat-rules SRC-NAT1
set services service-set INT-STYLE-SS-NAT1 interface-service service-interface si-0/0/0.0
## Configure interfaces ##
set interfaces xe-0/0/0 unit 0 family inet address 10.1.1.1/24
set interfaces xe-0/0/0 description INSIDE
set interfaces xe-1/0/0 unit 0 family inet address 192.168.1.1/24
set interfaces xe-1/0/0 description OUTSIDE
set interfaces xe-0/0/0 unit 0 family inet service input service-set INT-STYLE-SS-NAT1
set interfaces xe-0/0/0 unit 0 family inet service output service-set INT-STYLE-SS-NAT1
Enable Inline Services and Create an Inline Interface
Step-by-Step
Procedure
1.
Enable inline services for the relevant FPC slot and PIC slot, and define the amount
of bandwidth to dedicate for inline services.
The FPC and PIC settings here will create and map to an si- interface.
[edit chassis fpc 0 pic 0]
user@MX# set inline-services bandwidth 1g
2.
On the si- interface, specify the protocol family (or families) that will need NAT
services.
NOTE: The FPC and PIC settings here must match the settings defined
above.
[edit interfaces si-0/0/0]
user@MX# set unit 0 family inet
Configure NAT Rule and Pool
Step-by-Step
Procedure
1.
Configure a NAT rule that matches on traffic arriving at the MX device from H1’s
subnet (10.1.1.0/24), translates it using basic IPv4 NAT, and uses an IP address from
pool p1.
[edit services nat]
user@MX# set rule SRC-NAT1 match-direction input
user@MX# set rule SRC-NAT1 term r1 from source-address 10.1.1.0/24
user@MX# set rule SRC-NAT1 term r1 then translated translation-type basic-nat44
user@MX# set rule SRC-NAT1 term r1 then translated source-pool p1
2.
Configure the NAT pool.
Copyright © 2018, Juniper Networks, Inc.
223
Adaptive Services Interfaces Feature Guide for Routing Devices
[edit services nat]
user@MX# set pool p1 address 192.0.2.0/24
Configure the (Interface-style) Service Set
Step-by-Step
Procedure
1.
Configure a service set that uses the inline NAT service (nat-rules), and the inline
interface defined above. Use the interface-service parameter to specify that this is
an interface-style service set.
Traffic will flow into and out of the si- interface to access the inline NAT service.
[edit services]
user@MX# set service-set INT-STYLE-SS-NAT1 nat-rules SRC-NAT1
user@MX# set service-set INT-STYLE-SS-NAT1 interface-service service-interface
si-0/0/0.0
Configure Physical Interfaces
Step-by-Step
Procedure
1.
Configure the physical interfaces.
[edit interfaces]
user@MX# set xe-0/0/0 unit 0 family inet address 10.1.1.1/24
user@MX# set xe-0/0/0 description INSIDE
user@MX# set xe-1/0/0 unit 0 family inet address 192.168.1.1/24
user@MX# set xe-1/0/0 description OUTSIDE
2.
On the ’inside’ interface, specify that traffic will be sent through the service set
defined above.
[edit interfaces xe-0/0/0 unit 0]
user@MX# set family inet service input service-set INT-STYLE-SS-NAT1
user@MX# set family inet service output service-set INT-STYLE-SS-NAT1
224
Copyright © 2018, Juniper Networks, Inc.
Chapter 17: Achieving Line-Rate, Low-Latency Translations Using Inline NAT
Results
chassis {
fpc 0 {
pic 0 {
inline-services {
bandwidth 1g;
}
}
}
}
services {
service-set INT-STYLE-SS-NAT1 {
nat-rules SRC-NAT1;
interface-service {
service-interface si-0/0/0.0;
}
}
nat {
pool p1 {
address 192.0.2.0/24;
}
rule SRC-NAT1 {
match-direction input;
term r1 {
from {
source-address {
10.1.1.0/24;
}
}
then {
translated {
source-pool p1;
translation-type {
basic-nat44;
}
}
}
}
}
}
}
interfaces {
si-0/0/0 {
unit 0 {
family inet;
}
}
xe-0/0/0 {
description INSIDE;
unit 0 {
family inet {
service {
input {
service-set INT-STYLE-SS-NAT1;
}
output {
service-set INT-STYLE-SS-NAT1;
}
}
Copyright © 2018, Juniper Networks, Inc.
225
Adaptive Services Interfaces Feature Guide for Routing Devices
address 10.1.1.1/24;
}
}
}
xe-1/0/0 {
description OUTSIDE;
unit 0 {
family inet {
address 192.168.1.1/24;
}
}
}
}
Verification
Confirm that the configuration is working properly.
•
Verifying Reachability from Host H1 to Server S1 on page 226
•
Verifying Address Translation on page 226
Verifying Reachability from Host H1 to Server S1
Purpose
Action
Verify reachability between H1 and S1.
On host H1, verify that the host can ping server S1.
user@H1> ping 192.168.1.2 count 5
PING 192.168.1.2 (192.168.1.2): 56 data bytes
64 bytes from 192.168.1.2: icmp_seq=0 ttl=63 time=0.991 ms
64 bytes from 192.168.1.2: icmp_seq=1 ttl=63 time=14.186 ms
64 bytes from 192.168.1.2: icmp_seq=2 ttl=63 time=3.016 ms
64 bytes from 192.168.1.2: icmp_seq=3 ttl=63 time=3.742 ms
64 bytes from 192.168.1.2: icmp_seq=4 ttl=63 time=4.748 ms
--- 192.168.1.2 ping statistics --5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.991/5.337/14.186/4.593 ms
Meaning
H1 can successfully reach S1.
Verifying Address Translation
Purpose
Action
Verify that address translation is working correctly.
1.
On the MX device, verify that the inline NAT configuration details have been applied
correctly.
user@MX> show services inline nat pool
Interface: si-0/0/0, Service set: INT-STYLE-SS-NAT1
NAT pool: p1, Translation type: BASIC NAT44
226
Copyright © 2018, Juniper Networks, Inc.
Chapter 17: Achieving Line-Rate, Low-Latency Translations Using Inline NAT
Address range: 192.0.2.0-192.0.2.255
NATed packets: 5, deNATed packets: 5, Errors: 0
2. On server S1, verify that the server is receiving the pings from H1’s NAT-translated
source IP address (192.0.2.2).
Issue the command below, and send pings again from H1.
NOTE: For this setup, another MX device is used to represent server S1 to
enable monitoring of the inbound traffic.
user@S1> monitor traffic interface xe-1/1/1 no-resolve
verbose output suppressed, use <detail> or <extensive> for full protocol decode
Address resolution is OFF.
Listening on xe-1/1/1, capture size 96 bytes
23:28:28.577377 In IP 192.0.2.2 >
seq 0, length 64
23:28:28.577405 Out IP 192.168.1.2
0, length 64
23:28:29.579253 In IP 192.0.2.2 >
seq 1, length 64
23:28:29.579278 Out IP 192.168.1.2
1, length 64
23:28:30.579275 In IP 192.0.2.2 >
seq 2, length 64
23:28:30.579302 Out IP 192.168.1.2
2, length 64
23:28:31.580279 In IP 192.0.2.2 >
seq 3, length 64
23:28:31.580305 Out IP 192.168.1.2
3, length 64
23:28:32.581266 In IP 192.0.2.2 >
seq 4, length 64
23:28:32.581293 Out IP 192.168.1.2
4, length 64
^C
10 packets received by filter
0 packets dropped by kernel
Meaning
Related
Documentation
192.168.1.2: ICMP echo request, id 3293,
> 192.0.2.2: ICMP echo reply, id 3293, seq
192.168.1.2: ICMP echo request, id 3293,
> 192.0.2.2: ICMP echo reply, id 3293, seq
192.168.1.2: ICMP echo request, id 3293,
> 192.0.2.2: ICMP echo reply, id 3293, seq
192.168.1.2: ICMP echo request, id 3293,
> 192.0.2.2: ICMP echo reply, id 3293, seq
192.168.1.2: ICMP echo request, id 3293,
> 192.0.2.2: ICMP echo reply, id 3293, seq
Step 1 above confirms that the inline NAT service parameters and interface-style service
set are correctly implemented. Step 2 above confirms that server S1 is correctly receiving
H1’s pings from its NAT-translated source IP address.
•
Inline Network Address Translation Overview on page 219
•
Understanding Service Sets on page 7
•
Example: Configuring Inline Network Address Translation—Route-Based Method on
page 228
•
Day One: CGNAT Up and Running on the MX Series
Copyright © 2018, Juniper Networks, Inc.
227
Adaptive Services Interfaces Feature Guide for Routing Devices
Example: Configuring Inline Network Address Translation—Route-Based Method
This configuration example illustrates how to configure route-based inline network
address translation (NAT) on MX Series devices using si- (service-inline) interfaces with
next-hop style service-sets.
This topic covers:
•
Requirements on page 228
•
Overview and Topology on page 228
•
Configuration on page 229
•
Verification on page 234
Requirements
This example uses the following hardware and software components:
•
MX Series router with a Modular Port Concentrator (MPC) line card
•
Junos OS Release 11.4R1 or higher
Overview and Topology
As of Junos OS Release 11.4R1, MPC line cards can perform some services without the
need of a dedicated services card, such as an MS-MPC. Inline services generally provide
better performance than using a services card, however their functionality tends to be
more basic. For example, inline NAT supports only static NAT.
In this example, an MX Series device with an MPC line card provides inline source NAT
services to traffic flowing between two end hosts. The topology for this scenario is shown
in Figure 17 on page 221
Figure 19: Inline Source NAT Using an MX Series Device with an MPC
Request
Src: 10.1.1.2
Dst: 192.168.1.2
Request
Src: 192.0.2.2
Dst: 192.168.1.2
2. MX device performs
request translation
1. Client sends request
192.168.1.2
H1
4. MX device performs
response translation
MX Series
Inside
3. Response from server
Outside
S1
Request
Src: 192.168.1.2
Dst: 192.0.2.2
g200025
10.1.1.2
Request
Src: 192.168.1.2
Dst: 10.1.1.2
As shown in the figure, host H1 sends traffic towards server S1. The MX Series device
performs source NAT to translate H1’s source IP address from 10.1.1.2 to 192.0.2.2. Server
S1 then sends return traffic to host H1 using the destination IP address 192.0.2.2, and the
MX Series device reverts H1’s IP address back to 10.1.1.2.
The following configuration elements are used in this scenario:
228
Copyright © 2018, Juniper Networks, Inc.
Chapter 17: Achieving Line-Rate, Low-Latency Translations Using Inline NAT
•
Inline service interface—a virtual interface that resides on the Packet Forwarding Engine
of the MPC. To access services, traffic flows in and out of these si- (service-inline)
interfaces.
•
Service set—defines the service(s) to be performed, and identifies which inline
interface(s) will feed traffic into and out of the service set. There are two ways to
implement service sets:
•
Interface-style—an interface-based method, where packets arriving at an interface
are forwarded through the inline service.
•
Next-hop-style—a route-based method, where static routes are used to forward
packets destined for a specific destination through the inline service.
This example uses the next-hop-style service set.
•
NAT rule—uses an if-then structure (similar to firewall filters) to define matching
conditions and then apply address translation to the matching traffic.
•
NAT pool—a user-defined set of IP addresses that are used by the NAT rule for
translation.
•
Routing instance—a collection of routing tables, interfaces, and routing protocol
parameters that run separate from the main (default) routing instance.
Route-based inline NAT is typically used in scenarios that involve routing instances.
These elements come together as shown in Figure 18 on page 222.
Figure 20: Route-Based Inline Source NAT
MX Series Device
RI-A
Default
Next-hop-style Service Set
NAT
Rule: If Src = 10.1.1.0/24,
then translate
Pool: 192.0.2.0/24
si-0/0/0.1
si-0/0/0.2
xe-1/0/0
to < destination >
g200032
xe-0/0/0
Configuration
To configure inline NAT using a next-hop-style service set, perform these tasks:
•
Configure Physical Interfaces on page 230
•
Enable Inline Services and Create an Inline Interface on page 230
•
Configure Routing Instance and Identify Traffic to Send Through Inline NAT
Service on page 231
•
Configure NAT Rule and Pool on page 231
•
Configure the (Next-hop-style) Service Set on page 231
Copyright © 2018, Juniper Networks, Inc.
229
Adaptive Services Interfaces Feature Guide for Routing Devices
CLI Quick
Configuration
To quickly configure this example, copy the following commands, paste them into a text
file, remove any line breaks, change any details necessary to match your network
configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy
level.
## Configure interfaces ##
set interfaces xe-0/0/0 unit 0 family inet address 10.1.1.1/24
set interfaces xe-0/0/0 description INSIDE
set interfaces xe-1/0/0 unit 0 family inet address 192.168.1.1/24
set interfaces xe-1/0/0 description OUTSIDE
## Enable inline services, create an si- interface, reserve bandwidth ##
set chassis fpc 0 pic 0 inline-services bandwidth 1g
set interfaces si-0/0/0 unit 1 family inet
set interfaces si-0/0/0 unit 1 service-domain inside
set interfaces si-0/0/0 unit 2 family inet
set interfaces si-0/0/0 unit 2 service-domain outside
## Configure routing instance, feed traffic into the inline NAT service ##
set routing-instances RI-A instance-type virtual-router
set routing-instances RI-A interface xe-0/0/0.0
set routing-instances RI-A interface si-0/0/0.1
set routing-instances RI-A routing-options static route 192.168.1.2/32 next-hop si-0/0/0.1
## Configure a NAT rule and pool ##
set services nat rule SRC-NAT1 match-direction input
set services nat rule SRC-NAT1 term r1 from source-address 10.1.1.0/24
set services nat rule SRC-NAT1 term r1 then translated translation-type basic-nat44
set services nat rule SRC-NAT1 term r1 then translated source-pool p1
set services nat pool p1 address 192.0.2.0/24
## Configure the (next-hop-style) service set ##
set services service-set NH-STYLE-SS-NAT1 nat-rules SRC-NAT1
set services service-set NH-STYLE-SS-NAT1 next-hop-service inside-service-interface
si-0/0/0.1
set services service-set NH-STYLE-SS-NAT1 next-hop-service outside-service-interface
si-0/0/0.2
Configure Physical Interfaces
Step-by-Step
Procedure
1.
Configure the physical interfaces.
[edit interfaces]
user@MX# set xe-0/0/0 unit 0 family inet address 10.1.1.1/24
user@MX# set xe-0/0/0 description INSIDE
user@MX# set xe-1/0/0 unit 0 family inet address 192.168.1.1/24
user@MX# set xe-1/0/0 description OUTSIDE
Enable Inline Services and Create an Inline Interface
Step-by-Step
Procedure
1.
Enable inline services for the relevant FPC slot and PIC slot, and define the amount
of bandwidth to dedicate for inline services.
The FPC and PIC settings here will create and map to an si- interface.
[edit chassis fpc 0 pic 0]
user@MX# set inline-services bandwidth 1g
230
Copyright © 2018, Juniper Networks, Inc.
Chapter 17: Achieving Line-Rate, Low-Latency Translations Using Inline NAT
2.
On the si- interface, create two logical units. For each unit, specify the protocol
family (or families) that will need NAT services, and the ’inside’ or ’outside’ interfaces
for the service domain.
NOTE: The FPC and PIC settings here must match the settings defined
above.
[edit interfaces si-0/0/0]
user@MX# set unit 1 family inet
user@MX# set unit 1 service-domain inside
user@MX# set unit 2 family inet
user@MX# set unit 2 service-domain outside
Configure Routing Instance and Identify Traffic to Send Through Inline NAT Service
Step-by-Step
Procedure
1.
Configure a routing instance that includes the 'ínside' physical and si- interfaces,
as well as a static route that identifies traffic to forward into the inline NAT service
through the si- interface.
For simplicity, the static route used here simply identifies server S1.
[edit routing-instances]
user@MX# set RI-A instance-type virtual-router
user@MX# set RI-A interface xe-0/0/0.0
user@MX# set RI-A interface si-0/0/0.1
user@MX# set RI-A routing-options static route 192.168.1.2/32 next-hop si-0/0/0.1
Configure NAT Rule and Pool
Step-by-Step
Procedure
1.
Configure a NAT rule that matches on traffic arriving at the MX device from H1’s
subnet (10.1.1.0/24), translates it using basic IPv4 NAT, and uses an IP address from
pool p1.
[edit services nat]
user@MX# set rule SRC-NAT1 match-direction input
user@MX# set rule SRC-NAT1 term r1 from source-address 10.1.1.0/24
user@MX# set rule SRC-NAT1 term r1 then translated translation-type basic-nat44
user@MX# set rule SRC-NAT1 term r1 then translated source-pool p1
2.
Configure the NAT pool.
[edit services nat]
user@MX# set pool p1 address 192.0.2.0/24
Configure the (Next-hop-style) Service Set
Step-by-Step
Procedure
1.
Configure a service set that uses the inline NAT service (nat-rules), and the inline
interfaces defined above. Use the next-hop-service parameter to specify that this
Copyright © 2018, Juniper Networks, Inc.
231
Adaptive Services Interfaces Feature Guide for Routing Devices
is a next-hop-style service set, and assign the si- interfaces as ’inside’ and ’outside’
based on their settings above.
Traffic will flow into and out of the si- interfaces to access the inline NAT service.
[edit services]
user@MX# set service-set NH-STYLE-SS-NAT1 nat-rules SRC-NAT1
user@MX# set service-set NH-STYLE-SS-NAT1 next-hop-service
inside-service-interface si-0/0/0.1
user@MX# set service-set NH-STYLE-SS-NAT1 next-hop-service
outside-service-interface si-0/0/0.2
232
Copyright © 2018, Juniper Networks, Inc.
Chapter 17: Achieving Line-Rate, Low-Latency Translations Using Inline NAT
Results
chassis {
fpc 0 {
pic 0 {
inline-services {
bandwidth 1g;
}
}
}
}
services {
service-set NH-STYLE-SS-NAT1 {
nat-rules SRC-NAT1;
next-hop-service {
inside-service-interface si-0/0/0.1;
outside-service-interface si-0/0/0.2;
}
}
nat {
pool p1 {
address 192.0.2.0/24;
}
rule SRC-NAT1 {
match-direction input;
term r1 {
from {
source-address {
10.1.1.0/24;
}
}
then {
translated {
source-pool p1;
translation-type {
basic-nat44;
}
}
}
}
}
}
}
interfaces {
si-0/0/0 {
unit 1 {
family inet;
service-domain inside;
}
unit 2 {
family inet;
service-domain outside;
}
}
xe-0/0/0 {
description INSIDE;
unit 0 {
family inet {
address 10.1.1.1/24;
}
Copyright © 2018, Juniper Networks, Inc.
233
Adaptive Services Interfaces Feature Guide for Routing Devices
}
}
xe-1/0/0 {
description OUTSIDE;
unit 0 {
family inet {
address 192.168.1.1/24;
}
}
}
}
routing-instances {
RI-A {
instance-type virtual-router;
interface xe-0/0/0.0;
interface si-0/0/0.1;
routing-options {
static {
route 192.168.1.2/32 next-hop si-0/0/0.1;
}
}
}
}
Verification
Confirm that the configuration is working properly.
•
Verifying Reachability from Host H1 to Server S1 on page 234
•
Verifying Address Translation on page 235
Verifying Reachability from Host H1 to Server S1
Purpose
Action
Verify reachability between H1 and S1.
On host H1, verify that the host can ping server S1.
user@H1> ping 192.168.1.2 count 5
PING 192.168.1.2 (192.168.1.2): 56 data bytes
64 bytes from 192.168.1.2: icmp_seq=0 ttl=63 time=0.926
64 bytes from 192.168.1.2: icmp_seq=1 ttl=63 time=0.859
64 bytes from 192.168.1.2: icmp_seq=2 ttl=63 time=0.853
64 bytes from 192.168.1.2: icmp_seq=3 ttl=63 time=0.825
64 bytes from 192.168.1.2: icmp_seq=4 ttl=63 time=0.930
ms
ms
ms
ms
ms
--- 192.168.1.2 ping statistics --5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.825/0.879/0.930/0.042 ms
Meaning
234
H1 can successfully reach S1.
Copyright © 2018, Juniper Networks, Inc.
Chapter 17: Achieving Line-Rate, Low-Latency Translations Using Inline NAT
Verifying Address Translation
Purpose
Action
Verify that address translation is working correctly.
1.
On the MX device, verify that the inline NAT configuration details have been applied
correctly.
user@MX> show services inline nat pool
Interface: si-0/0/0, Service set: NH-STYLE-SS-NAT1
NAT pool: p1, Translation type: BASIC NAT44
Address range: 192.0.2.0-192.0.2.255
NATed packets: 5, deNATed packets: 5, Errors: 0, Skipped packets: 0
2. On server S1, verify that the server is receiving the pings from H1’s NAT-translated
source IP address (192.0.2.2).
Issue the command below, and send pings again from H1.
NOTE: For this setup, another MX device is used to represent server S1 to
enable monitoring of the inbound traffic.
user@S1> monitor traffic interface xe-1/1/1 no-resolve
verbose output suppressed, use <detail> or <extensive> for full protocol decode
Address resolution is OFF.
Listening on xe-1/1/1, capture size 96 bytes
20:19:36.182690 In IP 192.0.2.2 >
seq 0, length 64
20:19:36.182719 Out IP 192.168.1.2
0, length 64
20:19:37.182918 In IP 192.0.2.2 >
seq 1, length 64
20:19:37.182945 Out IP 192.168.1.2
1, length 64
20:19:38.183914 In IP 192.0.2.2 >
seq 2, length 64
20:19:38.183940 Out IP 192.168.1.2
2, length 64
20:19:39.184872 In IP 192.0.2.2 >
seq 3, length 64
20:19:39.184896 Out IP 192.168.1.2
3, length 64
20:19:40.185882 In IP 192.0.2.2 >
seq 4, length 64
20:19:40.185907 Out IP 192.168.1.2
4, length 64
^C
10 packets received by filter
0 packets dropped by kernel
Copyright © 2018, Juniper Networks, Inc.
192.168.1.2: ICMP echo request, id 4436,
> 192.0.2.2: ICMP echo reply, id 4436, seq
192.168.1.2: ICMP echo request, id 4436,
> 192.0.2.2: ICMP echo reply, id 4436, seq
192.168.1.2: ICMP echo request, id 4436,
> 192.0.2.2: ICMP echo reply, id 4436, seq
192.168.1.2: ICMP echo request, id 4436,
> 192.0.2.2: ICMP echo reply, id 4436, seq
192.168.1.2: ICMP echo request, id 4436,
> 192.0.2.2: ICMP echo reply, id 4436, seq
235
Adaptive Services Interfaces Feature Guide for Routing Devices
Meaning
Related
Documentation
236
Step 1 above confirms that the inline NAT service parameters and next-hop-style service
set are correctly implemented. Step 2 above confirms that server S1 is correctly receiving
H1’s pings from its NAT-translated source IP address.
•
Inline Network Address Translation Overview on page 219
•
Understanding Service Sets on page 7
•
Example: Configuring Inline Network Address Translation—Interface-Based Method
on page 221
•
Day One: CGNAT Up and Running on the MX Series
Copyright © 2018, Juniper Networks, Inc.
CHAPTER 18
Removing Address Dependency Using
Network Prefix Translation for IPv6 Traffic
•
Stateless Source Network Prefix Translation for IPv6 Overview on page 237
•
Guidelines for Configuring Stateless Source Network Prefix Translation on page 239
•
Interoperation of Functionalities with Network Prefix Translation for IPv6 on page 240
•
Working of NPTv6 with Interface-Style and Next Hop-Style Service Sets on page 242
•
Example: Achieving Address Independence By Configuring Stateless Network Prefix
Translation in IPv6 Networks by Using Interface-Style Service Sets on page 243
•
Example: Achieving Address Independence By Configuring Stateless Network Prefix
Translation in IPv6 Networks by Using Next-Hop -Style Service Sets on page 249
Stateless Source Network Prefix Translation for IPv6 Overview
Starting with Junos OS Release 15.1, you can configure stateless translation of source
address prefixes in IPv6 networks (IPv6 to IPv6). This capability is supported on MX Series
routers with MPCs where inline NAT is supported. To configure stateless network prefix
translation for IPv6 packets (NPTv6), include the translation-type nptv6 statement at
the [edit services nat rule rule-name term term-name then translated] hierarchy level. The
NPTv6 translator translates the source address prefix in such a way that the transport
layer checksum of the packet does not need to be recomputed. NPTv6 defines a stateless
method of IPv6 network prefix translation between internal and external networks. NPTv6
does not maintain the state for each node or each flow in the translator. You can use the
show services nat mappings nptv6 (internal | external) command to view the NAT
mappings for NPTv6 for internal and external addresses respectively. You can also use
the show services inline nat statistics and show services inline nat pool commands to
display information about inline NAT with NPTv6 configured.
Benefits of Stateless Source Network Prefix Translation
•
For edge networks, you do not need to renumber the IPv6 addresses used inside the
local network for interfaces, access lists, and system logging messages if:
•
The global prefixes used by the edge network are changed.
•
The IPv6 addresses are used inside the edge network or within other upstream
networks (such as multihomed devices) when a site adds, drops, or changes upstream
networks.
Copyright © 2018, Juniper Networks, Inc.
237
Adaptive Services Interfaces Feature Guide for Routing Devices
•
IPv6 addresses used by the edge network do not need ingress filtering in upstream
networks and do not need their customer-specific prefixes advertised to upstream
networks.
•
Connections that traverse the translation function are not disrupted by a reset or brief
outage of an NPTv6 translator.
NPTv6
Network prefix translation for IPv6 (NPTv6) defines a stateless way of IPv6 address
prefix translation between internal and external networks. NPTv6 does not maintain the
state for each node or each flow in the translator. Maintenance of mapping state is not
required for the address mapping of inbound or outbound packets. A stateless,
transport-agnostic IPv6-to-IPv6 NPTv6 function offers the advantage of
address-independence associated with IPv4-to-IPv4 NAT (NAPT44) and provides a 1:1
relationship between addresses in the inside and outside prefixes, thereby preserving
end-to-end reachability at the network layer. In upstream networks, IPv6 addresses used
by the edge network always contain a provider-allocated prefix.
NPTv6 is designed to provide address independence to the edge networks to achieve
internal address stability, regardless of its upstream service provider networks. However,
using provider-independent addresses without translation might be very expensive
because the routing table enumerates the edge networks, instead of enumerating the
transit domain that provides the service to the edge networks. This phenomenon can
cause a massive and unmanageable route table. NPTv6 is a mechanism that effectively
and cohesively provides address independence without advertising an internal network
prefix to external networks. In contrast, the main objective of network address port
translation (NAPT) for IPv4 (NAPT44) is to solve IPv4 address depletion, although it
brings the same benefit of address independence. NAPT for IPv6, specifically NAPT66,
is already supported in microkernel. However, similar to NAPT44, NAPT66 requires
flow-state information to be preserved. NPTv6 provides a simple and streamlined
technique to avoid as many of the limitations associated with NAPT66 as possible. It is
defined to include a two-way, checksum-neutral, and an algorithmic translation function.
NPTv6 does not maintain state information for a node, flow, or a connection in the
translator. Internal to external and external to internal packets are translated
algorithmically using information present in the IPv6 header. As a result of its stateless
nature, if multiple NPTv6 translators exist between the same two networks, the load can
shift or be dynamically shared among them. Also, unlike NAPT44, because the mapping
can be done in either direction, the translator does not interfere with the inbound
connection establishment. Instead, a firewall can be used in conjunction with an NPTv6
translator. This behavior offers the network administrator more flexibility to specify
security policy than that can be achieved with a traditional NAT.
Another advantage of NPTv6 is checksum-neutral translations. The translator does not
need to rewrite the transport header for updating the checksum and does not perform
port mapping. As a result, to deploy new transport layer protocols, you do not need to
modify the translator. Because the transport layer is not modified, the algorithm does
not interfere with encryption of the IP payload. Although NPTv6 compares favorably to
NAPT44 or NAPT66 in several ways, it does not eliminate all of the architectural problems.
238
Copyright © 2018, Juniper Networks, Inc.
Chapter 18: Removing Address Dependency Using Network Prefix Translation for IPv6 Traffic
Because NPTv6 modifies the IP headers of packets, it is not compatible with security
mechanisms such as the IPsec authentication header. The use of separate internal and
external prefixes creates complexity for Domain Name System (DNS) deployment. Also,
those applications that require application layer gateways (ALGs) to work correctly
through NAPT44 or NAPT66 devices might require similar ALGs to work through NPTv6
translators. Because NPTv6 does not maintain connection states, the failure of the
translator does not impact the non-transmit power control (TPC) traffic through the
server. TCP connections can be interrupted because of the change in the source IP address
of a connection. Connections might be timed out and then reestablished in this case.
NPTv6 uses inline NAT. Inline NAT uses the capabilites of the Modular Port Concentrator
(MPC) line card, eliminating the need for a MultiServices DPC (MS-DPC) for NAT. To
configure inline NAT, you define your service interface as type si- (service-inline) interface.
You must also reserve adequate bandwidth for the inline interface. This enables you to
configure both interface service sets and next-hop service sets used for NAT. The siinterface serves as a virtual service PIC.
Guidelines for Configuring Stateless Source Network Prefix Translation
Keep the following points in mind when you configure stateless translation of source
IPv6 prefixes:
This topic contains the following sections that describe the working behavior of different
functionalities with stateless source IPv6 prefix translation and the various system
conditions:
•
Graceful Routing Engine switchover (GRES) support is the same as for NAT44.
•
Unified ISSU and nonstop software upgrade (NSSU) are not supported.
•
NPTv6 deployment enables direct inbound connections to internal nodes from external
networks. This mechanism causes slight vulnerability because it opens the internal
nodes to attacks from outside. The stateless translation of NPTv6 makes it difficult
to trace external connection requests, based on connection states. This behavior
enables NAT44 networks to be well-protected against external attacks. The best
option to secure an NPTv6 translator is to add a firewall above the NPTv6 translator.
•
A 6rd softwire concentrator interoperates with NPTv6. All other mechanisms that do
not require the application layer gateway (ALG) to change the source IP address in the
payload are supported. TCP, UDP, ICMP, SSH, and Telnet are supported by the NPTv6
translator. FTP and Session Initiation Protocol (SIP) that require the ALG to change
the source IP address in the payload are not supported.
•
The NPTv6 pools are allocated in the external data memory. The pool data structure
consists of the address prefix, prefix length, and the checksum. The size of each record
is of 192 bits. For every pool, a denat pool is allocated automatically. The size of the
denat pool is 192 bits. There is a total allocation of 8000 64-bit entries for
NAT-processed and untranslated NPTv6 pools. This allocation comes from the 64,000
entries allocated for the inline services (JNH_APP_INLINE_SVCS).
•
Chaining of inline services for interoperation of 6rd with NPTv6 is not supported.
Copyright © 2018, Juniper Networks, Inc.
239
Adaptive Services Interfaces Feature Guide for Routing Devices
•
You need to configure a source pool and specify the from (source) address, while
configuring NPTv6.
•
The external and internal prefix lengths must be greater than or equal to /16 subnet
mask and less than or equal to /112 subnet mask.
•
Two different internal prefixes cannot be translated to the same external prefix.
•
NPTv6 cannot be applied to IPSec and Internet Key Exchange (IKE) packets. The
NPTv6 translator is bypassed in this case.
•
Because the translation is of one IPv6 address prefix, there is only one address in the
pool. If more than one address is configured by the user, the system does not raise any
error, instead only the first address prefix of the pool is chosen for translation.
•
For packets going from internal network to external network, if the internal subnet is
not mapped or is set to 0xFFFF, then the datagram is discarded and an ICMP destination
unreachable error is generated.
•
For packets going from internal network to external network, if the 16-bit word has the
adjustment added to it using the 1’s complement method and is equal to 0xFFFF, then
the value is written as zero.
•
For packets coming from the external network to internal network, if the 16-bit word
has the adjustment subtracted from it using 1’s complement method and is equal to
0xFFFF, the 16-bit word is overwritten as zero.
•
For translation of prefixes /48 or shorter, the adjustment must be added or subtracted
from the first 16 bits after the /48 subnet mask, the values of which are not 0xFFFF. If
the prefix is /49 or longer, then the adjustment must be added or subtracted from the
first 16 bits (from 64 to 123), the values of which are not 0xFFFF.
Interoperation of Functionalities with Network Prefix Translation for IPv6
This topic contains the following sections that describe the working behavior of different
functionalities with stateless source IPv6 prefix translation and the various system
conditions:
Address Mapping Algorithm
The NPTv6 translator filters the packets going out of the network and, if the source
address of the packet matches with the source address defined in the rule (the from or
source address in configuration), the source address is replaced with an address prefix
from the pool defined for the rule. The next 16 bits after the prefix of the source address
are replaced with the checksum-adjusted value to ensure that the checksum remains
the same in the outgoing packet even though the source address is changed. During the
definition of the configuration rule and pool for the packets going outside the network,
a denat rule and pool are created for the translation of the destination address for the
packets coming into the network.
240
Copyright © 2018, Juniper Networks, Inc.
Chapter 18: Removing Address Dependency Using Network Prefix Translation for IPv6 Traffic
Internal to External Translation
When a packet is going from the internal network to the external network, the IPv6 prefix
in the source address of the packet (coming from inside node) is mapped to the external
prefix. After checksum adjustment, the packet is routed toward the external network.
External to Internal Translation
When a packet is coming from external network to internal network, the IPv6 prefix in
the destination address of the packet (coming from outside host) is mapped to the
internal prefix. After checksum adjustment, the packet is routed to internal network.
Checksum-Neutral Translation
The NPTv6 translator translates the source address prefix in such a way that the transport
layer checksum of the packet does not need to be recomputed. A checksum change
caused by modifying part of the area covered by the checksum can be corrected by
making an additional change to a different 16-bit field covered by the same checksum.
This checksum neutral method first computes 1's complement checksum of the
internal-prefix and the external-prefix.
For packets coming from the internal network, the adjustment is calculated as 1’s
complement and it is computed as follows:
Adjustment = Internal prefix checksum – External prefix checksum.
The adjustment value is added to the 16-bit word of the source address after the prefix.
For packets coming from external network, the adjustment is 1’s complement and it is
calculated as follows:
Adjustment = External prefix checksum – Internal prefix checksum.
The adjustment is added to the 16-bit word of the destination address after the translated
prefix.
Multihoming
If there are two NPTv6 translators with different external IPv6 prefix configurations for
the same internal IPv6 prefix, then these two NPTV6 translators will translate the same
internal IPv6 network prefix to two different external IPv6 network prefixes, depending
on the translator the packet traverses.
Hairpinning
When an internal node has knowledge of only the external (that is, the global address)
of another internal node, it uses that address to send packet to that internal node. If such
a packet is received by an NPTv6 translator, that packet is routed toward the internal
network again after it undergoes source address and destination address translation.
Copyright © 2018, Juniper Networks, Inc.
241
Adaptive Services Interfaces Feature Guide for Routing Devices
Load Balancing
Load sharing is achieved when two translators have the same internal to external mapping
configuration and packet load is shared between them. How the load balancing is achieved
is beyond the scope of NPTv6.
The balancing could be implemented based on subnet ID portion of the IPv6 address.
There can be two si- logical interfaces with the same mapping of the internal prefix to
the external prefix. Packets are routed to one of the si- logical interfaces based on the
subnet ID.
ICMPv6 for NPTv6
Any host in the internal network should be able to ping a host in the external network
through an NPTv6 translator. All ICMP error messages should be forwarded to the host
in the internal network. During internal to external translation if there is no mapping
possible for a prefix, then packet is dropped and the ICMP Destination Unreachable
message is sent back. An ICMPv6 Destination Unreachable error is returned by the
translator if the ICMP error is enabled in the following cases:
•
If source address prefix lengths are less than or equal to /48 and the 48-63 bits are
equal to 0xFFFF
•
If prefix lengths are greater than /48 and all the 16-bit blocks in the interface ID (IID)
(bits 64-127) are equal to 0xFFFF
Otherwise the packet is discarded.
For prefix lengths less than or equal to /48, the bits 48-63 are used as the 16-bit word
adjusted for checksum. For prefix lengths greater than /48, the first 16-bit block in the
IID that does not have the value 0xFFFF is the 16-bit word adjusted for checksum.
If the interface ID (IID) part of the address to be translated contains all zeros, ICMPv6
Parameter Problem error is returned by the translator if the ICMP error option is enabled.
Otherwise the packet is discarded. ICMPv6 errors are generated by the control plane.
The source address of the ICMPv6 pakcket is the IP address of the ingress interface.
Related
Documentation
•
Working of NPTv6 with Interface-Style and Next Hop-Style Service Sets
The objective is to add network prefix translation for IPv6 (NPTv6) inline service that
performs stateless translation of the source IPv6 address. Consider a sample topology
in which NPTv6 is implemented between an internal network with the prefix of
FD01:0203:0405:/48 and an external network with the prefix of 2001:0DB8:0001:/48.
The source addresses FD01:0203:0405:/48 in the packets from a single administrative
domain (internal network) destined to hosts in global network (external network) will
be translated to 2001:0DB8:0001:/48. Packets destined to internal network coming from
external network will have their destination address as 2001:0DB8:0001:/48. This
242
Copyright © 2018, Juniper Networks, Inc.
Chapter 18: Removing Address Dependency Using Network Prefix Translation for IPv6 Traffic
destination address will be mapped to internal network address FD01:0203:0405:/48
and will be forwarded to the internal network host. The lengths of both the subnets are
assumed to be the same for this case. If they differ the shorter one would be extended
to the prefix length of the longer one by suffixing zeros.
Address mapping algorithm used for NPTv6 is checksum-neutral. The translated IP
headers will generate the same IPv6 pseudo-header checksum. Checksum is calculated
using the standard Internet checksum algorithm. Changes that are made during translation
of the IPv6 prefix are offset by the calculated changes made to the other parts of the
IPv6 address. This results in transport layers that use the Internet checksum (such as
TCP and UDP) calculating the same IPv6 pseudo-header checksum for both the internal
and external forms of the same datagram and avoids the need to modify transport layer
headers to correct the checksum value. The algorithm can map the addresses for inbound
packets and outbound packets.
The NPTv6 translator works for both fragmented packets and packets with IP options
enabled. The configuration changes required for NPTv6 are covered in the next sections.
The configuration of a router to handle services is through the definition of logical service
interface, service sets and service set rules. These define how the service is applied to
the packets.
The inline services logical interface, si-ifl, implementation available for static v4-v4
source-address inline-NAT can be reused for inline NPTv6. The configuration for the
NPTv6 implemented for MS-DPC can be modified for inline NPTv6 implementation.
There are two types of service set configurations—interface style and next hop style.
For the next hop-style service, a route entry is configured to steer packets to an inline
service interface. There the packet would go through the service rules. If the packet
matches the service rules, it is processed as per the service rules. For the interface-style
service, the service set is configured directly on the media interface affecting traffic as it
leaves and enters the interface. The packets are steered to the inline service interface
by the service filter applied to the media interface.
Example: Achieving Address Independence By Configuring Stateless Network Prefix
Translation in IPv6 Networks by Using Interface-Style Service Sets
You can configure stateless translation of source address prefixes in IPv6 networks (IPv6
to IPv6) on MX Series routers with MPCs that support inline NAT. The NPTv6 translator
translates the source address prefix in such a way that the transport layer checksum of
the packet does not need to be recomputed. NPTv6 defines a stateless method of IPv6
network prefix translation between internal and external networks. NPTv6 does not
maintain the state for each node or each flow in the translator. You can use the show
services nat mappings nptv6 (internal | external) command to view the NAT mappings
for NPTv6 for internal and external addresses respectively. You can also use the show
services inline nat statistics and show services inline nat pool commands to display
information about inline NAT with NPTv6 configured.
Copyright © 2018, Juniper Networks, Inc.
243
Adaptive Services Interfaces Feature Guide for Routing Devices
NOTE: This functionality is supported on MX Series routers with Trio-based
FPCs (MPCs).
This example describes how to configure stateless source prefix translation for IPv6
packets using interface-style service sets on MX Series routers with MPCs, and contains
the following sections:
•
Requirements on page 244
•
Overview and Topology for Stateless Network Prefix Translation in IPv6 Networks
Using Interface-Style Service Sets on page 244
•
Configuration on page 244
•
Verification on page 247
Requirements
This example uses the following hardware and software components:
•
One MX Series router with an MPC.
•
Junos OS Release 15.1R1 or later for MX Series routers
Overview and Topology for Stateless Network Prefix Translation in IPv6 Networks Using
Interface-Style Service Sets
For the interface style service, the service set is configured directly on the media interface
affecting traffic as it leaves and enters the interface. The packets are steered to the inline
service interface by the service filter applied to the media interface.
When you have defined and grouped the service rules by configuring the service-set
definition, you can apply services to one or more interfaces installed on the router. When
you apply the service set to an interface, it automatically ensures that packets are directed
to the PIC.
Consider a sample configuration scenario in which NPTv6 is configured using
interface-style service sets. An inline services interface, si-0/1/0, is configured with a
bandwidth reserved for 10 gigabits per second. The si-0/1/0 interface is defined with
inet6 family. A NAT address pool, nptv6_pool, is configured with the address of
abcd:ef12:3456::/48. A NAT rule is applied in the input direction to perform NPTv6
translation on packets that arrive from the source address of 1234:5678:9abc::/48. For
packets from the source address of 1234:5678:9abc::/48 that match the NAT rule criterion,
the address from the NAT address pool is allocated. A service set, ss_nptv6, is specified
with the NAT rule. A gigabit Ethernet interface, ge-5/0/0, is configured and the service
set is applied to this interface.
Configuration
To configure stateless network prefix translation for IPv6 using interface-style service
sets, perform these tasks:
244
Copyright © 2018, Juniper Networks, Inc.
Chapter 18: Removing Address Dependency Using Network Prefix Translation for IPv6 Traffic
CLI Quick
Configuration
To quickly configure this example, copy the following commands, paste them in a text
file, remove any line breaks, change any details necessary to match your network
configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy
level:
Configuring Interfaces
set interfaces si-0/1/0 unit 0 family inet6
Configuring Interfaces
for Traffic to Be
Handled By the Service
Set
set interfaces ge-5/0/0 unit 0 family inet6 service input service-set nptv6-service-set
set interfaces ge-5/0/0 unit 0 family inet6 service output service-set nptv6-service-set
set interfaces ge-5/0/0 unit 0 family inet6 address 1234:5678:9abc::1/64
Configuring Bandwidth
for the Service Inline
(si-) Interface
set chassis fpc 0 pic 1 inline-services bandwidth 10g
Configuring NAT Pool
and Rules
set services nat pool ss_nptv6_pool address abcd:ef12:3456::/48
set services nat rule ss_nptv6_rule match-direction input term t0 from source-address
1234:5678:9abc::/48
set services nat rule ss_nptv6_rule match-direction input term t0 then translated
source-pool ss_nptv6_pool
set services nat rule ss_nptv6_rule match-direction input term t0 then translated
translation-type nptv6
Configuring the Service
Set
Step-by-Step
Procedure
set services service-set ss_nptv6 nat-rules ss_nptv6_rule
set services service-set ss_nptv6 nat-options nptv6 icmpv6-error-messages
set services service-set ss_nptv6 interface-service service-interface si-0/1/0.0
The following example requires you to navigate various levels in the configuration
hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration
Mode in the CLI User Guide.
To configure stateless network prefix translation for IPv6 using interface-style service
sets:
1.
Configure an inline services (si-) interface.
[edit]
user@host# set interfaces si-0/1/0 unit 0 family inet6
2.
Configure the interfaces for traffic to be handled by the service set.
[edit]
user@host# set interfaces ge-5/0/0 unit 0 family inet6 service input service-set
nptv6-service-set
user@host# set interfaces ge-5/0/0 unit 0 family inet6 service output service-set
nptv6-service-set
user@host# set interfaces ge-5/0/0 unit 0 family inet6 address
1234:5678:9abc::1/64
3.
Configure the bandwidth for the service inline (si-) interface.
Copyright © 2018, Juniper Networks, Inc.
245
Adaptive Services Interfaces Feature Guide for Routing Devices
[edit]
user@host# set chassis fpc 0 pic 1 inline-services bandwidth 10g
4.
Configure a NAT pool and rule.
[edit]
user@host# set services nat pool ss_nptv6_pool address abcd:ef12:3456::/48
user@host# set services nat rule ss_nptv6_rule match-direction input term t0 from
source-address 1234:5678:9abc::/48
user@host# set services nat rule ss_nptv6_rule match-direction input term t0 then
translated source-pool ss_nptv6_pool
user@host# set services nat rule ss_nptv6_rule match-direction input term t0 then
translated translation-type nptv6
5.
Configure the service set
[edit]
user@host# set services service-set ss_nptv6 nat-rules ss_nptv6_rule
user@host# set services service-set ss_nptv6 nat-options nptv6
icmpv6-error-messages
user@host# set services service-set ss_nptv6 interface-service service-interface
si-0/1/0.0
Results
From the configuration mode, confirm your configuration by entering the show chassis,
show interfaces, and show services commands. If the output does not display the intended
configuration, repeat the instructions in this example to correct the configuration.
user@host# show chassis
chassis {
fpc 0 {
pic 1 {
inline-services {
bandwidth 10g;
}
}
}
}
user@host# show interfaces
interfaces {
si-0/1/0 {
unit 0 {
family inet6;
}
}
ge-5/0/0 {
unit 0 {
family inet6 {
service {
input {
service-set nptv6-service-set;
}
output {
246
Copyright © 2018, Juniper Networks, Inc.
Chapter 18: Removing Address Dependency Using Network Prefix Translation for IPv6 Traffic
service-set nptv6-service-set;
}
}
address 1234:5678:9abc::1/64;
}
}
}
}
user@host# show services
services {
service-set ss_nptv6 {
nat-rules ss_nptv6_rule;
nat-options {
nptv6 {
icmpv6-error-messages;
}
}
interface-service {
service-interface si-0/1/0.0;
}
}
nat {
pool ss_nptv6_pool {
address abcd:ef12:3456::/48;
}
rule ss_nptv6_rule {
match-direction input;
term t0 {
from {
source-address {
1234:5678:9abc::/48;
}
}
then {
translated {
source-pool ss_nptv6_pool;
translation-type {
nptv6;
}
}
}
}
}
}
}
Verification
To confirm that the configuration is working properly, perform the following:
•
Verifying the NAT Pool Mappings on page 247
•
Verifying the Inline NAT Pools and Statistics on page 248
Verifying the NAT Pool Mappings
Purpose
Verify the existing NAT address pools and mappings for IPv6 network prefix translation.
Copyright © 2018, Juniper Networks, Inc.
247
Adaptive Services Interfaces Feature Guide for Routing Devices
Action
From operational mode, use the show services nat mappings nptv6 command:
user@host> show services nat mappings nptv6 internal 1111:2222:3333:aaaa:bbbb::1
Interface
Service-set
si-0/1/0
ss_nptv6
aaaa:bbbb:cccc:dddd:bbbb::1
NAT-Pool
ss_nptv6_pool
Address Mapping
1111:2222:3333:aaaa:bbbb::1 ->
user@host> show services nat mappings nptv6 external aaaa:bbbb:cccc:dddd:bbbb::1
Interface
Service-set
si-0/1/0
ss_nptv6
-> aaaa:bbbb:cccc:dddd:bbbb::1
Meaning
NAT-Pool
ss_nptv6_pool
Address Mapping
1111:2222:3333:aaaa:bbbb::1
The output shows the mapping between NAT addresses and ports for IPv6 stateless
network prefix translation of external and internal addresses. The address and port details
that are originally sent and converted using NAT are displayed.
Verifying the Inline NAT Pools and Statistics
Purpose
Action
Verify the inline NAT pools and statistics for IPv6 network prefix translation.
From operational mode, use the show services inline nat command:
user@host> show services inline nat statistics interface si-4/0/0
Service PIC Name: si-4/0/0
Control Plane Statistics
ICMPv4 errors packets
ICMPv4 errors packets
ICMPv6 errors packets
ICMPv6 errors packets
Dropped packets
pass through
locally generated
pass through
locally generated
:0
:0
:0
:0
:0
Data Plane Statistics
NATed packets
deNATed packets
Errors
:0
:0
:0
user@host> show services inline nat pool
Interface: si-4/0/0, Service set: ss_nptv6
NAT pool: ss_nptv6_pool1, Translation type: NPTV6
Address range: abcd:ef12:3456::/48
NATed packets: 0, deNATed packets: 0, Errors: 0
NAT pool: ss_nptv6_pool2, Translation type: NPTV6
Address range: 1111:2222:3333::/48
NATed packets: 0, deNATed packets: 0, Errors: 0
user@host> show services inline nat pool ss_nptv6_pool1
Interface: si-4/0/0, Service set: ss_nptv6
NAT pool: ss_nptv6_pool1, Translation type: NPTV6
248
Copyright © 2018, Juniper Networks, Inc.
Chapter 18: Removing Address Dependency Using Network Prefix Translation for IPv6 Traffic
Address range: abcd:ef12:3456::/48
NATed packets: 0, deNATed packets: 0, Errors: 0
Meaning
Related
Documentation
The output shows the information about inline NAT address translations, such as the
number of packets that are subject to NAT processing, the packets that are not translated,
and the packets with translation errors for a specified service set and an si- interface.
•
Example: Achieving Address Independence By Configuring Stateless Network Prefix
Translation in IPv6 Networks by Using Next-Hop -Style Service Sets
You can configure stateless translation of source address prefixes in IPv6 networks (IPv6
to IPv6) on MX Series routers with MPCs where inline NAT is supported. The NPTv6
translator translates the source address prefix in such a way that the transport layer
checksum of the packet does not need to be recomputed. NPTv6 defines a stateless
method of IPv6 network prefix translation between internal and external networks. NPTv6
does not maintain per node or per flow state in the translator. You can use the show
services nat mappings nptv6 (internal | external) command to view the NAT mappings
for NPTv6 for internal and external addresses respectively. You can also use the show
services inline nat statistics and show services inline nat pool commands to display
information about inline NAT with NPTv6 configured.
NOTE: This functionality is supported on MX Series routers with Trio-based
FPCs (MPCs).
This example describes how to configure stateless source prefix translation for IPv6
packets using next-hop style service sets on MX Series routers with MPCs, and contains
the following sections:
•
Requirements on page 249
•
Overview and Topology of Stateless Network Prefix Translation in IPv6 Networks Using
Next-Hop Style Service Sets on page 250
•
Configuration on page 250
•
Verification on page 254
Requirements
This example uses the following hardware and software components:
•
One MX Series router with an MPC.
•
Junos OS Release 15.1R1 or later for MX Series routers
Copyright © 2018, Juniper Networks, Inc.
249
Adaptive Services Interfaces Feature Guide for Routing Devices
Overview and Topology of Stateless Network Prefix Translation in IPv6 Networks Using
Next-Hop Style Service Sets
A next-hop service set is a route-based method of applying a particular service. Only
packets destined for a specific next hop are serviced by the creation of explicit static
routes. This configuration is useful when services need to be applied to an entire virtual
private network (VPN) routing and forwarding (VRF) table, or when routing decisions
determine that services need to be performed.
For the next hop style service, a route entry is configured to steer packets to an inline
service interface. The packet is validated through the service rules. If the packet matches
the service rules, it would be processed according to the service rules.
Consider a sample configuration scenario in which NPTv6 is configured using next-hop
style service sets. An inline services interface, si-0/1/0, is configured with a bandwidth
reserved for 10 gigabits per second. The si-0/1/0 interface is defined with inet6 family.
A NAT address pool, nptv6_pool, is configured with the address of abcd:ef12:3456::/48.
A NAT rule is applied in the input direction to perform NPTv6 translation on packets that
arrive from the source address of 1234:5678:9abc::/48. For packets from the source
address of 1234:5678:9abc::/48 that match the NAT rule criterion, the address from the
NAT address pool is allocated. The service set is configured for forwarding next-hops
with the service interface of si-0/1/0.1 associated with the service set applied inside the
network. with parameters for next hop service interfaces for the inside network and
si-/1/0.2 associated with the service set applied outside the network. A service set,
ss_nptv6, is specified with the NAT rule. The service interface domain is specified for the
si- interface with the inside service-domain configured for si-0/1/0.1 and outside service
domain configured for si-0/1/0.2. A routing instance, inst1, is configured with the instance
type as a VRF instance. interface si-0/1/0.1 and interface ge-5/0/0 are associated with
inst1. The inside and outside interface domain matches that specified with the
inside-service-interface and outside-service-interface statements. A policy is configured
for NAT events with the action to reject all packets.
Configuration
To configure stateless network prefix translation for IPv6 using next-hop style service
sets, perform these tasks:
CLI Quick
Configuration
Configuring Inline
Interfaces
250
To quickly configure this example, copy the following commands, paste them in a text
file, remove any line breaks, change any details necessary to match your network
configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy
level:
set interfaces si-0/1/0 unit 0 family inet6
set interfaces si-0/1/0 unit 1 family inet6
set interfacessi-0/1/0 unit 1 service-domain inside
set interfaces si-0/1/0 unit 2 family inet6
set interfaces si-0/1/0 unit 2 service-domain outside
set interfaces ge-5/0/0 unit 0 family inet6 address 1234:5678:9abc::1/64
Copyright © 2018, Juniper Networks, Inc.
Chapter 18: Removing Address Dependency Using Network Prefix Translation for IPv6 Traffic
Configuring Bandwidth
for Inline Services
set chassis fpc 0 pic 1 inline-services bandwidth 10g
Configuring NAT Pool
and Rule
set services nat pool ss_nptv6_pool address abcd:ef12:3456::/48
set services nat rule ss_nptv6_rule match-direction input term t0 from source-address
1234:5678:9abc::/48
set services nat rule ss_nptv6_rule match-direction input term t0 then translated
source-pool ss_nptv6_pool
set services nat rule ss_nptv6_rule match-direction input term t0 then translated
translation-type nptv6
Configuring a Service
Set
set services service-set ss_nptv6 nat-rules ss_nptv6_rule
set services service-set ss_nptv6 nat-options nptv6 icmpv6-error-messages
set services service-set ss_nptv6 nexthop-service inside-service-interface si-0/1/0.1
set services service-set ss_nptv6 nexthop-service outside-service-interface si-0/1/0.2
Configuring Routing
Instances
set routing-instances inst1 instance-type vrf
set routing-instances inst1 interface si-0/1/0.1
set routing-instances inst1 interface ge-5/0/0.0
set routing-instances inst1 route-distinguisher 1234:5678
set routing-instances inst1 vrf-import reject-all
set routing-instances inst1 vrf-export reject-all
set routing-instances inst1 routing-options rib inst1.inet6.0 static route ::0/0 next-hop
si-0/1/0.1
Configuring the Policy
and Action Modifier
Step-by-Step
Procedure
set policy-options policy-statement reject-all then reject
The following example requires you to navigate various levels in the configuration
hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration
Mode in the CLI User Guide.
To configure stateless network prefix translation for IPv6 using next-hop style service
sets:
1.
Configure the inline interface for NAT services.
[edit]
user@host# set interfaces si-0/1/0 unit 0 family inet6
user@host# set interfaces si-0/1/0 unit 1 family inet6
user@host# set interfacessi-0/1/0 unit 1 service-domain inside
user@host# set interfaces si-0/1/0 unit 2 family inet6
user@host# set interfaces si-0/1/0 unit 2 service-domain outside
user@host# set interfaces ge-5/0/0 unit 0 family inet6 address
1234:5678:9abc::1/64
2.
Set the bandwidth for inline services.
[edit]
user@host# set chassis fpc 0 pic 1 inline-services bandwidth 10g
3.
Configure the NAT pool and rule.
Copyright © 2018, Juniper Networks, Inc.
251
Adaptive Services Interfaces Feature Guide for Routing Devices
[edit]
user@host# set services nat pool ss_nptv6_pool address abcd:ef12:3456::/48
user@host# set services nat rule ss_nptv6_rule match-direction input term t0 from
source-address 1234:5678:9abc::/48
user@host# set services nat rule ss_nptv6_rule match-direction input term t0 then
translated source-pool ss_nptv6_pool
user@host# set services nat rule ss_nptv6_rule match-direction input term t0 then
translated translation-type nptv6
4.
Configure a service set using the NAT rule associated with the NAT pool.
[edit]
user@host# set services service-set ss_nptv6 nat-rules ss_nptv6_rule
user@host# set services service-set ss_nptv6 nat-options nptv6
icmpv6-error-messages
user@host# set services service-set ss_nptv6 nexthop-service
inside-service-interface si-0/1/0.1
user@host# set services service-set ss_nptv6 nexthop-service
outside-service-interface si-0/1/0.2
5.
Configure routing instances that use the si- interfaces configured.
[edit]
user@host# set routing-instances inst1 instance-type vrf
user@host# set routing-instances inst1 interface si-0/1/0.1
user@host# set routing-instances inst1 interface ge-5/0/0.0
user@host# set routing-instances inst1 route-distinguisher 1234:5678
user@host# set routing-instances inst1 vrf-import reject-all
user@host# set routing-instances inst1 vrf-export reject-all
user@host# set routing-instances inst1 routing-options rib inst1.inet6.0 static route
::0/0 next-hop si-0/1/0.1
6.
Configure the policy and the action modifier for NAT packets.
[edit]
user@host# set policy-options policy-statement reject-all then reject
Results
From the configuration mode, confirm your configuration by entering the show chassis,
show interfaces, show policy-options, show routing-instances, and show services
commands. If the output does not display the intended configuration, repeat the
instructions in this example to correct the configuration.
user@host# show chassis
chassis {
fpc 0 {
pic 1 {
inline-services {
bandwidth 10g;
}
}
}
}
252
Copyright © 2018, Juniper Networks, Inc.
Chapter 18: Removing Address Dependency Using Network Prefix Translation for IPv6 Traffic
user@host# show interfaces
chassis {
fpc 0 {
pic 1 {
inline-services {
bandwidth 10g;
}
}
}
}
interfaces {
si-0/1/0 {
unit 0 {
family inet6;
}
unit 1 {
family inet6;
service-domain inside;
}
unit 2 {
family inet6;
service-domain outside;
}
}
ge-5/0/0 {
unit 0 {
family inet6 {
address 1234:5678:9abc::1/64;
}
}
}
}
user@host# show policy-options
policy-options {
policy-statement reject-all {
then reject;
}
}
user@host# show routing-instances
routing-instances {
inst1 {
instance-type vrf;
interface si-0/1/0.1;
interface ge-5/0/0.0;
route-distinguisher 1234:5678;
vrf-import reject-all;
vrf-export reject-all;
routing-options {
rib inst1.inet6.0 {
static {
route ::0/0 next-hop si-0/1/0.1;
}
}
}
Copyright © 2018, Juniper Networks, Inc.
253
Adaptive Services Interfaces Feature Guide for Routing Devices
}
}
user@host# show services
services {
service-set ss_nptv6 {
nat-rules ss_nptv6_rule;
nat-options {
nptv6 {
icmpv6-error-messages;
}
}
nexthop-service {
inside-service-interface si-0/1/0.1;
outside-service-interface si-0/1/0.2;
}
}
nat {
pool ss_nptv6_pool {
address abcd:ef12:3456::/48;
}
rule ss_nptv6_rule {
match-direction input;
term t0 {
from {
source-address {
1234:5678:9abc::/48;
}
}
then {
translated {
source-pool ss_nptv6_pool;
translation-type {
nptv6;
}
}
}
}
}
}
}
Verification
To confirm that the configuration is working properly, perform the following:
•
Verifying the NAT Pool Mappings on page 254
•
Verifying the Inline NAT Pools and Statistics on page 255
Verifying the NAT Pool Mappings
Purpose
Action
Verify the existing NAT address pools and mappings for IPv6 network prefix translation.
From operational mode, use the show services nat mappings nptv6 command:
user@host> show services nat mappings nptv6 internal 1111:2222:3333:aaaa:bbbb::1
254
Copyright © 2018, Juniper Networks, Inc.
Chapter 18: Removing Address Dependency Using Network Prefix Translation for IPv6 Traffic
Interface
Service-set
si-0/1/0
ss_nptv6
aaaa:bbbb:cccc:dddd:bbbb::1
NAT-Pool
ss_nptv6_pool
Address Mapping
1111:2222:3333:aaaa:bbbb::1 ->
user@host> show services nat mappings nptv6 external aaaa:bbbb:cccc:dddd:bbbb::1
Interface
Service-set
si-0/1/0
ss_nptv6
-> aaaa:bbbb:cccc:dddd:bbbb::1
Meaning
NAT-Pool
ss_nptv6_pool
Address Mapping
1111:2222:3333:aaaa:bbbb::1
The output shows the information about inline NAT address translations, such as the
number of packets that are subject to NAT processing, the packets that are not translated,
and the packets with translation errors for a specified service set and an si- interface.
Verifying the Inline NAT Pools and Statistics
Purpose
Action
Verify the inline NAT pools and statistics for IPv6 network prefix translation.
From operational mode, use the show services inline nat command:
user@host> show services inline nat statistics interface si-4/0/0
Service PIC Name
:si-4/0/0
Control Plane Statistics
ICMPv4 errors packets
ICMPv4 errors packets
ICMPv6 errors packets
ICMPv6 errors packets
Dropped packets
:0
pass through
locally generated
pass through
locally generated
:0
:0
:0
:0
Data Plane Statistics
NATed packets
:0
deNATed packets
:0
Errors
:0
user@host> show services inline nat pool
Interface: si-0/1/0, Service set: ss_nptv6
NAT pool: ss_nptv6_pool1, Translation type: NPTV6
Address range: abcd:ef12:3456::/48
NATed packets: 0, deNATed packets: 0, Errors: 0
NAT pool: ss_nptv6_pool2, Translation type: NPTV6
Address range: 1111:2222:3333::/48
NATed packets: 0, deNATed packets: 0, Errors: 0
user@host> show services inline nat pool ss_nptv6_pool1
Copyright © 2018, Juniper Networks, Inc.
255
Adaptive Services Interfaces Feature Guide for Routing Devices
Interface: si-0/1/0, Service set: ss_nptv6
NAT pool: ss_nptv6_pool1, Translation type: NPTV6
Address range: abcd:ef12:3456::/48
NATed packets: 0, deNATed packets: 0, Errors: 0
Meaning
256
The output shows the mapping between NAT addresses and ports for IPv6 stateless
network prefix translation of external and internal addresses. The address and port details
that are originally sent and converted using NAT are displayed.
Copyright © 2018, Juniper Networks, Inc.
CHAPTER 19
Monitoring NAT
•
Configuring NAT Session Logs on page 257
•
Monitoring NAT Pool Usage on page 258
•
Using the Enterprise-Specific Utility MIB on page 258
Configuring NAT Session Logs
You can configure session logs for NAT from the CLI. By default, session open and close
logs are produced. However, you can request that only one type of log be produced.
To configure NAT session logs:
1.
Go to the [edit services service-set service-set-name syslog host class classname
hierarchy level.
user@host# edit services service-set service-set-name syslog host class classname
2. Configure NAT logging using the nat-logs configuration statement.
]edit services service-set service-set-name syslog host class classname]
user@host# set nat-logs.
3. Configure session logging using the session-logs statement. Open and close logs are
produced by default. Specify open or close to produce only one type of log.
]edit services service-set service-set-name syslog host class classname]
user@host# set session-logs.
Or
]edit services service-set service-set-name syslog host class classname]
user@host# set session-logs open.
Or
]edit services service-set service-set-name syslog host class classname]
user@host# set session-logs close.
4. For NAT sessions that us secured port block allocation (PBA), enter the
pba-interim-logging interval option.
]edit services service-set service-set-name syslog host class classname]
Copyright © 2018, Juniper Networks, Inc.
257
Adaptive Services Interfaces Feature Guide for Routing Devices
user@host# top.
[edit]
user@host# set interfaces interface-name service-options
pba-interim-logging-intervale.
Related
Documentation
•
Configuring System Logging for Service Sets on page 26
•
Interim Logging for Secured Port Block Allocation on page 192
Monitoring NAT Pool Usage
Purpose
Action
Use the show services nat pool detail command to find global NAT statistics related to
pool usage. This command is frequently used in conjunction with the show services
stateful-firewall statistics command.
user@host# show services nat pool detail
Interface: ms-1/0/0, Service set: s1
NAT pool: dest-pool, Translation type: DNAT-44
Address range: 10.10.10.2-10.10.10.2
NAT pool: napt-pool, Translation type: NAPT-44
Address range: 50.50.50.1-50.50.50.254
Port range: 1024-63487, Ports in use: 0, Out of port errors: 0, Max ports
used: 0
NAT pool: source-dynamic-pool, Translation type: DYNAMIC NAT44
Address range: 40.40.40.1-40.40.40.254
Out of address errors: 0, Addresses in use: 0
NAT pool: source-static-pool, Translation type: BASIC NAT44
Address range: 30.30.30.1-30.30.30.254
Related
Documentation
•
Configuring Pools of Addresses and Ports for Network Address Translation Overview
on page 61
Using the Enterprise-Specific Utility MIB
•
Using the Enterprise-Specific Utility MIB on page 258
•
Populating the Enterprise-Specific Utility MIB with Information on page 259
•
Stopping the SLAX Script with the CLI on page 264
•
Clearing the Utility MIB on page 265
•
Recovering from an Abnormal SLAX Script Exit or a SLAX Script Exit with the
CLI on page 265
Using the Enterprise-Specific Utility MIB
The enterprise-specific Utility MIB enables you to add SNMP-compliant applications
information to the enterprise-specific Utility MIB. The application information includes:
258
Copyright © 2018, Juniper Networks, Inc.
Chapter 19: Monitoring NAT
•
NAT mappings
•
Carrier-grade NAT (CGNAT) pools
•
Service set CPU utilization
•
Service set memory usage
•
Service set summary information
•
Service set packet drop information
•
Service set memory zone information
•
Multiservices PIC CPU and memory utilization
•
Stateful firewall flow counters
•
Session application connection information
•
Session analysis information
•
Subscriber analysis information
•
Traffic Load Balancer information
You use a delivered Stylesheet Language Alternative Syntax (SLAX) script to place
applications information into the enterprise-specific Utility MIB. The script is invoked
based on event policies (such as reboot of the router or switchover of Routing Engines)
defined in an event script. The script can also be invoked from the command line as an
op script. The script only runs on the master Routing Engine. After the script is invoked,
it polls data from the specified components at regular intervals using the XML-RPC API
and writes the converted data to the Utility MIB as SNMP variables. The script
automatically restarts after a configured polling cycle elapses.
See Also
•
Populating the Enterprise-Specific Utility MIB with Information on page 259
Populating the Enterprise-Specific Utility MIB with Information
To use a SLAX script to populate the enterprise-specific Utility MIB with information:
1.
Enable the services-oids-slax script.
user@host# set system scripts op file services-oids.slax
2. Configure the maximum amount of memory for the data segment during the execution
of the script.
user@host# set event-options event-script max-database 512m
3. Enable the script.
user@host# set event-options event-script file services-oids-ev-policy.slax
4. (Optional) Enable the log-stats argument to allow sys logging of stateful firewall
rate statistics when the event-script is run.
Copyright © 2018, Juniper Networks, Inc.
259
Adaptive Services Interfaces Feature Guide for Routing Devices
a. Display the event policies and the arguments that can be used.
user@host> show event-options event-scripts polices
event-options {
policy services-oids-done {
events system;
attributes-match {
system.message matches "Completed polling cycle normally.
Exiting";
}
then {
event-script services-oids.slax {
arguments {
max-polls 30;
interval 120;
}
}
}
}
policy system-started {
events system;
attributes-match {
system.message matches "Starting of initial processes complete";
}
then {
event-script services-oids.slax {
arguments {
max-polls 30;
interval 120;
}
}
}
}
}
event-options {
policy services-oids-done {
events system;
attributes-match {
system.message matches "Completed polling cycle normally.
Exiting";
}
then {
event-script services-oids.slax {
arguments {
max-polls 30;
interval 120;
}
}
}
}
policy system-started {
events system;
attributes-match {
system.message matches "Starting of initial processes complete";
}
then {
event-script services-oids.slax {
arguments {
260
Copyright © 2018, Juniper Networks, Inc.
Chapter 19: Monitoring NAT
max-polls 30;
interval 120;
}
}
}
}
}
The log-stats argument does not appear, so you must enable it.
b. Start the Linux shell.
user@host> start shell
%
c. Open the /var/db/scripts/event/services-oids-eve-policy.slax file for editing.
<event-options> {
/*
* This policy detects when the services-oids.slax script ends, then
restarts it.
*/
<policy> {
<name> "services-oids-done";
<events> "system";
<attributes-match> {
<from-event-attribute> "system.message";
<condition> "matches";
<to-event-attribute-value> "Completed polling cycle normally.
Exiting";
}
<then> {
<event-script> {
<name> "services-oids.slax";
<arguments> {
<name>"max-polls";
<value>"30";
}
<arguments> {
<name>"interval";
<value>"120";
}
/*
<arguments> {
<name>"log-stats";
<value>"yes";
}
*/
}
}
}
/*
* This policy detects when the system has booted and kicks off the
services-oids.slax script.
* This policy hooks the 'system started' event
*/
<policy> {
<name> "system-started";
<events> "system";
Copyright © 2018, Juniper Networks, Inc.
261
Adaptive Services Interfaces Feature Guide for Routing Devices
<attributes-match> {
<from-event-attribute> "system.message";
<condition> "matches";
<to-event-attribute-value> "Starting of initial processes
complete";
}
<then> {
<event-script> {
<name> "services-oids.slax";
<arguments> {
<name>"max-polls";
<value>"30";
}
<arguments> {
<name>"interval";
<value>"120";
}
/*
<arguments> {
<name>"log-stats";
<value>"yes";
}
*/
}
}
}
}
d. Remove the comment enclosures (/* and */) surrounding the <arguments> tags
containing “log-stats”.
e. Exit the Linux shell and return to the CLI.
% exit
f. Load the changes you made to the event script file.
user@host>request system scripts event-scripts reload
The log-stats argument is available the next time the event script restarts.
5. Set up the script logging file services-oids.log.
user@host# set system syslog file services-oids.log any info
user@host# set system syslog file services-oids.log match cscript
6. Synchronize scripts between Routing Engines so that when a switchover of Routing
Engine occurs, the event policy starts on the new master.
•
To synchronize on a per-commit basis:
user@host# commit synchronize scripts
•
To synchronize scripts every time you execute a commit synchronize:
[edit system scripts]
user@host# set synchronize
user@host# commit synchronize
262
Copyright © 2018, Juniper Networks, Inc.
Chapter 19: Monitoring NAT
7. The script starts automatically at system boot, but you can manually start it with the
CLI.
user@host> op services-oids arguments
Table 11 on page 263 describes the arguments that you can use.
Table 11: Arguments for services-oids.slax Script
Argument
Description
clean
A value of 1 clears all Utility MIB OIDs. Use this only to clean OID tables.
clear-semaphore
A value of 1 resets the semaphore in the Utility MIB to recover from an abnormal script exit
or from a manual script exit.
debug
Prints debug messages on console.
detail
Displays detailed output.
interval
Sets the number of seconds between poll cycles (default is 120).
invoke-debugger
Invokes script in debugger mode.
log-stats
Yes value enables sys logging of stateful firewall rate statistics (default is no).
max-polls
Sets the number of poll cycles before exiting the script (default is 30).
one-cycle-only
Value of 1 quits after one cycle of polling. Event policy does not restart the script. Use this
option for testing only. The default is 0.
signal-stop
A value of 1 stops the script and sets the semaphore, which causes the next iteration to exit.
silent
Prints trace messages on console if it is unset. Set it to zero-length string (“ ”) to unset it.
Default is 1.
|
Pipes through a command.
8. Check the status of the script from the log file.
router> show /var/log/services-oids.log | no-more
Jun 27 19:51:47 wf-cheesypoofs cscript: services-oids.slax(v0.14):[info]
Beginning polling cycle.
Jun 27 19:51:47 wf-cheesypoofs cscript: services-oids.slax(v0.14):[info]
processing traffic load-balance statistics
Jun 27 19:51:48 wf-cheesypoofs cscript: services-oids.slax(v0.14):[info]
processing cgnat pool detail
Jun 27 19:51:48 wf-cheesypoofs cscript: services-oids.slax(v0.14):[info]
processing cgnat mappings summary
Jun 27 19:51:48 wf-cheesypoofs cscript: services-oids.slax(v0.14):[info]
processing service-sets summary
Jun 27 19:51:48 wf-cheesypoofs cscript: services-oids.slax(v0.14):[info]
processing service-sets cpu-usage
Copyright © 2018, Juniper Networks, Inc.
263
Adaptive Services Interfaces Feature Guide for Routing Devices
Jun 27 19:51:48 wf-cheesypoofs cscript: services-oids.slax(v0.14):[info]
processing service-sets mem-usage
Jun 27 19:51:49 wf-cheesypoofs cscript: services-oids.slax(v0.14):[info]
processing stateful firewall statistics
Jun 27 19:51:49 wf-cheesypoofs cscript: services-oids.slax(v0.14):[info]
processing stateful firewall flow-analysis
Jun 27 19:51:49 wf-cheesypoofs cscript: services-oids.slax(v0.14):[info]
processing stateful firewall flows counts
Jun 27 19:51:49 wf-cheesypoofs cscript: services-oids.slax(v0.14):[info]
processing FW policy connections/second
Jun 27 19:51:49 wf-cheesypoofs cscript: services-oids.slax(v0.14):[info]
processing FW/NAT app connections
Jun 27 19:51:51 wf-cheesypoofs cscript: services-oids.slax(v0.14):[info]
processing service-set packet-drops
Jun 27 19:51:51 wf-cheesypoofs cscript: services-oids.slax(v0.14):[info]
processing service-set memory-usage zone
Jun 27 19:51:51 wf-cheesypoofs cscript: services-oids.slax(v0.14):[info]
processing service-set policy throughput stats
Jun 27 19:51:52 wf-cheesypoofs cscript: services-oids.slax(v0.14):[info]
processing ms-pic CPU amd Memory utilization stats
Jun 27 19:51:52 wf-cheesypoofs cscript: services-oids.slax(v0.14):[info] 1/30
Sleeping for 110 seconds.
9. Verify that you are getting Utility MIB OID updates.
router> show snmp mib walk jnxUtil ascii
. . .
jnxUtilCounter64Value."services10tcp-errors09CGN-SET-1"
jnxUtilCounter64Value."services10tcp-errors09CGN-SET-2"
jnxUtilCounter64Value."services10tcp-errors09CGN-SET-3"
jnxUtilCounter64Value."services10udp-errors09CGN-SET-1"
jnxUtilCounter64Value."services10udp-errors09CGN-SET-2"
. . .
=
=
=
=
=
0
0
0
1119
0
To exclude the timestamp information, use
router> show snmp mib walk jnxUtil ascii | match Value
See Also
•
Using the Enterprise-Specific Utility MIB on page 258
Stopping the SLAX Script with the CLI
To stop the SLAX script from the CLI:
•
Issue the stop argument.
user@host> op services-oids signal-stop 1
See Also
264
•
Populating the Enterprise-Specific Utility MIB with Information on page 259
•
Using the Enterprise-Specific Utility MIB on page 258
Copyright © 2018, Juniper Networks, Inc.
Chapter 19: Monitoring NAT
Clearing the Utility MIB
To clear all the utility MIB OIDs:
•
Issue the clean argument.
user@host> op services-oids clean 1
See Also
•
Populating the Enterprise-Specific Utility MIB with Information on page 259
•
Using the Enterprise-Specific Utility MIB on page 258
Recovering from an Abnormal SLAX Script Exit or a SLAX Script Exit with the CLI
To recover from an abnormal SLAX script exit or an SLAX script exit with the CLI:
•
Issue the clear semaphore argument.
user@host> op services-oids clear-semaphore 1
See Also
Related
Documentation
•
Populating the Enterprise-Specific Utility MIB with Information on page 259
•
Using the Enterprise-Specific Utility MIB on page 258
•
SLAX Overview
Copyright © 2018, Juniper Networks, Inc.
265
Adaptive Services Interfaces Feature Guide for Routing Devices
266
Copyright © 2018, Juniper Networks, Inc.
PART 3
Transitioning to IPv6 Using Softwires
•
Softwires Overview on page 269
•
Softwires Configuration Overview on page 275
•
Transitioning to IPv6 Using 6to4 Softwires on page 279
•
Transitioning to IPv6 Using DS-Lite Softwires on page 283
•
Transitioning to IPv6 Using 6rd Softwires on page 303
•
Monitoring and Troubleshooting Softwires on page 331
Copyright © 2018, Juniper Networks, Inc.
267
Adaptive Services Interfaces Feature Guide for Routing Devices
268
Copyright © 2018, Juniper Networks, Inc.
CHAPTER 20
Softwires Overview
•
Tunneling Services for IPv4-to-IPv6 Transition Overview on page 269
Tunneling Services for IPv4-to-IPv6 Transition Overview
Junos OS enables service providers to transition to IPv6 by using softwire encapsulation
and decapsulation techniques. A softwire is a tunnel that is created between softwire
customer premises equipment (CPE). A softwire CPE can share a unique common internal
state for multiple softwires, making it a very light and scalable solution. When you use
softwires, you need not maintain an interface infrastructure for each softwire, unlike a
typical mesh of generic routing encapsulation (GRE) tunnels that requires you to do so.
A softwire initiator at the customer end encapsulates native packets and tunnels them
to a softwire concentrator at the service provider. The softwire concentrator decapsulates
the packets and sends them to their destination. A softwire is created when a softwire
concentrator receives the first tunneled packet of a flow and prepares the packet for
flow processing. The softwire exists as long as the softwire concentrator is providing
flows for routing. A flow counter is maintained; when the number of active flows is 0, the
softwire is deleted. Statistics are kept for both flows and softwires.
Softwire addresses are not specifically configured under any physical or virtual interface.
The number of established softwires does not affect throughput, and scalability is
independent of the number of interfaces. Scalability is only limited to the number of
flows that the services DPC or PIC can support.
This topic contains the following sections:
•
6to4 Overview on page 269
•
DS-Lite Softwires—IPv4 over IPv6 on page 271
•
6rd Softwires—IPv6 over IPv4 on page 272
•
Basic 6to4 on page 270
•
6to4 Anycast on page 270
•
6to4 Provider-Managed Tunnels on page 271
6to4 Overview
Copyright © 2018, Juniper Networks, Inc.
269
Adaptive Services Interfaces Feature Guide for Routing Devices
Basic 6to4
6to4 is an Internet transition mechanism for migrating from IPv4 to IPv6, a system that
enables IPv6 packets to be transmitted over an IPv4 network (generally the IPv4 Internet)
without the need to configure explicit tunnels. 6to4 is described in RFC 3056, Connection
of IPv6 Domains via IPv4 Clouds. 6to4 is especially relevant during the initial phases of
deployment to full, native IPv6 connectivity, because IPv6 is not required on nodes
between the host and the destination. 6to4 is intended only as a transition mechanism
and is not meant to be used permanently.
6to4 is supported on Multiservices 100, 400, and 500 PICs on M Series routers and on
MX Series routers equipped with Multiservices DPCs. 6rd is not supported on MX Series
routers with MS-MPCs or MS-MICs.
6to4 can be used by an individual host or by a local IPv6 network. When used by a host,
6to4 must have a global IPv4 address connected, and the host is responsible for the
encapsulation of outgoing IPv6 packets and the decapsulation of incoming 6to4 packets.
If the host is configured to forward packets for other clients, often a local network, it is
then a router.
There are two kinds of 6to4 virtual routers: border routers and relay routers.
•
A 6to4 border router is an IPv6 router supporting a 6to4 pseudointerface, and is normally
the border router between an IPv6 site and a wide-area IPv4 network.
•
A relay router is a 6to4 router configured to support transit routing between 6to4
addresses and pure native IPv6 addresses.
In order for a 6to4 host to communicate with the native IPv6 Internet, the host’s IPv6
default gateway must be set to a 6to4 address that contains the IPv4 address of a 6to4
relay router. To avoid the need for users to set this up manually, the Anycast address of
192.88.99.1 has been allocated to send packets to a 6to4 relay router. When processed
by 6to4 with the subnet and hosts fields set to zero, this IPv4 address (192.88.99.1)
becomes the IPv6 address 2002:c058:6301::. To ensure BGP routing propagation, a short
prefix of 192.88.99.0/24 has been allocated for routes pointed at 6to4 relay routers that
use this Anycast IP address. We recommend that providers who want to provide 6to4
service to their clients or peers advertise the Anycast prefix like any other IP prefix, and
route the prefix to the provider’s 6to4 relay.
Packets from the IPv6 Internet to 6to4 systems must be sent to a 6to4 relay router by
normal IPv6 routing methods. The specification states that such relay routers must only
advertise 2002::/16 and not subdivisions of it to prevent the embedding of IPv4 routes
into the routing tables of IPv6 routers. From the 6to4 relay router the packets can then
be sent over the IPv4 Internet to the destination.
6to4 Anycast
Router 6to4 requires that 6to4 routers and relays are managed and configured
cooperatively. In particular, 6to4 sites must configure a relay router to carry the outbound
traffic, which becomes the default IPv6 router (except for 2002::/16). The objective of
the Anycast variant, defined in RFC 3068, An Anycast Prefix for 6to4 Relay Routers, is to
270
Copyright © 2018, Juniper Networks, Inc.
Chapter 20: Softwires Overview
avoid the need for such configuration. Removing this configuration makes the solution
available for small or domestic users, even those with a single host or simple home
gateway instead of a border router. Removing this configuration is achieved by defining
192.88.99.1 as the default IPv4 address for a 6to4 relay, and 2002:c058:6301:: as the
default IPv6 router prefix (well-known prefix) for a 6to4 site.
RFC 6343, Advisory Guidelines for 6to4 Deployment, published in August 2011, identifies
a wide range of problems associated with the use of unmanaged 6to4 Anycast relay
routers.
6to4 Provider-Managed Tunnels
A solution to many problems associated with unmanaged Anycast 6to4 is presented in
IETF informational draft draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-02, 6to
4 Provider-Managed Tunnels (PMT). That document, a work in progress, proposes a
solution that providers can implement to exercise greater control over the routing of 6to4
traffic.
Anycast 6to4 implies a default configuration for the user site. It does not require any
particular user action. It does require an IPv4 Anycast route to be in place to a relay at
192.88.99.1. Traffic does not necessarily return to the same 6to4 gateway because of
the well-known 6to4 prefix used and advertised by all 6to4 traffic.
6to4 provider-managed tunnels (PMTs) facilitate the management of 6to4 tunnels
using an Anycast configuration. 6to4 PMT enables service providers to improve 6to4
operation when network conditions provide suboptimal performance or break normal
6to4 operation. 6to4 PMT provides a stable provider prefix and forwarding environment
by utilizing existing 6to4 relays with an added function of IPv6 prefix translation that
controls the flow of return traffic.
The 6to4 managed tunnel model behaves like a standard 6to4 service between the
customer IPv6 host or gateway and the 6to4 PMT relay (within the provider domain).
The 6to4-PMT relay shares properties with 6rd (RFC5969) by decapsulating and
forwarding embedded IPv6 flows, within an IPv4 packet, to the IPv6 Internet. The model
provides an additional function that translates the source 6to4 prefix to a provider
assigned prefix that is not found in 6rd (RFC5969) or traditional 6to4 operation. The
6to4-PMT relay provides a stateless (or stateful) mapping of the 6to4 prefix to a
provider-supplied prefix by mapping the embedded IPv4 address in the 6to4 prefix to
the provider prefix.
DS-Lite Softwires—IPv4 over IPv6
When an ISP begins to allocate new subscriber home IPv6 addresses and IPv6-capable
equipment, dual-stack lite (DS-Lite) provides a method for the private IPv4 addresses
behind the IPv6 customer edge WAN equipment to reach the IPv4 network. DS-Lite
enables IPv4 customers to continue to access the Internet using their current hardware
by using a softwire initiator, referred to as a Basic Bridging Broadband (B4), at the
customer edge to encapsulate IPv4 packets into IPv6 packets and tunnel them over an
IPv6 network to a softwire concentrator, referred to as an Address Family Transition
Router (AFTR), for decapsulation. DS-Lite creates the IPv6 softwires that terminate on
Copyright © 2018, Juniper Networks, Inc.
271
Adaptive Services Interfaces Feature Guide for Routing Devices
the services PIC. Packets coming out of the softwire can then have other services such
as NAT applied on them.
DS-Lite is supported on MS-DPCs and MS-100, MS-400, and MS-500 MultiServices
PICS. Starting in Junos OS release 17.4R1, DS-Lite is supported on MX Series routers with
MS-MPCs and MS-MICs.
NOTE: IPv6 Provider Edge , or MPLS-enabled IPv6, is available for ISPs with
MPLS-enabled networks. These networks now can use Multiprotocol BGP
(MP-BGP) to provide connectivity between the DS-Lite B4 and AFTR (or any
two IPv6 nodes). DS-Lite properly handles encapsulation and decapsulation
despite the presence of additional MPLS header information.
For more information on DS-Lite softwires, see the IETF draft Dual Stack Lite Broadband
Deployments Following IPv4 Exhaustion.
NOTE: The most recent IETF draft documentation for DS-Lite uses new
terminology:
•
The term softwire initiator has been replaced by B4.
•
The term softwire concentrator has been replaced by AFTR.
The Junos OS documentation generally uses the original terms when
discussing configuration in order to be consistent with the command-line
interface (CLI) statements used to configure DS-Lite.
6rd Softwires—IPv6 over IPv4
6rd softwire flow is shown in Figure 21 on page 272.
Figure 21: 6rd Softwire Flow
IPv4 6rd
IPv6 end user
6rd
IPv4 in IPv6 tunnel Concentrator
IPv6
Destination host
g017573
Local host
Junos OS supports a 6rd softwire concentrator on a services DPC or PIC to facilitate rapid
deployment of IPv6 service to subscribers on native IPv4 customer edge WANs. IPv6
packets are encapsulated in IPv4 packets by a softwire initiator at the customer edge
WAN. These packets are tunneled to a softwire concentrator residing on an MS-DPC
(branch relay). A softwire is created when IPv4 packets containing IPv6 destination
information are received at the softwire concentrator, which decapsulates IPv6 packets
and forwards them for IPv6 routing. All of these functions are performed in a single pass
of the services PIC.
272
Copyright © 2018, Juniper Networks, Inc.
Chapter 20: Softwires Overview
In the reverse path, IPv6 packets are sent to the services DPC where they are encapsulated
in IPv4 packets corresponding to the proper softwire and sent to the customer edge
WAN.
The softwire concentrator creates softwires as the IPv4 packets are received from the
customer edge WAN side or IPv6 packets are received from the Internet. A 6rd softwire
on the Services DPC is identified by the 3-tuple containing the service set ID, customer
edge softwire initiator IPv4 address, and softwire concentrator IPv4 address. IPv6 flows
are also created for the encapsulated IPv6 payload, and are associated with the specific
softwire that carried them in the first place. When the last IPv6 flow associated with a
softwire ends, the softwire is deleted. This simplifies configuration and there is no need
to create or manage tunnel interfaces.
6rd is supported on Multiservices 100, 400, and 500 PICs on M Series routers, and on
MX Series routers equipped with Multiservices DPCs. 6rd is not supported on MX Series
routers with MS-MPCs or MS-MICs.
Junos OS supports inline 6rd and 6to4 on Modular Port Concentrator (MPC) line cards.
For more information on 6rd softwires, see RFC 5969, IPv6 Rapid Deployment on IPv4
Infrastructures (6rd) -- Protocol Specification.
Release History Table
Related
Documentation
Release
Description
17.4R1
Starting in Junos OS release 17.4R1, DS-Lite is supported on MX Series
routers with MS-MPCs and MS-MICs.
•
Junos Address Aware Network Addressing Overview on page 45
•
Configuring a 6rd Softwire Concentrator on page 303
•
Configuring a DS-Lite Softwire Concentrator on page 283
•
Configuring Softwire Rules on page 275
•
Configuring Service Sets for Softwire on page 276
•
Configuring Inline 6rd on page 317
Copyright © 2018, Juniper Networks, Inc.
273
Adaptive Services Interfaces Feature Guide for Routing Devices
274
Copyright © 2018, Juniper Networks, Inc.
CHAPTER 21
Softwires Configuration Overview
•
Configuring Softwire Rules on page 275
•
Configuring Service Sets for Softwire on page 276
Configuring Softwire Rules
You configure softwire rules to instruct the router how to direct traffic to the addresses
specified for 6rd or DS-Lite softwire concentrators. Softwire rules do not perform any
filtration of the traffic. They do not include a from statement, and the only option in the
then statement is to specify the address of the 6rd or DS-Lite softwire concentrator.
Softwire rules are supported on Multiservices 100, 400, and 500 PICs on M Series routers,
and on MX Series routers equipped with Multiservices DPCs. Starting in Junos OS release
17.4R1, softwire rules for DS-Lite are supported on MX Series routers with MS-MPCs and
MS-MICs.
You can create a softwire rule consisting of one or more terms and associate a particular
6rd or DS-Lite softwire concentrator with each term. You can include the softwire rule
in service sets along with other services rules.
To configure a softwire rule:
1.
Assign a name to the rule.
[edit services softwire ]
user@host# edit rule rule-name
2. Specify the match direction.
[edit services softwire rule rule-name]
user@host# set match-direction (input | output)
3. Assign a name for the first term.
[edit services softwire rule rule-name]
user@host# edit term term-name
4. Associate a 6rd or DS-Lite softwire concentrator with this term.
[edit services softwire rule rule-name term term-name]
Copyright © 2018, Juniper Networks, Inc.
275
Adaptive Services Interfaces Feature Guide for Routing Devices
user@host# set then ds-lite name
Or
user@host# set then v6rd v6rd-softwire-concentator
5. Repeat Steps 3 and 4 for as many additional terms as needed.
Release History Table
Related
Documentation
Release
Description
17.4R1
Starting in Junos OS release 17.4R1, softwire rules for DS-Lite are supported
on MX Series routers with MS-MPCs and MS-MICs.
•
Tunneling Services for IPv4-to-IPv6 Transition Overview on page 269
•
Configuring a 6rd Softwire Concentrator on page 303
•
Configuring a DS-Lite Softwire Concentrator on page 283
•
Configuring IPv6 Multicast Interfaces on page 284
•
Configuring Service Sets for Softwire on page 276
Configuring Service Sets for Softwire
You must include softwire rules or a softwire rule set in a service set to enable softwire
processing. You must include a stateful firewall rule for DS-Lite.
Softwire rules are supported on Multiservices 100, 400, and 500 PICs on M Series routers,
and on MX Series routers equipped with Multiservices DPCs. Starting in Junos OS release
17.4R1, softwire rules for DS-Lite are supported on MX Series routers with MS-MPCs and
MS-MICs.
To configure service sets for softwire:
1.
Include a softwire rule or rule set in the service set.
[edit services service-set service-set-name]
user@host# set softwire-rules rule softwire-rule-name
2. When using a 6rd softwire, include a stateful-firewall rule.
[edit services service-set service-set-name]
user@host# set stateful-firewall-rules softwire-rule-name
3. You can include a NAT rule for flows originated by DS-Lite softwires.
276
Copyright © 2018, Juniper Networks, Inc.
Chapter 21: Softwires Configuration Overview
NOTE:
Currently a NAT rule configuration is required with a DS-Lite softwire
configuration when you use interface service set configurations; NAT is
not required when using next-hop service set configurations. NAT
processing from IPv4 to IPv6 address pools and vice versa is not currently
supported. FTP, HTTP, and RSTP are supported.
NOTE: With a DS-Lite softwire concentrator, if you configure stateful
firewall rules without configuring NAT rules, using an interface service set
causes the ICMP echo reply messages to be not sent correctly to DS-Lite.
This behavior occurs if you apply a service set to both inet and inet6
families. In such a scenario, the traffic that is not destined to the DS-Lite
softwire concentrator is also processed by the service set and the packets
might be dropped, although the service set must not process such packets.
To prevent the problem to incorrect processing of traffic applicable for
DS-Lite, you must configure a next-hop style service set and not an
interface style service set. This problem does not occur when you configure
NAT rules with interface service sets for DS-Lite.
For further information, see ““Configuring Service Rules” on page 14.”
Release History Table
Related
Documentation
Release
Description
17.4R1
Starting in Junos OS release 17.4R1, softwire rules for DS-Lite are supported
on MX Series routers with MS-MPCs and MS-MICs.
•
Tunneling Services for IPv4-to-IPv6 Transition Overview on page 269
•
Configuring Softwire Rules on page 275
•
Example: Configuring DS-Lite and 6rd in the Same Service Set on page 291
Copyright © 2018, Juniper Networks, Inc.
277
Adaptive Services Interfaces Feature Guide for Routing Devices
278
Copyright © 2018, Juniper Networks, Inc.
CHAPTER 22
Transitioning to IPv6 Using 6to4 Softwires
•
Configuring a 6to4 Provider-Managed Tunnel on page 279
Configuring a 6to4 Provider-Managed Tunnel
When configuring a 6to4 provider-managed tunnel (PMT), replace the Anycast destination
with the address of a managed relay in the provider network.
6to4 tunnels are supported on Multiservices 100, 400, and 500 PICs on M Series routers,
and on MX Series routers equipped with Multiservices DPCs. 6to4 tunnels are not
supported on MX Series routers with MS-MPCs or MS-MICs.
To configure a 6to4 PMT:
1.
Configure the ingress interface for 6to4 traffic. Include the name of the service set
that identifies the rules for input and output service on this interface.
[edit interfaces ge-0/2/1]
user@host# set unit logical-unit-number family family service input service-set-name
user@host# set unit logical-unit-number family family service output service-set-name
user@host# set unit logical-unit-number family family address addres
For example:
[edit interfaces ge-0/2/1]
user@host# set unit 0 family inet service input service-set v6to4-pmt
user@host# set unit 0 family inet service output service-set v6to4-pmt
user@host# set unit 0 family inet address 130.130.130.1/24
2. Configure the egress interface.
[edit interfaces ge-0/2/2]
user@host# set unit logical-unit-number family family address address
For example:
[edit interfaces ge-0/2/2]
user@host# set unit 0 family inet6 address 4ABC::1/16
3. Configure the service interface that contains the rules for processing incoming traffic.
Include a syslog option and associate a logical unit.
[edit interfaces sp-2/0/0]
Copyright © 2018, Juniper Networks, Inc.
279
Adaptive Services Interfaces Feature Guide for Routing Devices
user@host# edit services-options syslog host host-name services any
user@host# edit unit logical-unit-number family family
user@host# edit unit 0 family family
For example:
[edit interfaces sp-2/0/0]
user@host# set services-options syslog host local services any
user@host# set unit 0 family inet
user@host# set unit 0 family inet6
4. Configure the softwire concentrator and softwire rule for 6to4. In the Junos OS, 6to4
PMT configuration uses the same options as 6rd.
[edit services softwire softwire-concentrator v6rd v6to4]
user@host# set softwire-address softwire-addres
user@host# set ipv4-prefix ipv4-prefix
user@host# set v6rd-prefix v6rd-prefix
user@host# set mtu-v4 mtu-v4
For example:
[edit services softwire softwire-concentrator v6rd v6to4]
user@host# set softwire-address 192.88.99.1
user@host# set ipv4-prefix 130.130.130.2/32
user@host# set v6rd-prefix 2002::0/16
user@host# set mtu-v4 9192
5. Define the softwire rule that will process traffic on the ingress interface.
[edit services softwire rule v6to4-r1]
user@host# set match-direction input
user@host# set term term-name then v6rd softwire-concentrator
For example:
[edit services softwire rule v6to4-r1]
user@host# set match-direction input
user@host# set term t1 then v6rd v6to4
6. Define a stateful firewall rule that will accept all incoming traffic on the ingress
interface.
[edit services stateful-firewall rule sfw-r1]
user@host# set match-direction direction
user@host# set term term-name then accept
user@host# set term term-name then syslog
For example:
[edit services stateful-firewall rule sfw-r1]
user@host# set match-direction input-output
user@host# set term t1 then accept
user@host# set term t1 then syslog
7. Define the NAT pool to be used for IPv6 NAT translation. This pool supports translation
of the Anycast 6to4 relay addresses to addresses at the provider-managed relay.
280
Copyright © 2018, Juniper Networks, Inc.
Chapter 22: Transitioning to IPv6 Using 6to4 Softwires
[edit services nat pool v6to4-pmt]
user@host# set address address
user@host# port automatic
For example:
[edit services nat pool v6to4-pmt]
user@host# set address 3ABC::1/128
user@host# set port automatic
8. Define the NAT rule for translation.
[edit services nat rule rule-name]
user@host# set match-direction input
user@host# set term term-name then translated source-pool pool-name
user@host# set term t1 then translated translation-type translation-type
For example:
[edit services nat rule v6to4-pmt-r1]
user@host# set match-direction input
user@host# set term t1 then translated source-pool v6to4-pmt
user@host# set term t1 then translated translation-type napt-66
9. Define the service set that specifies the softwire rule and NAT rule.
[edit services service-set v6to4-pmt]
user@host# set softwire-rules rule-name
user@host# set stateful-firewall-rules rule-name
user@host# set nat-rules rule-name
user@host# set interface-service service-interface interface-name
For example:
[edit services service-set v6to4-pmt]
user@host# set softwire-rules v6to4-r1
user@host# set stateful-firewall-rules sfw-r1
user@host# set nat-rules v6to4-pmt-r1
user@host# set interface-service service-interface sp-2/0/0
Copyright © 2018, Juniper Networks, Inc.
281
Adaptive Services Interfaces Feature Guide for Routing Devices
282
Copyright © 2018, Juniper Networks, Inc.
CHAPTER 23
Transitioning to IPv6 Using DS-Lite
Softwires
•
Configuring a DS-Lite Softwire Concentrator on page 283
•
Configuring IPv6 Multicast Interfaces on page 284
•
Example: Basic DS-Lite Configuration on page 285
•
Example: Configuring DS-Lite and 6rd in the Same Service Set on page 291
•
Protecting CGN Devices Against Denial of Service (DOS) Attacks on page 299
•
DS-Lite Subnet Limitation on page 299
Configuring a DS-Lite Softwire Concentrator
DS-Lite is supported on Multiservices 100, 400, and 500 PICs on M Series routers, and
on MX Series routers equipped with Multiservices DPCs. Starting in Junos OS release
17.4R1, DS-Lite is supported on MX Series routers with MS-MPCs and MS-MICs.
To configure a DS-Lite softwire concentrator:
1.
Assign a name to the DS-Lite softwire concentrator.
[edit services softwire softwire-concentrator]
user@host# edit ds-lite ds-lite-softwire-concentrator
2. Specify the address of the softwire tunnel.
[edit services softwire softwire-concentrator ds-lite ds-lite-softwire-concentrator]
user@host# set softwire-address address
3. Specify the MTU for the softwire tunnel.
[edit services softwire softwire-concentrator ds-lite ds-lite-softwire-concentrator]
user@host# set mtu-v6 bytes
Copyright © 2018, Juniper Networks, Inc.
283
Adaptive Services Interfaces Feature Guide for Routing Devices
NOTE: The mtu-v6 option is supported on MX Series routers equipped
with MS-DPCs. Starting in Junos OS release 18.1R1, the mtu-v6 option is
supported on MX Series routers with MS-MPCs or MS-MICs.
This option sets the maximum transmission unit when encapsulating IPv4
packets into IPv6. If the final length is greater than the MTU, the IPv6
packet will be fragmented. This option is mandatory since it depends on
other network parameters under administrator control.
4. To copy DSCP information from the IPv6 header into the decapsulated IPv4 header,
include the copy-dscp statement. This statement is not supported on MS-MPCs and
MS-MICs.
[edit services softwire softwire-concentrator ds-lite ds-lite-softwire-concentrator]
user@host# set copy-dscp
5. Specify the maximum number of flows for the softwire.
[edit services softwire softwire-concentrator ds-lite ds-lite-softwire-concentrator]
user@host# set flow-limit 1000
Release History Table
Related
Documentation
Release
Description
18.1R1
Starting in Junos OS release 18.1R1, the mtu-v6 option is supported on MX
Series routers with MS-MPCs or MS-MICs.
17.4R1
Starting in Junos OS release 17.4R1, DS-Lite is supported on MX Series
routers with MS-MPCs and MS-MICs.
•
Tunneling Services for IPv4-to-IPv6 Transition Overview on page 269
•
Configuring Softwire Rules on page 275
•
Configuring IPv6 Multicast Interfaces on page 284
•
Configuring Service Sets for Softwire on page 276
•
Example: Basic DS-Lite Configuration on page 285
•
Example: Configuring DS-Lite and 6rd in the Same Service Set on page 291
Configuring IPv6 Multicast Interfaces
Configure multicast filters on Ethernet interfaces when IPv6 NAT is used for neighbor
discovery. This enables the router to process softwire-initiated flows in both directions.
To configure IPv6 multicast interfaces:
1.
284
Access the softwire hierarchy.
Copyright © 2018, Juniper Networks, Inc.
Chapter 23: Transitioning to IPv6 Using DS-Lite Softwires
user@host# edit services softwire
2. Include the ipv6-multicast-interfaces statement for an individual interface.
[edit services softwire]
user@host# set ipv6-multicast-interfaces interface-name
Or configure all softwire interfaces as IPv6 multicast.
[edit services softwire]
user@host# set ipv6-multicast-interfaces all
Related
Documentation
•
Tunneling Services for IPv4-to-IPv6 Transition Overview on page 269
•
Configuring a 6rd Softwire Concentrator on page 303
•
Configuring a DS-Lite Softwire Concentrator on page 283
•
Configuring Softwire Rules on page 275
Example: Basic DS-Lite Configuration
•
Requirements on page 285
•
Configuration Overview and Topology on page 285
•
Configuration on page 286
Requirements
The following hardware components can perform DS-Lite:
•
M Series Multiservice Edge routers with Multiservices PICs.
•
T Series Core routers with Multiservices PICs.
•
MX Series 3D Universal Edge routers with Multiservices DPCs. Starting in Junos OS
release 17.4R1, DS-Lite is supported on MX Series routers with MS-MPCs and MS-MICs.
Configuration Overview and Topology
This example describes how configure an MX Series router with an MS-DPC as an AFTR
to facilitate the flow shown in Figure 22 on page 286.
Copyright © 2018, Juniper Networks, Inc.
285
Adaptive Services Interfaces Feature Guide for Routing Devices
Figure 22: DS-Lite Topology
Host
Home
router
IPv4 Host
10.0.0.1
10.0.0.2
B4
2001:0:0:1::1
IPv4-in IPv-6 softwire
2001:0:0:2::1
AFTR
129.0.0.1
128.0.0.1
NAT
Internet
g040626
concentrator
ISP IPv6
cloud network
In this example, the DS-Lite softwire concentrator, or AFTR, is an MX Series router with
two Gigabit interfaces and a Services DPC. The interface facing the B4 element is ge-3/1/5
and the interface facing the Internet is ge-3/1/0.
Configuration
•
Chassis Configuration on page 286
•
Interfaces Configuration on page 286
•
Network Address and Port Translation Configuration on page 288
•
Softwire Configuration on page 289
•
Service Set Configuration on page 290
Chassis Configuration
Step-by-Step
Procedure
To configure the service PIC (FPC 0 Slot 0) with the Layer 3 service package:
1.
Enter the edit chassis hierarchy level.
user@host# edit chassis
2.
Configure the Layer 3 service package.
[edit chassis]
user@host# set fpc 0 pic 0 adaptive-services service-package layer-3
Interfaces Configuration
Step-by-Step
Procedure
To configure interfaces facing the B4 (softwire initiator) and facing the Internet:
1.
286
Go the [edit interfaces] edit hierachy level for ge-3/1/0, which faces the Internet.
Copyright © 2018, Juniper Networks, Inc.
Chapter 23: Transitioning to IPv6 Using DS-Lite Softwires
host# edit interfaces ge-3/1/0
2.
Define the interface.
[edit interfaces ge-3/1/0]
user@host# set description AFTR-Internet
user@host# set unit 0 family inet address 128.0.0.2/24
3.
Go to the [edit interfaces] hierachy level for ge-3/1/5, which faces the B4.
user@host# up 1
[edit]
user@host# edit interfaces ge-3/1/5
4.
Define the interface.
[edit interfaces ge-3/1/5]
user@host# set description AFTR-B4
user@host# set unit 0 family inet
user@host# edit unit 0 family inet6
[edit unit 0 family inet6]
user@host# set service input service-set sset
user@host# set service output service-set sset
user@host# set address 2001:0:0:2::1/48
5.
Go to the [edit interfaces] hierarchy level for sp-0/0/0, used to host the DS-Lite
AFTR.
[edit]
user@host# edit interfaces sp-0/0/0
6.
Define the interface.
[edit interfaces sp-0/0/0]
user@host# set description AFTR-B4
user@host# set unit 0 family inet
user@host# edit unit 0 family inet6
Copyright © 2018, Juniper Networks, Inc.
287
Adaptive Services Interfaces Feature Guide for Routing Devices
Results
user@host# show interfaces ge-3/1/0
description AFTR-Internet;
unit 0 {
family inet {
address 128.0.0.2/24;
}
}
user@host# show interfaces ge-3/1/5
description AFTR-B4;
unit 0 {
family inet;
family inet6 {
service {
input {
service-set sset;
}
output {
service-set sset;
}
}
address 2001:0:0:2::1/48;
}
}
user@host# show interfaces sp-o/o/o
unit 0 {
family inet;
family inet6;
}
Network Address and Port Translation Configuration
Step-by-Step
Procedure
To configure NAPT:
1.
Go to the [edit services nat] hierarchy level.
user@host# edit services nat
[edit services nat]
2.
Define a NAT pool p1.
user@host# set pool p1 address 129.0.0.1/32 port automatic
3.
Define a NAT rule, beginning with the match direction.
[edit services nat]
user@host# set rule r1 match-direction input
4.
Define a term for the rule, beginning with a from clause.
[edit services nat]
user@host# set rule r1 term t1 from source-address 10.0.0.0/16
288
Copyright © 2018, Juniper Networks, Inc.
Chapter 23: Transitioning to IPv6 Using DS-Lite Softwires
5.
Define the desired translation in a then clause. In this case, use dynamic source
translation.
[edit services nat]
user@host# set rule r1 term t1 then translated source-pool p1 translation-type
napt-44
6.
(Optional) Configure logging of translation information for the rule.
[edit services nat]
user@host# set rule r1 term t1 then syslog
Results
user@host# show services nat
pool p1 {
address 129.0.0.1/32;
port {
automatic;
}
}
rule r1 {
match-direction input;
term t1 {
from {
source-address {
10.0.0.0/16;
}
}
then {
translated {
source-pool p1;
translation-type {
napt-44;
}
}
syslog;
}
}
Softwire Configuration
Step-by-Step
Procedure
To configure the DS-Lite softwire concentrator and associated rules:
1.
Go to the [edit services softwire] hierarchy level.
user@host# edit services softwire
2.
Define the DS-Lite softwire concentrator.
[edit services softwire]
user@host# set softwire-concentrator ds-lite ds-1 softwire-address 1001::1 mtu-v6
1460
3.
Define the softwire rule.
Copyright © 2018, Juniper Networks, Inc.
289
Adaptive Services Interfaces Feature Guide for Routing Devices
[edit services softwire]
user@host# set rule r1 match-direction input term t1 then ds-lite ds1.
Results
user@host# show services softwire
softwire-concentrator {
ds-lite ds1 {
softwire-address 1001::1;
mtu-v6 1460;
}
}
rule r1 {
match-direction input;
term t1 {
then {
ds-lite ds1;
}
}
}
Service Set Configuration
Step-by-Step
Procedure
Configure a service set that includes softwire and NAT rules and specifies either
interface-service or next-hop service. This example uses a next-hop service.
1.
Go to the [edit services service-set] hierarchy level, naming the service set.
user@host# edit services service-set sset
2.
Define the NAT rule to be used for IPv4-to-IPv4 translation.
[edit services service-set sset]
user@host# set nat-rules r1
3.
Define the softwire rule to define the softwire tunnel.
[edit services service-set sset]
user@host# set softwire-rules r1
4.
Define the interface service,
[edit services service-set sset]
user@host# set interface-service service-interface sp-0/0/0.0
TIP: In order to avoid or minimize IPv6 fragmentation, you can configure
a TCP maximum segment size (MSS) for your service set.
5.
(Optional) Define a TCP MSS.
[edit services service-set sset]
290
Copyright © 2018, Juniper Networks, Inc.
Chapter 23: Transitioning to IPv6 Using DS-Lite Softwires
user@host# set tcp-mss 1024
Results
user@host# show services service-set
syslog {
host local {
services any;
}
}
softwire-rules r1;
nat-rules r1;
interface-service {
service-interface sp-0/0/0;
}
}
Release History Table
Related
Documentation
Release
Description
17.4R1
Starting in Junos OS release 17.4R1, DS-Lite is supported on MX Series
routers with MS-MPCs and MS-MICs.
•
Tunneling Services for IPv4-to-IPv6 Transition Overview on page 269
•
Configuring a DS-Lite Softwire Concentrator on page 283
•
Configuring Softwire Rules on page 275
•
Configuring Service Sets for Softwire on page 276
•
Example: Basic 6rd Configuration on page 305
•
Example: Configuring DS-Lite and 6rd in the Same Service Set on page 291
Example: Configuring DS-Lite and 6rd in the Same Service Set
•
Requirements on page 291
•
Overview on page 292
•
Configuration on page 292
Requirements
The following hardware components can perform DS-Lite:
•
M Series Multiservice Edge routers with Multiservices PICs.
•
T Series Core routers with Multiservices PICs.
•
MX Series 3D Universal Edge routers with Multiservices DPCs. Starting in Junos OS
release 17.4R1, DS-Lite is supported on MX Series routers with MS-MPCs and MS-MICs.
Copyright © 2018, Juniper Networks, Inc.
291
Adaptive Services Interfaces Feature Guide for Routing Devices
Overview
This example describes a softwire solution that includes DS-Lite and 6rd in the same
service set.
Configuration
Chassis Configuration
Step-by-Step
Procedure
To configure the chassis:
1.
Configure the ingress interface.
user@host# edit interfaces ge-1/2/0
[edit interfaces ge-1/2/0]
user@host# set unit 0 family inet service input service-set v6rd-dslite-service-set
user@host# set unit 0 family inet service output service-set v6rd-dslite-service-set
user@host# set unit 0 family inet address address 10.10.10.1/24
user@host# set unit 0 family inet6 service input service-set v6rd-dslite-service-set
user@host# set unit 0 family inet6 service output service-set v6rd-dslite-service-set
user@host# set unit 0 family inet6 address address address 2001::1/16
Here the service set is applied on the inet (IPv4) and inet6 (IPv6) families of subunit
0. Both DS-Lite IPv6 traffic and 6rd IPv4 traffic hits the service filter and is sent to
the services PIC.
2.
Configure the egress interface (IPv6 Internet). The IPv4 server that the DS-Lite
clients are trying to reach is at 200.200.200.2/24, and the IPv6 server is at
3ABC::2/16.
user@host# edit interfaces ge-1/2/2
[edit interfaces ge-1/2/2]
user@host# set unit 0 family inet address 200.200.200.1/24
user@host# set unit 0 family inet6 address 3ABC::1/16
3.
Configure the services PIC.
user@host# edit interfaces sp-3/0/0
[edit interfaces sp-3/0/0]
user@host# set unit 0 family inet
user@host# set unit 0 family inet6
292
Copyright © 2018, Juniper Networks, Inc.
Chapter 23: Transitioning to IPv6 Using DS-Lite Softwires
Results
[edit interfaces]
user@host# show
ge-1/2/0 {
unit 0 {
family inet {
service {
input {
service-set v6rd-dslite-service-set;
}
output {
service-set v6rd-dslite-service-set;
}
}
address 10.10.10.1/24;
}
family inet6 {
service {
input {
service-set v6rd-dslite-service-set;
}
output {
service-set v6rd-dslite-service-set;
}
}
address 2001::1/16;
}
}
}
ge-1/2/2 {
unit 0 {
family inet {
address 200.200.200.1/24;
}
family inet6 {
address 3ABC::1/16;
}
}
}
sp-3/0/0 {
unit 0 {
family inet;
family inet6;
}
}
Softwire Concentrator, Softwire Rule, Stateful Firewall Rule Configuration
Step-by-Step
Procedure
To configure the softwire concentrator, softwire rule, and stateful firewall rule:
1.
Configure the DS-Lite and 6rd softwire concentrators.
user@host# edit services softwire softwire-concentrator ds-lite ds1
[edit services softwire softwire-concentrator ds-lite ds1]
user@host# set softwire-address 1001::1
user@host# mtu-v6 9192
usert@host# up 1
usert@host# edit v6rd v6rd-dom1
[edit services softwire softwire-concentrator v6rd v6rd-dom1]
Copyright © 2018, Juniper Networks, Inc.
293
Adaptive Services Interfaces Feature Guide for Routing Devices
user@host# set softwire-address 30.30.30.1
user@host# set ipv4-prefix 10.10.10.0/24
user@host# set v6rd-prefix 3040::0/16
user@host# set mtu-v4 9192
2.
Configure the softwire rules.
user@host# edit services softwire rule v6rd-r1]
[edit services softwire rule v6rd-r1]
user@host# set match-direction input
user@host# set term t1 then v6rd v6rd-dom1
user@host# up 1
user@host# edit services softwire]
[edit services softwire]
user@host# edit rule dslite-r1
[edit services softwire rule dslite-r1]
user@host# set term dslite-t1 then ds-lite ds1
The following routes are added by the services PIC daemon on the Routing Engine:
user@host# run show route 30.30.30.1
inet.0: 43 destinations, 46 routes (42 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both
30.30.30.1/32
*[Static/786432] 00:24:11
Service to v6rd-dslite-service-set
[edit]
user@host# run show route 3040::0/16
inet6.0: 23 destinations, 33 routes (23 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
3040::/16
*[Static/786432] 00:24:39
Service to v6rd-dslite-service-set
user@host# run show route 1001::1
inet6.0: 33 destinations, 43 routes (33 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
1001::1/128
3.
*[Static/1] 1w2d 22:05:41
Service to v6rd-dslite-service-set
Configure a stateful firewall rule.
user@host# edit services stateful-firewall rule r1
[edit services stateful-firewall rule r1]
user@host# set match-direction input-output
user@host# set term t1 then accept
[edit services stateful-firewall]
rule r1 {
match-direction input-output;
term t1 {
then {
accept;
}
}
294
Copyright © 2018, Juniper Networks, Inc.
Chapter 23: Transitioning to IPv6 Using DS-Lite Softwires
}
Results
[edit services softwire]
user@host# show
softwire-concentrator {
ds-lite ds1 {
softwire-address 1001::1;
mtu-v6 9192;
}
v6rd v6rd-dom1 {
softwire-address 30.30.30.1;
ipv4-prefix 10.10.10.0/24;
v6rd-prefix 3040::0/16;
mtu-v4 9192;
}
}
rule v6rd-r1 {
match-direction input;
term t1 {
then {
v6rd v6rd-dom1;
}
}
}
rule dslite-r1 {
match-direction input;
term dslite-t1 {
then {
ds-lite ds1;
}
}
}
[edit services stateful-firewall]
user@host# show
rule r1 {
match-direction input-output;
term t1 {
then {
accept;
}
}
}
NAT Configuration for DS-Lite
Step-by-Step
Procedure
To configure NAT for DS-Lite:
1.
Configure a NAT pool for DS-Lite.
user@host# edit services nat pool dslite-pool
[edit services nat pool dslite-pool]
user@host# set address-range low 33.33.33.1 high 33.33.33.32
user@host# set port automatic
Copyright © 2018, Juniper Networks, Inc.
295
Adaptive Services Interfaces Feature Guide for Routing Devices
2.
Configure a NAT rule.
user@host# up 1
[edit services nat rule dslite-nat-r1]
user@host# set match-direction input
user@host# set term dslite-nat-t1 from source-address 20.20.0.0/16 then translated
translation-type napt-44
296
Copyright © 2018, Juniper Networks, Inc.
Chapter 23: Transitioning to IPv6 Using DS-Lite Softwires
Results
[edit services nat]
user@host# show
pool dslite-pool {
address-range low 33.33.33.1 high 33.33.33.32;
port {
automatic;
}
}
rule dslite-nat-r1 {
match-direction input;
term dslite-nat-t1 {
from {
source-address {
20.20.0.0/16;
}
}
then {
translated {
source-pool dslite-pool;
translation-type {
source dynamic;
}
}
}
}
}
Because of this NAT rule, the following NAT routes are installed for the reverse DS-Lite
traffic:
user@host# run show route 33.33.33.0/24
inet.0: 48 destinations, 52 routes (47 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both
33.33.33.1/32
33.33.33.2/31
33.33.33.4/30
33.33.33.8/29
33.33.33.16/28
33.33.33.32/32
*[Static/1] 1w2d 23:08:38
Service to v6rd-dslite-service-set
*[Static/1] 1w2d 23:08:38
Service to v6rd-dslite-service-set
*[Static/1] 1w2d 23:08:38
Service to v6rd-dslite-service-set
*[Static/1] 1w2d 23:08:38
Service to v6rd-dslite-service-set
*[Static/1] 1w2d 23:08:38
Service to v6rd-dslite-service-set
*[Static/1] 1w2d 23:08:38
Service to v6rd-dslite-service-set
The NAT rule triggers address translation for the traffic coming from 20.20.0.0/16 to
public address range 33.33.33.1 to 33.33.33.32.
Service Set Configuration
Step-by-Step
Procedure
Copyright © 2018, Juniper Networks, Inc.
297
Adaptive Services Interfaces Feature Guide for Routing Devices
This service set has a stateful firewall rule and 6rd rule for 6rd service. The service set
also includes a softwire rule for DS-Lite and a NAT rule to perform address translation
for all DS-Lite traffic. The NAT rule performs NAPT translation in the forward direction
on the source address and port of the DS-Lite traffic.
To configure the service set:
Define the service set.
1.
user@host# edit services service-set v6rd-dslite-service-set
2.
Configure the service set rules.
[edit services service-set v6rd-dslite-service-set]
user@host# set softwire-rules dslite-r1
user@host# set stateful-firewall-rules r1
user@host# set nat-rules dslite-nat-r1
3.
Configure the service set interface-service.
[edit services service-set v6rd-dslite-service-set]
user@host# set interface-service service-interface sp-3/0/0
Results
[edit services service-set]
user@host# show
v6rd-dslite-service-set {
softwire-rules v6rd-r1;
softwire-rules dslite-r1;
stateful-firewall-rules r1;
nat-rules dslite-nat-r1;
interface-service {
service-interface sp-3/0/0;
}
Release History Table
Related
Documentation
298
Release
Description
17.4R1
Starting in Junos OS release 17.4R1, DS-Lite is supported on MX Series
routers with MS-MPCs and MS-MICs.
•
Tunneling Services for IPv4-to-IPv6 Transition Overview on page 269
•
Configuring Service Sets for Softwire on page 276
•
Example: Basic DS-Lite Configuration on page 285
•
Example: Basic 6rd Configuration on page 305
Copyright © 2018, Juniper Networks, Inc.
Chapter 23: Transitioning to IPv6 Using DS-Lite Softwires
Protecting CGN Devices Against Denial of Service (DOS) Attacks
You can now choose configuration options that help prevent or minimize the effect of
attempted denial of service (DOS) attacks.
•
Mapping Refresh Behavior on page 299
•
EIF Inbound Flow Limit on page 299
Mapping Refresh Behavior
Prior to the implementation of the new options for configuring NAT mapping refresh
behavior, described in this topic, a conversation was kept alive when either inbound or
outbound flows were active. This remains the default behavior. You can now also specify
mapping refresh for only inbound flows or only outbound flows. To configure mapping
refresh behavior, include the mapping-refresh (inbound | outbound | inbound-outbound)
statement at the [edit services nat rule rule-name term term-name then translated
secure-nat-mapping] hierearchy level.
EIF Inbound Flow Limit
Previously. the number of inbound connections on an EIF mapping was limited only by
the maximum flows allowed on the system. You can now configure the number of inbound
flows allowed for an EIF. To limit the number of inbound connections on an EIF mapping,
include the eif-flow-limit number-of-flows statement at the [edit services nat rule rule-name
term term-name then translated secure-nat-mapping] hierarchy level.
DS-Lite Subnet Limitation
•
DS-Lite Per Subnet Limitation Overview on page 299
•
Configuring DS-Lite Per Subnet Session Limitation to Prevent Denial of Service
Attacks on page 300
DS-Lite Per Subnet Limitation Overview
Junos OS enables you to limit the number of softwire flows from a subscriber’s basic
bridging broadband (B4) device at a given point in time, preventing subscribers from
excessive use of addresses within the subnet. This limitation reduces the risk of
denial-of-service (DoS) attacks. This limitation is supported on MX Series routers equipped
with MS-DPCs, but not on MS-MPCs or MS-MICs.
A household using IPv6 with DS-Lite is a subnet, not just an individual IP address. The
subnet limitation feature associates a subscriber and mapping with an IPv6 prefix instead
of an IPv6 address. A subscriber can use any IPv6 addresses in that prefix as a DS-Lite
B4 address and potentially exhaust carrier-grade NAT resources. The subnet limitation
feature enables greater control of resource utilization by identifying a subscriber with a
prefix instead of a specific address.
Copyright © 2018, Juniper Networks, Inc.
299
Adaptive Services Interfaces Feature Guide for Routing Devices
The subnet limit provides the following features:
•
Flows utilize the complete B4 address.
•
Prefix length can be configured per service set under softwire-options for the individual
service-set.
•
Port blocks are allocated per prefix of the subscriber B4 device, and not on each B4
address (if the prefix length is less than 128). If prefix the length is 128, then each IPv6
address is treated as a B4. Port blocks are allocated per 128-bit V6 address.
•
Session limit, defined under the DS-Lite softwire concentrator configuration, limits the
number of IPv4 sessions for the prefix.
•
EIM, EIF, and PCP mappings are created per softwire tunnel (full 128 bit IPv6 address).
Stale mappings time out based on timeout values.
•
If prefix length is configured , then PCP max-mappings-per-subscriber (configurable
under pcp-server) is based on the prefix only, and not the full B4 address.
•
SYSLOGS for PBA allocation and release contain the prefix portion of the address
completed with all zeros. SYSLOGS for PCP alloc and release, Flow creation and
deletion will still contain the complete IPv6 address.
The show services nat mappings address-pooling-paired operational command output
now shows the mapping for the prefix. The mapping shows the address of the active B4.
The show services softwire statistics ds-lite output includes a new field that displays the
number of times the session limit was exceeded for the MPC.
See Also
•
show services nat mappings on page 1482
•
show services softwire statistics on page 1560
Configuring DS-Lite Per Subnet Session Limitation to Prevent Denial of Service Attacks
You can configure the DS-Lite per subnet limitation on MX Series routers equipped with
MS-DPCs, but not on MS-MPCs or MS-MICs.
To configure DS-Lite per subnet session limitation:
1.
Configure the size of the subnet prefix to which limiting is applied. Specify a prefix
length of 56, 64, 96, or 128.
[edit}
user@host# set services service-set service-set-name softwire-options
dslite-ipv6-prefix-length 56.
NOTE: Ensure that all mappings are cleared before changing the prefix
length.
300
Copyright © 2018, Juniper Networks, Inc.
Chapter 23: Transitioning to IPv6 Using DS-Lite Softwires
2. Configure the maximum number of subscriber sessions allowed per prefix. You can
configure from 0 through 16,384 sessions.
[edit}
user@host# set services softwire softwire-concentrator dslite dslite-concentrator-name
session-limit-per-prefix 12
NOTE: You cannot use flow-limit and session-limit-per-prefix in the same
dslite configuration.
See Also
•
DS-Lite Per Subnet Limitation Overview on page 299
•
clear services nat mappings on page 1253
•
softwire-options on page 1125
•
ds-lite on page 917
Copyright © 2018, Juniper Networks, Inc.
301
Adaptive Services Interfaces Feature Guide for Routing Devices
302
Copyright © 2018, Juniper Networks, Inc.
CHAPTER 24
Transitioning to IPv6 Using 6rd Softwires
•
Configuring a 6rd Softwire Concentrator on page 303
•
Configuring Stateful Firewall Rules for 6rd Softwire on page 304
•
Example: Basic 6rd Configuration on page 305
•
High Availability and Load Balancing for 6rd Softwires on page 311
•
Configuring Inline 6rd on page 317
•
Inline 6rd and 6to4 Configuration Guidelines on page 321
•
Examples: 6rd and 6to4 Configurations on page 322
Configuring a 6rd Softwire Concentrator
The 6rd feature is supported on Multiservices 100, 400, and 500 PICs on M Series routers,
and on MX Series routers equipped with Multiservices DPCs. The 6rd feature is not
supported on MX Series routers with MS-MPCs or MS-MICs.
To configure a 6rd softwire concentrator:
1.
Assign a name to the 6rd softwire concentrator.
[edit services softwire softwire-concentrator]
user@host# edit v6rd v6rd-softwire-concentator
2. Specify the address of the softwire tunnel.
[edit services softwire softwire-concentrator v6rd v6rd-softwire-concentator]
user@host# set softwire-address address
3. Specify the MTU for the softwire tunnel.
[edit services softwire softwire-concentrator v6rd v6rd-softwire-concentator]
user@host# set mtu-v4 mtu-v4
TIP: In this release there is no support for fragmentation and reassembly,
therefore the MTUs on the IPv6 and IPV4 network must be properly
configured by the administrator.
Copyright © 2018, Juniper Networks, Inc.
303
Adaptive Services Interfaces Feature Guide for Routing Devices
NOTE: Configuration changes to 6rd softwire concentrators do not become
effective in the Packet Forwarding Engine. This is a known limitation. If you
attempt to add the new configuration of softwire concentrators by overriding
the existing configuration of 1024 softwire concentrators, which is the
maximum limit of softwire concentrators that the system supports, the new
configuration is not updated. To work around this limitation, you must delete
the existing configuration and commit the settings, and then add the new
configuration of softwire concentrators and commit the settings.
NOTE: For 6rd softwire concentrators, packet drops are observed and error
messages logged on the virtual terminal session (VTY) console, if one inline
services (si-) interface is replaced with another si- interface without stopping
the traffic during the replacement of the interface. In a scenario in which an
si- interface is associated with a service set that has a large number of softwire
concentrators, replacing that interface without halting the traffic causes
traffic disruption. You must stop the traffic and restart it during such a
replacement of si- interfaces with 6rd softwire concentrators. The following
error messages are displayed on the VTY console of the FPC:
packet discarded because no ifl or not SI ifl
Related
Documentation
•
Tunneling Services for IPv4-to-IPv6 Transition Overview on page 269
•
Configuring Softwire Rules on page 275
•
Configuring Stateful Firewall Rules for 6rd Softwire on page 304
•
Configuring Service Sets for Softwire on page 276
•
Example: Basic 6rd Configuration on page 305
•
Example: Configuring DS-Lite and 6rd in the Same Service Set on page 291
Configuring Stateful Firewall Rules for 6rd Softwire
You must configure a stateful firewall rule for use with 6rd softwires. The stateful firewall
service is used only to direct packets to the softwire, not for firewalling purposes. The
6rd softwire service itself must be stateless. To support stateless processing, you must
include an allow term in both directions of the stateful firewall policy.
The 6rd feature is supported on Multiservices 100, 400, and 500 PICs on M Series routers,
and on MX Series routers equipped with Multiservices DPCs. The 6rd feature is not
supported on MX Series routers with MS-MPCs or MS-MICs.
To include a stateful firewall rule for 6rd softwire processing:
1.
Assign a name to the rule.
[edit services stateful-firewall]
304
Copyright © 2018, Juniper Networks, Inc.
Chapter 24: Transitioning to IPv6 Using 6rd Softwires
user@host# edit rule rule-name
2. Specify the match direction.
[edit services stateful-firewall rule-name]
user@host# set match-direction input-output
3. Assign a name for the term.
[edit services stateful-firewall rule-name]
user@host# edit term term-name
4. Specify that all traffic in both directions should be accepted for the softwire process.
[edit services stateful-firewall rule-name term term-name]
user@host# set then accept
Related
Documentation
•
Tunneling Services for IPv4-to-IPv6 Transition Overview on page 269
•
Configuring a 6rd Softwire Concentrator on page 303
•
Configuring Softwire Rules on page 275
•
Configuring Service Sets for Softwire on page 276
•
Example: Basic 6rd Configuration on page 305
•
Example: Configuring DS-Lite and 6rd in the Same Service Set on page 291
Example: Basic 6rd Configuration
•
Requirements on page 305
•
Overview on page 306
•
Configuration on page 306
Requirements
NOTE: The 6rd feature is supported on Multiservices 100, 400, and 500 PICs
on M Series routers, and on MX Series routers equipped with Multiservices
DPCs. The 6rd feature is not supported on MX Series routers with MS-MPCs
or MS-MICs.
This example describes how a 6rd concentrator can be configured for a 6rd domain, D1,
to provide IPv6 Internet connectivity.
The following hardware components can perform 6rd:
•
M Series Multiservice Edge routers with Multiservices PICs
•
T Series Core routers with Multiservices PICs
Copyright © 2018, Juniper Networks, Inc.
305
Adaptive Services Interfaces Feature Guide for Routing Devices
•
MX Series 3D Universal Edge routers with Multiservices DPCs
Overview
This configuration example describes how to configure a basic 6rd tunneling solution.
Configuration
CLI Quick
Configuration
To quickly configure this example, copy the following commands, paste them into a text
file, remove any line breaks, change any details necessary to match your network
configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy
level.
set interfaces ge-1/2/0 unit 0 family inet service input service-set v6rd-dom1-service-set
set interfaces ge-1/2/0 unit 0 family inet service output service-set v6rd-dom1-service-set
set interfaces ge-1/2/0 unit 0 family inet address 10.10.10.1/24
set interfaces ge-1/2/0 unit 0 family inet6 service input service-set v6rd-dom1-service-set
set interfaces ge-1/2/0 unit 0 family inet6 service output service-set v6rd-dom1-service-set
set interfaces ge-1/2/2 unit 0 family inet6 address 3abc::1/16
set interfaces sp-0/2/0 unit 0 family inet
set interfaces sp-0/2/0 unit 0 family inet6
set services softwire softwire-concentrator v6rd v6rd-dom1 softwire-address 30.30.30.1
set services softwire softwire-concentrator v6rd v6rd-dom1 ipv4-prefix 10.10.10.0/24
set services softwire softwire-concentrator v6rd v6rd-dom1 v6rd-prefix 3040::0/16
set services softwire softwire-concentrator v6rd v6rd-dom1 mtu-v4 9192
set services softwire rule v6rd-dom1 match-direction input
set services softwire rule v6rd-dom1 term t1 then v6rd v6rd-dom1
set services service-set v6rd-dom1-service-set softwire-rules v6rd-dom1
set services service-set v6rd-dom1-service-set stateful-firewall-rules r1
set services service-set v6rd-dom1-service-set interface-service service-interface sp-0/2/0
set services stateful-firewall rule r1 match-direction input-output
set services stateful-firewall rule r1 term t1 then accept
Chassis Configuration
Step-by-Step
Procedure
To configure the chassis:
1.
Define the ingress interface.
user@host# edit interfaces ge-1/2/0
2.
Configure the ingress interface logical unit and input/output service options.
[edit interfaces ge-1/2/0]
user@host# set unit 0 family inet service input service-set v6rd-dom1-service-set
user@host# set unit 0 family inet service output service-set v6rd-dom1-service-set
user@host# set unit 0 family inet6 service input service-set v6rd-dom1-service-set
user@host# set unit 0 family inet6 service output service-set v6rd-dom1-service-set
3.
Configure the address of the ingress interface.
[edit interfaces ge-1/2/0]
user@host# set unit 0 family inet address 10.10.10.1/24
306
Copyright © 2018, Juniper Networks, Inc.
Chapter 24: Transitioning to IPv6 Using 6rd Softwires
4.
Define the egress interface.
user@host# up
[edit interfaces]
user@host# edit ge-1/2/2
5.
Define the logical unit and address for the egress interface.
[edit interfaces ge-1/2/2]
user@host# set unit 0 family inet6 address 3ABC::1/16
6.
Define the services PIC.
[edit interfaces ge-1/2/2]
user@host# up
[edit interfaces]
user@host# edit sp-0/2/0
7.
Configure the logical unit for the services PIC.
[edit interfaces sp-0/2/0]
user@host# up
[edit interfaces]
user@host# set unit 0 family inet
user@host# set unit 0 family inet6
Copyright © 2018, Juniper Networks, Inc.
307
Adaptive Services Interfaces Feature Guide for Routing Devices
Results
[edit interfaces]
user@host# show
sp-0/2/0 {
unit 0 {
family inet;
family inet6;
}
}
ge-1/2/0 {
unit 0 {
family inet {
service {
input {
service-set v6rd-dom1-service-set;
}
output {
service-set v6rd-dom1-service-set;
}
}
address 10.10.10.1/24;
}
family inet6 {
service {
input {
service-set v6rd-dom1-service-set;
}
output {
service-set v6rd-dom1-service-set;
}
}
}
}
}
ge-1/2/2 {
unit 0 {
family inet6 {
address 3abc::1/16;
}
}
}
Softwire Concentrator, Softwire Rule, and Stateful Firewall Rule Configuration
Step-by-Step
Procedure
To configure the softwire concentrator, softwire rule, and stateful firewall rule:
1.
Define the 6rd softwire concentrator.
user@host# top
user@host# edit services softwire softwire-concentrator v6rd v6rd-dom1
2.
Configure the softwire concentrator properties. Here, softwire address 30.30.30.1
is the softwire concentrator IPv4 address, 10.10.10.0/24 is the IPv4 prefix of the CE
WAN side, and 3040::0/16 is the IPv6 prefix of the 6rd domain D1.
[edit services softwire softwire-concentrator v6rd v6rd-dom1]
user@host# set softwire-address 30.30.30.1
user@host# set ipv4-prefix 10.10.10.0/24
308
Copyright © 2018, Juniper Networks, Inc.
Chapter 24: Transitioning to IPv6 Using 6rd Softwires
user@host# set v6rd-prefix 3040::0/16
user@host# set mtu-v4 9192
3.
Define the softwire rule.
[edit services softwire softwire-concentrator v6rd v6rd-dom1]
user@host# up 2
[edit services softwire]
user@host# edit rule v6rd-dom1
[edit services softwire rule v6rd-dom1]
user@host# set match-direction input
[edit services softwire rule v6rd-dom1]
user@host# set term t1 then v6rd v6rd-dom1
4.
Define a stateful firewall rule and properties. You must configure a stateful firewall
rule that accepts all traffic in both the input and output direction in order for 6rd to
work; however, this is not enforced through the CLI. This is because in IPv6, gratuitous
IPv6 packets are expected (due to Anycast) and should not be dropped. The service
PIC can handle reverse traffic without seeing all forward traffic. This can also happen
with service PIC switchover in the middle of a session. By default, the stateful firewall
on the service PIC will drop all traffic unless a rule is configured explicitly to allow
it.
[edit services softwire softwire-concentrator v6rd v6rd-dom1]
user@host# up 3
[edit servicesl]
user@host# edit services stateful-firewall
[edit services stateful-firewall]
user@host# edit rule r1
[edit services stateful-firewall rule r1]
user@host# set match-direction input-output
user@host# set term t1 then accept
Copyright © 2018, Juniper Networks, Inc.
309
Adaptive Services Interfaces Feature Guide for Routing Devices
Results
[edit services softwire]
user@host# show
softwire-concentrator {
v6rd v6rd-dom1 {
softwire-address 30.30.30.1;
ipv4-prefix 10.10.10.0/24;
v6rd-prefix 3040::0/16;
mtu-v4 9192;
}
}
rule v6rd-dom1-r1 {
match-direction input;
term t1 {
then {
v6rd v6rd-dom1;
}
}
}
Service Set Configuration
Step-by-Step
Procedure
To configure the service set:
1.
Define the service set for 6rd processing.
user@host# top
user@host# edit services service-set v6rd-dom1-service-set
2.
Define the softwire and stateful firewall rules for the service set.
[edit services service-set v6rd-dom1-service-set]
user@host# set softwire-rules v6rd-dom1
user@host# set stateful-firewall-rules r1
3.
Define the interface-service for the service set.
[edit services service-set v6rd-dom1-service-set]
user@host# set interface-service service-interface sp-0/2/0
Results
Related
Documentation
310
[edit service-set v6rd-dom1-service-set]
user@host# show
softwire-rules v6rd-dom1-r1
interface-service {
service-interface sp-0/2/0;
}
•
Tunneling Services for IPv4-to-IPv6 Transition Overview on page 269
•
Configuring a 6rd Softwire Concentrator on page 303
•
Configuring Softwire Rules on page 275
Copyright © 2018, Juniper Networks, Inc.
Chapter 24: Transitioning to IPv6 Using 6rd Softwires
•
Configuring Stateful Firewall Rules for 6rd Softwire on page 304
•
Configuring Service Sets for Softwire on page 276
•
Example: Basic DS-Lite Configuration on page 285
•
Example: Configuring DS-Lite and 6rd in the Same Service Set on page 291
High Availability and Load Balancing for 6rd Softwires
NOTE: The 6rd feature is supported on Multiservices 100, 400, and 500 PICs
on M Series routers, and on MX Series routers equipped with Multiservices
DPCs. The 6rd feature is not supported on MX Series routers with MS-MPCs
or MS-MICs.
•
Load Balancing a 6rd Domain Across Multiple Services PICs on page 311
•
Example: Load Balancing a 6rd Domain Across Multiple Services PICs on page 311
•
Configuring High Availability for 6rd Using 6rd Anycast on page 316
Load Balancing a 6rd Domain Across Multiple Services PICs
The 6rd domain is an IPv6 network, which can potentially be very large. A single PIC, or
network processing unit (NPU) on a Multiservices DPC, might not be able to handle all
the traffic for the 6rd domain. To alleviate load problems, you can load-balance the 6rd
domain traffic across multiple PICs. To do so, assign the same softwire rule to different
services sets that use different interfaces. Configure explicit routes and equal-cost
multipath (ECMP) to load-balance the 6rd traffic.
Example: Load Balancing a 6rd Domain Across Multiple Services PICs
•
Hardware and Software Requirements on page 311
•
Overview on page 312
•
Configuration on page 312
Hardware and Software Requirements
This example requires the following hardware:
•
An MX Series 3D Universal Edge router with a services DPC with two available NPUs
or an M Series Multiservice Edge router with two services PICs available for 6rd softwire
concentrator processing
•
A domain name server (DNS)
Copyright © 2018, Juniper Networks, Inc.
311
Adaptive Services Interfaces Feature Guide for Routing Devices
This example uses the following software:
•
Junos OS Release 11.4 or higher
Overview
Because of anticipated volume, a provider needs to balance 6rd softwire traffic between
two services PICs.
Configuration
•
Chassis Configuration on page 312
•
Softwire Concentrator and Softwire Rule Configuration on page 313
•
Stateful Firewall Configuration on page 313
•
Service Set Configuration on page 314
•
Load-Balancing Configuration on page 315
Chassis Configuration
Step-by-Step
Procedure
To configure the chassis:
1.
Define the ingress interface and its properties.
user@host# edit interfaces ge-1/2/0
user@host# set unit 0 family inet address 10.10.10.1/16
2.
Define the egress interface and its properties. In this example, the IPv6 clients try
to reach the IPv6 server at 3abc::2/16.
user@host# edit interfaces ge-1/2/2
user@host# set unit 0 family inet6 address 3ABC::1/16
3.
Define the services PICs for selection as softwire concentrators by the load-balancing
process. This configuration uses two PICs/NPUs: sp-3/0/0 and sp-3/1/0. A next-hop
style service set is configured (shown in the next section).
user@host# edit interfaces sp-3/0/0
[edit interfaces ge-3/0/0]
user@host# set services-options syslog host local services any
user@host# set unit 0 family inet
user@host# set unit 0 family inet6
user@host# set unit 1 family inet service-domain inside
user@host# set unit 1 family inet service-domain outside
user@host# set unit 2 family inet service-domain inside
user@host# set unit 2 family inet service-domain outside
user@host# up 1
[edit]
user@host# edit interfaces sp-3/1/0
[edit interfaces sp-3/1/0]
user@host# set services-options syslog host local services any
user@host# set unit 0 family inet
user@host# set unit 0 family inet6
user@host# set unit 1 family inet service-domain inside
312
Copyright © 2018, Juniper Networks, Inc.
Chapter 24: Transitioning to IPv6 Using 6rd Softwires
user@host# set unit 1 family inet service-domain outside
user@host# set unit 2 family inet service-domain inside
user@host# set unit 2 family inet service-domain outside
Softwire Concentrator and Softwire Rule Configuration
Step-by-Step
Procedure
The softwire configuration is straightforward. In this example, the 6rd domain prefix is
3040::0/16, the 6rd softwire concentrator IPv4 address is 30.30.30.1, and the customer
IPv4 network is 10.10.0.0/16. In the customer premises equipment (CPE) network, all
customer edge (CE) devices have addresses that belong to the 10.10.0.0/16 network. To
configure the softwire:
1.
Go to the [edit services softwire] hierarchy level.
user@host# edit services softwire
2.
Configure IPv6 multicast.
[edit services softwire]
user@host# set ipv6-multicast-interfaces all
3.
Go to the softtwire concentrator v6rd hierarchy level and name the softwire
concentrator shenick01-rd1.
[edit services softwire]
user@host# edit softwire-concentrator v6rd shenick01-rd1
4.
Configure the softwire concentrator properties.
[edit services softwire softwire-concentrator v6rdshenick01-rd1 ]
user@host# set softwire-address 30.30.30.1
user@host# set ipv4-prefix 10.10.0.0/16
user@host# set v6rd-prefix 3040::/16
user@host# set mtu-v4 9192
5.
Configure a softwire rule for incoming 6rd traffic.
[edit services softwire softwire-concentrator v6rd shenick01-rd1 ]
user@host# up 1
[edit services softwire ]
user@host# edit rule shenick01-r1
[edit services softwire rule shenick01-r1]
user@host# set match-direction input
user@host# set term t1 then v6rd shenick01-rd1
Stateful Firewall Configuration
Step-by-Step
Procedure
To configure the stateful firewall rule:
1.
Go to the stateful firewall hierarchy level and define a rule.
user@host# edit services stateful-firewall rule r1
Copyright © 2018, Juniper Networks, Inc.
313
Adaptive Services Interfaces Feature Guide for Routing Devices
2.
Set the match direction.
[edit services stateful-firewall rule r1]
user@host# set match-direction input-output
3.
Configure a term that accepts all traffic.
[edit services stateful-firewall rule r1]
user@host# set term t1 then accept
Service Set Configuration
Step-by-Step
Procedure
This configuration provides two service sets, each pointing to a different network
processing unit (NPU). Both service sets use the same stateful firewall and softwire rules.
Because they use the same softwire rule, they refer to same 6rd softwire concentrator.
This results in the software concentrator being hosted on both the NPUs.
To configure the service set:
1.
Define a service set for the first NPU.
user@host# edit services service-set v6rd-sset1
2.
Configure the softwire and stateful firewall rules for the first NPU.
[edit services service-set v6rd-sset1]
user@host# set softwire-rules shenick01-r1
user@host# set stateful-firewall-rules r1
3.
Configure the inside and outside interfaces for the next-hop service.
[edit services service-set v6rd-sset1]
user@host# set next-hop-service inside-service-interface sp-3/0/0.1
user@host# set next-hop-service outside-service-interface sp-3/0/0.2
4.
Define a service set for the second NPU.
user@host# edit services service-set v6rd-sset2
5.
Configure the softwire and stateful firewall rules for the second NPU.
[edit services service-set v6rd-sset2]
user@host# set softwire-rules shenick01-r1
user@host# set stateful-firewall-rules r1
6.
Configure the inside and outside interfaces for the next-hop service.
[edit services service-set v6rd-sset1]
user@host# set next-hop-service inside-service-interface sp-3/1/0.1
user@host# set next-hop-service outside-service-interface sp-3/1/0.2
314
Copyright © 2018, Juniper Networks, Inc.
Chapter 24: Transitioning to IPv6 Using 6rd Softwires
Load-Balancing Configuration
Step-by-Step
Procedure
To configure load balancing:
Configure explicit routes and ECMP to load-balance the 6rd traffic. Configure explicit
routes for both the 6rd concentrator IPv4 address and the 6rd domain prefix, so that they
point to both NPUs.
1.
To configure static routes for the 6rd domain using the routing-table inet6.0, go to
the [edit forwarding-options rib inet6.0 static] hierarchy level and set the routes for
the 6rd domain and the 6rd concentrator IPv4 address.
user@host edit forwarding-options rib inet6.0 static
[edit forwarding-options rib inet6.0 static]
user@host# set route 3040::0/16 next-hop [ sp-3/0/0.2 sp-3/1/0.2 ]
user@host# set route 30.30.30.1/32 next-hop [ sp-3/0/0.1 sp-3/1/0.1 ]
The service PIC daemon (spd) also adds default routes to these addresses pointing
to the NPUs. However, the routes added by the spd use different metrics, which are
computed based on the FPC, PIC, slot numbers, and subunit of the services PIC if
used in the service set configuration. The static routes configured in this sample
configuration will have metrics of 5 and therefore a higher preference than the
spd-added routes.
The explicitly configured routes are as follows:
root@host# run show route 30.30.30.1
inet.0: 37 destinations, 40 routes (36 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both
30.30.30.1/32
*[Static/5] 00:00:10
> via sp-3/0/0.1
via sp-3/1/0.1
[Static/786433] 00:23:03
> via sp-3/0/0.1
[Static/851969] 00:00:09
> via sp-3/1/0.1
root@host# run show route 3040::/16
inet6.0: 20 destinations, 33 routes (20 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
3040::/16
*[Static/5] 00:00:15
via sp-3/0/0.2
> via sp-3/1/0.2
[Static/786434] 00:23:08
> via sp-3/0/0.2
[Static/851970] 00:00:14
> via sp-3/1/0.2
BEST PRACTICE: The spd-installed routes have higher metric values
(hence a low preference) and the metrics are different. If the metrics
are different and ECMP is not enabled, even though multiple routes exist
for the same destination, only one of the routes is picked up all the time
Copyright © 2018, Juniper Networks, Inc.
315
Adaptive Services Interfaces Feature Guide for Routing Devices
(based on the metric). For ECMP you must configure equal-cost routes,
and hence a manual configuration of routes is needed as shown above.
2.
Configure equal-cost multipath (ECMP) load balancing by configuring the hash key
at the [edit forwarding-optionshash-key] hierarchy level.
user@host# forwarding-options hash-key
[edit forwarding-options hash-key]
user@host# set family inet layer-3 destination-address
user@host# set family inet layer-3 source-address
user@host# set family inet6 layer-3 destination-address
user@host# set family inet6 layer-3 source-address
3.
Verify your configuration by displaying forwarding-options.
user@host# show forwarding-options
hash-key {
family inet { <== IPv4 traffic from CEs uses this
layer-3 {
destination-address;
source-address;
}
}
family inet6 { <== IPv6 traffic from Internet uses this
layer-3 {
destination-address;
source-address;
}
}
}
TIP: Both IPv4 and IPv6 hash keys must be configured. The IPv4 hash
key is used to distribute the traffic coming from CPE devices to the 6rd
branch relay. The IPv6 hash key is used to distribute the traffic coming
from the IPv6 Internet to the 6rd domain. Because the hash in the
forward and reverse direction is for different families, different flows
from the same session can reside on different NPUs. However, 6rd
processing is stateless (as far as mapping IPv6 packets to softwires is
concerned), so this should not be a problem.
Configuring High Availability for 6rd Using 6rd Anycast
You configure 6rd Anycast by defining two service sets that use the same softwire rule
in both service sets, just as you do when you configure load balancing for 6rd. However,
you do not configure ECMP, and as a result, the services PIC daemon (spd) installs two
routes each for the softwire concentrator address and 6rd domain pointing to each service
interface. The forwarding plane can select any route based on the priority, which is
316
Copyright © 2018, Juniper Networks, Inc.
Chapter 24: Transitioning to IPv6 Using 6rd Softwires
computed when the spd installs the routes. The priority is computed based on the FPC,
PIC, slot numbers, and subunit number used on the sp- interface. Only one PIC is used
based on the route priority, and that PIC gets all of the 6rd traffic. If the PIC goes down.
the route pointing to it is also deleted and the forwarding plane automatically selects
the alternate available PIC.
6rd Anycast is completely stateless. The spd installs the route and doesn’t run any state
machine for the PIC. Because the routes are pre-installed and service sets are already
on the PIC, there is no service delay if a failover occurs.
Related
Documentation
•
Tunneling Services for IPv4-to-IPv6 Transition Overview on page 269
Configuring Inline 6rd
Junos OS supports inline 6rd and 6to4 on the following Modular Port Concentrator (MPC)
line cards: MPC3E, MPC5E, and MPC6E. This saves customers the cost of using
Multiservices Dense Port Concentrators (MS-DPCs) for the required tunneling,
encapsulation, and decapsulation processes. Anycast is supported for 6to4 (next-hop
service interfaces only). Hairpinning is also supported for traffic between 6rd domains.
To implement the inline functionality, you configure service interfaces on the MPC as
inline services interfaces (si-) rather than as multiServices (ms-) interfaces.
•
Configuring the Bandwidth for Inline Services on page 317
•
Configuring the Interfaces on page 318
•
Configuring the Softwire Concentrator and Rule on page 319
•
Configuring the Service Set on page 320
•
Configuring the Routing Instance on page 321
Configuring the Bandwidth for Inline Services
You must provide bandwidth configuration for inline services on the modular port
concentrator (MPC) used for inline 6rd processing.
To configure bandwidth:
•
Specify the MPC and logical interface, and the desired bandwidth, 1g or 10g.
user@host# set chassis fpc mpc-number pic logical-interface-number inline-services
bandwidth bandwidth
For example:
user@host# set chassis fpc 0 pic 0 inline-services bandwidth 10g
Copyright © 2018, Juniper Networks, Inc.
317
Adaptive Services Interfaces Feature Guide for Routing Devices
Configuring the Interfaces
Configure the si- interfaces for 6rd control and data. 6rd services must be configured on
port 0.
To configure the si- interfaces:
1.
Configure the 6rd services on port 0 and include units for IPv4 and IPv6.
user@host# set interfaces si-mpc-number/logical-interface-number/0 unit 0 family
inet
user@host# set interfaces si-mpc-number/logical-interface-number/0 unit 0 family
inet6
For example:
user@host# set interfaces si-0/0/0 unit 0 family inet
user@host# set interfaces si-0/0/0 unit 0 family inet6
2. Configure the media interfaces for the inside service domain.
user@host# set interfaces si-mpc-number/logical-interface-number/0 unit unit-number
family inet
user@host# set interfaces si-mpc-number/logical-interface-number/0 unit unit-number
family inet6
user@host# set interfaces si-0/0/0 unit unit-number service-domain inside
For example:
user@host# set interfaces si-0/0/0 unit 1 family inet
user@host# set interfaces si-0/0/0 unit 1 family inet6
user@host# set interfaces si-0/0/0 unit 1 service-domain inside
3. Configure the media interfaces for the outside service domain.
user@host# set interfaces si-mpc-number/logical-interface-number/0 unit unit-number
family inet
user@host# set interfaces si-mpc-number/logical-interface-number/0 unit unit-number
family inet6
user@host# set interfaces si-mpc-number/logical-interface-number/0 unit unit-number
service-domain outside
For example:
user@host# set interfaces si-0/0/0 unit 2 family inet
user@host# set interfaces si-0/0/0 unit 2 family inet family inet6
user@host# set interfaces si-mpc-number/logical-interface-number/0 unit unit-number
service-domain outside
4. Configure the IPv4-facing interface for use with an interface-style or next-hop service
set.
•
To configure for use with an interface-style service set, configure input and output
service and specify the service set.
user@host# set interfaces ge-mpc-number/logical-interface-number/port unit
unit-number family inet service input service-set service-set-name
318
Copyright © 2018, Juniper Networks, Inc.
Chapter 24: Transitioning to IPv6 Using 6rd Softwires
user@host# set interfaces ge-mpc-number/logical-interface-number/port unit
unit-number family inet service output service-set service-set-name
user@host# set interfaces ge-mpc-number/logical-interface-number/port unit
unit-number family inet address ip-address
For example:
user@host# set interfaces ge-0/2/7 unit 0 family inet service input service-set
vrf-intf-service-set
user@host# set interfaces ge-0/2/7 unit 0 family inet service output service-set
vrf-intf-service-set
user@host# set interfaces ge-0/2/7 unit 0 family inet address 10.10.10.1/16
•
To configure for use with a next-hop style service set, omit the service input. and
service output references.
user@host# set interfaces ge-mpc-number/logical-interface-number/port unit
unit-number family inet
user@host# set interfaces ge-mpc-number/logical-interface-number/port unit
unit-number family inet address ip-address
For example:
user@host# set interfaces ge-0/2/7 unit 0 family inet
user@host# set interfaces ge-0/2/7 unit 0 family inet address 10.10.10.1/16
5. Configure the IPv6 facing interface.
user@host# set interfaces ge-mpc-number/logical-interface-number/port unit
unit-number family inet6 address ipv6-address
For example:
user@host# set interfaces ge-0/2/8 unit 0 family inet6 address 3abc::1/16
Configuring the Softwire Concentrator and Rule
Define the softwire concentrator and rule used for encapsulation and decapsulation of
IPv6 over IPv4 packets for CE.
To define the softwire concentrator:
1.
Specify a 6rd softwire concentrator and its address.
user@host# set services softwire softwire-concentrator v6rd concentrator-name
softwire-address ip-address
For example:
user@host# set services softwire softwire-concentrator v6rd swire01-rd1
softwire-address 30.30.30.1
2. Configure the IPv4 address prefix for the customer edge network and the IPv6 address
prefix for the 6rd domain.
user@host# set services softwire softwire-concentrator v6rd concentrator-name
ipv4-prefix ipv4-prefix v6rd-prefix v6rd-prefix
For example:
Copyright © 2018, Juniper Networks, Inc.
319
Adaptive Services Interfaces Feature Guide for Routing Devices
user@host# set services softwire softwire-concentrator v6rd swire01-rd1 ipv4-prefix
10.10.0.0/16 v6rd-prefix 3040::0/16
3. Configure the size, in bytes, of the maximum transmission unit mtu-ipv4 for IPv6
packets encapsulated in IPv4. Compute this as the maximum expected IPv4 packet
size plus 20.
user@host# set services softwire softwire-concentrator v6rd concentrator-name set
mtu-ipv4 number-of-bytes
For example:
user@host# set services softwire softwire-concentrator v6rd swire01-rd1 set mtu-ipv4
9192
To configure the softwire rule:
•
Specify the softwire rule, specifying the direction of traffic to be tunneled and the 6rd
softwire concentrator to be used.
user@host# set services softwire rule softwire-rule-name match-direction
match-direction term rule-term-number then v6rd concentrator-name
For example:
user@host# set services softwire rule swire01-r1 match-direction input term t1 then
v6rd swire01-rd1
Configuring the Service Set
To configure an interface style or next-hop service set for 6rd processing:
•
Specify an interface style service set.
user@host# set services service-set service-set-name softwire-rules softwire-rule-name
service-interface interface-name
For example:
user@host# set services service-set vrf-intf-service-set softwire-rules swire01-r1
service-interface si-0/0/0.0
or
•
Configure a next-hop service set.
user@host# set services service-set service-set-name softwire-rules softwire-rule-name
user@host# set services service-set service-set-name next-hop-service
inside-service-interface inside-interface outside-service-interface outside-interface
user@host# set services service-set vrf-nh-service-set softwire-rules swire01-r1
user@host# set services service-set vrf-nh-service-set next-hop-service
inside-service-interface si-0/0/0.1 outside-service-interface si-0/0/0.2
320
Copyright © 2018, Juniper Networks, Inc.
Chapter 24: Transitioning to IPv6 Using 6rd Softwires
Configuring the Routing Instance
To configure the routing instance:
1.
Specify the routing instance and each interface it serves.
user@host# set routing-instance routing-instance-name instance-type vrf interface
interface-name
For example:
user@host# set routing-instance v6rd-vrf instance-type vrf interface si-0/0/0.1
user@host# set routing-instance v6rd-vrf instance-type vrf interface interface
ge-0/2/7.0
2. Specify the route distinguisher and vrf-target.
user@host# set routing-instance v6rd-vrf route-distinguisher 1.1.1.1:1
user@host# set routing-instance v6rd-vrf vrf-target target:100:100
Related
Documentation
•
Configuring a 6rd Softwire Concentrator on page 303
•
Configuring Softwire Rules
•
Configuring Inline 6rd on page 317
Inline 6rd and 6to4 Configuration Guidelines
Keep the following points in mind when you are configuring and using inline 6rd and 6to4.
•
You can configure a maximum of 1024 softwire concentrators on a single line card.
•
Reassembly of 6rd IPv4 packet from CE is not added as part of this release.
•
6rd multicast is not supported.
•
Any ICMPv4 errors generated in the IPv4 access network (between CPE and border
relays) are dropped on the border relay. They are not converted into IPv6 errors and
forwarded to IPv6 side.
•
6rd/6to4 Anycast and load balancing can be configured only using next-hop style
service-interface configuration, not interface style.
•
The si- interface input features are not exercised for packets flowing to the 6rd tunnel.
•
Bandwidth for traffic from the 6rd tunnel is limited by the available PFE bandwidth;
bandwidth for traffic to the 6rd tunnel is limited by the internal VRF loopback bandwidth.
SI-IFD loopback bandwidth configuration under the [edit chassis] hierarchy has no
impact on the 6rd loopback bandwidth.
•
If the packet length is more than Tunnel MTU for downlink packets after encapsulating
with an IPv4 header, the packet is dropped as v4 MTU errors. For these packet drops
an ICMPv6 packet too big error message is sent back to the sender. Typically 6rd Tunnel
MTU is configured with a high value so if the packet size is larger than the configured
value, fragmentation occurs at the egress interface (towards the IPv4 access network).
Copyright © 2018, Juniper Networks, Inc.
321
Adaptive Services Interfaces Feature Guide for Routing Devices
Examples: 6rd and 6to4 Configurations
NOTE: The 6rd and 6to4 features are supported on Multiservices 100, 400,
and 500 PICs on M Series routers, and on MX Series routers equipped with
Multiservices DPCs. The 6rd and 6to4 features are not supported on MX
Series routers with MS-MPCs or MS-MICs.
•
Example: 6rd with Interface-Style Service Set Configuration on page 322
•
Example: 6rd with Next-Hop-Style Service Set Configuration on page 323
•
Example: 6rd Anycast Configuration on page 325
•
Example: Hairpinning Between 6rd Domains Configuration on page 326
•
Example: 6to4 Configuration on page 328
Example: 6rd with Interface-Style Service Set Configuration
chassis {
fpc 0 {
pic 0 {
inline-services {
bandwidth 10g;
}
}
}
}
services {
service-set vrf-intf-service-set {
softwire-rules swire01-r1;
interface-service {
service-interface si-0/0/0.0;
}
}
softwire {
softwire-concentrator {
v6rd swire01-rd1 {
softwire-address 30.30.30.1;
ipv4-prefix 10.10.0.0/16;
v6rd-prefix 3040::0/16;
mtu-v4 9192;
}
}
rule swire01-r1 {
match-direction input;
term t1 {
then {
v6rd swire01-rd1;
}
}
}
}
}
322
Copyright © 2018, Juniper Networks, Inc.
Chapter 24: Transitioning to IPv6 Using 6rd Softwires
interfaces {
si-0/0/0 {
unit 1 {
family inet;
family inet6;
service-domain inside;
}
unit 2 {
family inet;
family inet6;
service-domain outside;
}
}
ge-0/2/7 {
unit 0 {
family inet {
address 10.10.10.1/16;
}
}
}
ge-0/2/8 {
unit 0 {
family inet6 {
address 3abc::1/16;
}
}
}
}
routing-instances {
v6rd-vrf {
instance-type vrf;
interface si-0/0/0.1;
interface ge-0/2/7.0;
route-distinguisher 1.1.1.1:1;
vrf-target target:100:100;
}
}
Example: 6rd with Next-Hop-Style Service Set Configuration
chassis {
fpc 0 {
pic 0 {
inline-services {
bandwidth 10g;
}
}
}
}
services {
service-set vrf-nh-service-set {
softwire-rules swire01-r1;
next-hop-service {
inside-service-interface si-0/0/0.1;
outside-service-interface si-0/0/0.2;
}
Copyright © 2018, Juniper Networks, Inc.
323
Adaptive Services Interfaces Feature Guide for Routing Devices
}
softwire {
softwire-concentrator {
v6rd swire01-rd1 {
softwire-address 30.30.30.1;
ipv4-prefix 10.10.0.0/16;
v6rd-prefix 3040::0/16;
mtu-v4 9192;
}
}
rule swire01-r1 {
match-direction input;
term t1 {
then {
v6rd swire01-rd1;
}
}
}
}
}
interfaces {
si-0/0/0 {
unit 1 {
family inet;
family inet6;
service-domain inside;
}
unit 2 {
family inet;
family inet6;
service-domain outside;
}
}
ge-0/2/7 {
unit 0 {
family inet {
address 10.10.10.1/16;
}
}
}
ge-0/2/8 {
unit 0 {
family inet6 {
address 3abc::1/16;
}
}
}
}
routing-instances {
v6rd-vrf {
instance-type vrf;
interface si-0/0/0.1;
interface ge-0/2/7.0;
route-distinguisher 1.1.1.1:1;
vrf-target target:100:100;
}
324
Copyright © 2018, Juniper Networks, Inc.
Chapter 24: Transitioning to IPv6 Using 6rd Softwires
}
Example: 6rd Anycast Configuration
chassis {
fpc 0 {
pic 0 {
inline-services {
bandwidth 10g;
}
}
pic 2 {
inline-services {
bandwidth 1g;
}
}
}
}
services {
service-set anycast-nh-set1 {
softwire-rules swire01-r1;
next-hop-service {
inside-service-interface si-0/0/0.1;
outside-service-interface si-0/0/0.2;
}
}
service-set anycast-nh-set2 {
softwire-rules swire01-r1;
next-hop-service {
inside-service-interface si-0/2/0.1;
outside-service-interface si-0/2/0.2;
}
}
softwire {
softwire-concentrator {
v6rd swire01-rd1 {
softwire-address 30.30.30.1;
ipv4-prefix 10.10.0.0/16;
v6rd-prefix 3040::0/16;
mtu-v4 9192;
}
}
rule swire01-r1 {
match-direction input;
term t1 {
then {
v6rd swire01-rd1;
}
}
}
}
}
interfaces {
si-0/0/0 {
unit 0 {
family inet;
Copyright © 2018, Juniper Networks, Inc.
325
Adaptive Services Interfaces Feature Guide for Routing Devices
family inet6;
}
unit 1 {
family inet;
family inet6;
service-domain inside;
}
unit 2 {
family inet;
family inet6;
service-domain outside;
}
}
si-0/2/0 {
unit 0 {
family inet;
family inet6;
}
unit 1 {
family inet;
family inet6;
service-domain inside;
}
unit 2 {
family inet;
family inet6;
service-domain outside;
}
}
ge-0/2/7 {
unit 0 {
family inet {
address 10.10.10.1/16;
}
}
}
ge-0/2/8 {
unit 0 {
family inet6 {
address 3abc::1/16;
}
}
}
}
Example: Hairpinning Between 6rd Domains Configuration
This example uses an interface service-set and a next-hop service set as hairpinning
domains.
chassis {
fpc 0 {
pic 0 {
inline-services {
bandwidth 10g;
}
326
Copyright © 2018, Juniper Networks, Inc.
Chapter 24: Transitioning to IPv6 Using 6rd Softwires
}
}
}
services {
service-set hairpin-intf-service-set {
softwire-rules swire01-r1;
interface-service {
service-interface si-0/0/0.0;
}
}
service-set hairpin-nh-service-set {
softwire-rules swire01-r2;
next-hop-service {
inside-service-interface si-0/0/0.1;
outside-service-interface si-0/0/0.2;
}
}
softwire {
softwire-concentrator {
v6rd swire01-rd1 {
softwire-address 30.30.30.1;
ipv4-prefix 10.10.0.0/16;
v6rd-prefix 3040::0/16;
mtu-v4 9192;
}
v6rd swire01-rd2 {
softwire-address 60.60.60.1;
ipv4-prefix 40.40.40.0/24;
v6rd-prefix 3050::0/16;
mtu-v4 9192;
}
}
rule swire01-r1 {
match-direction input;
term t1 {
then {
v6rd swire01-rd1;
}
}
}
rule swire01-r2 {
match-direction input;
term t1 {
then {
v6rd swire01-rd2;
}
}
}
}
}
interfaces {
si-0/0/0 {
unit 0 {
family inet;
family inet6;
}
Copyright © 2018, Juniper Networks, Inc.
327
Adaptive Services Interfaces Feature Guide for Routing Devices
unit 1 {
family inet;
family inet6;
service-domain inside;
}
unit 2 {
family inet;
family inet6;
service-domain outside;
}
}
ge-0/2/7 {
unit 0 {
family inet {
service {
input {
service-set hairpin-intf-service-set;
}
output {
service-set hairpin-intf-service-set;
}
}
address 10.10.10.1/16;
}
}
}
ge-0/2/8 {
unit 0 {
family inet {
address 40.40.40.1/24;
}
}
}
}
Example: 6to4 Configuration
chassis {
fpc 0 {
pic 0 {
inline-services {
bandwidth 10g;
}
}
}
}
services {
service-set 6to4-intf-service-set {
softwire-rules shenick01-r1;
interface-service {
service-interface si-0/0/0.0;
}
}
interfaces {
si-0/0/0 {
unit 0 {
328
Copyright © 2018, Juniper Networks, Inc.
Chapter 24: Transitioning to IPv6 Using 6rd Softwires
family inet;
family inet6;
}
unit 1 {
family inet;
family inet6;
service-domain inside;
}
unit 2 {
family inet;
family inet6;
service-domain outside;
}
}
ge-0/2/7 {
unit 0 {
family inet {
service {
input {
service-set 6to4-intf-service-set;
}
output {
service-set 6to4-intf-service-set;
}
}
address 10.10.10.1/16;
}
}
}
ge-0/2/8 {
unit 0 {
family inet6 {
address 3abc::1/16;
}
}
}
}
Related
Documentation
•
Configuring a 6to4 Provider-Managed Tunnel
Copyright © 2018, Juniper Networks, Inc.
329
Adaptive Services Interfaces Feature Guide for Routing Devices
330
Copyright © 2018, Juniper Networks, Inc.
CHAPTER 25
Monitoring and Troubleshooting Softwires
•
Ping and Traceroute for DS-Lite on page 331
•
Monitoring Softwire Statistics on page 331
•
Monitoring CGN, Stateful Firewall, and Softwire Flows on page 333
Ping and Traceroute for DS-Lite
With Junos OS Release 11.4, you can use the ping and traceroute commands to determine
the status of the DS-Lite softwire tunnels:
•
IPv6 ping—The softwire address endpoint on the DS-Lite softwire terminator (AFTR)
is usually configured only at the [edit services softwire] hierarchy level; it need not be
hosted on any interface. Previous releases of the Junos OS software did not provide
replies to pings to the IPv6 softwire address when the AFTR was not configured on a
specific interface or loopback. An IPv6 ping enables the softwire initiator (B4) to verify
the softwire address of the AFTR before creating a tunnel.
•
IPv4 ping—A special IPv4 address, 192.0.0.1, is reserved for the AFTR. Previous releases
of the Junos OS did not respond to any pings sent to this address. A B4 and other IPv4
nodes can now ping to this address to determine whether the DS-Lite tunnel is working.
•
Traceroute—The AFTR now generates and forwards traceroute packets over the DS-Lite
tunnel.
NOTE: No additional CLI configuration is necessary to use the new
functionality.
Monitoring Softwire Statistics
Purpose
You can review softwire global statistics by using the show services softwire or show
services softwire statistics command.
Copyright © 2018, Juniper Networks, Inc.
331
Adaptive Services Interfaces Feature Guide for Routing Devices
Action
user@host# show services softwire
Interface: sp-0/0/0, Service set: sset
Softwire Direction Flow count
2001:0:0:1::1 -> 1001::1 I 3
user@host# show services softwire statistics
DS-Lite Statistics:
Service PIC Name: :sp-0/0/0
Statistics
---------Softwires Created :2
Softwires Deleted :1
Softwires Flows Created :2
Softwires Flows Deleted :1
Slow Path Packets Processed :2
Fast Path Packets Processed :274240
Fast Path Packets Encapsulated :583337
Rule Match Failed :0
Rule Match Succeeded :2
IPv6 Packets Fragmented :0
Transient Errors
---------------Flow Creation Failed - Retry :0
Slow Path Failed - Retry :0
Errors
-----Softwire Creation Failed :0
Flow Creation Failed :0
Slow Path Failed :0
Packet not IPv4-in-IPv6 :0
IPv6 Fragmentation Error :0
Slow Path Failed - IPv6 Next Header Offset :0
Decapsulated Packet not IPv4 :0
Fast Path Failed - IPv6 Next Header Offset :0
No Softwire ID :0
No Flow Extension :0
Flow Limit Exceeded :0
6rd Statistics:
Service PIC Name :sp-0/0/0
Statistics
---------Softwires Created :0
Softwires Deleted :0
Softwires Flows Created :0
Softwires Flows Deleted :0
Slow Path Packets Processed :0
Fast Path Packets Processed :0
Fast Path Packets Encapsulated :0
Rule Match Failed :0
Rule Match Succeeded :0
Transient Errors
---------------Flow Creation Failed - Retry :0
Slow Path Failed - Retry :0
Errors
-----Softwire Creation Failed :0
Flow Creation Failed :0
Slow Path Failed :0
Packet not IPv6-in-IPv4 :0
332
Copyright © 2018, Juniper Networks, Inc.
Chapter 25: Monitoring and Troubleshooting Softwires
Slow Path Failed - IPv6 Next Header Offset :0
Decapsulated Packet not IPv6 :0
Encapsulation Failed - No packet memory :0
No Softwire ID :0
No Flow Extension :0
ICMPv4 Dropped Packets :0
Monitoring CGN, Stateful Firewall, and Softwire Flows
Purpose
Action
Related
Documentation
Use the following commands to check the creation of the softwires, pre-NAT flows, and
post-NAT flows. Output can be filtered using more specific fields such as AFTR or B4
address or both for DS-Lite, and softwire-concentrator or softwire-initiator or both for
6rd.
•
show services stateful-firewall flows
•
show services softwire flows
user@host# show services stateful-firewall flows
Interface: sp-0/1/0, Service set: dslite-svc-set2
Flow
State
Dir
TCP
200.200.200.2:80
->
44.44.44.1:1025 Forward O
NAT dest
44.44.44.1:1025
->
20.20.1.4:1025
Softwire
2001::2
->
1001::1
TCP
20.20.1.2:1025 -> 200.200.200.2:80
Forward I
NAT source
20.20.1.2:1025
->
44.44.44.1:1024
Softwire
2001::2
->
1001::1
TCP
200.200.200.2:80
->
44.44.44.1:1024 Forward O
NAT dest
44.44.44.1:1024
->
20.20.1.2:1025
Softwire
2001::2
->
1001::1
DS-LITE
2001::2
->
1001::1
Forward I
TCP
200.200.200.2:80
->
44.44.44.1:1026 Forward O
NAT dest
44.44.44.1:1026
->
20.20.1.3:1025
Softwire
2001::2
->
1001::1
TCP
20.20.1.3:1025 -> 200.200.200.2:80
Forward I
NAT source
20.20.1.3:1025
->
44.44.44.1:1026
Softwire
2001::2
->
1001::1
TCP
20.20.1.4:1025 -> 200.200.200.2:80
Forward I
NAT source
20.20.1.4:1025
->
44.44.44.1:1025
Softwire
2001::2
->
1001::1
•
Frm count
219942
110244
219140
988729
218906
110303
110944
Tunneling Services for IPv4-to-IPv6 Transition Overview on page 269
Copyright © 2018, Juniper Networks, Inc.
333
Adaptive Services Interfaces Feature Guide for Routing Devices
334
Copyright © 2018, Juniper Networks, Inc.
PART 4
Enabling Traffic to Pass Securely Using
ALGs
•
ALG Overview on page 337
•
ALGs Configuration Overview on page 367
Copyright © 2018, Juniper Networks, Inc.
335
Adaptive Services Interfaces Feature Guide for Routing Devices
336
Copyright © 2018, Juniper Networks, Inc.
CHAPTER 26
ALG Overview
•
ALG Descriptions on page 337
•
ALGs Available for Junos OS Address Aware NAT on page 362
ALG Descriptions
This topic describes the Application Layer Gateways (ALGs) supported by Junos OS. ALG
support includes managing pinholes and parent-child relationships for the supported
ALGs. This topic includes the following sections:
•
Supported ALGs on page 337
•
ALG Support Details on page 339
•
Juniper Networks Defaults on page 349
•
Examples: Referencing the Preset Statement from the Junos OS Default
Group on page 360
Supported ALGs
Table 12 on page 337 lists ALGs supported by Junos OS. For information about which ALGs
are supported on MS-DPCs, MS-MPCs, or MS-MICs, see “ALGs Available for Junos OS
Address Aware NAT” on page 147.
Table 12: ALGs Supported by Junos OS
ALGs Supported
v4 - v4
v6 - v4
v6 - v6
DS-Lite (Support
for ALGs with
DS-lite on
MS-MPC and
MS-MIC starts in
Junos OS Release
18.1R1)
Basic TCP ALG
Yes
Yes
Yes
Yes
Basic UPD ALG
Yes
Yes
Yes
Yes
BOOTP
Yes
No
No
No
DCE RPC Services
Yes
No
No
No
Copyright © 2018, Juniper Networks, Inc.
337
Adaptive Services Interfaces Feature Guide for Routing Devices
Table 12: ALGs Supported by Junos OS (continued)
ALGs Supported
v4 - v4
v6 - v4
v6 - v6
DS-Lite (Support
for ALGs with
DS-lite on
MS-MPC and
MS-MIC starts in
Junos OS Release
18.1R1)
DNS
Yes
Yes
No
Yes
FTP
Yes
No
No
Yes
Gatekeeper RAS
Yes (Starting in
Junos OS Release
17.1R1)
Yes (Starting in
Junos OS Release
17.2R1)
No
No
H323
Yes
Yes (Starting in
Junos OS Release
17.2R1)
No
No
ICMP
Yes
Yes
Yes
Yes
IKE ALG (Starting in Junos OS
Release 14.2R7, 15.1R5, 16.1R2, and
17.1R1)
Yes
Yes
No
No
IIOP
Yes
No
No
No
IP
Yes
No
No
No
NETBIOS
Yes
No
No
No
NETSHOW
Yes
No
No
No
PPTP
Yes
No
No
Yes
REALAUDIO
Yes
No
No
No
Sun RPC and RPC Port Map
Services
Yes
No
No
No
RTSP
Yes
No
No
Yes
SIP
Yes
No
No
No
SNMP
Yes
No
No
No
SQLNET
Yes
No
No
No
TFTP
Yes
No
No
Yes
338
Copyright © 2018, Juniper Networks, Inc.
Chapter 26: ALG Overview
Table 12: ALGs Supported by Junos OS (continued)
ALGs Supported
v4 - v4
v6 - v4
v6 - v6
DS-Lite (Support
for ALGs with
DS-lite on
MS-MPC and
MS-MIC starts in
Junos OS Release
18.1R1)
Traceroute
Yes
Yes
No
Yes
Unix Remote Shell Service
Yes
No
No
No
WINFrame
Yes
No
No
No
ALG Support Details
This section includes details about the ALGs. It includes the following:
•
Basic TCP ALG on page 340
•
Basic UDP ALG on page 340
•
BOOTP on page 341
•
DCE RPC Services on page 341
•
DNS on page 341
•
FTP on page 341
•
Gatekeeper RAS on page 342
•
H323 on page 342
•
ICMP on page 343
•
IIOP on page 343
•
IKE ALG on page 343
•
IP on page 344
•
NetBIOS on page 344
•
NetShow on page 344
•
ONC RPC Services on page 344
•
PPTP on page 344
•
RealAudio on page 344
•
Sun RPC and RPC Portmap Services on page 345
•
RTSP on page 347
•
SIP on page 347
•
SNMP on page 347
•
SQLNet on page 348
•
TFTP on page 348
Copyright © 2018, Juniper Networks, Inc.
339
Adaptive Services Interfaces Feature Guide for Routing Devices
•
Traceroute on page 348
•
UNIX Remote-Shell Services on page 348
•
Winframe on page 349
Basic TCP ALG
This ALG performs basic sanity checking on TCP packets. If it finds errors, it generates
the following anomaly events and system log messages:
•
TCP source or destination port zero
•
TCP header length check failed
•
TCP sequence number zero and no flags are set
•
TCP sequence number zero and FIN/PSH/RST flags are set
•
TCP FIN/RST or SYN(URG|FIN|RST) flags are set
The TCP ALG performs the following steps:
1.
When the router receives a SYN packet, the ALG creates TCP forward and reverse
flows and groups them in a conversation. It tracks the TCP three-way handshake.
2. The SYN-defense mechanism tracks the TCP connection establishment state. It
expects the TCP session to be established within a small time interval (currently
4 seconds). If the TCP three-way handshake is not established in that period, the
session is terminated.
3. A keepalive mechanism detects TCP sessions with nonresponsive endpoints.
4. ICMP errors are allowed only when a flow matches the selector information specified
in the ICMP data.
Basic UDP ALG
This ALG performs basic sanity checking on UDP headers. If it finds errors, it generates
the following anomaly events and system log messages:
•
UDP source or destination port 0
•
UDP header length check failed
The UDP ALG performs the following steps:
1.
When it receives the first packet, the ALG creates bidirectional flows to accept forward
and reverse UDP session traffic.
2. If the session is idle for more than the maximum allowed idle time (the default is
30 seconds), the flows are deleted.
3. ICMP errors are allowed only when a flow matches the selector information specified
in the ICMP data.
340
Copyright © 2018, Juniper Networks, Inc.
Chapter 26: ALG Overview
BOOTP
The Bootstrap Protocol (BOOTP) client retrieves its networking information from a server
across the network. It sends out a general broadcast message to request the information,
which is returned by the BOOTP server. For the protocol specification, see
ftp://ftp.isi.edu/in-notes/rfc951.txt.
Stateful firewall support requires that you configure the BOOTP ALG on UDP server
port 67 and client port 68. If the client sends a broadcast message, you should configure
the broadcast address in the from statement of the service rule. Network Address
Translation (NAT) is not performed on the BOOTP traffic, even if the NAT rule matches
the traffic. If the BOOTP relay feature is activated on the router, the remote BOOTP server
is assumed to assign addresses for clients masked by NAT translation.
DCE RPC Services
Distributed Computing Environment (DCE) Remote Procedure Call (RPC) services are
mainly used by Microsoft applications. The ALG uses well-known TCP port 135 for port
mapping services, and uses the universal unique identifier (UUID) instead of the program
number to identify protocols. The main application-based DCE RPC is the Microsoft
Exchange Protocol.
Support for stateful firewall and NAT services requires that you configure the DCE RPC
portmap ALG on TCP port 135. The DCE RPC ALG uses the TCP protocol with
application-specific UUIDs.
DNS
The Domain Name System (DNS) ALG handles data associated with locating and
translating domain names into IP addresses. The ALG typically runs on port 53. The ALG
monitors DNS query and reply packets and supports only UDP traffic. The ALG does not
support payload translations. The DNS ALG closes the session only when a reply is
received or an idle timeout is reached.
FTP
FTP is the File Transfer Protocol, specified in RFC 959. In addition to the main control
connection, data connections are also made for any data transfer between the client
and the server; and the host, port, and direction are negotiated through the control
channel.
For non-passive-mode FTP, Junos OS stateful firewall service scans the client-to-server
application data for the PORT command, which provides the IP address and port number
to which the server connects. For passive-mode FTP, Junos OS stateful firewall service
scans the client-to-server application data for the PASV command and then scans the
server-to-client responses for the 227 response, which contains the IP address and port
number to which the client connects.
There is an additional complication: FTP represents these addresses and port numbers
in ASCII. As a result, when addresses and ports are rewritten, the TCP sequence number
might be changed, and thereafter the NAT service needs to maintain this delta in SEQ
and ACK numbers by performing sequence NAT on all subsequent packets.
Copyright © 2018, Juniper Networks, Inc.
341
Adaptive Services Interfaces Feature Guide for Routing Devices
Support for stateful firewall and NAT services requires that you configure the FTP ALG
on TCP port 21 to enable the FTP control protocol. The ALG performs the following tasks:
•
Automatically allocates data ports and firewall permissions for dynamic data
connection
•
Creates flows for the dynamically negotiated data connection
•
Monitors the control connection in both active and passive modes
•
Rewrites the control packets with the appropriate NAT address and port information
On MS-MPCs and MS-MICs, for passive FTP to work properly without FTP application
layer gateway (ALG) enabled (by not specifying the application junos-ftp statement at
the [edit services stateful-firewall rule rule-name term term-name from] and the [edit
services nat rule rule-name term term-name from] hierarchy levels), you must enable the
address pooling paired (APP) functionality enabled (by including the address-pooling
statement at the [edit services nat rule rule-name term term-name then translated]
hierarchy level). Such a configuration causes the data and control FTP sessions to receive
the same NAT address.
Gatekeeper RAS
Starting in Junos OS Release 17.1R1, the gatekeeper registration, administration, and status
(RAS) ALG allows full support of gatekeeper mode for H.323 calls. An endpoint registers
to a gatekeeper and asks for its management. Before making a call, an endpoint asks its
gatekeeper for permission to place the call. In both registration and admission phases,
the RAS channel is used. Use the gatekeeper RAS ALG and the H323 ALG in IPv4 and
IPv6 stateful-firewall rules or NAPT-44 rules. Starting in Junos OS Release 17.2R1, NAT-64
rules are also supported. The Junos default application set junos-h323-suite includes the
H323 ALG and the gatekeeper RAS ALG.
H323
H323 is a suite of ITU protocols for audio and video conferencing and collaboration
applications. H323 consists of H.225 call signaling protocols and H.245 control protocol
for media communication. During H.225 negotiation, the endpoints create a call by
exchanging call signaling messages on the control channel and negotiate a new control
channel for H.245. A new control connection is created for H.245 messages. Messages
are exchanged on the H.245 control channel to open media channels.
Stateful firewall monitors the H.225 control channel to open the H.245 control channel.
After the H.245 channel is created, stateful firewall also monitors this channel for media
channel information and allows the media traffic throught the firewall.
H323 ALG supports static destination, static and dynamic source NAT by rewriting the
appropriate addresses and ports in the H.225 and H.245 messages.
To support gatekeeper mode for H.323 calls, use the H323 ALG and the gatekeeper RAS
ALG in IPv4 and IPv6 stateful-firewall rules or NAPT-44 rules. Starting in Junos OS Release
17.2R1, NAT-64 rules are also supported. The Junos default application set junos-h323-suite
includes the H323 ALG and the gatekeeper RAS ALG.
342
Copyright © 2018, Juniper Networks, Inc.
Chapter 26: ALG Overview
ICMP
The Internet Control Message Protocol (ICMP) is defined in RFC 792. The Junos OS
stateful firewall service allows ICMP messages to be filtered by specific type or specific
type code value. ICMP error packets that lack a specifically configured type and code are
matched against any existing flow in the opposite direction to check for the legitimacy
of the error packet. ICMP error packets that pass the filter matching are subject to NAT
translation.
The ICMP ALG always tracks ping traffic statefully using the ICMP sequence number.
Each echo reply is forwarded only if there is an echo request with the corresponding
sequence number. For any ping flow, only 20 echo requests can be forwarded without
receiving an echo reply. When you configure dynamic NAT, the PING packet identifier is
translated to allow additional hosts in the NAT pool to use the same identifier.
Support for stateful firewall and NAT services requires that you configure the ICMP ALG
if the protocol is needed. You can configure the ICMP type and code for additional filtering.
IIOP
The Oracle Application Server Name Server Internet Inter-ORB Protocol (IIOP). This ALG
is used in Common Object Request Broker Architecture (CORBA) based on distributed
computing. Even though CORBA and IIOP are Object Management Group (OMG)
standards, no fixed port is assigned for IIOP. Each vendor implementing CORBA chooses
a port. Java Virtual machine uses port 1975 by default, while ORBIX uses port 3075 as a
default.
Stateful firewall and NAT require ALG IIOP be configured for TCP port 1975 for Java VM
IIOP, and 3075 for CORBA applications ORBIX, a CORBA framework from Iona
Technologies.
IKE ALG
Starting in Junos OS Release 14.2R7, 15.1R5, 16.1R2, and 17.1R1, the IKE ALG enables the
passing of IKEv1 and IPsec packets through NAPT-44 and NAT64 rules between IPsec
peers that are not NAT-T compliant. This ALG supports only ESP tunnel mode.
Use this ALG in NAT rules and specify the UDP protocol and port 500.
This ALG performs the following:
•
Tracks IKEv1 connection-initiation requests to determine whether NAT processing is
required.
•
Performs NAT translation on outgoing and incoming IKEv1 requests and creates IKE
sessions.
•
Identifies IPsec packets related to the established IKE session and establishes security
association between peers.
•
Performs NAT translation on IPsec packets.
Copyright © 2018, Juniper Networks, Inc.
343
Adaptive Services Interfaces Feature Guide for Routing Devices
IP
The IP ALG is used to create unidirectional flows only. In case of TCP traffic, it does not
check the 3-way handshake process. This ALG is useful in case of stateful firewall only
service sets, where it allows traffic to flow uni-directionally only. When configuring in
conjunction with match-direction input-output it allows the return traffic to flow through
the stateful firewall as well. Typical scenarios are static NAT, destination NAT or scenarios
where traffic is expected to traverse the stateful firewall in the presence of asymmetric
routing. The Junos IP ALG is not intended for use with NAPT, which causes matching
traffic to be discarded through the creation of a drop flow.
NetBIOS
A NetBIOS ALG translates NetBIOS IP addresses and port numbers when NAT is used.
NetBIOS supports the TCP and UDP transport protocols. Support for stateful firewall
and NAT services requires that you configure the NetBIOS ALG on UDP port 138 and TCP
port 139.
NetShow
The Microsoft protocol ms-streaming is used by NetShow, the Microsoft media server.
This protocol supports several transport protocols: TCP, UDP, and HTTP. The client starts
a TCP connection on port 1755 and sends the PORT command to the server. The server
then starts UDP on that port to the client. Support for stateful firewall and NAT services
requires that you configure the NetShow ALG on UDP port 1755.
ONC RPC Services
Open Networks Computing (ONC) RPC services function similarly to DCE RCP services.
However, the ONC RPC ALG uses TCP/UDP port 111 for port mapping services, and uses
the program number to identify protocols rather than the UUID.
Support for stateful firewall and NAT services requires that you configure the ONC RPC
portmap ALG on TCP port 111. The ONC RPC ALG uses the TCP protocol with
application-specific program numbers.
PPTP
The Point-to-Point Tunneling Protocol (PPTP) ALG is a TCP-based ALG. PPTP allows
the Point-to-Point Protocol (PPP) to be tunneled through an IP network. PPTP defines
a client-server architecture, a PPTP Network Server, and a PPTP Access Concentrator.
The PPTP ALG requires a control connection and a data tunnel. The control connection
uses TCP to establish and disconnect PPP sessions, and runs on port 1723. The data
tunnel carries PPP traffic in generic routing encapsulated (GRE) packets that are carried
over IP.
RealAudio
Real Networks PNA protocol RealVideo is not a separate service. It is part of the RealPlayer
and most likely uses another channel for video. The RealPlayer versions G2, 7, and 8 use
PNA and RTSP. For this version to work, the ALG must allow both PNA(7070) and
RTSP(554). For the media, the server selects from a range of UDP ports(6970 through
344
Copyright © 2018, Juniper Networks, Inc.
Chapter 26: ALG Overview
7170), or TCP port 7071, or HTTP. The client can be configured to use a particular port.
The RealPlayer versions 4.0 and 5.0 use control channel 7070 media UDP ports 6970
through 7170, or TCP port 7071, or HTTP. RealAudio player version 3.0 uses control channel
7070 media, UDP ports 6770-7170, or TCP port 7071.
Real products use the ports and ranges of ports shown in Table 13 on page 345.
Table 13: RealAudio Product Port Usage
Real Product
Port Usage
4.0 and 5.0 Servers/Players
Control channel (bidirectional) on TCP port 7070. Data channel from server to player on TCP
port 7070 or UDP port 6970-7170.
4.0 and 5.0
Servers/Encoders
Control channel (bidirectional) on TCP port 7070. Data channel from encoder or server on TCP
port 7070.
G2 Servers/Players
Control channel (bidirectional) on TCP port 80, 554, 7070, or 8080. Data channel from server
to player on TCP port 80, 554, 7070, 8080 or UDP port 6970-32,000.
G2 Server/3.1, and 5.x
Encoders
Control channel (bidirectional) on TCP port 7070. Data channel from encoder to server on TCP
port 7070.
G2 Server/G2 Producer
Control channel (bidirectional) on TCP port 4040. Data channel from encoder to server on TCP
port 4040 and UDP port 6970-32,000.
2 Server/G2 Producer (TCP
ONLY)
Control channel (bidirectional) on TCP port 4040 Data channel from encoder to server on TCP
port 4040. Note: TCP-ONLY option available in version 6.1 or above.
NOTE: RealAudio was the original protocol by RealPlayers. Newer versions
of RealPlayer use RTSP. Stateful firewall and NAT require ALG RealAudio to
be programmed on TCP port 7070.
Sun RPC and RPC Portmap Services
The Remote Procedure Call (RPC) ALG uses well-known ports TCP 111 and UDP 111 for
port mapping, which dynamically assigns and opens ports for RPC services. The RPC
Portmap ALG keeps track of port requests and dynamically opens the firewall for these
requested ports. The RPC ALG can further restrict the RPC protocol by specifying allowed
program numbers.
The ALG includes the RPC services listed in Table 14 on page 345.
Table 14: Supported RPC Services
Name
Description
Comments
rpc-mountd
Network File Server (NFS) mount daemon; for
details, see the UNIX man page for
rpc.mountd(8).
The base support is RPC v2 and the port mapper service
on port 111 (see RFC 1050).
Copyright © 2018, Juniper Networks, Inc.
345
Adaptive Services Interfaces Feature Guide for Routing Devices
Table 14: Supported RPC Services (continued)
Name
Description
Comments
rpc-nfsprog
Used as part of NFS. For details, see RFC 1094.
See also RFC1813 for NFS v3.
The base support is RPC v2 and the port mapper service
on port 111 (see RFC 1050).
rpc-nisplus
Network Information Service Plus (NIS+),
designed to replace NIS; it is a default naming
service for Sun Solaris and is not related to the
old NIS. No protocol information is available.
The base support is RPC v2 and the port mapper service
on port 111 (see RFC 1050).
rpc-nlockmgr
Network lock manager.
The base support is RPC v2 and the port mapper service
on port 111 (see RFC 1050). Once the RPC program table
is built, rpc-nlockmgr service can be allowed or blocked
based on RPC program 100021.
rpc-pcnfsd
Kernel statistics server. For details, see the UNIX
man pages for rstatd and rpc.rstatd.
The base support is RPC v2 and the port mapper service
on port 111 (see RFC 1050). Once the RPC program table
is built, rpc-rstat service can be allowed or blocked based
on RPC program 150001.
rpc-rwall
Used to write a message to users; for details, see
the UNIX man page for rpc.rwalld.
The base support is RPC v2 and the port mapper service
on port 111 (see RFC 1050). Once the RPC program table
is built, rpc-rwall service can be allowed or blocked based
on RPC program 150008.
rpc-ypbind
NIS binding process. For details, see the UNIX
man page for ypbind.
The base support is RPC v2 and the port mapper service
on port 111 (see RFC 1050). Once the RPC program table
is built, rpc-ypbind service can be allowed or blocked
based on RPC program 100007.
rpc-yppasswd
NIS password server. For details, see the UNIX
man page for yppasswd.
The base support is RPC v2 and the port mapper service
on port 111 (see RFC 1050). Once the RPC program table
is built, rpc-yppasswd service can be allowed or blocked
based on RPC program 100009.
rpc-ypserv
NIS server. For details, see the UNIX man page
for ypserv.
The base support is RPC v2 and the port mapper service
on port 111 (see RFC 1050). Once the RPC program table
is built, rpc-ypserv service can be allowed or blocked
based on RPC program 100004.
rpc-ypupdated
Network updating tool.
The base support is RPC v2 and the port mapper service
on port 111 (see RFC 1050). Once the RPC program table
is built, rpc-ypupdated service can be allowed or blocked
based on RPC program 100028.
rpc-ypxfrd
NIS map transfer server. For details, see the UNIX
man page for rpc.ypxfrd.
The base support is RPC v2 and the port mapper service
on port 111 (see RFC 1050). Once the RPC program table
is built, rpc-ypxfrd service can be allowed or blocked
based on RPC program 100069.
Support for stateful firewall and NAT services that use port mapping requires that you
configure the RPC portmap ALG on TCP/UDP destination port 111 and the RPC ALG for
346
Copyright © 2018, Juniper Networks, Inc.
Chapter 26: ALG Overview
both TCP and UDP. You can specify one or more rpc-program-number values to further
restrict allowed RPC protocols.
RTSP
The Real-Time Streaming Protocol (RTSP) controls the delivery of data with real-time
properties such as audio and video. The streams controlled by RTSP can use RTP, but it
is not required. Media can be transmitted on the same RTSP control stream. This is an
HTTP-like text-based protocol, but client and server maintain session information. A
session is established using the SETUP message and terminated using the TEARDOWN
message. The transport (the media protocol, address, and port numbers) is negotiated
in the setup and the setup-response.
Support for stateful firewall and NAT services requires that you configure the RTSP ALG
for TCP port 554.
The ALG monitors the control connection, opens flows dynamically for media (RTP/RTSP)
streams, and performs NAT address and port rewrites.
SIP
The Session Initiation Protocol (SIP) is an application layer protocol that can establish,
maintain, and terminate media sessions. It is a widely used voice over IP (VoIP) signaling
protocol. The SIP ALG monitors SIP traffic and dynamically creates and manages pinholes
on the signaling and media paths. The ALG only allows packets with the correct
permissions. The SIP ALG also performs the following functions:
•
Manages parent-child session relationships.
•
Enforces security policies.
•
Manages pinholes for VoIP traffic.
The SIP ALG supports the following features:
•
Stateful firewall
•
Static source NAT
•
Dynamic address only source NAT
•
Network Address Port Translation (NAPT)
NOTE: SIP sessions are limited to 12 hours (720 minutes) for NAT processing
on the MS-MIC and MS-MPC interface cards. SIP sessions on the MS-DPC
have no time limit.
SNMP
SNMP is a communication protocol for managing TCP/IP networks, including both
individual network devices and aggregated devices. The protocol is defined by RFC 1157.
SNMP runs on top of UDP.
Copyright © 2018, Juniper Networks, Inc.
347
Adaptive Services Interfaces Feature Guide for Routing Devices
The Junos OS stateful firewall service implements the SNMP ALG to inspect the SNMP
type. SNMP does not enforce stateful flow. Each SNMP type needs to be specifically
enabled. Full SNMP support of stateful firewall services requires that you configure the
SNMP ALG on UDP port 161. This enables the SNMP get and get-next commands, as well
as their response traffic in the reverse direction: UDP port 161 enables the SNMP
get-response command. If SNMP traps are permitted, you can configure them on UDP
port 162, enabling the SNMP trap command.
SQLNet
The SQLNet protocol is used by Oracle SQL servers to execute SQL commands from
clients, including load balancing and application-specific services.
Support of stateful firewall and NAT services requires that you configure the SQLNet
ALG for TCP port 1521.
The ALG monitors the control packets, opens flows dynamically for data traffic, and
performs NAT address and port rewrites.
TFTP
The Trivial File Transfer Protocol (TFTP) is specified in RFC 1350. The initial TFTP requests
are sent to UDP destination port 69. Additional flows can be created to get or put individual
files. Support of stateful firewall and NAT services requires that you configure the TFTP
ALG for UDP destination port 69.
Traceroute
Traceroute is a tool for displaying the route that packets take to a network host. It uses
the IP time-to-live (TTL) field to trigger ICMP time-exceeded messages from routers or
gateways. It sends UDP datagrams to destination ports that are believed to be not in
use; destination ports are numbered using the formula: + nhops – 1. The default base
port is 33434. To support traceroute through the firewall, two types of traffic must be
passed through:
1.
UDP probe packets (UDP destination port > 33000, IP TTL < 30)
2. ICMP response packets (ICMP type time-exceeded)
When NAT is applied, the IP address and port within the ICMP error packet also must be
changed.
Support of stateful firewall and NAT services requires you to configure the Traceroute
ALG for UDP destination port 33434 to 33450. In addition, you can configure the TTL
threshold to prevent UDP flood attacks with large TTL values.
UNIX Remote-Shell Services
Three protocols form the basis for UNIX remote-shell services:
•
348
Exec—Remote command execution; enables a user on the client system to execute a
command on the remote system. The first command from client (rcmd) to server (rshd)
uses well-known TCP port 512. A second TCP connection can be opened at the request
Copyright © 2018, Juniper Networks, Inc.
Chapter 26: ALG Overview
of rcmd. The client port number for the second connection is sent to the server as an
ASCII string.
•
Login—Better known as rlogin; uses well-known TCP port 513. For details, see RFC 1282.
No special firewall processing is required.
•
Shell—Remote command execution; enables a user on the client system to execute
a command on the remote system. The first command from client (rcmd) to server
(rshd) uses well-known TCP port 514. A second TCP connection can be opened at the
request of rcmd. The client port number for the second connection is sent to the server
as an ASCII string.
Support of stateful firewall services requires that you configure the Exec ALG on TCP
port 512, the Login ALG on TCP port 513, and the Shell ALG on TCP port 514. NAT
remote-shell services require that any dynamic source port assigned be within the port
range 512 to 1023. If you configure a NAT pool, this port range is reserved exclusively for
remote shell applications.
Winframe
WinFrame application server software provides access to virtually any Windows
application, across any type of network connection to any type of client.
This protocol is mainly used by Citrix Windows applications.
Stateful firewall and NAT require the ALG Winframe to be configured on TCP destination
port 1494 and UDP port 1604.
Juniper Networks Defaults
The Junos OS provides a default, hidden configuration group called junos-defaults that
is automatically applied to the configuration of your router. The junos-defaults group
contains preconfigured statements that contain predefined values for common
applications. Some of the statements must be referenced to take effect, such as
applications like FTP or Telnet. Other statements are applied automatically, such as
terminal settings. All of the preconfigured statements begin with the reserved name
junos-.
NOTE: You can override the Junos OS default configuration values, but you
cannot delete or edit them. If you delete a configuration, the defaults return
when a new configuration is added.
You cannot use the apply-groups statement with the Junos OS defaults group.
To view the full set of available preset statements from the Junos OS default group, issue
the show groups junos-defaults configuration mode command. The following example
displays the list of Junos OS default groups that use application protocols (ALGs):
user@host# show groups junos-defaults
applications {
#
# File Transfer Protocol
Copyright © 2018, Juniper Networks, Inc.
349
Adaptive Services Interfaces Feature Guide for Routing Devices
#
application junos-ftp {
application-protocol ftp;
protocol tcp;
destination-port 21;
}
#
# Trivial File Transfer Protocol
#
application junos-tftp {
application-protocol tftp;
protocol udp;
destination-port 69;
}
#
# RPC portmapper on TCP
#
application junos-rpc-portmap-tcp {
application-protocol rpc-portmap;
protocol tcp;
destination-port 111;
}
#
# RPC portmapper on UDP
#
application junos-rpc-portmap-udp {
application-protocol rpc-portmap;
protocol udp;
destination-port 111;
}
#
# SNMP get
#
application junos-snmp-get {
application-protocol snmp;
protocol udp;
destination-port 161;
snmp-command get;
}
#
# SNMP get next
#
application junos-snmp-get-next {
application-protocol snmp;
protocol udp;
destination-port 161;
snmp-command get-next;
}
#
# SNMP response
#
application junos-snmp-response {
application-protocol snmp;
protocol udp;
source-port 161;
snmp-command get-response;
350
Copyright © 2018, Juniper Networks, Inc.
Chapter 26: ALG Overview
}
#
# SNMP trap
#
application junos-snmp-trap {
application-protocol snmp;
protocol udp;
destination-port 162;
snmp-command trap;
}
#
# remote exec
#
application junos-rexec {
application-protocol exec;
protocol tcp;
destination-port 512;
}
#
# remote login
#
application junos-rlogin {
application-protocol shell;
protocol tcp;
destination-port 513;
}
#
# remote shell
#
application junos-rsh {
application-protocol shell;
protocol tcp;
destination-port 514;
}
#
# Real Time Streaming Protocol
#
application junos-rtsp {
application-protocol rtsp;
protocol tcp;
destination-port 554;
}
#
# Citrix windows application server protocol
# windows applications remotely on windows/non-windows clients
#
# citrix needs udp 1604 to be open
#
application junos-citrix-winframe {
application-protocol winframe;
protocol tcp;
destination-port 1494;
}
application junos-citrix-winframe-udp {
protocol udp;
destination-port 1604;
Copyright © 2018, Juniper Networks, Inc.
351
Adaptive Services Interfaces Feature Guide for Routing Devices
}
#
# Oracle SQL servers use this protocol to execute sql commands
# from clients, load balance, use application-specific servers, etc
#
application junos-sqlnet {
application-protocol sqlnet;
protocol tcp;
destination-port 1521;
}
#
# H.323 Protocol for audio/video conferencing
#
application junos-h323 {
application-protocol h323;
protocol tcp;
destination-port 1720;
}
application junos-h323-ras {
application-protocol ras;
protocol udp;
destination-port 1719;
}
#
# Internet Inter-ORB Protocol - used for CORBA applications
# The ORB protocol in Java virtual machines uses port 1975 as default
#
application junos-iiop-java {
application-protocol iiop;
protocol tcp;
destination-port 1975;
}
#
# Internet Inter-ORB Protocol - used for CORBA applications
# ORBIX is a CORBA framework from Iona Technologies that uses port
# 3075 as default
#
application junos-iiop-orbix {
application-protocol iiop;
protocol tcp;
destination-port 3075;
}
#
# Real players use this protocol for real time streaming
# This was the original protocol for real players.
# RTSP is more widely used by real players
# but they still support realaudio.
#
application junos-realaudio {
application-protocol realaudio;
protocol tcp;
destination-port 7070;
}
#
# traceroute application.
#
352
Copyright © 2018, Juniper Networks, Inc.
Chapter 26: ALG Overview
application junos-traceroute {
application-protocol traceroute;
protocol udp;
destination-port 33435-33450;
ttl-threshold 30;
}
#
# The full range of known RPC programs using UDP
# The program numbers can be more specific to certain applications.
#
application junos-rpc-services-udp {
application-protocol rpc;
protocol udp;
rpc-program-number 100000-400000;
}
#
# The full range of known RPC programs using TCP
# The program numbers can be more specific to certain applications.
#
application junos-rpc-services-tcp {
application-protocol rpc;
protocol tcp;
rpc-program-number 100000-400000;
}
#
# All ICMP traffic
# This can be made to be more restrictive by specifying ICMP type
# and code.
#
application junos-icmp-all {
application-protocol icmp;
}
#
# Protocol used by Windows media server and windows media player
#
application junos-netshow {
application-protocol netshow;
protocol tcp;
destination-port 1755;
}
#
# NetBIOS - networking protocol used on
# Windows networks name service port, both UDP and TCP
#
application junos-netbios-name-udp {
application-protocol netbios;
protocol udp;
destination-port 137;
}
application junos-netbios-name-tcp {
protocol tcp;
destination-port 137;
}
#
# NetBIOS - networking protocol used on
# Windows networks datagram service port
Copyright © 2018, Juniper Networks, Inc.
353
Adaptive Services Interfaces Feature Guide for Routing Devices
#
application junos-netbios-datagram {
application-protocol netbios;
protocol udp;
destination-port 138;
}
#
# NetBIOS - networking protocol used on
# Windows networks session service port
#
application junos-netbios-session {
protocol tcp;
destination-port 139;
}
#
# DCE-RPC portmapper on TCP
#
application junos-dce-rpc-portmap {
application-protocol dce-rpc-portmap;
protocol tcp;
destination-port 135;
}
#
# DCE-RPC application on TCP sample UUID
# This application requires user to specify the UUID value
#
# application junos-dcerpc {
# application-protocol dce-rpc;
# protocol tcp;
#
# # UUID also needs to be defined as shown below
# UUID 11223344 22334455 33445566 44556677;
#
#}
#
# ms-exchange needs these 3 UUIDs
#
application junos-dcerpc-endpoint-mapper-service {
application-protocol dce-rpc;
protocol tcp;
uuid e1af8308-5d1f-11c9-91a4-08002b14a0fa;
}
application junos-dcerpc-msexchange-directory-rfr {
application-protocol dce-rpc;
protocol tcp;
uuid 1544f5e0-613c-11d1-93df-00c04fd7bd09;
}
application junos-dcerpc-msexchange-information-store {
application-protocol dce-rpc;
protocol tcp;
uuid a4f1db00-ca47-1067-b31f-00dd010662da;
}
application junos-ssh {
protocol tcp;
destination-port 22;
}
354
Copyright © 2018, Juniper Networks, Inc.
Chapter 26: ALG Overview
application junos-telnet {
protocol tcp;
destination-port 23;
}
application junos-smtp {
protocol tcp;
destination-port 25;
}
application junos-dns-udp {
protocol udp;
destination-port 53;
}
application junos-dns-tcp {
protocol tcp;
destination-port 53;
}
application junos-tacacs {
protocol tcp;
destination-port 49;
}
# TACACS Database Service
application junos-tacacs-ds {
protocol tcp;
destination-port 65;
}
application junos-dhcp-client {
protocol udp;
destination-port 68;
}
application junos-dhcp-server {
protocol udp;
destination-port 67;
}
application junos-bootpc {
protocol udp;
destination-port 68;
}
application junos-bootps {
protocol udp;
destination-port 67;
}
application junos-finger {
protocol tcp;
destination-port 79;
}
application junos-http {
protocol tcp;
destination-port 80;
}
application junos-https {
protocol tcp;
destination-port 443;
}
application junos-pop3 {
protocol tcp;
destination-port 110;
Copyright © 2018, Juniper Networks, Inc.
355
Adaptive Services Interfaces Feature Guide for Routing Devices
}
application junos-ident {
protocol tcp;
destination-port 113;
}
application junos-nntp {
protocol tcp;
destination-port 119;
}
application junos-ntp {
protocol udp;
destination-port 123;
}
application junos-imap {
protocol tcp;
destination-port 143;
}
application junos-imaps {
protocol tcp;
destination-port 993;
}
application junos-bgp {
protocol tcp;
destination-port 179;
}
application junos-ldap {
protocol tcp;
destination-port 389;
}
application junos-snpp {
protocol tcp;
destination-port 444;
}
application junos-biff {
protocol udp;
destination-port 512;
}
# UNIX who
application junos-who {
protocol udp;
destination-port 513;
}
application junos-syslog {
protocol udp;
destination-port 514;
}
# line printer daemon, printer, spooler
application junos-printer {
protocol tcp;
destination-port 515;
}
# UNIX talk
application junos-talk-tcp {
protocol tcp;
destination-port 517;
}
356
Copyright © 2018, Juniper Networks, Inc.
Chapter 26: ALG Overview
application junos-talk-udp {
protocol udp;
destination-port 517;
}
application junos-ntalk {
protocol udp;
destination-port 518;
}
application junos-rip {
protocol udp;
destination-port 520;
}
# INA sanctioned RADIUS port numbers
application junos-radius {
protocol udp;
destination-port 1812;
}
application junos-radacct {
protocol udp;
destination-port 1813;
}
application junos-nfsd-tcp {
protocol tcp;
destination-port 2049;
}
application junos-nfsd-udp {
protocol udp;
destination-port 2049;
}
application junos-cvspserver {
protocol tcp;
destination-port 2401;
}
#
# Label Distribution Protocol
#
application junos-ldp-tcp {
protocol tcp;
destination-port 646;
}
application junos-ldp-udp {
protocol udp;
destination-port 646;
}
#
# JUNOScript and JUNOScope management
#
application junos-xnm-ssl {
protocol tcp;
destination-port 3220;
}
application junos-xnm-clear-text {
protocol tcp;
destination-port 3221;
}
#
Copyright © 2018, Juniper Networks, Inc.
357
Adaptive Services Interfaces Feature Guide for Routing Devices
# IPsec tunnel
#
application junos-ipsec-esp {
protocol esp;
}
#
#IKE application for IPSec VPN
#
application junos-ike {
application-protocol ike-esp-nat;
protocol udp;
destination-port 500;
}
#
# 'junos-algs-outbound' defines a set of all applications
# requiring an ALG. Useful for defining rule to the the public
# internet allowing private network users to use all JUNOS OS
# supported ALGs initiated from the private network.
#
# NOTE: the contents of this set might grow in future JUNOS OS versions.
#
application-set junos-algs-outbound {
application junos-ftp;
application junos-tftp;
application junos-rpc-portmap-tcp;
application junos-rpc-portmap-udp;
application junos-snmp-get;
application junos-snmp-get-next;
application junos-snmp-response;
application junos-snmp-trap;
application junos-rexec;
application junos-rlogin;
application junos-rsh;
application junos-rtsp;
application junos-citrix-winframe;
application junos-citrix-winframe-udp;
application junos-sqlnet;
application junos-h323;
application junos-iiop-java;
application junos-iiop-orbix;
application junos-realaudio;
application junos-traceroute;
application junos-rpc-services-udp;
application junos-rpc-services-tcp;
application junos-icmp-all;
application junos-netshow;
application junos-netbios-name-udp;
application junos-netbios-datagram;
application junos-dcerpc-endpoint-mapper-service;
application junos-dcerpc-msexchange-directory-rfr;
application junos-dcerpc-msexchange-information-store;
}
#
# 'junos-management-inbound' represents the group of applications
# that might need access the router from public network for
# for management purposes.
358
Copyright © 2018, Juniper Networks, Inc.
Chapter 26: ALG Overview
#
# Set is intended for a UI to display management choices.
#
# NOTE: It is not recommended the user to use the entire set
# directly in a firewall rule and open up firewall to all
# of these applications. Also, the user should always
# specify the source and destination prefixes when using
# each application.
#
# NOTE: the contents of this set may grow in future JUNOS versions.
#
application-set junos-management-inbound {
application junos-snmp-get;
application junos-snmp-get-next;
application junos-snmp-response;
application junos-snmp-trap;
application junos-ssh;
application junos-telnet;
application junos-http;
application junos-https;
application junos-xnm-ssl;
application junos-xnm-clear-text;
}
#
# 'junos-routing-inbound' represents routing protocols that might
# need to access the router from public network.
#
# Set is intended for a UI to display routing involvement choices.
#
# NOTE: It is not recommended the user to use the entire set
# directly in a firewall rule and open up firewall to all
# of these applications. Also, the user should always
# specify the source and destination prefixes when using
# each application.
#
# NOTE: the contents of this set might grow in future JUNOS OS versions.
#
application-set junos-routing-inbound {
application junos-bgp;
application junos-rip;
application junos-ldp-tcp;
application junos-ldp-udp;
}
application-set junos-h323-suite {
application junos-h323-ras,
application junos-h323;
}
}
To reference statements available from the junos-defaults group, include the selected
junos-default-name statement at the applicable hierarchy level. To configure application
protocols, see “Configuring Application Properties” on page 367; for details about a specific
protocol, see “ALG Descriptions” on page 337.
Copyright © 2018, Juniper Networks, Inc.
359
Adaptive Services Interfaces Feature Guide for Routing Devices
Examples: Referencing the Preset Statement from the Junos OS Default Group
The following example is a preset statement from the Junos OS default groups that is
available for FTP in a stateful firewall:
[edit]
groups {
junos-defaults {
applications {
application junos-ftp { # Use FTP default configuration
application-protocol ftp;
protocol tcp;
destination-port 21;
}
}
}
To reference a preset Junos OS default statement from the Junos OS default groups,
include the junos-default-name statement at the applicable hierarchy level. For example,
to reference the Junos OS default statement for FTP in a stateful firewall, include the
junos-ftp statement at the [edit services stateful-firewall rule rule-name term term-name
from applications] hierarchy level.
[edit]
services {
stateful-firewall {
rule my-rule {
term my-term {
from {
applications junos-ftp; #Reference predefined statement, junos-ftp,
}
}
}
}
}
The following example shows configuration of the default Junos IP ALG:
[edit]
services {
stateful-firewall {
rule r1 {
match-direction input;
term t1 {
from {
applications junos-ip;
}
then {
accept;
syslog;
}
}
}
}
}
360
Copyright © 2018, Juniper Networks, Inc.
Chapter 26: ALG Overview
If you configure the IP ALG in the stateful firewall rule, it is matched by any IP traffic, but
when any other more specific application matches the same traffic, the IP ALG is not
matched. For example, in the following configuration, both the ICMP ALG and the IP ALG
are configured, but traffic is matched for ICMP packets, because it is the more specific
match.
[edit]
services {
stateful-firewall {
rule r1 {
match-direction input;
term t1 {
from {
applications [ junos-ip junos-icmp-all ];
}
then {
accept;
syslog;
}
}
}
}
}
Release History Table
Related
Documentation
Release
Description
18.1R1
Support for ALGs with DS-lite on MS-MPC and MS-MIC starts in Junos OS
Release 18.1R1
17.2R1
(Starting in Junos OS Release 17.2R1)
17.2R1
(Starting in Junos OS Release 17.2R1)
17.2R1
Starting in Junos OS Release 17.2R1, NAT-64 rules are also supported.
17.2R1
Starting in Junos OS Release 17.2R1, NAT-64 rules are also supported.
17.1R1
(Starting in Junos OS Release 17.1R1)
17.1R1
Starting in Junos OS Release 17.1R1, the gatekeeper registration,
administration, and status (RAS) ALG allows full support of gatekeeper
mode for H.323 calls.
14.2R7
IKE ALG (Starting in Junos OS Release 14.2R7, 15.1R5, 16.1R2, and 17.1R1)
14.2R7
Starting in Junos OS Release 14.2R7, 15.1R5, 16.1R2, and 17.1R1, the IKE ALG
enables the passing of IKEv1 and IPsec packets through NAPT-44 and NAT64
rules between IPsec peers that are not NAT-T compliant.
•
Configuring Application Sets on page 367
•
Configuring Application Properties on page 367
Copyright © 2018, Juniper Networks, Inc.
361
Adaptive Services Interfaces Feature Guide for Routing Devices
ALGs Available for Junos OS Address Aware NAT
The following Application Level Gateways (ALGs) listed in Table 10 on page 148 are
supported for NAT processing on the listed platforms.
To view the implementation details (port, protocol, and so on) for these Junos OS default
applications, locate the Junos OS Default ALG Name in the table and then look up the
listed name in the groups. For example, for details about TFTP, look up junos-tftp as
shown.
TIP: The Junos OS provides the junos-alg, which enables other ALGs to
function by handling ALG registrations, causing slow path packets to flow
through registered ALGs, and transferring ALG events to the ALG plug-ins.
The junos-alg ALG is automatically available on the MS-MPC and MS-MIC
platforms and does not require further configuration.
NOTE: The remote shell (RSH) and remote login (rlogin) application layer
gateways (ALGs) are not supported with network address port translation
(NAPT) on MX Series routers with MS-MICs and MS-MPCs.
user@host# show groups junos-defaults applications application junos-tftp
application-protocol tftp;
protocol udp;
destination-port 69;
Table 10 on page 148 summarizes the ALGs available for Junos OS Address Aware NAT
for services interfaces cards.
Table 15: ALGs Available for NAT by Type of Interface Card
ALG
MS-DPC
MS-MPC, MS-MIC
Junos OS Default ALG Name
Basic TCP ALG
yes
yes
NOTE: Specific Junos OS ALGs are not
supported. However, a feature called TCP
tracker, available by default, performs segment
ordering and retransmit and connection tracking,
validations for TCP connections.
Basic UDP ALG
yes
yes
NOTE: TCP tracker performs limited integrity
and validation checks for UDP.
BOOTP
yes
no
•
junos-bootpc
•
junos-bootps
362
Copyright © 2018, Juniper Networks, Inc.
Chapter 26: ALG Overview
Table 15: ALGs Available for NAT by Type of Interface Card (continued)
ALG
MS-DPC
MS-MPC, MS-MIC
Junos OS Default ALG Name
DCE RPC Services
yes
yes
•
junos-dce-rpc-portmap
•
junos-dcerpc-endpoint-mapper-service
•
junos-dcerpc-msexchange-directory-nsp
•
junos-dcerpc-msexchange-directory-rfr
•
junos-dcerpc-msexchange-information-store
DNS
yes
yes
•
junos-dns-udp
DNS
yes
no
•
junos-dns-tcp
FTP
yes
yes
•
junos-ftp
Gatekeeper RAS
(Starting in Junos OS
Release 17.1R1)
no
yes
•
junos-h323-ras
H323
no
yes
•
junos-h323
ICMP
yes
yes
•
junos-icmp-all
•
junos-icmp-ping
•
junos-iiop-java
•
junos-iiop-orbix
•
junos-ike
NOTE: In Junos OS Release 14.1
and earlier, ICMP messages are
handled by default, but PING ALG
support is not provided. Starting
In Junos OS 14.2, ICMP messages
are handled by default and PING
ALG support is provided.
IIOP
IKE ALG
yes
no
no
yes
NOTE: Starting in Junos OS
Release 14.2R7, 15.1R5, 16.1R2,
and 17.1R1, the IKE ALG ALG is
supported on MS-MPCs and
MS-MICs.
IP
yes
The TCP tracker, available by
default on these platforms,
performs limited integrity and
validation checks.
•
junos-ip
NETBIOS
yes
no
•
junos-netbios-datagram
•
junos-netbios-name-tcp
•
junos-netbios-name-udp
•
junos-netbios-session
•
junos-netshow
NETSHOW
yes
Copyright © 2018, Juniper Networks, Inc.
no
363
Adaptive Services Interfaces Feature Guide for Routing Devices
Table 15: ALGs Available for NAT by Type of Interface Card (continued)
ALG
MS-DPC
MS-MPC, MS-MIC
Junos OS Default ALG Name
PPTP
yes
yes
•
junos-pptp
REALAUDIO
yes
no
•
junos-realaudio
Sun RPC and RPC Port
Map Services
yes
yes
•
junos-rpc-portmap-tcp
•
junos-rpc-portmap-udp
RTSP
yes
yes
•
junos-rtsp
SIP
yes
Yes
•
junos-sip
The SIP callid is not translated in register
messages.
NOTE: SIP sessions are limited to 12 hours (720
minutes) for NAT processing on the MS-MIC and
MS-MPC interface cards. SIP sessions on the
MS-DPC have no time limits.
SNMP
yes
No
•
junos-snmp-get
•
junos-snmp-get-next
•
junos-snmp-response
•
junos-snmp-trap
SQLNET
yes
yes
•
junos-sqlnet
TFTP
yes
yes
•
junos-tftp
Traceroute
yes
yes
•
junos-traceroute
Unix Remote Shell
Service
yes
yes
•
junos-rsh
•
junos-citrix-winframe
•
junos-citrix-winframe-udp
NOTE: Remote Shell (RSH) ALG
is not supported for network
address port translation (NAPT).
WINFrame
yes
No
TALK-UDP
No
Yes
•
junos-talk-udp
MS RPC
No
Yes
•
junos-rpc-portmap-tcp
•
junos-rpc-portmap-udp
•
junos-rpc-services-tcp
•
junos-rpc-services-udp
364
Copyright © 2018, Juniper Networks, Inc.
Chapter 26: ALG Overview
Release History Table
Related
Documentation
•
Release
Description
17.1R1
Gatekeeper RAS (Starting in Junos OS Release 17.1R1)
14.2R7
Starting in Junos OS Release 14.2R7, 15.1R5, 16.1R2, and 17.1R1, the IKE ALG
ALG is supported on MS-MPCs and MS-MICs.
14.2
Starting In Junos OS 14.2, ICMP messages are handled by default and PING
ALG support is provided.
ALG Descriptions on page 337
Copyright © 2018, Juniper Networks, Inc.
365
Adaptive Services Interfaces Feature Guide for Routing Devices
366
Copyright © 2018, Juniper Networks, Inc.
CHAPTER 27
ALGs Configuration Overview
•
Configuring Application Sets on page 367
•
Configuring Application Properties on page 367
•
Examples: Configuring Application Protocols on page 386
•
Verifying the Output of ALG Sessions on page 387
•
ICMP, Ping, and Traceroute ALGs for MS-MICs and MS-MPCs on page 393
•
Monitoring Port Control Protocol Operations on page 394
Configuring Application Sets
You can group the applications you have defined into a named object by including the
application-set statement at the [edit applications] hierarchy level with an application
statement for each application:
[edit applications]
application-set application-set-name {
application application;
}
For an example of a typical application set, see “Examples: Configuring Application
Protocols” on page 386.
Related
Documentation
•
ALG Descriptions on page 337
•
Configuring Application Properties on page 367
•
Examples: Configuring Application Protocols on page 386
•
Verifying the Output of ALG Sessions on page 387
Configuring Application Properties
To configure application properties, include the application statement at the [edit
applications] hierarchy level:
[edit applications]
application application-name {
application-protocol protocol-name;
child-inactivity-timeout seconds;
Copyright © 2018, Juniper Networks, Inc.
367
Adaptive Services Interfaces Feature Guide for Routing Devices
destination-port port-number;
gate-timeout seconds;
icmp-code value;
icmp-type value;
inactivity-timeout value;
protocol type;
rpc-program-number number;
snmp-command command;
source-port port-number;
ttl-threshold value;
uuid hex-value;
}
You can group application objects by configuring the application-set statement; for more
information, see “Configuring Application Sets” on page 367.
This section includes the following tasks for configuring applications:
•
Configuring an Application Protocol on page 368
•
Configuring the Network Protocol on page 370
•
Configuring the ICMP Code and Type on page 372
•
Configuring Source and Destination Ports on page 373
•
Configuring the Inactivity Timeout Period on page 376
•
Configuring an IKE ALG Application on page 376
•
Configuring SIP on page 377
•
Configuring an SNMP Command for Packet Matching on page 385
•
Configuring an RPC Program Number on page 385
•
Configuring the TTL Threshold on page 385
•
Configuring a Universal Unique Identifier on page 385
Configuring an Application Protocol
The application-protocol statement allows you to specify which of the supported
application protocols (ALGs) to configure and include in an application set for service
processing. To configure application protocols, include the application-protocol statement
at the [edit applications application application-name] hierarchy level:
[edit applications application application-name]
application-protocol protocol-name;
Table 16 on page 368 shows the list of supported protocols. For more information about
specific protocols, see “ALG Descriptions” on page 337.
Table 16: Application Protocols Supported by Services Interfaces
Protocol Name
CLI Value
Comments
Bootstrap protocol (BOOTP)
bootp
Supports BOOTP and dynamic host configuration protocol (DHCP).
Distributed Computing Environment
(DCE) remote procedure call (RPC)
dce-rpc
Requires the protocol statement to have the value udp or tcp. Requires
a uuid value. You cannot specify destination-port or source-port values.
368
Copyright © 2018, Juniper Networks, Inc.
Chapter 27: ALGs Configuration Overview
Table 16: Application Protocols Supported by Services
Interfaces (continued)
Protocol Name
CLI Value
Comments
DCE RPC portmap
dce-rpc-portmap
Requires the protocol statement to have the value udp or tcp. Requires
a destination-port value.
Domain Name System (DNS)
dns
Requires the protocol statement to have the value udp. This application
protocol closes the DNS flow as soon as the DNS response is received.
Exec
exec
Requires the protocol statement to have the value tcp or to be
unspecified. Requires a destination-port value.
FTP
ftp
Requires the protocol statement to have the value tcp or to be
unspecified. Requires a destination-port value.
H.323
h323
–
IKE ALG
ike-esp-nat
Requires the protocol statement to have the value udp and requires
the destination-port value to be 500.
Internet Control Message Protocol
(ICMP)
icmp
Requires the protocol statement to have the value icmp or to be
unspecified.
Internet Inter-ORB Protocol
iiop
–
IP
ip
–
Login
login
–
NetBIOS
netbios
Requires the protocol statement to have the value udp or to be
unspecified. Requires a destination-port value.
NetShow
netshow
Requires the protocol statement to have the value tcp or to be
unspecified. Requires a destination-port value.
Point-to-Point Tunneling Protocol
pptp
–
RealAudio
realaudio
–
Real-Time Streaming Protocol
(RTSP)
rtsp
Requires the protocol statement to have the value tcp or to be
unspecified. Requires a destination-port value.
RPC User Datagram Protocol (UDP)
or TCP
rpc
Requires the protocol statement to have the value udp or tcp. Requires
a rpc-program-number value. You cannot specify destination-port or
source-port values.
RPC port mapping
rpc-portmap
Requires the protocol statement to have the value udp or tcp. Requires
a destination-port value.
Shell
shell
Requires the protocol statement to have the value tcp or to be
unspecified. Requires a destination-port value.
Copyright © 2018, Juniper Networks, Inc.
369
Adaptive Services Interfaces Feature Guide for Routing Devices
Table 16: Application Protocols Supported by Services
Interfaces (continued)
Protocol Name
CLI Value
Comments
Session Initiation Protocol
sip
–
SNMP
snmp
Requires the protocol statement to have the value udp or to be
unspecified. Requires a destination-port value.
SQLNet
sqlnet
Requires the protocol statement to have the value tcp or to be
unspecified. Requires a destination-port or source-port value.
Talk Program
talk
Trace route
traceroute
Requires the protocol statement to have the value udp or to be
unspecified. Requires a destination-port value.
Trivial FTP (TFTP)
tftp
Requires the protocol statement to have the value udp or to be
unspecified. Requires a destination-port value.
WinFrame
winframe
–
NOTE: You can configure application-level gateways (ALGs) for ICMP and
trace route under stateful firewall, NAT, or CoS rules when twice NAT is
configured in the same service set. These ALGs cannot be applied to flows
created by the Packet Gateway Controller Protocol (PGCP). Twice NAT does
not support any other ALGs. NAT applies only the IP address and TCP or UDP
headers, but not the payload.
For more information about configuring twice NAT, see “Junos Address Aware
Network Addressing Overview” on page 45.
Related
Documentation
•
ALGs Available for Junos OS Address Aware NAT on page 147
Configuring the Network Protocol
The protocol statement allows you to specify which of the supported network protocols
to match in an application definition. To configure network protocols, include the protocol
statement at the [edit applications application application-name] hierarchy level:
[edit applications application application-name]
protocol type;
You specify the protocol type as a numeric value; for the more commonly used protocols,
text names are also supported in the command-line interface (CLI). Table 17 on page 371
shows the list of the supported protocols.
370
Copyright © 2018, Juniper Networks, Inc.
Chapter 27: ALGs Configuration Overview
Table 17: Network Protocols Supported by Services Interfaces
CLI
Value
Comments
IP Security (IPsec) authentication header
(AH)
ah
–
External Gateway Protocol (EGP)
egp
–
IPsec Encapsulating Security Payload (ESP)
esp
–
Generic routing encapsulation (GR)
gre
–
ICMP
icmp
Requires an application-protocol value of icmp.
ICMPv6
icmp6
Requres an application-protocol value of icmp.
Internet Group Management Protocol
(IGMP)
igmp
–
IP in IP
ipip
–
OSPF
ospf
–
Protocol Independent Multicast (PIM)
pim
–
Resource Reservation Protocol (RSVP)
rsvp
–
TCP
tcp
Requires a destination-port or source-port value unless you specify
application-protocol rcp or dce-rcp.
UDP
udp
Requires a destination-port or source-port value unless you specify
application-protocol rcp or dce-rcp.
Network Protocol Type
For a complete list of possible numeric values, see RFC 1700, Assigned Numbers (for the
Internet Protocol Suite).
NOTE: IP version 6 (IPv6) is not supported as a network protocol in
application definitions.
By default, the twice NAT feature can affect IP, TCP, and UDP headers
embedded in the payload of ICMP error messages. You can include the
protocol tcp and protocol udp statements with the application statement for
twice NAT configurations. For more information about configuring twice NAT,
see “Junos Address Aware Network Addressing Overview” on page 45.
Copyright © 2018, Juniper Networks, Inc.
371
Adaptive Services Interfaces Feature Guide for Routing Devices
Configuring the ICMP Code and Type
The ICMP code and type provide additional specification, in conjunction with the network
protocol, for packet matching in an application definition. To configure ICMP settings,
include the icmp-code and icmp-type statements at the [edit applications application
application-name] hierarchy level:
[edit applications application application-name]
icmp-code value;
icmp-type value;
You can include only one ICMP code and type value. The application-protocol statement
must have the value icmp. Table 18 on page 372 shows the list of supported ICMP values.
Table 18: ICMP Codes and Types Supported by Services Interfaces
CLI Statement
Description
icmp-code
This value or keyword provides more specific information than icmp-type.
Because the value’s meaning depends upon the associated icmp-type
value, you must specify icmp-type along with icmp-code. For more
information, see the Routing Policies, Firewall Filters, and Traffic Policers
Feature Guide.
In place of the numeric value, you can specify one of the following text
synonyms (the field values are also listed). The keywords are grouped
by the ICMP type with which they are associated:
parameter-problem: ip-header-bad (0), required-option-missing (1)
redirect: redirect-for-host (1), redirect-for-network (0),
redirect-for-tos-and-host (3), redirect-for-tos-and-net (2)
time-exceeded: ttl-eq-zero-during-reassembly (1),
ttl-eq-zero-during-transit (0)
unreachable: communication-prohibited-by-filtering (13),
destination-host-prohibited (10), destination-host-unknown (7),
destination-network-prohibited (9), destination-network-unknown (6),
fragmentation-needed (4), host-precedence-violation (14),
host-unreachable (1), host-unreachable-for-TOS (12),
network-unreachable (0), network-unreachable-for-TOS (11),
port-unreachable (3), precedence-cutoff-in-effect (15),
protocol-unreachable (2), source-host-isolated (8), source-route-failed (5)
icmp-type
Normally, you specify this match in conjunction with the protocol match
statement to determine which protocol is being used on the port. For
more information, see the Routing Policies, Firewall Filters, and Traffic
Policers Feature Guide.
In place of the numeric value, you can specify one of the following text
synonyms (the field values are also listed): echo-reply (0),
echo-request (8), info-reply (16), info-request (15), mask-request (17),
mask-reply (18), parameter-problem (12), redirect (5),
router-advertisement (9), router-solicit (10), source-quench (4),
time-exceeded (11), timestamp (13), timestamp-reply (14), or
unreachable (3).
372
Copyright © 2018, Juniper Networks, Inc.
Chapter 27: ALGs Configuration Overview
NOTE: If you configure an interface with an input firewall filter that includes
a reject action and with a service set that includes stateful firewall rules, the
router executes the input firewall filter before the stateful firewall rules are
run on the packet. As a result, when the Packet Forwarding Engine sends an
ICMP error message out through the interface, the stateful firewall rules might
drop the packet because it was not seen in the input direction.
Possible workarounds are to include a forwarding-table filter to perform the
reject action, because this type of filter is executed after the stateful firewall
in the input direction, or to include an output service filter to prevent the
locally generated ICMP packets from going to the stateful firewall service.
Configuring Source and Destination Ports
The TCP or UDP source and destination port provide additional specification, in
conjunction with the network protocol, for packet matching in an application definition.
To configure ports, include the destination-port and source-port statements at the [edit
applications application application-name] hierarchy level:
[edit applications application application-name]
destination-port value;
source-port value;
You must define one source or destination port. Normally, you specify this match in
conjunction with the protocol match statement to determine which protocol is being
used on the port; for constraints, see Table 16 on page 368.
You can specify either a numeric value or one of the text synonyms listed in
Table 19 on page 373.
Table 19: Port Names Supported by Services Interfaces
Port Name
Corresponding Port Number
afs
1483
bgp
179
biff
512
bootpc
68
bootps
67
cmd
514
cvspserver
2401
dhcp
67
Copyright © 2018, Juniper Networks, Inc.
373
Adaptive Services Interfaces Feature Guide for Routing Devices
Table 19: Port Names Supported by Services Interfaces (continued)
374
Port Name
Corresponding Port Number
domain
53
eklogin
2105
ekshell
2106
exec
512
finger
79
ftp
21
ftp-data
20
http
80
https
443
ident
113
imap
143
kerberos-sec
88
klogin
543
kpasswd
761
krb-prop
754
krbupdate
760
kshell
544
ldap
389
login
513
mobileip-agent
434
mobilip-mn
435
msdp
639
netbios-dgm
138
netbios-ns
137
Copyright © 2018, Juniper Networks, Inc.
Chapter 27: ALGs Configuration Overview
Table 19: Port Names Supported by Services Interfaces (continued)
Port Name
Corresponding Port Number
netbios-ssn
139
nfsd
2049
nntp
119
ntalk
518
ntp
123
pop3
110
pptp
1723
printer
515
radacct
1813
radius
1812
rip
520
rkinit
2108
smtp
25
snmp
161
snmptrap
162
snpp
444
socks
1080
ssh
22
sunrpc
111
syslog
514
tacacs-ds
65
talk
517
telnet
23
tftp
69
Copyright © 2018, Juniper Networks, Inc.
375
Adaptive Services Interfaces Feature Guide for Routing Devices
Table 19: Port Names Supported by Services Interfaces (continued)
Port Name
Corresponding Port Number
timed
525
who
513
xdmcp
177
zephyr-clt
2103
zephyr-hm
2104
For more information about matching criteria, see the Routing Policies, Firewall Filters,
and Traffic Policers Feature Guide.
Configuring the Inactivity Timeout Period
You can specify a timeout period for application inactivity. If the software has not detected
any activity during the duration, the flow becomes invalid when the timer expires. To
configure a timeout period, include the inactivity-timeout statement at the [edit
applications application application-name] hierarchy level:
[edit applications application application-name]
inactivity-timeout seconds;
The default value is 14,400 seconds. The value you configure for an application overrides
any global value configured at the [edit interfaces interface-name service-options] hierarchy
level; for more information, see Configuring Default Timeout Settings for Services Interfaces.
Configuring an IKE ALG Application
The IKE ALG enables the passing of IKEv1 and IPsec packets through NAPT-44 and NAT64
filters between IPsec peers that are not NAT-T compliant. This ALG supports only ESP
tunnel mode. You can use the predefined IKE ALG application junos-ike, which has
predefined values for the destination port (500), inactivity timeout (14,400 seconds),
gate timeout (120 seconds), and ESP session idle timeout (800 seconds). If you want
to use the IKE ALG with values different from the predefined junos-ike application, you
need to configure a new IKE ALG application.
To configure an IKE ALG application:
1.
Specify a name for the application.
[edit applications]
user@host# set application application-name
2. Specify the IKE ALG.
[edit applications application application-name]
user@host# set application-protocol ike-esp-nat
376
Copyright © 2018, Juniper Networks, Inc.
Chapter 27: ALGs Configuration Overview
3. Specify the UDP protocol.
[edit applications application application-name]
user@host# set protocol udp
4. Specify 500 for the destination port.
[edit applications application application-name]
user@host# set destination-port 500
5. Specify the number of seconds that the IKE session is inactive before it is deleted. The
default is 14,400 seconds.
[edit applications application application-name]
user@host# set inactivity-timeout seconds
6. Specify the number of seconds that can pass after IKE establishes the security
association between the IPsec client and server and before the ESP traffic starts in
both directions. If the ESP traffic has not started before this timeout value, the ESP
gates are deleted and the ESP traffic is blocked. The default is 120 seconds.
[edit applications application application-name]
user@host# set gate-timeout seconds
7. Specify the ESP session (IPsec data traffic) idle timeout in seconds. If no IPsec data
traffic is passed on the ESP session in this time, the session is deleted. The default is
800 seconds.
[edit applications application application-name]
user@host# set child-inactivity-timeout seconds
Configuring SIP
The Session Initiation Protocol (SIP) is a generalized protocol for communication between
endpoints involved in Internet services such as telephony, fax, video conferencing, instant
messaging, and file exchange.
The Junos OS provides ALG services in accordance with the standard described in RFC
3261, SIP: Session Initiation Protocol. SIP flows under the Junos OS are as described in
RFC 3665, Session Initiation Protocol (SIP) Basic Call Flow Examples.
NOTE: Before implementing the Junos OS SIP ALG, you should be familiar
with certain limitations, discussed in “Junos OS SIP ALG Limitations” on
page 384
The use of NAT in conjunction with the SIP ALG results in changes in SIP
header fields due to address translation. For an explanation of these
translations, refer to “SIP ALG Interaction with Network Address Translation”
on page 378.
Copyright © 2018, Juniper Networks, Inc.
377
Adaptive Services Interfaces Feature Guide for Routing Devices
To implement SIP on adaptive services interfaces, you configure the application-protocol
statement at the [edit applications application application-name] hierarchy level with the
value sip. For more information about this statement, see “Configuring an Application
Protocol” on page 368. In addition, there are two other statements you can configure to
modify how SIP is implemented:
•
You can enable the router to accept any incoming SIP calls for the endpoint devices
that are behind the NAT firewall. When a device behind the firewall registers with the
proxy that is outside the firewall, the AS or Multiservices PIC maintains the registration
state. When the learn-sip-register statement is enabled, the router can use this
information to accept inbound calls. If this statement is not configured, no inbound
calls are accepted; only the devices behind the firewall can call devices outside the
firewall.
To configure SIP registration, include the learn-sip-register statement at the [edit
applications application application-name] hierarchy level:
[edit applications application application-name]
learn-sip-register;
You can also manually inspect the SIP register by issuing the show services
stateful-firewall sip-register command; for more information, see the Junos OS System
Basics and Services Command Reference.
•
You can specify a timeout period for the duration of SIP calls that are placed on hold.
When a call is put on hold, there is no activity and flows might time out after the
configured inactivity-timeout period expires, resulting in call state teardown. To avoid
this, when a call is put on hold, the flow timer is reset to the sip-call-hold-timeout cycle
to preserve the call state and flows for longer than the inactivity-timeout period.
To configure a timeout period, include the sip-call-hold-timeout statement at the [edit
applications application application-name] hierarchy level:
[edit applications application application-name]
sip-call-hold-timeout seconds;
The default value is 7200 seconds and the range is from 0 through 36,000 seconds
(10 hours).
SIP ALG Interaction with Network Address Translation
The Network Address Translation (NAT) protocol enables multiple hosts in a private
subnet to share a single public IP address to access the Internet. For outgoing traffic,
NAT replaces the private IP address of the host in the private subnet with the public IP
address. For incoming traffic, the public IP address is converted back into the private
address, and the message is routed to the appropriate host in the private subnet.
Using NAT with the Session Initiation Protocol (SIP) service is more complicated because
SIP messages contain IP addresses in the SIP headers as well as in the SIP body. When
using NAT with the SIP service, the SIP headers contain information about the caller and
the receiver, and the device translates this information to hide it from the outside network.
The SIP body contains the Session Description Protocol (SDP) information, which includes
IP addresses and port numbers for transmission of the media. The device translates SDP
information for allocating resources to send and receive the media.
378
Copyright © 2018, Juniper Networks, Inc.
Chapter 27: ALGs Configuration Overview
How IP addresses and port numbers in SIP messages are replaced depends on the
direction of the message. For an outgoing message, the private IP address and port
number of the client are replaced with the public IP address and port number of the
Juniper Networks firewall. For an incoming message, the public address of the firewall is
replaced with the private address of the client.
When an INVITE message is sent out across the firewall, the SIP Application Layer
Gateway (ALG) collects information from the message header into a call table, which it
uses to forward subsequent messages to the correct endpoint. When a new message
arrives, for example an ACK or 200 OK, the ALG compares the “From:, To:, and Call-ID:”
fields against the call table to identify the call context of the message. If a new INVITE
message arrives that matches the existing call, the ALG processes it as a REINVITE.
When a message containing SDP information arrives, the ALG allocates ports and creates
a NAT mapping between them and the ports in the SDP. Because the SDP requires
sequential ports for the Real-Time Transport Protocol (RTP) and Real-Time Control
Protocol (RTCP) channels, the ALG provides consecutive even-odd ports. If it is unable
to find a pair of ports, it discards the SIP message.
This topic contains the following sections:
•
Outgoing Calls on page 379
•
Incoming Calls on page 380
•
Forwarded Calls on page 380
•
Call Termination on page 380
•
Call Re-INVITE Messages on page 380
•
Call Session Timers on page 381
•
Call Cancellation on page 381
•
Forking on page 381
•
SIP Messages on page 381
•
SIP Headers on page 381
•
SIP Body on page 384
Outgoing Calls
When a SIP call is initiated with a SIP request message from the internal to the external
network, NAT replaces the IP addresses and port numbers in the SDP and binds the IP
addresses and port numbers to the Juniper Networks firewall. Via, Contact, Route, and
Record-Route SIP header fields, if present, are also bound to the firewall IP address. The
ALG stores these mappings for use in retransmissions and for SIP response messages.
The SIP ALG then opens pinholes in the firewall to allow media through the device on
the dynamically assigned ports negotiated based on information in the SDP and the Via,
Contact, and Record-Route header fields. The pinholes also allow incoming packets to
reach the Contact, Via, and Record-Route IP addresses and ports. When processing
return traffic, the ALG inserts the original Contact, Via, Route, and Record-Route SIP
fields back into packets.
Copyright © 2018, Juniper Networks, Inc.
379
Adaptive Services Interfaces Feature Guide for Routing Devices
Incoming Calls
Incoming calls are initiated from the public network to public static NAT addresses or to
interface IP addresses on the device. Static NATs are statically configured IP addresses
that point to internal hosts; interface IP addresses are dynamically recorded by the ALG
as it monitors REGISTER messages sent by internal hosts to the SIP registrar. When the
device receives an incoming SIP packet, it sets up a session and forwards the payload of
the packet to the SIP ALG.
The ALG examines the SIP request message (initially an INVITE) and, based on information
in the SDP, opens gates for outgoing media. When a 200 OK response message arrives,
the SIP ALG performs NAT on the IP addresses and ports and opens pinholes in the
outbound direction. (The opened gates have a short time-to-live, and they time out if a
200 OK response message is not received quickly.)
When a 200 OK response arrives, the SIP proxy examines the SDP information and reads
the IP addresses and port numbers for each media session. The SIP ALG on the device
performs NAT on the addresses and port numbers, opens pinholes for outbound traffic,
and refreshes the timeout for gates in the inbound direction.
When the ACK arrives for the 200 OK, it also passes through the SIP ALG. If the message
contains SDP information, the SIP ALG ensures that the IP addresses and port numbers
are not changed from the previous INVITE—if they are, the ALG deletes old pinholes and
creates new pinholes to allow media to pass through. The ALG also monitors the Via,
Contact, and Record-Route SIP fields and opens new pinholes if it determines that these
fields have changed.
Forwarded Calls
A forwarded call is when, for example, user A outside the network calls user B inside the
network, and user B forwards the call to user C outside the network. The SIP ALG
processes the INVITE from user A as a normal incoming call. But when the ALG examines
the forwarded call from B to C outside the network and notices that B and C are reached
using the same interface, it does not open pinholes in the firewall, because media will
flow directly between user A and user C.
Call Termination
The BYE message terminates a call. When the device receives a BYE message, it translates
the header fields just as it does for any other message. But because a BYE message must
be acknowledged by the receiver with a 200 OK, the ALG delays call teardown for five
seconds to allow time for transmission of the 200 OK.
Call Re-INVITE Messages
Re-INVITE messages add new media sessions to a call and remove existing media
sessions. When new media sessions are added to a call, new pinholes are opened in the
firewall and new address bindings are created. The process is identical to the original
call setup. When one or more media sessions are removed from a call, pinholes are closed
and bindings released just as with a BYE message.
380
Copyright © 2018, Juniper Networks, Inc.
Chapter 27: ALGs Configuration Overview
Call Session Timers
The SIP ALG uses the Session-Expires value to time out a session if a Re-INVITE or
UPDATE message is not received. The ALG gets the Session-Expires value, if present,
from the 200 OK response to the INVITE and uses this value for signaling timeout. If the
ALG receives another INVITE before the session times out, it resets all timeout values to
this new INVITE or to default values, and the process is repeated.
As a precautionary measure, the SIP ALG uses hard timeout values to set the maximum
amount of time a call can exist. This ensures that the device is protected should one of
the following events occur:
•
End systems crash during a call and a BYE message is not received.
•
Malicious users never send a BYE in an attempt to attack a SIP ALG.
•
Poor implementations of SIP proxy fail to process Record-Route and never send a BYE
message.
•
Network failures prevent a BYE message from being received.
Call Cancellation
Either party can cancel a call by sending a CANCEL message. Upon receiving a CANCEL
message, the SIP ALG closes pinholes through the firewall—if any have been opened—and
releases address bindings. Before releasing the resources, the ALG delays the control
channel age-out for approximately five seconds to allow time for the final 200 OK to
pass through. The call is terminated when the five second timeout expires, regardless of
whether a 487 or non-200 response arrives.
Forking
Forking enables a SIP proxy to send a single INVITE message to multiple destinations
simultaneously. When the multiple 200 OK response messages arrive for the single call,
the SIP ALG parses but updates call information with the first 200 OK messages it
receives.
SIP Messages
The SIP message format consists of a SIP header section and the SIP body. In request
messages, the first line of the header section is the request line, which includes the method
type, request-URI, and protocol version. In response messages, the first line is the status
line, which contains a status code. SIP headers contain IP addresses and port numbers
used for signaling. The SIP body, separated from the header section by a blank line, is
reserved for session description information, which is optional. Junos OS currently supports
the SDP only. The SIP body contains IP addresses and port numbers used to transport
the media.
SIP Headers
In the following sample SIP request message, NAT replaces the IP addresses in the header
fields to hide them from the outside network.
INVITE bob@10.150.20.5 SIP/2.0
Via: SIP/2.0/UDP 10.150.20.3:5434
Copyright © 2018, Juniper Networks, Inc.
381
Adaptive Services Interfaces Feature Guide for Routing Devices
From: alice@10.150.20.3
To: bob@10.150.20.5
Call-ID: a12abcde@10.150.20.3
Contact: alice@10.150.20.3:5434
Route: <sip:netscreen@10.150.20.3:5060>
Record-Route: <sip:netscreen@10.150.20.3:5060>
How IP address translation is performed depends on the type and direction of the
message. A message can be any of the following:
•
Inbound request
•
Outbound response
•
Outbound request
•
Inbound response
Table 20 on page 382 shows how NAT is performed in each of these cases. Note that for
several of the header fields the ALG determine more than just whether the messages
comes from inside or outside the network. It must also determine what client initiated
the call, and whether the message is a request or response.
Table 20: Requesting Messages with NAT Table
Inbound Request
(from public to private)
382
To:
Replace domain with local address
From:
None
Call-ID:
None
Via:
None
Request-URI:
Replace ALG address with local address
Contact:
None
Record-Route:
None
Route:
None
Copyright © 2018, Juniper Networks, Inc.
Chapter 27: ALGs Configuration Overview
Table 20: Requesting Messages with NAT Table (continued)
Outbound Response
(from private to public)
Outbound Request
(from private to public)
Outbound Response
(from public to private)
To:
Replace ALG address with local address
From:
None
Call-ID:
None
Via:
None
Request-URI:
N/A
Contact:
Replace local address with ALG address
Record-Route:
Replace local address with ALG address
Route:
None
To:
None
From:
Replace local address with ALG address
Call-ID:
None
Via:
Replace local address with ALG address
Request-URI:
None
Contact:
Replace local address with ALG address
Record-Route:
Replace local address with ALG address
Route:
Replace ALG address with local address
To:
None
From:
Replace ALG address with local address
Call-ID:
None
Via:
Replace ALG address with local address
Request-URI:
N/A
Contact:
None
Record-Route:
Replace ALG address with local address
Route:
Replace ALG address with local address
Copyright © 2018, Juniper Networks, Inc.
383
Adaptive Services Interfaces Feature Guide for Routing Devices
SIP Body
The SDP information in the SIP body includes IP addresses the ALG uses to create
channels for the media stream. Translation of the SDP section also allocates resources,
that is, port numbers to send and receive the media.
The following excerpt from a sample SDP section shows the fields that are translated
for resource allocation.
o=user 2344234 55234434 IN IP4 10.150.20.3
c=IN IP4 10.150.20.3
m=audio 43249 RTP/AVP 0
SIP messages can contain more than one media stream. The concept is similar to
attaching multiple files to an e-mail message. For example, an INVITE message sent
from a SIP client to a SIP server might have the following fields:
c=IN IP4 10.123.33.4
m=audio 33445 RTP/AVP 0
c=IN IP4 10.123.33.4
m=audio 33447 RTP/AVP 0
c=IN IP4 10.123.33.4
m=audio 33449 RTP/AVP 0
Junos OS supports up to 6 SDP channels negotiated for each direction, for a total of 12
channels per call.
Junos OS SIP ALG Limitations
The following limitations apply to configuration of the SIP ALG:
384
•
Only the methods described in RFC 3261 are supported.
•
Only SIP version 2 is supported.
•
TCP is not supported as a transport mechanism for signaling messages.
•
Do not configure the SIP ALG when using STUN. if clients use STUN/TURN to detect
the firewall or NAT devices between the caller and responder or proxy, the client
attempts to best-guess the NAT device behavior and act accordingly to place the call.
•
Do not use the endpoint-independent mapping NAT pool option in conjunction with
the SIP ALG. Errors will result.
•
IPv6 signaling data is not supported.
•
Authentication is not supported.
•
Encrypted messages are not supported.
•
SIP fragmentation is not supported.
•
The maximum UDP packet size containing a SIP message is assumed to be 4 KB. SIP
messages larger than this are not supported.
•
The maximum number of media channels in a SIP message is assumed to be six.
•
Fully qualified domain names (FQDNs) are not supported in critical fields.
Copyright © 2018, Juniper Networks, Inc.
Chapter 27: ALGs Configuration Overview
•
QoS is not supported.
•
High availability is not supported, except for warm standby.
•
A timeout setting of never is not supported on SIP or NAT.
•
Multicast (forking proxy) is not supported.
Configuring an SNMP Command for Packet Matching
You can specify an SNMP command setting for packet matching. To configure SNMP,
include the snmp-command statement at the [edit applications application
application-name] hierarchy level:
[edit applications application application-name]
snmp-command value;
The supported values are get, get-next, set, and trap. You can configure only one value
for matching. The application-protocol statement at the [edit applications application
application-name] hierarchy level must have the value snmp. For information about
specifying the application protocol, see “Configuring an Application Protocol” on page 368.
Configuring an RPC Program Number
You can specify an RPC program number for packet matching. To configure an RPC
program number, include the rpc-program-number statement at the [edit applications
application application-name] hierarchy level:
[edit applications application application-name]
rpc-program-number number;
The range of values used for DCE or RPC is from 100,000 through 400,000. The
application-protocol statement at the [edit applications application application-name]
hierarchy level must have the value rpc. For information about specifying the application
protocol, see “Configuring an Application Protocol” on page 368.
Configuring the TTL Threshold
You can specify a trace route time-to-live (TTL) threshold value, which controls the
acceptable level of network penetration for trace routing. To configure a TTL value,
include the ttl-threshold statement at the [edit applications application application-name]
hierarchy level:
[edit applications application application-name]
ttl-threshold value;
The application-protocol statement at the [edit applications application application-name]
hierarchy level must have the value traceroute. For information about specifying the
application protocol, see “Configuring an Application Protocol” on page 368.
Configuring a Universal Unique Identifier
You can specify a Universal Unique Identifier (UUID) for DCE RPC objects. To configure
a UUID value, include the uuid statement at the [edit applications application
application-name] hierarchy level:
Copyright © 2018, Juniper Networks, Inc.
385
Adaptive Services Interfaces Feature Guide for Routing Devices
[edit applications application application-name]
uuid hex-value;
The uuid value is in hexadecimal notation. The application-protocol statement at the
[edit applications application application-name hierarchy level must have the value dce-rpc.
For information about specifying the application protocol, see “Configuring an Application
Protocol” on page 368. For more information on UUID numbers, see
http://www.opengroup.org/onlinepubs/9629399/apdxa.htm.
Examples: Configuring Application Protocols
The following example shows an application protocol definition describing a special FTP
application running on port 78:
[edit applications]
application my-ftp-app {
application-protocol ftp;
protocol tcp;
destination-port 78;
timeout 100; # inactivity timeout for FTP service
}
The following example shows a special ICMP protocol (application-protocol icmp) of
type 8 (ICMP echo):
[edit applications]
application icmp-app {
application-protocol icmp;
protocol icmp;
icmp-type icmp-echo;
}
The following example shows a possible application set:
[edit applications]
application-set basic {
http;
ftp;
telnet;
nfs;
icmp;
}
The software includes a predefined set of well-known application protocols. The set
includes applications for which the TCP and UDP destination ports are already recognized
by stateless firewall filters.
Related
Documentation
386
•
ALG Descriptions on page 337
•
Configuring Application Sets on page 367
•
Configuring Application Properties on page 367
•
Verifying the Output of ALG Sessions on page 387
Copyright © 2018, Juniper Networks, Inc.
Chapter 27: ALGs Configuration Overview
Verifying the Output of ALG Sessions
This section contains examples of successful output from ALG sessions and information
on system log configuration. You can compare the results of your sessions to check
whether the configurations are functioning correctly.
•
FTP Example on page 387
•
RTSP ALG Example on page 389
•
System Log Messages on page 392
FTP Example
This example analyzes the output during an active FTP session. It consists of four different
flows; two are control flows and two are data flows. The example consists of the following
parts:
•
Sample Output on page 387
•
FTP System Log Messages on page 388
•
Analysis on page 388
•
Troubleshooting Questions on page 389
Sample Output
The following is a complete sample output from the show services stateful-firewall
conversations application-protocol ftp operational mode command:
user@host>show services stateful-firewall conversations application-protocol ftp
Interface: ms-1/3/0, Service set: CLBJI1-AAF001
Conversation: ALG protocol: ftp
Number of initiators: 2, Number of responders: 2
Flow
State
Dir
TCP
1.1.79.2:14083 ->
2.2.2.2:21
Watch
I
NAT source
1.1.79.2:14083
->
194.250.1.237:50118
TCP
1.1.79.2:14104 ->
2.2.2.2:20
Forward I
NAT source
1.1.79.2:14104
->
194.250.1.237:50119
TCP
2.2.2.2:21
-> 194.250.1.237:50118 Watch
O
NAT dest
194.250.1.237:50118
->
1.1.79.2:14083
TCP
2.2.2.2:20
-> 194.250.1.237:50119 Forward O
NAT dest
194.250.1.237:50119
->
1.1.79.2:14104
Frm count
13
3
12
5
For each flow, the first line shows flow information, including protocol (TCP), source
address, source port, destination address, destination port, flow state, direction, and
frame count.
•
The state of a flow can be Watch, Forward, or Drop:
•
A Watch flow state indicates that the control flow is monitored by the ALG for
information in the payload. NAT processing is performed on the header and payload
as needed.
•
A Forward flow forwards the packets without monitoring the payload. NAT is
performed on the header as needed.
Copyright © 2018, Juniper Networks, Inc.
387
Adaptive Services Interfaces Feature Guide for Routing Devices
•
•
A Drop flow drops any packet that matches the 5 tuple.
The frame count (Frm count) shows the number of packets that were processed on
that flow.
The second line shows the NAT information.
•
source indicates source NAT.
•
dest indicates destination NAT.
•
The first address and port in the NAT line are the original address and port being
translated for that flow.
•
The second address and port in the NAT line are the translated address and port for
that flow.
FTP System Log Messages
System log messages are generated during an FTP session. For more information about
system logs, see “System Log Messages” on page 392.
The following system log messages are generated during creation of the FTP control
flow:
•
Rule Accept system log:
Oct 27 11:42:54 (FPC Slot 1, PIC Slot 1) {ss_ftp}[FWNAT]: ASP_SFW_RULE_ACCEPT:
proto 6 (TCP) application: ftp, fe-3/3/3.0:1.1.1.2:4450 -> 2.2.2.2:21, Match SFW accept
rule-set:, rule: ftp, term: 1
•
Create Accept Flow system log:
Oct 27 11:42:54 (FPC Slot 1, PIC Slot 1) {ss_ftp}[FWNAT]:
ASP_SFW_CREATE_ACCEPT_FLOW: proto 6 (TCP) application: ftp,
fe-3/3/3.0:1.1.1.2:4450 -> 2.2.2.2:21, creating forward or watch flow
•
System log for data flow creation:
Oct 27 11:43:30 (FPC Slot 1, PIC Slot 1) {ss_ftp}[FWNAT]:
ASP_SFW_FTP_ACTIVE_ACCEPT: proto 6 (TCP) application: ftp, so-2/1/2.0:2.2.2.2:20
-> 1.1.1.2:50726, Creating FTP active mode forward flow
Analysis
Control Flows
The control flows are established after the three-way handshake is complete.
•
Control flow from FTP client to FTP server. TCP destination port is 21.
TCP
13
1.1.79.2:14083 ->
NAT source
•
388
1.1.79.2:14083
2.2.2.2:21
->
Watch
I
194.250.1.237:50118
Control flow from FTP server to FTP client. TCP source port is 21.
Copyright © 2018, Juniper Networks, Inc.
Chapter 27: ALGs Configuration Overview
TCP
12
2.2.2.2:21
NAT dest
->
194.250.1.237:50118 Watch
194.250.1.237:50118
->
O
1.1.79.2:14083
Data Flows
A data port of 20 is negotiated for data transfer during the course of the FTP control
protocol. These two flows are data flows between the FTP client and the FTP server:
TCP
1.1.79.2:14104 ->
2.2.2.2:20
Forward I
1.1.79.2:14104
->
194.250.1.237:50119
2.2.2.2:20
-> 194.250.1.237:50119 Forward O
194.250.1.237:50119
->
1.1.79.2:14104
3
NAT source
TCP
NAT dest
5
Troubleshooting Questions
1.
How do I know if the FTP ALG is active?
•
The ALG protocol field in the conversation should display ftp.
•
There should be a valid frame count (Frm count) in the control flows.
•
A valid frame count in the data flows indicates that data transfer has taken place.
2. What do I need to check if the FTP connection is established but data transfer does
not take place?
•
Most probably, the control connection is up, but the data connection is down.
•
Check the conversations output to determine whether both the control and data
flows are present.
3. How do I interpret each flow? What does each flow mean?
•
FTP control flow initiator flow—Flow with destination port 21
•
FTP control flow responder flow—Flow with source port ;21
•
FTP data flow initiator flow—Flow with destination port 20
•
FTP data flow responder flow—Flow with source port 20
RTSP ALG Example
The following is an example of an RTSP conversation. The application uses the RTSP
protocol for control connection. Once the connection is set up, the media is sent using
UDP protocol (RTP).
This example consists of the following:
•
Sample Output on page 390
•
Analysis on page 390
•
Troubleshooting Questions on page 390
Copyright © 2018, Juniper Networks, Inc.
389
Adaptive Services Interfaces Feature Guide for Routing Devices
Sample Output
Here is the output from the show services stateful-firewall conversations operational
mode command:
user@host# show services stateful-firewall conversations
Interface: ms-3/2/0, Service set: svc_set
Conversation: ALG protocol: rtsp
Number of initiators: 5, Number of responders: 5
Flow
State
Dir
TCP
1.1.1.3:58795 ->
2.2.2.2:554
Watch
I
UDP
1.1.1.3:1028 ->
2.2.2.2:1028 Forward I
UDP
1.1.1.3:1029 ->
2.2.2.2:1029 Forward I
UDP
1.1.1.3:1030 ->
2.2.2.2:1030 Forward I
UDP
1.1.1.3:1031 ->
2.2.2.2:1031 Forward I
TCP
2.2.2.2:554
->
1.1.1.3:58795 Watch
O
UDP
2.2.2.2:1028 ->
1.1.1.3:1028 Forward O
UDP
2.2.2.2:1029 ->
1.1.1.3:1029 Forward O
UDP
2.2.2.2:1030 ->
1.1.1.3:1030 Forward O
UDP
2.2.2.2:1031 ->
1.1.1.3:1031 Forward O
Frm count
7
0
0
0
0
5
6
0
3
0
Analysis
An RTSP conversation should consist of TCP flows corresponding to the RTSP control
connection. There should be two flows, one in each direction, from client to server and
from server to client:
TCP
TCP
1.1.1.3:58795 ->
2.2.2.2:554
->
2.2.2.2:554
Watch
1.1.1.3:58795 Watch
I
O
7
5
•
The RTSP control connection for the initiator flow is sent from destination port 554.
•
The RTSP control connection for the responder flow is sent from source port 554.
The UDP flows correspond to RTP media sent over the RTSP connection.
Troubleshooting Questions
1.
Media does not work when the RTSP ALG is configured. What do I do?
•
Check RTSP conversations to see whether both TCP and UDP flows exist.
•
The ALG protocol should be displayed as rtsp.
NOTE: The state of the flow is displayed as Watch, because the ALG
processing is taking place and the client is essentially “watching” or
processing payload corresponding to the application. For FTP and RTSP
ALG flows, the control connections are always Watch flows.
2. How do I check for ALG errors?
•
390
You can check for errors by issuing the following command. Each ALG has a separate
field for ALG packet errors.
Copyright © 2018, Juniper Networks, Inc.
Chapter 27: ALGs Configuration Overview
user@host# show services stateful-firewall statistics extensive
Interface: ms-3/2/0
Service set: svc_set
New flows:
Accepts: 1347, Discards: 0, Rejects: 0
Existing flows:
Accepts: 144187, Discards: 0, Rejects: 0
Drops:
IP option: 0, TCP SYN defense: 0
NAT ports exhausted: 0
Errors:
IP: 0, TCP: 276
UDP: 0, ICMP: 0
Non-IP packets: 0, ALG: 0
IP errors:
IP packet length inconsistencies: 0
Minimum IP header length check failures: 0
Reassembled packet exceeds maximum IP length: 0
Illegal source address: 0
Illegal destination address: 0
TTL zero errors: 0, Illegal IP protocol number (0 or 255): 0
Land attack: 0
Non-IPv4 packets: 0, Bad checksum: 0
Illegal IP fragment length: 0
IP fragment overlap: 0
IP fragment reassembly timeout: 0
Unknown: 0
TCP errors:
TCP header length inconsistencies: 0
Source or destination port number is zero: 0
Illegal sequence number and flags combinations: 0
SYN attack (multiple SYN messages seen for the same flow): 276
First packet not a SYN message: 0
TCP port scan (TCP handshake, RST seen from server for SYN): 0
Bad SYN cookie response: 0
UDP errors:
IP data length less than minimum UDP header length (8 bytes): 0
Source or destination port number is zero: 0
UDP port scan (ICMP error seen for UDP flow): 0
ICMP errors:
IP data length less than minimum ICMP header length (8 bytes): 0
ICMP error length inconsistencies: 0
Duplicate ping sequence number: 0
Mismatched ping sequence number: 0
ALG errors:
BOOTP: 0, DCE-RPC: 0, DCE-RPC portmap: 0
DNS: 0, Exec: 0, FTP: 0
ICMP: 0
Login: 0, NetBIOS: 0, NetShow: 0
RPC: 0, RPC portmap: 0
RTSP: 0, Shell: 0
SNMP: 0, SQLNet: 0, TFTP: 0
Traceroute: 0
Copyright © 2018, Juniper Networks, Inc.
391
Adaptive Services Interfaces Feature Guide for Routing Devices
System Log Messages
Enabling system log generation and checking the system log are also helpful for ALG
flow analysis. This section contains the following:
•
System Log Configuration on page 392
•
System Log Output on page 392
System Log Configuration
You can configure the enabling of system log messages at a number of different levels
in the Junos OS CLI. As shown in the following sample configurations, the choice of level
depends on how specific you want the event logging to be and what options you want
to include. For details on the configuration options, see the Junos OS Administration Library
(system level) or the Junos OS Services Interfaces Library for Routing Devices (all other
levels).
1.
At the topmost global level:
user@host# show system syslog
file messages {
any any;
}
2. At the service set level:
user@host# show services service-set svc_set
syslog {
host local {
services any;
}
}
stateful-firewall-rules allow_rtsp;
interface-service {
service-interface ms-3/2/0;
}
3. At the service rule level:
user@host# show services stateful-firewall rule allow_rtsp
match-direction input-output;
term 0 {
from {
applications junos-rtsp;
}
then {
accept;
syslog;
}
}
System Log Output
System log messages are generated during flow creation, as shown in the following
examples:
392
Copyright © 2018, Juniper Networks, Inc.
Chapter 27: ALGs Configuration Overview
The following system log message indicates that the ASP matched an accept rule:
Oct 25 16:11:37 (FPC Slot 3, PIC Slot 2) {svc_set}[FWNAT]: ASP_SFW_RULE_ACCEPT:
proto 6 (TCP) application: rtsp, ge-2/0/1.0:1.1.1.2:35595 -> 2.2.2.2:554, Match SFW accept
rule-set: , rule: allow_rtsp, term: 0
For a complete listing of system log messages, see the System Log Explorer.
Related
Documentation
•
ALG Descriptions on page 337
•
Configuring Application Sets on page 367
•
Configuring Application Properties on page 367
•
Examples: Configuring Application Protocols on page 386
ICMP, Ping, and Traceroute ALGs for MS-MICs and MS-MPCs
Starting with Junos OS Release 14.2, Junos OS extension-provider packages that are
preinstalled and preconfigured on the MS-MIC and MS-MPC offer support for ping,
traceroute, and ICMP ALGs in a consistent manner that is identical to the support that
the uKernel service provides. Parity and uniformity of support is established for these
ALGs between MS-MICs/MS-MPCs and the uKernel service. Until Junos OS Release 14.1,
ICMP ALGs, ping ALGs, and traceroute ALGs were not entirely supported on MX Series
routers with MS-MICs and MS-MPCs in comparison with the uKernel service that enables
Network Address Translation (NAT) with stateful firewall (SFW) on the uKernel PIC.
Support was available for handling of ICMP error response packets that match any
existing flow in the opposite direction and NAT processing of ICMP packets with NAT
processing of ping packets.
On MX Series routers with MS-MICs and MS-MPCs, tracking of ping traffic states wholly
using the ICMP sequence numbers (for example, forwarding an echo reply only if the
echo request with the corresponding sequence number is identified) is supported. ICMP
application layer gateway (ALG) is enhanced to provide detailed logging information.
Also, the traceroute ALGs enable UDP probe packets to be processed with the UDP
destination port number greater than 33000 and the IP time-to-live (TTL) is less than
30 seconds. Traceroute ALGs enable ICMP response packets for which the ICMP type is
time-exceeded to be processed and support a traceroute TTL threshold value, which
controls the acceptable level of network penetration for trace routing.
You can configure ICMP and ping messages with the application junos-icmp-all, application
junos-icmp-ping, and application icmp-code statements at the [edit services
stateful-firewall rule rule-name term term-name from] and the [edit services nat rule
rule-name term term-name from] hierarchy levels to define the match condition for the
stateful firewall and NAT rules. Until Junos OS Release 14.1, a restriction or a validation
on the applications that you could define for ICMP messages was not present. MS-MICs
and MS-MPCs function the same way as the uKernel service, which causes the ping traffic
to be tracked statefully using the ICMP sequence numbers (an echo reply is forwarded
only if echo request with the corresponding sequence number matches). Also, MS-MICs
and MS-MPCs impose a limit on the outstanding ping requests and drop the subsequent
ping requests when the limit is reached.
Copyright © 2018, Juniper Networks, Inc.
393
Adaptive Services Interfaces Feature Guide for Routing Devices
Similarly, for traceroute messages, you can configure the application junos-traceroute
and application junos-traceroute-ttl-1 statements at the [edit services stateful-firewall
rule rule-name term term-name from] and the [edit services nat rule rule-name term
term-name from] hierarchy levels to define the match condition for traceroute messages
for the stateful firewall and NAT rules.
Traceroute and ICMP messages are supported for both IPv4 and IPv6 packets. For the
traceroute functionality to work, you only need to ensure that the user-defined applications
are working as expected with the inactivity timeout period and the TTL threshold values
are configured to be the same period of time as configured by using the session-timeout
seconds statement at the [edit services application-identification application
application-name] hierarchy level. During the logging of ICMP messages, the ALG
information for ping and ICMP utilities is displayed in the output of the relevant show
commands, such as show sessions and show conversations, in the same manner as
displayed for uKernel logging.
Related
Documentation
•
ALG Descriptions on page 337
Monitoring Port Control Protocol Operations
You can monitor Port Control Protocol (PCP) operations with the following operational
commands:
•
show services nat mappings pcp
•
show services nat mappings endpoint-independent
•
show services pcp statistics protocol
The following are examples of the output of these commands.
user@host> show services nat mappings pcp
Interface: sp-0/0/0, Service set: in
NAT pool: p
PCP Client
Mapping
Session Count
Mapping State
: 10.1.1.2
: 10.1.1.2
:
1
: Active
DS-LITE output:
===============
PCP Client
Mapping
Session Count
Mapping State
B4 Address
:
:
:
:
:
2222::1
88.1.0.47
1
Active
2222::1
: 9000
PCP lifetime : 995
--> 8.8.8.8
: 1025
:
PCP lifetime : 106
--> 70.70.70.1
47
:41972
user@host> show services nat mappings endpoint-independent
Interface: sp-0/0/0, Service set: in
NAT pool: p
Mapping
Session Count
394
: 10.1.1.2
:
0
:57400
--> 8.8.8.8
: 1024
Copyright © 2018, Juniper Networks, Inc.
Chapter 27: ALGs Configuration Overview
Mapping State
PCP Client
Mapping
Session Count
Mapping State
:
:
:
:
:
Timeout
10.1.1.2
10.1.1.2
1
Active
DS-LITE output:
===============
PCP Client
Mapping
Session Count
Mapping State
B4 Address
:
:
:
:
:
2222::1
88.1.1.3
1
Active
2222::1
: 9000
PCP lifetime : 991
--> 8.8.8.8
: 1025
: 4001
PCP lifetime : 190
--> 70.70.70.2
:58989
user@host> show services pcp statistics protocol
Protocol Statistics:
Operational Statistics
Map request received
Peer request received
Other operational counters
:0
:0
:0
Option Statistics
Unprocessed requests received
Third party requets received
Prefer fail option received
Filter option received
Other options counters
Option optional received
:0
:0
:0
:0
:0
:0
Result Statistics
PCP success
PCP unsupported version
Not authorized
Bad requests
Unsupported opcode
Unsupported option
Bad option
Network failure
Out of resources
Unsupported protocol
User exceeded quota
Cannot provide external
Address mismatch
Excessive number of remote peers
Processing error
Other result counters
Copyright © 2018, Juniper Networks, Inc.
:0
:0
:0
:0
:0
:0
:0
:0
:0
:0
:0
:0
:0
:0
:0
:0
395
Adaptive Services Interfaces Feature Guide for Routing Devices
396
Copyright © 2018, Juniper Networks, Inc.
PART 5
Securing Content Using Junos Network
Secure and IDS
•
Junos Network Secure Overview on page 399
•
Junos Network Secure Configuration Overview on page 403
•
IDS Configuration on MS-DPC Overview on page 429
•
Network Attack Protection Configuration on MS-MPC on page 443
•
Monitoring Junos Network Secure on page 457
Copyright © 2018, Juniper Networks, Inc.
397
Adaptive Services Interfaces Feature Guide for Routing Devices
398
Copyright © 2018, Juniper Networks, Inc.
CHAPTER 28
Junos Network Secure Overview
•
Junos Network Secure Overview on page 399
Junos Network Secure Overview
Routers use firewalls to track and control the flow of traffic. Adaptive Services and
MultiServices PICs employ a type of firewall called a stateful firewall. Contrasted with a
stateless firewall that inspects packets in isolation, a stateful firewall provides an extra
layer of security by using state information derived from past communications and other
applications to make dynamic control decisions for new communication attempts.
NOTE: On ACX Series routers, the stateful firewall configuration is supported
only on the ACX500 indoor routers.
Stateful firewalls group relevant flows into conversations. A flow is identified by the
following five properties:
•
Source address
•
Source port
•
Destination address
•
Destination port
•
Protocol
A typical Transmission Control Protocol (TCP) or User Datagram Protocol (UDP)
conversation consists of two flows: the initiation flow and the responder flow. However,
some conversations, such as an FTP conversation, might consist of two control flows
and many data flows.
Firewall rules govern whether the conversation is allowed to be established. If a
conversation is allowed, all flows within the conversation are permitted, including flows
that are created during the life cycle of the conversation.
You configure stateful firewalls using a powerful rule-driven conversation handling path.
A rule consists of direction, source address, source port, destination address, destination
port, IP protocol value, and application protocol or service. In addition to the specific
values you configure, you can assign the value any to rule objects, addresses, or ports,
Copyright © 2018, Juniper Networks, Inc.
399
Adaptive Services Interfaces Feature Guide for Routing Devices
which allows them to match any input value. Finally, you can optionally negate the rule
objects, which negates the result of the type-specific match.
Firewall rules are directional. For each new conversation, the router software checks the
initiation flow matching the direction specified by the rule.
Firewall rules are ordered. The software checks the rules in the order in which you include
them in the configuration. The first time the firewall discovers a match, the router
implements the action specified by that rule. Rules still unchecked are ignored.
NOTE: Starting in Junos OS Release 14.2, MS-MPC and MS-MIC interface
cards support IPv6 traffic for Junos Network Secure Stateful Firewall.
For more information, see “Configuring Stateful Firewall Rules” on page 403.
Stateful Firewall Support for Application Protocols
By inspecting the application protocol data, the AS or MultiServices PIC firewall can
intelligently enforce security policies and allow only the minimal required packet traffic
to flow through the firewall.
The firewall rules are configured in relation to an interface. By default, the stateful firewall
allows all sessions initiated from the hosts behind the interface to pass through the
router.
NOTE: Stateful firewall ALGs are not supported on ACX500 routers.
Stateful Firewall Anomaly Checking
The stateful firewall recognizes the following events as anomalies and sends them to
the IDS software for processing:
•
•
IP anomalies:
•
IP version is not correct.
•
IP header length field is too small.
•
IP header length is set larger than the entire packet.
•
Bad header checksum.
•
IP total length field is shorter than header length.
•
Packet has incorrect IP options.
•
Internet Control Message Protocol (ICMP) packet length error.
•
Time-to-live (TTL) equals 0.
IP address anomalies:
•
400
IP packet source is a broadcast or multicast.
Copyright © 2018, Juniper Networks, Inc.
Chapter 28: Junos Network Secure Overview
•
•
•
•
•
•
Land attack (source IP equals destination IP).
IP fragmentation anomalies:
•
IP fragment overlap.
•
IP fragment missed.
•
IP fragment length error.
•
IP packet length is more than 64 kilobytes (KB).
•
Tiny fragment attack.
TCP anomalies:
•
TCP port 0.
•
TCP sequence number 0 and flags 0.
•
TCP sequence number 0 and FIN/PSH/RST flags set.
•
TCP flags with wrong combination (TCP FIN/RST or SYN/(URG|FIN|RST).
•
Bad TCP checksum.
UDP anomalies:
•
UDP source or destination port 0.
•
UDP header length check failed.
•
Bad UDP checksum.
Anomalies found through stateful TCP or UDP checks:
•
SYN followed by SYN-ACK packets without ACK from initiator.
•
SYN followed by RST packets.
•
SYN without SYN-ACK.
•
Non-SYN first flow packet.
•
ICMP unreachable errors for SYN packets.
•
ICMP unreachable errors for UDP packets.
Packets dropped according to stateful firewall rules.
NOTE: ACX500 routers do not support IP fragmentation anomalies.
If you employ stateful anomaly detection in conjunction with stateless detection, IDS
can provide early warning for a wide range of attacks, including these:
•
TCP or UDP network probes and port scanning
•
SYN flood attacks
•
IP fragmentation-based attacks such as teardrop, bonk, and boink
Copyright © 2018, Juniper Networks, Inc.
401
Adaptive Services Interfaces Feature Guide for Routing Devices
Release History Table
402
Release
Description
14.2
Starting in Junos OS Release 14.2, MS-MPC and MS-MIC interface cards
support IPv6 traffic for Junos Network Secure Stateful Firewall.
Copyright © 2018, Juniper Networks, Inc.
CHAPTER 29
Junos Network Secure Configuration
Overview
•
Configuring Stateful Firewall Rules on page 403
•
Configuring Stateful Firewall Rule Sets on page 408
•
Examples: Configuring Stateful Firewall Rules on page 409
•
Example: BOOTP and Broadcast Addresses on page 412
•
Example: Configuring Layer 3 Services and the Services SDK on Two PICs on page 413
•
Example: Virtual Routing and Forwarding (VRF) and Service Configuration on page 427
Configuring Stateful Firewall Rules
To configure a stateful firewall rule, include the rule rule-name statement at the [edit
services stateful-firewall] hierarchy level:
[edit services stateful-firewall]
rule rule-name {
match-direction (input | output | input-output);
term term-name {
from {
application-sets set-name;
applications [ application-names ];
destination-address (address | any-ipv4 | any-ipv6 | any-unicast) <except>;
destination-address-range low minimum-value high maximum-value <except>;
destination-prefix-list list-name <except>;
source-address (address | any-ipv4 | any-ipv6 | any-unicast) <except>;
source-address-range low minimum-value high maximum-value <except>;
source-prefix-list list-name <except>;
}
then {
(accept <skip-ids>| discard | reject);
allow-ip-options [ values ];
syslog;
}
}
}
Copyright © 2018, Juniper Networks, Inc.
403
Adaptive Services Interfaces Feature Guide for Routing Devices
NOTE: ACX500 routers do not support applications and application-sets
at the [edit services stateful-firewall rule rule-name term term-name from]
hierarchy level.
NOTE: On ACX500 routers, to enable syslog, include the stateful-firewall-logs
CLI statement at the [edit services service-set service-set-name syslog host
local class] hierarchy level.
Each stateful firewall rule consists of a set of terms, similar to a filter configured at the
[edit firewall] hierarchy level. A term consists of the following:
•
from statement—Specifies the match conditions and applications that are included
and excluded. The from statement is optional in stateful firewall rules.
•
then statement—Specifies the actions and action modifiers to be performed by the
router software. The then statement is mandatory in stateful firewall rules.
ACX500 Series routers do not support the following while configuring stateful firewall
rules:
•
match-direction (output | input-output)
•
post-service-filter at the interface service input hierarchy level.
•
IPv6 source address and destination address.
•
application-sets, application, allow-ip-options at the [edit services stateful-firewall]
hierarchy level.
404
•
Application Layer Gateways (ALGs).
•
Chaining of services within Multiservices Modular Interfaces Card (MS-MIC) and with
inline-services (-si).
•
Class of service.
•
The following show services stateful-firewall CLI commands are not supported:
•
show services stateful-firewall conversations—Show conversations
•
show services stateful-firewall flow-analysis—Show flow table entries
•
show services stateful-firewall redundancy-statistics—Show redundancy statistics
•
show services stateful-firewall sip-call—Show SIP call information
•
show services stateful-firewall sip-register—Show SIP register information
•
show services stateful-firewall subscriber-analysis—Show subscriber table entries
Copyright © 2018, Juniper Networks, Inc.
Chapter 29: Junos Network Secure Configuration Overview
The following sections explain how to configure the components of stateful firewall
rules:
•
Configuring Match Direction for Stateful Firewall Rules on page 405
•
Configuring Match Conditions in Stateful Firewall Rules on page 405
•
Configuring Actions in Stateful Firewall Rules on page 407
Configuring Match Direction for Stateful Firewall Rules
Each rule must include a match-direction statement that specifies the direction in which
the rule match is applied. To configure where the match is applied, include the
match-direction statement at the [edit services stateful-firewall rule rule-name] hierarchy
level:
[edit services stateful-firewall rule rule-name]
match-direction (input | output | input-output);
NOTE: ACX500 Series routers do not support match-direction (output |
input-output).
If you configure match-direction input-output, sessions initiated from both directions
might match this rule.
The match direction is used with respect to the traffic flow through the AS or Multiservices
PIC. When a packet is sent to the PIC, direction information is carried along with it.
With an interface service set, packet direction is determined by whether a packet is
entering or leaving the interface on which the service set is applied.
With a next-hop service set, packet direction is determined by the interface used to route
the packet to the AS or Multiservices PIC. If the inside interface is used to route the packet,
the packet direction is input. If the outside interface is used to direct the packet to the
PIC, the packet direction is output. For more information on inside and outside interfaces,
see “Configuring Service Sets to be Applied to Services Interfaces” on page 9.
On the PIC, a flow lookup is performed. If no flow is found, rule processing is performed.
Rules in this service set are considered in sequence until a match is found. During rule
processing, the packet direction is compared against rule directions. Only rules with
direction information that matches the packet direction are considered. Most packets
result in the creation of bidirectional flows.
Configuring Match Conditions in Stateful Firewall Rules
To configure stateful firewall match conditions, include the from statement at the [edit
services stateful-firewall rule rule-name term term-name] hierarchy level:
[edit services stateful-firewall rule rule-name term term-name]
from {
application-sets set-name;
applications [ application-names ];
destination-address (address | any-ipv4 | any-ipv6 | any-unicast) <except>;
Copyright © 2018, Juniper Networks, Inc.
405
Adaptive Services Interfaces Feature Guide for Routing Devices
destination-address-range low minimum-value high maximum-value <except>;
destination-prefix-list list-name <except>;
source-address (address | any-ipv4 | any-ipv6 | any-unicast) <except>;
source-address-range low minimum-value high maximum-value <except>;
source-prefix-list list-name <except>;
}
NOTE: ACX500 routers do not support applications and application-sets
at the [edit services stateful-firewall rule rule-name term term-name from]
hierarchy level.
The source address and destination address can be either IPv4 or IPv6.
You can use either the source address or the destination address as a match condition,
in the same way that you would configure a firewall filter; for more information, see the
Routing Policies, Firewall Filters, and Traffic Policers Feature Guide. You can use the wildcard
values any-unicast, which denotes matching all unicast addresses, any-ipv4, which
denotes matching all IPv4 addresses, or any-ipv6, which denotes matching all IPv6
addresses.
Alternatively, you can specify a list of source or destination prefixes by configuring the
prefix-list statement at the [edit policy-options] hierarchy level and then including either
the destination-prefix-list or the source-prefix-list statement in the stateful firewall rule.
For an example, see “Examples: Configuring Stateful Firewall Rules” on page 409.
If you omit the from term, the stateful firewall accepts all traffic and the default protocol
handlers take effect:
•
User Datagram Protocol (UDP), Transmission Control Protocol (TCP), and Internet
Control Message Protocol (ICMP) create a bidirectional flow with a predicted reverse
flow.
•
IP creates a unidirectional flow.
You can also include application protocol definitions you have configured at the [edit
applications] hierarchy level; for more information, see “Configuring Application Properties”
on page 367.
•
To apply one or more specific application protocol definitions, include the applications
statement at the [edit services stateful-firewall rule rule-name term term-name from]
hierarchy level.
•
To apply one or more sets of application protocol definitions you have defined, include
the application-sets statement at the [edit services stateful-firewall rule rule-name term
term-name from] hierarchy level.
NOTE: If you include one of the statements that specifies application
protocols, the router derives port and protocol information from the
corresponding configuration at the [edit applications] hierarchy level; you
cannot specify these properties as match conditions.
406
Copyright © 2018, Juniper Networks, Inc.
Chapter 29: Junos Network Secure Configuration Overview
Configuring Actions in Stateful Firewall Rules
To configure stateful firewall actions, include the then statement at the [edit services
stateful-firewall rule rule-name term term-name] hierarchy level:
[edit services stateful-firewall rule rule-name term term-name]
then {
(accept | discard | reject);
allow-ip-options [ values ];
syslog;
}
You must include one of the following actions:
•
accept—The packet is accepted and sent on to its destination.
•
accept skip-ids—The packet is accepted and sent on to its destination, but IDS rule
processing configured on an MS-MPC is skipped.
•
discard—The packet is not accepted and is not processed further.
•
reject—The packet is not accepted and a rejection message is returned; UDP sends an
ICMP unreachable code and TCP sends RST. Rejected packets can be logged or
sampled.
NOTE: The ACX500 indoor routers do not support the action accept skip-ids.
You can optionally configure the firewall to record information in the system logging
facility by including the syslog statement at the [edit services stateful-firewall rule
rule-name term term-name then] hierarchy level. This statement overrides any syslog
setting included in the service set or interface default configuration.
Configuring IP Option Handling
You can optionally configure the firewall to inspect IP header information by including
the allow-ip-options statement at the [edit services stateful-firewall rule rule-name term
term-name then] hierarchy level. When you configure this statement, all packets that
match the criteria specified in the from statement are subjected to additional matching
criteria. A packet is accepted only when all of its IP option types are configured as values
in the allow-ip-options statement. If you do not configure allow-ip-options, only packets
without IP header options are accepted.
NOTE: ACX500 indoor routers do not support the configuration of
allow-ip-options statement.
The additional IP header option inspection applies only to the accept and reject stateful
firewall actions. This configuration has no effect on the discard action. When the IP header
inspection fails, reject frames are not sent; in this case, the reject action has the same
effect as discard.
Copyright © 2018, Juniper Networks, Inc.
407
Adaptive Services Interfaces Feature Guide for Routing Devices
If an IP option packet is accepted by the stateful firewall, Network Address Translation
(NAT) and intrusion detection service (IDS) are applied in the same way as to packets
without IP option headers. The IP option configuration appears only in the stateful firewall
rules; NAT applies to packets with or without IP options.
When a packet is dropped because it fails the IP option inspection, this exception event
generates both IDS event and system log messages. The event type depends on the first
IP option field rejected.
Table 21 on page 408 lists the possible values for the allow-ip-options statement. You can
include a range or set of numeric values, or one or more of the predefined IP option
settings. You can enter either the option name or its numeric equivalent. For more
information, refer to http://www.iana.org/assignments/ip-parameters.
Table 21: IP Option Values
Release History Table
IP Option Name
Numeric
Value
Comment
any
0
Any IP option
ip-security
130
–
ip-stream
136
–
loose-source-route
131
–
route-record
7
–
router-alert
148
–
strict-source-route
137
–
timestamp
68
–
Release
Description
17.1
accept skip-ids—The packet is accepted and sent on to its destination,
but IDS rule processing configured on an MS-MPC is skipped.
Related
Documentation
•
Junos Network Secure Overview on page 399
•
Configuring Protection Against Network Attacks on an MS-MPC or MS-MIC on page 448
Configuring Stateful Firewall Rule Sets
The rule-set statement defines a collection of stateful firewall rules that determine what
actions the router software performs on packets in the data stream. You define each rule
408
Copyright © 2018, Juniper Networks, Inc.
Chapter 29: Junos Network Secure Configuration Overview
by specifying a rule name and configuring terms. Then, you specify the order of the rules
by including the rule-set statement at the [edit services stateful-firewall] hierarchy level
with a rule statement for each rule:
[edit services stateful-firewall]
rule-set rule-set-name {
rule rule-name;
}
The router software processes the rules in the order in which you specify them in the
configuration. If a term in a rule matches the packet, the router performs the corresponding
action and the rule processing stops. If no term in a rule matches the packet, processing
continues to the next rule in the rule set. If none of the rules matches the packet, the
packet is dropped by default.
Examples: Configuring Stateful Firewall Rules
The following example show a stateful firewall configuration containing two rules, one
for input matching on a specified application set and the other for output matching on
a specified source address:
[edit services]
stateful-firewall {
rule Rule1 {
match-direction input;
term 1 {
from {
application-sets Applications;
}
then {
accept;
}
}
term accept {
then {
accept;
}
}
}
rule Rule2 {
match-direction output;
term Local {
from {
source-address {
10.1.3.2/32;
}
}
then {
accept;
}
}
}
}
Copyright © 2018, Juniper Networks, Inc.
409
Adaptive Services Interfaces Feature Guide for Routing Devices
The following example has a single rule with two terms. The first term rejects all traffic
in my-application-group that originates from the specified source address, and provides
a detailed system log record of the rejected packets. The second term accepts Hypertext
Transfer Protocol (HTTP) traffic from anyone to the specified destination address.
[edit services stateful-firewall]
rule my-firewall-rule {
match-direction input-output;
term term1 {
from {
source-address 10.1.3.2/32;
application-sets my-application-group;
}
then {
reject;
syslog;
}
}
term term2 {
from {
destination-address 10.2.3.2/32;
applications http;
}
then {
accept;
}
}
}
The following example shows use of source and destination prefix lists. This requires two
separate configuration items.
You configure the prefix list at the [edit policy-options] hierarchy level:
[edit]
policy-options {
prefix-list p1 {
1.1.1.1/32;
2.2.2.0/24;
}
prefix-list p2 {
3.3.3.3/32;
4.4.4.0/24;
}
}
You reference the configured prefix list in the stateful firewall rule:
[edit]
services {
stateful-firewall {
rule r1 {
match-direction input;
term t1 {
from {
source-prefix-list {
410
Copyright © 2018, Juniper Networks, Inc.
Chapter 29: Junos Network Secure Configuration Overview
p1;
}
destination-prefix-list {
p2;
}
}
then {
accept;
}
}
}
}
}
This is equivalent to the following configuration:
[edit]
services {
stateful-firewall {
rule r1 {
match-direction input;
term t1 {
from {
source-address {
1.1.1.1/32;
2.2.2.0/24;
}
destination-address {
3.3.3.3/32;
4.4.4.0/24;
}
}
then {
accept;
}
}
}
}
}
You can use the except qualifier with the prefix lists, as in the following example. In this
case, the except qualifier applies to all prefixes included in prefix list p2.
[edit]
services {
stateful-firewall {
rule r1 {
match-direction input;
term t1 {
from {
source-prefix-list {
p1;
}
destination-prefix-list {
p2 except;
}
Copyright © 2018, Juniper Networks, Inc.
411
Adaptive Services Interfaces Feature Guide for Routing Devices
}
then {
accept;
}
}
}
}
}
For additional examples that combine stateful firewall configuration with other services
and with virtual private network (VPN) routing and forwarding (VRF) tables, see the
configuration examples.
NOTE: You can define the service-set and assign it either as interface style
or next-hop style.
Related
Documentation
•
Example: BOOTP and Broadcast Addresses on page 412
•
Example: Dynamic Source NAT as a Next-Hop Service on page 134
•
Example: Virtual Routing and Forwarding (VRF) and Service Configuration on page 427
•
Example: Service Interfaces Configuration
•
Configuring Service Sets to be Applied to Services Interfaces on page 9
•
Example: Configuring Layer 3 Services and the Services SDK on Two PICs on page 413
Example: BOOTP and Broadcast Addresses
The following example supports Bootstrap Protocol (BOOTP) and broadcast addresses:
[edit applications]
application bootp {
application-protocol bootp;
protocol udp;
destination-port 67;
}
[edit services]
stateful-firewall bootp-support {
rule bootp-allow {
direction input;
term bootp-allow {
from {
destination-address {
any-unicast;
255.255.255.255;
}
application bootp;
}
then {
accept;
}
412
Copyright © 2018, Juniper Networks, Inc.
Chapter 29: Junos Network Secure Configuration Overview
}
}
}
Example: Configuring Layer 3 Services and the Services SDK on Two PICs
You can configure the Layer 3 service package and the Services SDK on two PICs. For
this example, you must configure an FTP or HTTP client and a server. In this configuration,
the client side of the router interface is ge-1/2/2.1 and the server side of the router interface
is ge-1/1/0.48. This configuration enables Network Address Translation (NAT) with
stateful firewall (SFW) on the uKernel PIC and application identification (APPID),
application-aware access list (AACL), and intrusion detection and prevention (IDP) on
the Services SDK PIC for FTP or HTTP traffic.
NOTE: The Services SDK does not support NAT yet. When NAT is required,
you can configure the Layer 3 service package to deploy NAT along with the
Services SDK such as APPID, AACL, or IDP.
NOTE: The IDP functionality is deprecated for the MX Series for Junos OS
release 17.1R1 and above.
To deploy the Layer 3 service package and the Services SDK on two PICs:
1.
In configuration mode, go to the following hierarchy level:
[edit services]
user@host# edit stateful-firewall
2. In the hierarchy level, configure the conditions for the stateful firewall rule r1.
[edit services stateful-firewall]
user@host# set rule rule-name match-direction input-output term term from
applications application-name
user@host# set rule rule-name match-direction input-output term term then accept
syslog
In this example, the stateful firewall term is ALLOWED-SERVICES. Enclose the
application names—junos-ftp, junos-http, and junos-icmp-ping—in brackets for
application-name.
[edit services stateful-firewall]
user@host# set rule r1 match-direction input-output term ALLOWED-SERVICES from
applications [ junos-ftp junos-http junos-icmp-ping ]
user@host# set rule r1 match-direction input-output term ALLOWED-SERVICES then
accept syslog
3. Configure the conditions for the stateful firewall rule r2.
[edit services stateful-firewall]
user@host# set rule rule-name match-direction input-output term term then discard
Copyright © 2018, Juniper Networks, Inc.
413
Adaptive Services Interfaces Feature Guide for Routing Devices
user@host# set rule rule-name match-direction input-output term term then syslog
In this example, the stateful firewall term is term1.
[edit services stateful-firewall]
user@host# set rule r2 match-direction input-output term term1 then discard
user@host# set rule r2 match-direction input-output term term1 then syslog
4. Go to the following hierarchy level and verify the configuration:
[edit services stateful-firewall]
user@host# show
rule r1 {
match-direction input-output;
term ALLOWED-SERVICES {
from {
applications [ junos-ftp junos-http junos-icmp-ping ];
}
then {
accept;
syslog;
}
}
}
rule r2 {
match-direction input-output;
term term1 {
then {
discard;
syslog;
}
}
}
5. Go to the following hierarchy level:
[edit services]
user@host# edit nat
6. In the hierarchy level, configure the NAT pool.
[edit services nat]
user@host# set pool pool-name address ip-address
user@host# set pool pool-name port automatic
In this example, the NAT pool is OUTBOUND-SERVICES and the IP address is
10.48.0.2/32.
[edit services natl]
user@host# set pool OUTBOUND-SERVICES address 10.48.0.2/32
user@host# set pool OUTBOUND-SERVICES port automatic
7. Configure the NAT rule.
[edit services nat]
user@host# set rule rule-name match-direction output term term from applications
application-name
414
Copyright © 2018, Juniper Networks, Inc.
Chapter 29: Junos Network Secure Configuration Overview
user@host# set rule rule-name match-direction output term term then translated
source-pool source-pool translation-type source dynamic
In this example, the NAT rule is SET-MSR-ADDR, the NAT term is
TRANSLATE-SOURCE-ADDR, and the source pool is OUTBOUND-SERVICES. Enclose
the application names—junos-ftp, junos-http, and junos-icmp-ping—in parentheses
for application-name.
[edit services nat]
user@host# set rule SET-MSR-ADDR match-direction output term
TRANSLATE-SOURCE-ADDR from applications [ junos-ftp junos-http
junos-icmp-ping ]
user@host# set rule SET-MSR-ADDR match-direction output term
TRANSLATE-SOURCE-ADDR then translated source-pool OUTBOUND-SERVICES
translation-type source dynamic
8. Go to the following hierarchy level and verify the configuration:
[edit services nat]
user@host# show
pool OUTBOUND-SERVICES {
address 11.48.0.2/32;
port {
automatic;
}
}
rule SET-MSR-ADDR {
match-direction output;
term TRANSLATE-SOURCE-ADDR {
from {
applications [ junos-ftp junos-http junos-icmp-ping ];
}
then {
translated {
source-pool OUTBOUND-SERVICES;
translation-type {
source dynamic;
}
}
}
}
}
9. Go to the following hierarchy level:
[edit security]
user@host# edit idp
NOTE: The [edit security idp] statements are deprecated for the MX Series
for Junos OS release 17.1R1 and above.
10. In the hierarchy level, configure the IDP policy.
[edit security idp]
user@host# set idp-policy policy-name rulebase-ips rule rule-name match application
default attacks predefined-attacks attack-name
Copyright © 2018, Juniper Networks, Inc.
415
Adaptive Services Interfaces Feature Guide for Routing Devices
user@host# set idp-policy policy-name rulebase-ips rule rule-name match application
default attacks predefined-attack-groups attack-group--name
user@host# set idp-policy policy-name rulebase-ips rule rule-name then action
no-action
user@host# set idp-policy policy-name rulebase-ips rule rule-name then notification
log-attacks alert
In this example, the IDP policy is test1, the rule is r1, the predefined attack is
FTP:USER:ROOT, and the predefined attack group is "Recommended Attacks".
[edit security idp]
user@host# set idp-policy test1 rulebase-ips rule r1 match application default attacks
predefined-attacks FTP:USER:ROOT
user@host# set idp-policy test1 rulebase-ips rule r1 match application default attacks
predefined-attack-groups [ "Recommended Attacks" ]
user@host# set idp-policy test1 rulebase-ips rule r1 then action no-action
user@host# set idp-policy test1 rulebase-ips rule r1 then notification log-attacks alert
11. Configure the trace options for IDP services.
[edit security idp]
user@host# set traceoptions file filename
user@host# set traceoptions flag all
user@host# set traceoptions level all
In this example, the log file name is idp-demo.log.
[edit security idp]
user@host# set traceoptions file idp-demo.log
user@host# set traceoptions flag all
user@host# set traceoptions level all
12. Go to the following hierarchy level and verify the configuration:
[edit security idp]
user@host# show
idp-policy test1 {
rulebase-ips {
rule r1 {
match {
application default;
attacks {
predefined-attacks FTP:USER:ROOT;
predefined-attack-groups "Recommended Attacks";
}
}
then {
action {
no-action;
}
notification {
log-attacks {
alert;
}
}
}
}
}
416
Copyright © 2018, Juniper Networks, Inc.
Chapter 29: Junos Network Secure Configuration Overview
}
traceoptions {
file idp-demo.log;
flag all;
level all;
}
13. Go to the following hierarchy level:
[edit services]
user@host# edit aacl
14. In the hierarchy level, configure the AACL rules.
[edit services aacl]
user@host# set rule rule-name match-direction input-output term term from
application-group-any
user@host# set rule rule-name match-direction input-output term term then count
application accept
In this example, the AACL rule is app-aware and the term is t1.
[edit services aacl]
user@host# set rule app-aware match-direction input-output term t1 from
application-group-any
user@host# set rule app-aware match-direction input-output term t1 then count
application accept
15. Go to the following hierarchy level and verify the configuration:
[edit services aacl]
user@host# show
rule app-aware {
match-direction input-output;
term t1 {
from {
application-group-any;
}
then {
count application;
accept;
}
}
}
16. Go to the following hierarchy level:
[edit services]
user@host# edit service-set App-Aware-Set
17. Configure the APPID profile.
[edit services service-set App-Aware-Set]
user@host# set application-identification-profile application-identification-profile
Copyright © 2018, Juniper Networks, Inc.
417
Adaptive Services Interfaces Feature Guide for Routing Devices
In this example, the APPID profile is dummy-profile.
[edit services service-set App-Aware-Set]
user@host# set application-identification-profile dummy-profile
18. Configure the IDP profile.
[edit services service-set App-Aware-Set]
user@host# set idp-profile idp-profile
In this example, the IDP profile is test1.
[edit services service-set App-Aware-Set]
user@host# set idp-profile test1
19. Configure the policy decision statistics profile.
[edit services service-set App-Aware-Set]
user@host# set policy-decision-statistics-profile profile-name
In this example, the policy decision statistics profile is lpdf-stats.
[edit services service-set App-Aware-Set]
user@host# set policy-decision-statistics-profile lpdf-stats
20. Configure the AACL rules.
[edit services service-set App-Aware-Set]
user@host# set aacl-rules rule-name
In this example, the AACL rule name is app-aware.
[edit services service-set App-Aware-Set]
user@host# set aacl-rules app-aware
21. Configure two stateful firewall rules.
[edit services service-set App-Aware-Set]
user@host# set stateful-firewall-rules rule-name
user@host# set stateful-firewall-rules rule-name
In this example, the first rule is r1 and the second rule is r2.
[edit services service-set App-Aware-Set]
user@host# set stateful-firewall-rules r1
user@host# set stateful-firewall-rules r2
22. In the hierarchy level, configure the service set to bypass traffic on service PIC failure.
[edit services service-set App-Aware-Set]
user@host# set service-set-options bypass-traffic-on-pic-failure
23. Configure interface-specific service set options.
[edit services service-set App-Aware-Set]
user@host# set interface-service service-interface service-interface
418
Copyright © 2018, Juniper Networks, Inc.
Chapter 29: Junos Network Secure Configuration Overview
In this example, the services interface is ms-0/1/0.
[edit services service-set App-Aware-Set]
user@host# set interface-service service-interface ms-0/1/0
24. Go to the following hierarchy level and verify the configuration:
[edit services service-set App-Aware-Set]
user@host# show
application-identification-profile dummy-profile;
idp-profile test1;
policy-decision-statistics-profile {
lpdf-stats;
}
aacl-rules app-aware;
stateful-firewall-rules r1;
stateful-firewall-rules r2;
service-set-options {
bypass-traffic-on-pic-failure;
}
interface-service {
service-interface ms-0/1/0;
}
25. Go to the following hierarchy level:
[edit services]
user@host# edit service-set NAT-SFW-SET
26. In the hierarchy level, configure optional notification parameters for the services
interface. Note that it is required only for debugging.
[edit services service-set NAT-SFW-SET]
user@host# set syslog host host-name services any
In this example, the host to notify is local.
[edit services service-set NAT-SFW-SET]
user@host# set services-options syslog host local services any
27. Configure two stateful firewall rules.
[edit services service-set NAT-SFW-SET]
user@host# set stateful-firewall-rules rule-name
user@host# set stateful-firewall-rules rule-name
In this example, the first rule is r1 and the second rule is r2.
[edit services service-set NAT-SFW-SET]
user@host# set stateful-firewall-rules r1
user@host# set stateful-firewall-rules r2
28. Configure NAT rules.
[edit services service-set NAT-SFW-SET]
user@host# set nat-rules rule-name
Copyright © 2018, Juniper Networks, Inc.
419
Adaptive Services Interfaces Feature Guide for Routing Devices
In this example, the NAT rule is SET-MSR-ADDR.
[edit services service-set NAT-SFW-SET]
user@host# set nat-rules SET-MSR-ADDR
29. Configure interface-specific service set options.
[edit services service-set NAT-SFW-SET]
user@host# set interface-service service-interface service-interface
In this example, the services interface is sp-3/1/0.
[edit services service-set NAT-SFW-SET]
user@host# set interface-service service-interface sp-3/1/0
30. Go to the following hierarchy level and verify the configuration:
[edit services service-set NAT-SFW-SET]
user@host# show
syslog {
host local {
services any;
}
}
stateful-firewall-rules r1;
stateful-firewall-rules r2;
interface-service {
service-interface sp-3/1/0;
}
31. Go to the following hierarchy level:
user@host# edit interfaces
32. In the hierarchy level, configure the interface.
[edit interfaces]
user@host# set interface
In this example, the interface is ge-1/2/2.1.
[edit interfaces]
user@host# set ge-1/2/2.1
33. Go to the following hierarchy level:
[edit interfaces]
user@host# edit ge-1/2/2.1
34. In the hierarchy level, configure the service set for received packets.
[edit interfaces ge-1/2/2 unit 1]
user@host# set family inet service input service-set service-set-name
In this example, the input service set is App-Aware-Set.
[edit interfaces ge-1/2/2 unit 1]
420
Copyright © 2018, Juniper Networks, Inc.
Chapter 29: Junos Network Secure Configuration Overview
user@host# set family inet service input service-set App-Aware-Set
35. Configure the service set for transmitted packets.
[edit interfaces ge-1/2/2 unit 1]
user@host# set family inet service output service-set service-set-name
In this example, the output service set is App-Aware-Set.
[edit interfaces ge-1/2/2 unit 1]
user@host# set family inet service output service-set App-Aware-Set
36. Go to the following hierarchy level:
[edit interfaces ge-1/2/2 unit 1]
user@host# edit family inet
37. In the hierarchy level, configure the interface address.
[edit interfaces ge-1/2/2 unit 1 family inet]
user@host# set address source
In this example, the interface address is 10.10.9.10/30.
[edit interfaces]
user@host# set address 10.10.9.10/30
38. Go to the following hierarchy level and verify the configuration:
[edit interfaces ge-1/2/2 unit 1]
user@host# show
family inet {
service {
input {
service-set App-Aware-Set;
}
output {
service-set App-Aware-Set;
}
}
address 10.10.9.10/30;
}
39. Go to the following hierarchy level:
user@host# edit interfaces
40. In the hierarchy level, configure the interface.
[edit interfaces]
user@host# set interface
In this example, the interface is ge-1/1/0.48.
[edit interfaces]
user@host# set ge-1/1/0.48
Copyright © 2018, Juniper Networks, Inc.
421
Adaptive Services Interfaces Feature Guide for Routing Devices
41. Go to the following hierarchy level:
[edit interfaces]
user@host# edit ge-1/1/0.48
42. In the hierarchy level, configure the service set for received packets.
[edit interfaces ge-1/1/0 unit 48]
user@host# set family inet service input service-set service-set-name
In this example, the service set is NAT-SFW-SET.
[edit interfaces ge-1/1/0 unit 48]
user@host# set family inet service input service-set NAT-SFW-SET
43. Configure the service set for transmitted packets.
[edit interfaces ge-1/1/0 unit 48]
user@host# set family inet service output service-set service-set-name
In this example, the service set is NAT-SFW-SET.
[edit interfaces ge-1/1/0 unit 48]
user@host# set family inet service output service-set NAT-SFW-SET
44. Go to the following hierarchy level:
[edit interfaces ge-1/1/0 unit 48]
user@host# edit family inet
45. Configure the interface address.
[edit interfaces ge-1/1/0 unit 48 family inet]
user@host# set address source
In this example, the interface address is 10.48.0.1/31.
[edit interfaces ge-1/1/0 unit 48 family inet]
user@host# set address 10.48.0.1/31
46. Go to the following hierarchy level and verify the configuration:
[edit interfaces ge-1/1/0 unit 48]
user@host# show
family inet {
service {
input {
service-set NAT-SFW-SET;
}
output {
service-set NAT-SFW-SET;
}
}
address 10.48.0.1/31;
}
47. Go to the following hierarchy level:
422
Copyright © 2018, Juniper Networks, Inc.
Chapter 29: Junos Network Secure Configuration Overview
user@host# edit interfaces
48. In the hierarchy level, configure the interface.
[edit interfaces]
set interface
In this example, the interface is ms-0/1/0.0.
[edit interfaces]
user@host# set ms-0/1/0.0
49. Go to the following hierarchy level:
[edit interfaces]
user@host# edit ms-0/1/0.0
50. In the hierarchy level, configure the protocol family.
[edit interfaces ms-0/1/0 unit 0]
user@host# set family inet
51. Go to the following hierarchy level and verify the configuration:
[edit interfaces ms-0/1/0]
user@host# show
unit 0 {
family inet;
}
52. Go to the following hierarchy level:
user@host# edit interfaces
53. In the hierarchy level, configure the interface.
[edit interfaces]
set interface
In this example, the interface is sp-3/1/0.0.
[edit interfaces]
user@host# set sp-3/1/0.0
54. Go to the following hierarchy level:
[edit interfaces]
user@host# edit sp-3/1/0
55. In the hierarchy level, configure optional notification parameters for the services
interface. Note that it is required only for debugging.
[edit interfaces sp-3/1/0]
user@host# set services-options syslog host host-name services any
Copyright © 2018, Juniper Networks, Inc.
423
Adaptive Services Interfaces Feature Guide for Routing Devices
In this example, the host to notify is local.
[edit interfaces sp-3/1/0]
user@host# set services-options syslog host local services any
56. Go to the following hierarchy level:
[edit interfaces]
user@host# edit sp-3/1/0.0
57. In the hierarchy level, configure the protocol family.
[edit interfaces sp-3/1/0 unit 0]
user@host# set family inet
58. Go to the following hierarchy level and verify the configuration:
[edit interfaces sp-3/1/0]
user@host# show
services-options {
syslog {
host local {
services any;
}
}
}
unit 0 {
family inet;
}
59. Go to the following hierarchy level:
[edit chassis]
60. In the hierarchy level, configure the redundancy settings.
[edit chassis]
user@host# set no-service-pic-restart-on-failover
user@host# set redundancy graceful-switchover
61. Configure the FPC and PIC.
[edit chassis]
user@host# edit fpc slot pic slot
In this example, the FPC is in slot 0 and the PIC is in slot 1.
[edit chassis]
user@host# edit fpc 0 pic 1
62. Configure the number of cores dedicated to run control functionality.
[edit chassis fpc slot pic slot]
user@host# set adaptive-services service-package extension-provider control-cores
control-cores
424
Copyright © 2018, Juniper Networks, Inc.
Chapter 29: Junos Network Secure Configuration Overview
In this example, the number of control cores is 1.
[edit chassis fpc 1 pic 0]
user@host# set adaptive-services service-package extension-provider control-cores
1
63. Configure the number of processing cores dedicated to data.
[edit chassis fpc slot pic slot]
user@host# set adaptive-services service-package extension-provider data-cores
data-cores
In this example, the number of data cores is 7.
[edit chassis fpc 1 pic 0]
user@host# set adaptive-services service-package extension-provider data-cores 7
64. Configure the size of the object cache in megabytes. Only values in increments of 128
MB are allowed and the maximum value of object cache can be 1280 MB. On MS-100,
the value is 512 MB.
[edit chassis fpc slot pic slot]
user@host# set adaptive-services service-package extension-provider
object-cache-size object-cache-size
In this example, the size of the object cache is 1280 MB.
[edit chassis fpc 1 pic 0]
user@host# set adaptive-services service-package extension-provider
object-cache-size 1280
65. Configure the size of the policy database in megabytes.
[edit chassis fpc slot pic slot]
user@host# set adaptive-services service-package extension-provider policy-db-size
policy-db-size
In this example, the size of the policy database is 64 MB.
[edit chassis fpc 1 pic 0]
user@host# set adaptive-services service-package extension-provider policy-db-size
64
66. Configure the packages.
[edit chassis fpc slot pic slot]
user@host# set adaptive-services service-package extension-provider package
package
In this example, the first package is jservices-appid, the second package is jservices-aacl,
the third package is jservices-llpdf, the fourth package is jservices-idp, and the fifth
package is jservices-sfw. jservices-sfw is available only in Junos OS Release 10.1 and
later.
[edit chassis fpc 1 pic 0]
user@host# set adaptive-services service-package extension-provider package
jservices-appid
Copyright © 2018, Juniper Networks, Inc.
425
Adaptive Services Interfaces Feature Guide for Routing Devices
user@host# set adaptive-services service-package extension-provider package
jservices-aacl
user@host# set adaptive-services service-package extension-provider package
jservices-llpdf
user@host# set adaptive-services service-package extension-provider package
jservices-idp
user@host# set adaptive-services service-package extension-provider package
jservices-sfw
67. Configure the IP network services.
[edit chassis]
user@host# set network-services ip
68. Go to the following hierarchy level and verify the configuration:
[edit chassis]
user@host# show chassis
no-service-pic-restart-on-failover;
filter-memory-enhanced;
redundancy {
graceful-switchover;
}
fpc 0 {
pic 1 {
adaptive-services {
service-package {
extension-provider {
control-cores 1;
data-cores 7;
object-cache-size 1280;
policy-db-size 64;
package jservices-appid;
package jservices-aacl;
package jservices-llpdf;
package jservices-idp;
package jservices-sfw;
}
}
}
}
}
network-services ip;
426
Copyright © 2018, Juniper Networks, Inc.
Chapter 29: Junos Network Secure Configuration Overview
Release History Table
Release
Description
17.1R1
The IDP functionality is deprecated for the MX Series for Junos OS release
17.1R1 and above.
17.1R1
The [edit security idp] statements are deprecated for the MX Series for
Junos OS release 17.1R1 and above.
Example: Virtual Routing and Forwarding (VRF) and Service Configuration
The following example combines virtual routing and forwarding (VRF) and services
configuration:
[edit policy-options]
policy-statement test-policy {
term t1 {
then reject;
}
}
[edit routing-instances]
test {
interface ge-0/2/0.0;
interface sp-1/3/0.20;
instance-type vrf;
route-distinguisher 10.58.255.1:37;
vrf-import test-policy;
vrf-export test-policy;
routing-options {
static {
route 0.0.0.0/0 next-table inet.0;
}
}
}
[edit interfaces]
ge-0/2/0 {
unit 0 {
family inet {
service {
input service-set nat-me;
output service-set nat-me;
}
}
}
}
sp-1/3/0 {
unit 0 {
family inet;
}
unit 20 {
family inet;
service-domain inside;
}
unit 21 {
Copyright © 2018, Juniper Networks, Inc.
427
Adaptive Services Interfaces Feature Guide for Routing Devices
family inet;
service-domain outside;
}
[edit services]
stateful-firewall {
rule allow-any-input {
match-direction input;
term t1 {
then accept;
}
}
}
nat {
pool hide-pool {
address 10.58.16.100;
port automatic;
}
rule hide-all-input {
match-direction input;
term t1 {
then {
translated {
source-pool hide-pool;
translation-type source napt-44;
}
}
}
}
}
service-set nat-me {
stateful-firewall-rules allow-any-input;
nat-rules hide-all-input;
interface-service {
service-interface sp-1/3/0.20;
}
}
}
428
Copyright © 2018, Juniper Networks, Inc.
CHAPTER 30
IDS Configuration on MS-DPC Overview
•
Understanding SYN Cookie Protection on an MS-DPC on page 429
•
Configuring IDS Rules on an MS-DPC on page 430
•
Configuring IDS Rule Sets on an MS-DPC on page 438
•
Examples: Configuring IDS Rules on an MS-DPC on page 439
Understanding SYN Cookie Protection on an MS-DPC
SYN cookie is a stateless SYN proxy mechanism you can use in conjunction with other
defenses against a SYN flood attack. SYN cookie is supported on the MS-DPC
multiservices card.
As with traditional SYN proxying, SYN cookie is activated when the SYN flood attack
threshold is exceeded. However, because SYN cookie is stateless, it does not set up a
session or policy and route lookups upon receipt of a SYN segment, and it maintains no
connection request queues. This dramatically reduces CPU and memory usage and is
the primary advantage of using SYN cookie over the traditional SYN proxying mechanism.
When SYN cookie is enabled on Junos OS and becomes the TCP-negotiating proxy for
the destination server, it replies to each incoming SYN segment with a SYN/ACK
containing an encrypted cookie as its initial sequence number (ISN). The cookie is an
MD5 hash of the original source address and port number, destination address and port
number, and ISN from the original SYN packet. After sending the cookie, Junos OS drops
the original SYN packet and deletes the calculated cookie from memory. If there is no
response to the packet containing the cookie, the attack is noted as an active SYN attack
and is effectively stopped.
If the initiating host responds with a TCP packet containing the cookie +1 in the TCP ACK
field, Junos OS extracts the cookie, subtracts 1 from the value, and recomputes the cookie
to validate that it is a legitimate ACK. If it is legitimate, Junos OS starts the TCP proxy
process by setting up a session and sending a SYN to the server containing the source
information from the original SYN. When Junos OS receives a SYN/ACK from the server,
it sends ACKs to the server and to the initiation host. At this point the connection is
established and the host and server are able to communicate directly.
Copyright © 2018, Juniper Networks, Inc.
429
Adaptive Services Interfaces Feature Guide for Routing Devices
NOTE: The use of SYN cookie or SYN proxy enables the router device to
protect the TCP servers behind it from SYN flood attacks in IPv6 flows.
Related
Documentation
•
Configuring IDS Rule Sets on an MS-DPC on page 438
Configuring IDS Rules on an MS-DPC
IDS rules configured with an MS-DPC identify traffic for which you want the router software
to count events. Because IDS is based on stateful firewall properties, you must configure
at least one stateful firewall rule and include it in the service set with the IDS rules; for
more information, see “Configuring Stateful Firewall Rules” on page 403.
NOTE: To configure network attack protection with an MS-MPC, see
“Configuring Protection Against Network Attacks on an MS-MPC or MS-MIC”
on page 448.
To configure an IDS rule, include the rule rule-name statement at the [edit services ids]
hierarchy level:
[edit services ids]
rule rule-name {
match-direction (input | output | input-output);
term term-name {
from {
application-sets set-name;
applications [ application-names ];
destination-address (address | any-unicast) <except>;
destination-address-range low minimum-value high maximum-value <except>;
destination-prefix-list list-name <except>;
source-address (address | any-unicast) <except>;
source-address-range low minimum-value high maximum-value <except>;
source-prefix-list list-name <except>;
}
then {
aggregation (IDS) {
destination-prefix prefix-value | destination-prefix-ipv6 (IDS) prefix-value;
source-prefix prefix-value | source-prefix-ipv6 prefix-value;
}
(force-entry | ignore-entry);
logging {
syslog;
threshold rate;
}
session-limit {
by-destination (IDS MS-DPC) {
hold-time seconds;
maximum number;
packets number;
430
Copyright © 2018, Juniper Networks, Inc.
Chapter 30: IDS Configuration on MS-DPC Overview
rate number;
}
by-pair (IDS MS-DPC) {
hold-time seconds;
maximum number;
packets number;
rate number;
}
by-source (IDS MS-DPC) {
hold-time seconds;
maximum number;
packets number;
rate number;
}
}
syn-cookie {
mss value;
threshold rate;
}
}
}
}
Each IDS rule consists of a set of terms, similar to a filter configured at the [edit firewall]
hierarchy level. A term consists of the following:
•
from statement—Specifies the match conditions and applications that are included
and excluded.
•
then statement—Specifies the actions and action modifiers to be performed by the
router software.
The following sections describe IDS rule content in more detail:
•
Configuring Match Direction for IDS Rules on page 431
•
Configuring Match Conditions in IDS Rules on page 432
•
Configuring Actions in IDS Rules on page 433
Configuring Match Direction for IDS Rules
Each rule must include a match-direction statement that specifies whether the match is
applied on the input or output side of the interface. To configure where the match is
applied, include the match-direction (input | input-output | output) statement at the [edit
services ids rule rule-name] hierarchy level:
[edit services ids rule rule-name]
match-direction (input | output | input-output);
If you configure match-direction input-output, bidirectional rule creation is .
The match direction is used with respect to the traffic flow through the AS or Multiservices
PIC. When a packet is sent to the PIC, direction information is carried along with it.
With an interface service set, packet direction is determined by whether a packet is
entering or leaving the interface on which the service set is applied.
Copyright © 2018, Juniper Networks, Inc.
431
Adaptive Services Interfaces Feature Guide for Routing Devices
With a next-hop service set, packet direction is determined by the interface used to route
the packet to the AS or Multiservices PIC. If the inside interface is used to route the packet,
the packet direction is input. If the outside interface is used to direct the packet to the
PIC, the packet direction is output. For more information on inside and outside interfaces,
see “Configuring Service Sets to be Applied to Services Interfaces” on page 9.
On the AS or Multiservices PIC, a flow lookup is performed. If no flow is found, rule
processing is performed. All rules in the service set are considered. During rule processing,
the packet direction is compared against rule directions. Only rules with direction
information that match the packet direction are considered.
Configuring Match Conditions in IDS Rules
To configure IDS match conditions, include the from statement at the [edit services ids
rule rule-name term term-name] hierarchy level:
[edit services ids rule rule-name term term-name]
from {
application-sets set-name;
applications [ application-names ];
destination-address (address | any-unicast) <except>;
destination-address-range low minimum-value high maximum-value <except>;
destination-prefix-list list-name <except>;
source-address (address | any-unicast) <except>;
source-address-range low minimum-value high maximum-value <except>;
source-prefix-list list-name <except>;
}
If you omit the from statement, the software accepts all events and places them in the
IDS cache for processing.
The source address and destination address can be either IPv4 or IPv6. You can use the
destination address, a range of destination addresses, a source address, or a range of
source addresses as a match condition, in the same way that you would configure a
firewall filter; for more information, see the Routing Policies, Firewall Filters, and Traffic
Policers Feature Guide.
Alternatively, you can specify a list of source or destination prefixes by including the
prefix-list statement at the [edit policy-options] hierarchy level and then including either
the destination-prefix-list or source-prefix-list statement in the IDS rule. For an example,
see “Examples: Configuring Stateful Firewall Rules” on page 409.
You can also include application protocol definitions that you have configured at the
[edit applications] hierarchy level; for more information, see “Configuring Application
Properties” on page 367.
432
•
To apply one or more specific application protocol definitions, include the applications
statement at the [edit services ids rule rule-name term term-name from] hierarchy level.
•
To apply one or more sets of application protocol definitions that you have defined,
include the application-sets statement at the [edit services ids rule rule-name term
term-name from] hierarchy level.
Copyright © 2018, Juniper Networks, Inc.
Chapter 30: IDS Configuration on MS-DPC Overview
NOTE: If you include one of the statements that specifies application
protocols, the router derives port and protocol information from the
corresponding configuration at the [edit applications] hierarchy level; you
cannot specify these properties as match conditions.
If a match occurs on an application, the application protocol is displayed separately in
the show services ids command output. For more information, see the CLI Explorer.
Configuring Actions in IDS Rules
To configure IDS actions, include the then statement at the [edit services ids rule rule-name
term term-name] hierarchy level:
[edit services ids rule rule-name term term-name]
then {
aggregation (IDS) {
destination-prefix prefix-value | destination-prefix-ipv6 (IDS) prefix-value;
source-prefix prefix-value | source-prefix-ipv6 prefix-value;
}
(force-entry | ignore-entry);
logging {
syslog;
threshold rate;
}
session-limit {
by-destination (IDS MS-DPC) {
hold-time seconds;
maximum number;
packets number;
rate number;
}
by-pair (IDS MS-DPC) {
hold-time seconds;
maximum number;
packets number;
rate number;
}
by-source (IDS MS-DPC) {
hold-time seconds;
maximum number;
packets number;
rate number;
}
}
syn-cookie {
mss value;
threshold rate;
}
}
You can configure the following possible actions:
Copyright © 2018, Juniper Networks, Inc.
433
Adaptive Services Interfaces Feature Guide for Routing Devices
•
aggregation—The router aggregates traffic labeled with the specified source or
destination prefixes before passing the events to IDS processing. This is helpful if you
want to examine all the traffic connected with a particular source or destination host.
To collect traffic with some other marker, such as a particular application or port,
configure that value in the match conditions.
To configure aggregation prefixes, include the aggregation statement at the [edit
services ids rule rule-name term term-name then] hierarchy level and specify values for
source-prefix, destination-prefix source-prefix-ipv6, or destination-prefix-ipv6:
[edit services ids rule rule-name term term-name then]
aggregation (IDS) {
destination-prefix prefix-value | destination-prefix-ipv6 (IDS) prefix-value;
source-prefix prefix-value | source-prefix-ipv6 prefix-value;
}
The value of source-prefix and destination-prefix must be an integer between 1 and 32.
The value of source-prefix-ipv6 and destination-prefix-ipv6 must be an integer between
1 and 128.
•
(force-entry | ignore-entry)—force-entry provides a permanent spot in IDS caches for
subsequent events after one event is registered. By default, the IDS software does not
record information about “good” packets that do not exhibit suspicious behavior. You
can use the force-entry statement to record all traffic from a suspect host, even traffic
that would not otherwise be counted.
ignore-entry ensures that all IDS events are ignored. You can use this statement to
disregard all traffic from a host you trust, including any temporary anomalies that IDS
would otherwise count as events.
To configure an entry behavior different from the default, include the force-entry or
ignore-entry statement at the [edit services ids rule rule-name term term-name then]
hierarchy level:
[edit services ids rule rule-name term term-name then]
(force-entry | ignore-entry);
•
logging—The event is logged in the system log file.
To configure logging, include the logging statement at the [edit services ids rule
rule-name term term-name then] hierarchy level:
[edit services ids rule rule-name term term-name then]
logging {
syslog;
threshold rate;
}
You can optionally include a threshold rate to trigger the generation of system log
messages. The threshold rate is specified in events per second. IDS logs are generated
once every 60 seconds for each anomaly that is reported. The logs are generated as
long as the events continue.
•
session-limit—The router limits open sessions when the specified threshold is reached.
To configure a threshold, include the session-limit statement at the [edit services ids
rule rule-name term term-name then] hierarchy level:
434
Copyright © 2018, Juniper Networks, Inc.
Chapter 30: IDS Configuration on MS-DPC Overview
[edit services ids rule rule-name term term-name then]
session-limit {
by-destination (IDS MS-DPC) {
hold-time seconds;
maximum number;
packets number;
rate number;
}
by-pair (IDS MS-DPC) {
hold-time seconds;
maximum number;
packets number;
rate number;
}
by-source (IDS MS-DPC) {
hold-time seconds;
maximum number;
packets number;
rate number;
}
}
You configure the thresholds for flow limitation based on traffic direction:
•
To limit the number of outgoing sessions from one internal host or subnet, configure
the by-source statement.
•
To limit the number of sessions between a pair of IP addresses, subnets, or
applications, configure the by-pair statement.
•
To limit the number of incoming sessions to one external public IP address or subnet,
configure the by-destination statement.
For each direction, you can configure the following threshold values:
•
hold-time seconds—When the rate or packets measurement reaches the threshold
value, stop all new flows for the specified number of seconds. Once hold-time is in
effect, the traffic is blocked for the specified time even if the rate subsides below
the specified limit. By default, hold-time has a value of 0; the range is 0 through
60 seconds.
•
maximum number—Maximum number of open sessions per IP address or subnet per
application. The range is 1 through 32,767.
•
packets number—Maximum number of packets per second (pps) per IP address or
subnet per application. The range is 4 through 2,147,483,647.
•
rate number—Maximum number of sessions per second per IP address or subnet per
application. The range is 4 through 32,767.
If you include more than one source address in the match conditions configured at
the [edit services ids rule rule-name term term-name from] hierarchy level, limits are
applied for each source address independently. For example, the following
configuration allows 20 connections from each source address (10.1.1.1 and 10.1.1.2),
not 20 connections total. The same logic applies to the applications and
destination-address match conditions.
Copyright © 2018, Juniper Networks, Inc.
435
Adaptive Services Interfaces Feature Guide for Routing Devices
[edit services ids rule rule-name term term-name]
from {
source-address 10.1.1.1;
source-address 10.1.1.2;
}
then {
session-limit by-source {
maximum 20;
}
}
NOTE: IDS limits are applied to packets that are accepted by stateful
firewall rules. They are not applied to packets discarded or rejected by
stateful firewall rules. For example, if the stateful firewall accepts 75
percent of the incoming traffic and the remaining 25 percent is rejected
or discarded, the IDS limit applies only to 75 percent of the traffic.
•
syn-cookie—The router activates SYN-cookie defensive mechanisms.
To configure SYN-cookie values, include the syn-cookie statement at the [edit services
ids rule rule-name term term-name then] hierarchy level:
[edit services ids rule rule-name term term-name then]
syn-cookie {
mss value;
threshold rate;
}
If you enable SYN-cookie defenses, you must include both a threshold rate to trigger
SYN-cookie activity and a Transmission Control Protocol (TCP) maximum segment
size (MSS) value for TCP delayed binding. The threshold rate is specified in SYN attacks
per second. By default, the TCP MSS value is 1500; the range is from 128 through 8192.
Handling of SYN Flood
Attacks and SYN
Cookie Protection
436
The main purpose of a SYN flood attack is to consume all new network connections at
a site and thereby prevent authorized and legitimate users from being able to connect
to network resources. The SYN (synchronize sequence number) packet is the first request
to connect sent to a system. The SYN packet contains an ID to which the receiver is
required to respond. If the packet contains an illegal ID, the receiving system does receive
a connection acknowledgment when it responds to the intended connection initiator.
Eventually, this half-open connection times out and the incoming channel on the receiver
becomes available again to normally handle another request. A SYN flood attack sends
so many such requests that all incoming connections are continuously tied up waiting
for acknowledgments that are never received. This condition causes the server to be
unavailable to legal users (except in cases where a user session is established when it
is exactly at the moment when one of the tied-up connections times out). A SYN flood
attack is a connectionless attack. It does not require a real source IP addresses and,
because it uses legitimate destination IP or port addresses, is practically impossible to
distinguish from legitimate packets. Therefore, it is very difficult to prevent this type of
attack by using only filters or stateful firewall rules. Basically, there are only three methods
to protect from this type of attack:
Copyright © 2018, Juniper Networks, Inc.
Chapter 30: IDS Configuration on MS-DPC Overview
•
Intercept (delayed binding)—The firewall intercepts incoming TCP synchronization
requests and establishes a connection with the client on the server’s behalf, and with
the server on the client’s behalf. If both connections are successful, the firewall
transparently merges the two connections. The firewall usually has aggressive timeouts
to prevent its own resources from being consumed by a SYN attack. This the most
intensive solution in terms of processing and memory requirements.
•
Watch (SYN defense)—The firewall passively watches half-open connections and
actively closes connections on the server after a configurable length of time.
•
SYN cookie—SYN cookies are particular choices for the initial TCP sequence number
chosen by the TCP server. A host requesting a connection must answer with the cookie
to connect to an open TCP socket while a SYN-flood has been detected as in progress
by the IDS.
Juniper Networks routers support the combination of stateful firewall and IDS mechanisms
to support the SYN cookie and watch (SYN defense) methods. The key to the SYN flood
attack is the filling of the SYN queue of the victim or the attacked network element. The
SYN cookie defense method enables the victim to continue accepting connection requests
when the SYN queue is full or, in the case of the firewall or IDS applications, when a
certain threshold has been reached. After the threshold is reached, a cryptographic cookie
(a 32-bit number) is created from information in the SYN segment and the SYN segment
is dropped. The cookie is used as the initial sequence number in the SYN-ACK sent to
the client. The cookie (plus one) is returned to the firewall or IDS application as the
acknowledgment number in the ACK from a legitimate client. The returned cookie can
be validated and the most important parts of the SYN segment can be reconstructed
from the cookie, thereby allowing a connection to be established. Because the spoofed
clients of the SYN flood never send ACKs, no resources are allocated for them in any
state when SYN cookies are in use. It is preferred that you use SYN flood countermeasures
only for hosts under attack. The anomaly table can be used for reliable attack recognition
or they can be enabled within the stateful firewall. Such a type of configuration also helps
prevent the depletion of system resources (especially the flow table) in case of attacks.
When combining multiple services, the general path is an important factor for
consideration in the forward and reverse directions. This is especially true when NAT is
deployed to determine whether the pre-NAT or post-NAT address must be used to match
a rule. In the forward path from a LAN interface to a WAN interface, IDS and stateful
firewall are performed first, then NAT, and finally IPSec. This sequence of processing of
services denotes that the stateful firewall must match on a pre-NAT address, whereas
the IPSec tunnel matches on the post-NAT address. In the return path, the IPSec packet
is processed first, then NAT, and finally the stateful firewall. This order of processing still
allows IPSec to match a public address and the stateful firewall to match on a private
address. You must separately configure the firewall, NAT, and IDS services. The processing
of packets becomes much more complicated when IPSec over GRE is implemented in
the router with other services turned on. This behavior occurs because Junos OS treats
GRE packets in a unique fashion after GRE encapsulation. After a packet is encapsulated
in a GRE packet, it is marked with an input interface as the next-hop outgoing interface.
This method of marking causes GRE packets to be blocked if any input filters or input
services are that do not allow for this service.
Copyright © 2018, Juniper Networks, Inc.
437
Adaptive Services Interfaces Feature Guide for Routing Devices
Junos OS services support a limited set of IDS rules to help detect attacks such as port
scanning and anomalies in traffic patterns. It also supports some attack prevention by
limiting the number of flows, sessions, and rates. In addition, it protects against SYN
attacks by implementing a SYN cookie mechanism. Because the intrusion detection and
prevention (IDP) service does not support higher-layer application signatures, an effective
approach against attacks is that protection against a SYN attack can be configured. The
IDP solution is largely a monitoring tool and not an essential prevention tool. To prevent
a SYN attack, the router will operate as a type of SYN “proxy” and utilizes cookie values.
When this feature is turned on, the router responds to the initial SYN packet with a
SYN-ACK packet that contains a unique cookie value in the sequence number field. If
the initiator responds with the same cookie in the sequence field, the TCP flow is accepted;
if the responder does not respond or if it responds with the wrong cookie, the flow is
dropped. To trigger this defense, you must configure a SYN cookie threshold. To enable
the SYN cookie defense, an IDS rule action must contain a threshold that indicates when
the feature should be enabled and an MSS value to avoid having the router manage
segmented fragments when acting as a SYN proxy:
[edit]
user@host# set services ids rule simple-ids term 1 then syn-cookie
Related
Documentation
•
Configuring IDS Rule Sets on an MS-DPC on page 438
•
Examples: Configuring IDS Rules on an MS-DPC on page 439
•
Configuring Protection Against Network Attacks on an MS-MPC or MS-MIC on page 448
Configuring IDS Rule Sets on an MS-DPC
You can use rule-set statement to define a collection of IDS rules that determine what
actions the router software performs on packets in the data stream. This is supported
on the MS-DPC multiservices card. (To configure network attack protection with an
MS-MPC, see “Configuring Protection Against Network Attacks on an MS-MPC or MS-MIC”
on page 448.)
You define each rule by specifying a rule name and configuring terms. Then, you specify
the order of the rules by including the rule-set statement at the [edit services ids] hierarchy
level with a rule statement for each rule:
[edit services ids]
rule-set rule-set-name {
rule rule-name;
}
The router software processes the rules in the order in which you specify them in the
configuration. If a term in a rule matches the packet, the router performs the corresponding
action and the rule processing stops. If no term in a rule matches the packet, processing
continues to the next rule in the rule set. If none of the rules matches the packet, the
packet is dropped by default.
438
Copyright © 2018, Juniper Networks, Inc.
Chapter 30: IDS Configuration on MS-DPC Overview
Related
Documentation
•
Configuring IDS Rules on an MS-DPC on page 430
•
Examples: Configuring IDS Rules on an MS-DPC on page 439
Examples: Configuring IDS Rules on an MS-DPC
The following configuration adds a permanent entry to the IDS anomaly table when it
encounters a flow with the destination address 10.410.6.2. This example is supported on
the MS-DPC multiservices card. (To configure network attack protection with an MS-MPC,
see “Configuring Protection Against Network Attacks on an MS-MPC or MS-MIC” on
page 448.)
[edit services ids]
rule simple_ids {
term 1 {
from {
destination-address 10.410.6.2/32;
}
then {
force-entry;
logging {
threshold 1;
syslog;
}
}
}
term default {
then {
aggregation {
source-prefix 24;
}
}
}
match-direction input;
}
The IDS configuration works in conjunction with the stateful firewall mechanism and
relies heavily on the anomalies reported by the stateful firewall. The following
configuration example shows this relationship:
[edit services ids]
rule simple_ids {
term 1 {
from {
source-address 10.30.20.2/32;
destination-address {
10.30.10.2/32;
10.30.1.2/32 except;
}
applications appl-ftp;
}
then {
force-entry;
logging {
Copyright © 2018, Juniper Networks, Inc.
439
Adaptive Services Interfaces Feature Guide for Routing Devices
threshold 5;
syslog;
}
syn-cookie {
threshold 10;
}
}
}
match-direction input;
}
[edit services stateful-firewall]
rule my-firewall-rule {
match-direction input-output;
term term1 {
from {
source-address 10.30.20.2/32;
applications appl-ftp ;
destination-address {
10.30.10.2/32;
10.30.1.2/32 except;
}
}
then {
accept;
syslog;
}
}
}
The stateful firewall or NAT service is used to generate the input data for the IDS
application. When you enable and configure an IDS service, you must also enable stateful
firewall with at least one rule (accept or discard all traffic). When the system is under
an attack, the stateful firewall sends the correct and complete list of attack events to
the IDS system. In your network environment, you can ensure that the system is wholly
protected against a whole range of attacks so that the IDS system reports all such attacks.
You must exercise caution when you configure the system to be protected from all attacks
and unauthenticated access scenarios so that the traffic bandwidth that the system
handles is not burdened. It is also important to verify the correlation between the firewall
syslog messages corresponding to the attacks and IDS tables. The IDS tables must have
the same or slightly less number of anomalies or errors compared to the firewall-based
syslog messages. You can use the appropriate show commands are used to display the
IDS tables.
A default stateful firewall rule can be as simple as only allowing connection initiation
from the inside interface to the outside interface and discarding all other packets. However,
in a real-word network environment, rules are generally more complex, such as configuring
only a certain tributary unit ports are to be opened, using application layer gateways
(ALGs) for complicated protocols, and using NAT for both outgoing connections and
inside hosts such as HTTP servers. Therefore, it is necessary to also configure the system
as needed to interwork with simple and complicated rules. For example, if a SYN attack
is directed towards an inside address that is simply discarded, no anomalies need to be
reported to the IDS system. But if the SYN attack is directed towards the real HTTP server,
anomalies must be reported. The IDS system can mitigate SYN attacks by using the TCP
440
Copyright © 2018, Juniper Networks, Inc.
Chapter 30: IDS Configuration on MS-DPC Overview
SYN cookie defense capability. You can enable the SYN cookie protection methodology
by setting a threshold for SYNs per second for a given host and also a maximum segment
size (MSS). Because the IDS system uses the stateful firewall, a firewall rule must be
defined in the service-set. If you do not configure the from statement in a stateful firewall
(rule term match condition) at the [edit services service-set service-set-name
stateful-firewall-rules rule-name term term-name] hierarchy level, it signifies that all events
are placed into the IDS cache.
The following example shows configuration of flow limits:
[edit services ids]
rule ids-all {
match-direction input;
term t1 {
from {
application-sets alg-set;
}
then {
aggregation {
destination-prefix 30; /* IDS action aggregation */
}
logging {
threshold 10;
}
session-limit {
by-destination {
hold-time 0;
maximum 10;
packets 200;
rate 100;
}
by-pair {
hold-time 0;
maximum 10;
packets 200;
rate 100;
}
by-source {
hold-time 5;
maximum 10;
packets 200;
rate 100;
}
}
}
}
}
Related
Documentation
•
Configuring IDS Rules on an MS-DPC on page 430
•
Configuring IDS Rule Sets on an MS-DPC on page 438
Copyright © 2018, Juniper Networks, Inc.
441
Adaptive Services Interfaces Feature Guide for Routing Devices
442
Copyright © 2018, Juniper Networks, Inc.
CHAPTER 31
Network Attack Protection Configuration
on MS-MPC
•
Understanding Network Attack Protection on an MS-MPC or MS-MIC on page 443
•
Configuring Protection Against Network Attacks on an MS-MPC or MS-MIC on page 448
•
Configuring Logging of Network Attack Protection Packet Drops on an MS-MPC or
MS-MIC on page 456
Understanding Network Attack Protection on an MS-MPC or MS-MIC
You can configure network attack protection on an MS-MPC or MS-MIC service set on
the MX Series router. The following types of network attack protection are available:
•
Network Probing Attacks on page 444
•
Network Flooding Attacks on page 444
•
Suspicious Packet Pattern Attacks on page 445
•
Header Anomaly Attacks on page 447
Copyright © 2018, Juniper Networks, Inc.
443
Adaptive Services Interfaces Feature Guide for Routing Devices
Network Probing Attacks
Network probing attacks for which you can configure protection include the following:
•
ICMP Address Sweep on page 444
•
TCP Port Scans on page 444
ICMP Address Sweep
In an ICMP address sweep, the attacker sends ICMP request probes (pings) to multiple
targets. If a target machine replies, the attacker receives the IP address of the target.
To protect against ICMP address sweeps, you can limit the number of ICMP sessions
originating from an individual source, the number of ICMP connections per second that
an individual source can create, and the number of ICMP packets per second sent from
an individual source. Packets that exceed the limit for an individual source are dropped.
TCP Port Scans
In a TCP port scan, the attacker sends TCP SYN packets from one source to multiple
destination ports of the target machine. If the target replies with a SYN-ACK from one
or more destination ports, the attacker learns which ports are open on the target.
To protect against TCP port scans, you can limit the number of concurrent TCP sessions
an individual source or destination can have. You can also limit the number of TCP
connection requests per second that an individual source can generate or an individual
destination can receive. Packets that exceed the limit for an individual source or
destination are dropped.
Network Flooding Attacks
Network flooding attacks for which you can configure protection include the following:
•
ICMP Flood on page 444
•
TCP SYN Flood on page 445
•
UDP Flood on page 445
ICMP Flood
In an ICMP flood, the attacker floods a target machine by sending a large number of ICMP
packets from one or more source IP addresses. The target machine uses up its resources
as it attempts to process those ICMP packets, and then it can no longer process valid
traffic.
To protect against ICMP floods, you can limit the number of concurrent ICMP sessions
for an individual destination, the number of ICMP connection requests per second that
an individual destination can receive, and the number of packets per second that an
individual destination can receive. Packets that exceed the limit for a destination are
dropped.
444
Copyright © 2018, Juniper Networks, Inc.
Chapter 31: Network Attack Protection Configuration on MS-MPC
TCP SYN Flood
In a TCP SYN flood, the attacker floods a target machine by sending a large number of
TCP SYN packets from one or more source IP addresses. The attacker might use real
source IP addresses, which results in a completed TCP connection, or might use fake
source IP addresses, resulting in the TCP connection not being completed. The target
creates states for all the completed and incompleted TCP connections. The target uses
up its resources as it attempts to manage the connection states, and then it can no longer
process valid traffic.
To protect against TCP SYN floods, you can limit the number of concurrent TCP sessions
allowed for an individual source or destination, the number of TCP connection requests
per second that an individual source can send or an individual destination can receive,
and the number of TCP packets per second that an individual source can send or an
individual destination can receive. Packets that exceed the limit for an individual source
or destination are dropped. You can also enable the closing of unestablished TCP sessions
after a timeout and the delivery of a TCP RST to the end host to clear the TCP states on
it.
UDP Flood
In a UDP flood, the attacker floods a target machine by sending a large number of UDP
packets from one or more source IP addresses. The target machine uses up its resources
as it attempts to process those UDP packets, and then it can no longer process valid
traffic.
To protect against UDP floods, you can limit the number of concurrent UDP sessions for
an individual destination, the number of UDP connection requests per second that an
individual destination can receive, and the number of UDP packets per second that an
individual destination can receive. Packets that exceed the limit for a destination are
dropped.
Suspicious Packet Pattern Attacks
Suspicious packet pattern attacks for which you can configure protection include the
following:
•
ICMP Fragmentation Attack on page 445
•
ICMP Large Packet Attack on page 446
•
IP Bad Option Attack on page 446
•
IP Teardrop Attack on page 446
•
Land Attack on page 446
•
TCP SYN Fragment Attack on page 446
•
TCP WinNuke Attack on page 446
ICMP Fragmentation Attack
In an ICMP fragmentation attack, the attacker sends the target ICMP packets that are IP
fragments. These are considered suspicious packets because ICMP packets are usually
short.
Copyright © 2018, Juniper Networks, Inc.
445
Adaptive Services Interfaces Feature Guide for Routing Devices
To protect against ICMP fragmentation attacks, you can enable the dropping of ICMP
packets that are IP fragments.
ICMP Large Packet Attack
In an ICMP large packet attack, the attacker sends the target large ICMP packets. These
are considered suspicious packets because most ICMP messages are not large.
To protect against ICMP large packet attacks, you can enable the dropping of ICMP
packets that are larger than 1024 bytes.
IP Bad Option Attack
In an IP bad option attack, the attacker sends the target packets with incorrectly formatted
IPv4 options or IPv6 extension headers. This can cause unpredictable issues, depending
on the IP stack implementation of routers and the target.
To protect against IP bad option attacks, you can identify the IPv4 options or the IPv6
extension headers that are allowed in packets and are checked.
IP Teardrop Attack
In an IP teardrop attack, the attacker sends the target fragmented IP packets that overlap.
The target machine uses up its resources as it attempts to reassemble the packets, and
then it can no longer process valid traffic. The MS-MPC and MS-MIC automatically protect
against these attacks.
Land Attack
In a land attack, the attacker sends the target spoofed SYN packets that contain the
target’s IP address as both the destination and the source IP address. The target uses
up its resources as it repeatedly replies to itself. In another variation of the land attack,
the SYN packets also contain the same source and destination ports.
To protect against land attacks, you can enable the dropping of SYN packets that have
the same source and destination IP address or the same source and destination IP address
and port.
TCP SYN Fragment Attack
In a TCP SYN fragment attack, the attacker sends the target TCP SYN packets that are
fragments. While the target waits for fragments to reassemble them, the target’s memory
buffer fills, preventing valid traffic connections.
To protect against TCP SYN fragment attacks, you can enable the dropping of TCP SYN
packets that are fragments.
TCP WinNuke Attack
In a TCP WinNuke attack, the attacker sends a TCP segment destined for port 139 of a
target running Windows, and the TCP segment has the urgent (URG) flag set. This might
cause the target machine to crash.
To protect against WinNuke attacks, you can enable the dropping of TCP segments that
are destined for port 139 and have the URG flag set.
446
Copyright © 2018, Juniper Networks, Inc.
Chapter 31: Network Attack Protection Configuration on MS-MPC
Header Anomaly Attacks
To protect against header anomaly attacks, a header integrity check is automatically
performed if you configure a stateful firewall rule, a NAT rule, or an IDS rule and apply it
to the service set. You can also explicitly configure a header integrity check for the service
set. The header integrity check provides protection against the following header anomaly
attacks:
•
ICMP Ping of Death Attack on page 447
•
IP Unknown Protocol Attack on page 447
•
TCP No Flag Attack on page 447
•
TCP SYN FIN Attack on page 447
•
TCP FIN No ACK Attack on page 447
ICMP Ping of Death Attack
In an ICMP ping of death attack, the attacker sends the target ICMP ping packets whose
IP datagram length(ip_len) exceeds the maximum legal length (65,535 bytes) for IP
packets, and the packet is fragmented. When the target attempts to reassemble the IP
packets, a buffer overflow might occur, resulting in a system crash.
IP Unknown Protocol Attack
In an IP unknown protocol attack, the attacker sends the target packets containing an
invalid Layer 4 value in the Protocol field of the IP header. An unknown protocol might
be malicious.
TCP No Flag Attack
In a TCP no flag attack, the attacker sends the target TCP packets containing no flags.
This can cause unpredictable behavior on the target, depending on its TCP stack
implementation.
TCP SYN FIN Attack
In a TCP SYN FIN attack, the attacker sends the target TCP packets that have both the
SYN and the FIN bits set. This can cause unpredictable behavior on the target, depending
on its TCP stack implementation.
TCP FIN No ACK Attack
In a TCP FIN no ACK attack, the attacker sends the target TCP packets that have the FIN
bit set but have the ACK bit unset. This can allow the attacker to identify the operating
system of the target or to identify open ports on the target.
Related
Documentation
•
Configuring Protection Against Network Attacks on an MS-MPC or MS-MIC on page 448
Copyright © 2018, Juniper Networks, Inc.
447
Adaptive Services Interfaces Feature Guide for Routing Devices
Configuring Protection Against Network Attacks on an MS-MPC or MS-MIC
This topic includes the following tasks, which describe how to protect against network
attacks when using an MS-MPC or MS-MIC:
•
Configuring Protection Against Network Probing, Network Flooding, and Suspicious
Pattern Attacks on page 448
•
Configuring Protection Against Header Anomaly Attacks on page 456
Configuring Protection Against Network Probing, Network Flooding, and Suspicious Pattern
Attacks
You configure protection against network probing attacks, network flooding attacks, and
suspicious pattern attacks by configuring an intrusion detection service (IDS) rule, and
then applying that rule to a service set that is on an MS-MPC or MS-MIC. Only the first
term of an IDS rule is used, and only the first IDS input rule and the first IDS output rule
for a service set are used.
Configuring protection against network probing, network flooding, and suspicious pattern
attacks includes:
•
Configuring IDS Rule Name and Direction on page 448
•
Configuring Session Limits for Subnets on page 449
•
Configuring Session Limits Independent of the Protocol on page 450
•
Configuring ICMP Address Sweep Protection on page 451
•
Configuring TCP Port Scanner Protection on page 451
•
Configuring ICMP Flooding Protection on page 452
•
Configuring UDP Flooding Protection on page 452
•
Configuring TCP SYN Flooding Protection on page 453
•
Configuring ICMP Fragmentation Protection on page 454
•
Configuring ICMP Large Packet Protection on page 454
•
Configuring IP Bad Options Protection on page 454
•
Configuring Land Attack Protection on page 455
•
Configuring TCP SYN Fragment Protection on page 455
•
Configuring WinNuke Protection on page 455
•
Configuring the Service Set on page 455
Configuring IDS Rule Name and Direction
For each IDS rule, you must configure a name and the direction of traffic to which it is
applied.
To configure the IDS rule name and direction:
1.
Specify a name for the IDS rule.
[edit services ids]
448
Copyright © 2018, Juniper Networks, Inc.
Chapter 31: Network Attack Protection Configuration on MS-MPC
user@host# set rule rule-name
2. Specify whether the IDS rule is applied to input traffic, output traffic, or both.
[edit services ids rule rule-name]
user@host# set match-direction (input | input-output |output)
Configuring Session Limits for Subnets
If you want to apply session limits to an aggregation of all attacks to or from individual
destination or source subnets rather than for individual addresses, configure aggregation.
To configure subnet aggregation:
•
If you want to apply session limits to an aggregation of all attacks from within an
individual IPv4 subnet, specify the subnet prefix length. The range is from 1 through
32.
[edit services ids rule rule-name term term-name then]
user@host# set aggregation source-prefix prefix-value
For example, the following statement configures an IPv4 prefix length of 24, and
attacks from 10.1.1.2 and 10.1.1.3 are counted as attacks from the 10.1.1/24 subnet.
[edit services ids rule rule1 term term1 then]
user@host# set aggregation source-prefix 24
However, if a single host on a subnet generates a large number of network probing or
flooding attacks, the flows for the entire subnet might be stopped.
•
If you want to apply session limits to an aggregation of all attacks from within an
individual IPv6 subnet, specify the subnet prefix length. The range is from 1 through
128.
[edit services ids rule rule-name term term-name then]
user@host# set aggregation source-prefix-ipv6 prefix-value
For example, the following statement configures an IPv6 prefix length of 64, and
attacks from 2001:db8:1234:72a2::2 and 2001:db8:1234:72a2::3 are counted as attacks
from the 2001:db8:1234:72a2::/64 subnet.
[edit services ids rule rule1 term term1 then]
user@host# set aggregation source-prefix-ipv6 64
However, if a single host on a subnet generates a large number of network probing or
flooding attacks, the flows for the entire subnet might be stopped.
•
If you want to apply session limits to an aggregation of all attacks to an individual
IPv4 subnet, specify the subnet prefix length. The range is from 1 through 32.
[edit services ids rule rule-name term term-name then]
user@host# set aggregation destination-prefix prefix-value
For example, the following statement configures an IPv4 prefix length of 24, and
attacks to 10.1.1.2 and 10.1.1.3 are counted as attacks to the 10.1.1/24 subnet.
Copyright © 2018, Juniper Networks, Inc.
449
Adaptive Services Interfaces Feature Guide for Routing Devices
[edit services ids rule rule1 term term1 then]
user@host# set aggregation destination-prefix 24
•
If you want to apply session limits to an aggregation of all attacks to an individual
IPv6 subnet, specify the subnet prefix length. The range is from 1 through 128.
[edit services ids rule rule-name term term-name then]
user@host# set aggregation destination-prefix-ipv6 prefix-value
For example, the following statement configures an IPv6 prefix length of 64, and
attacks to 2001:db8:1234:72a2::2 and 2001:db8:1234:72a2::3 are counted as attacks
to the 2001:db8:1234:72a2::/64 subnet.
[edit services ids rule rule1 term term1 then]
user@host# set aggregation destination-prefix-ipv6 64
Configuring Session Limits Independent of the Protocol
If you want to configure session limits for traffic to an individual destination or from an
individual source independent of the protocol, then perform one or more of the following
tasks:
•
To configure session limits for source IP addresses or subnets independent of a
protocol:
•
Configure the maximum number of concurrent sessions allowed from an individual
source IP address or subnet.
[edit services ids rule rule-name term term-name then]
user@host# set session-limit by-source maximum number
•
Configure the maximum number of packets per second allowed from an individual
source IP address or subnet.
[edit services ids rule rule-name term term-name then]
user@host# set session-limit by-source packets number
•
Configure the maximum number of connections per second allowed from an
individual source IP address or subnet.
[edit services ids rule rule-name term term-name then]
user@host# set session-limit by-source rate number
•
To configure session limits for destination IP addresses or subnets independent of a
protocol:
•
Configure the maximum number of concurrent sessions allowed for an individual
destination IP address or subnet.
[edit services ids rule rule-name term term-name then]
user@host# set session-limit by-destination maximum number
•
Configure the maximum number of packets per second allowed for an individual
destination IP address or subnet.
[edit services ids rule rule-name term term-name then]
user@host# set session-limit by-destination packets number
450
Copyright © 2018, Juniper Networks, Inc.
Chapter 31: Network Attack Protection Configuration on MS-MPC
•
Configure the maximum number of connections per second allowed for an individual
destination IP address or subnet.
[edit services ids rule rule-name term term-name then]
user@host# set session-limit by-destination rate number
Configuring ICMP Address Sweep Protection
To configure protection against ICMP address sweeps, configure any combination of the
maximum allowed ICMP concurrent sessions, packets per second, and connections per
second for a source:
•
Configure the maximum number of concurrent ICMP sessions allowed from an
individual source IP address or subnet.
[edit services ids rule rule-name term term-name then]
user@host# set session-limit by-source by-protocol icmp maximum number
•
Configure the maximum number of ICMP packets per second allowed from an
individual source IP address or subnet.
[edit services ids rule rule-name term term-name then]
user@host# set session-limit by-source by-protocol icmp packets number
•
Configure the maximum number of ICMP connections per second allowed from an
individual source IP address or subnet.
[edit services ids rule rule-name term term-name then]
user@host# set session-limit by-source by-protocol icmp rate number
Configuring TCP Port Scanner Protection
To configure protection against TCP port scanner attacks, configure any combination of
the maximum allowed TCP concurrent sessions and connections per second for a source
or destination:
•
Configure the maximum number of concurrent TCP sessions allowed from an individual
source IP address or subnet.
[edit services ids rule rule-name term term-name then]
user@host# set session-limit by-source by-protocol tcp maximum number
•
Configure the maximum number of TCP connections per second allowed for an
individual source IP address or subnet.
[edit services ids rule rule-name term term-name then]
user@host# set session-limit by-source by-protocol tcp rate number
•
Configure the maximum number of TCP sessions allowed for an individual destination
IP address or subnet.
[edit services ids rule rule-name term term-name then]
user@host# set session-limit by-destination by-protocol tcp maximum number
Copyright © 2018, Juniper Networks, Inc.
451
Adaptive Services Interfaces Feature Guide for Routing Devices
•
Configure the maximum number of TCP connections per second allowed for an
individual destination IP address or subnet.
[edit services ids rule rule-name term term-name then]
user@host# set session-limit by-destination by-protocol tcp rate number
Configuring ICMP Flooding Protection
To configure protection against ICMP flooding attacks, configure any combination of the
maximum allowed ICMP concurrent sessions, packets per second, and number of
connections per second for a destination:
•
Configure the maximum number of concurrent ICMP sessions allowed for an individual
destination IP address or subnet.
[edit services ids rule rule-name term term-name then]
user@host# set session-limit by-destination by-protocol icmp maximum number
•
Configure the maximum number of ICMP packets per second allowed for an individual
destination IP address or subnet.
[edit services ids rule rule-name term term-name then]
user@host# set session-limit by-destination by-protocol icmp packets number
•
Configure the maximum number of ICMP connections per second allowed for an
individual destination IP address or subnet for ICMP.
[edit services ids rule rule-name term term-name then]
user@host# set session-limit by-destination by-protocol icmp rate number
Configuring UDP Flooding Protection
To configure protection against UDP flooding attacks, configure any combination of the
maximum allowed UDP concurrent sessions, packets per second, and connections per
second for a destination:
•
Configure the maximum number of concurrent UDP sessions allowed for an individual
destination IP address or subnet.
[edit services ids rule rule-name term term-name then]
user@host# set session-limit by-destination by-protocol udp maximum number
•
Configure the maximum number of UDP packets per second allowed for an individual
destination IPaddress or subnet.
[edit services ids rule rule-name term term-name then]
user@host# set session-limit by-destination by-protocol udp packets number
•
Configure the maximum number of UDP connections per second allowed for an
individual destination IP address or subnet.
[edit services ids rule rule-name term term-name then]
user@host# set session-limit by-destination by-protocol udp rate number
452
Copyright © 2018, Juniper Networks, Inc.
Chapter 31: Network Attack Protection Configuration on MS-MPC
Configuring TCP SYN Flooding Protection
To configure protection against TCP SYN flooding attacks, configure any combination
of the maximum allowed TCP concurrent sessions, packets per second, and connections
per second for a source or destination. You can also configure the closing of unestablished
TCP connections after a timeout:
•
Configure the maximum number of concurrent TCP sessions allowed from an individual
source IP address or subnet.
[edit services ids rule rule-name term term-name then]
user@host# set session-limit by-source by-protocol tcp maximum number
•
Configure the maximum number of TCP packets per second allowed from an individual
source IP address or subnet.
[edit services ids rule rule-name term term-name then]
user@host# set session-limit by-source by-protocol tcp packets number
•
Configure the maximum number of TCP connections per second allowed from an
individual source IP address or subnet.
[edit services ids rule rule-name term term-name then]
user@host# set session-limit by-source by-protocol tcp rate number
•
Configure the maximum number of concurrent TCP sessions allowed for an individual
destination IP address or subnet.
[edit services ids rule rule-name term term-name then]
user@host# set session-limit by-destination by-protocol tcp maximum number
•
Configure the maximum number of TCP connections per second allowed for an
individual destination IP address or subnet.
[edit services ids rule rule-name term term-name then]
user@host# set session-limit by-destination by-protocol tcp rate number
•
Configure the maximum number of TCP packets per second allowed for an individual
destination IP address or subnet.
[edit services ids rule rule-name term term-name then]
user@host# set session-limit by-destination by-protocol tcp packets number
•
Configure the closing of unestablished TCP connections and the delivery of a TCP
RST to the end host to clear the TCP states on it when the open-timeout value at the
[edit interfaces interface-name service-options] hierarchy level expires.
[edit services ids rule rule-name term term-name then]
user@host# set tcp-syn-defense
Copyright © 2018, Juniper Networks, Inc.
453
Adaptive Services Interfaces Feature Guide for Routing Devices
Configuring ICMP Fragmentation Protection
To protect against ICMP fragmentation attacks:
•
Configure the identification and dropping of ICMP packets that are IP fragments.
[edit services ids rule rule-name term term-name then]
user@host# set icmp-fragment-check
Configuring ICMP Large Packet Protection
To protect against ICMP large packet attacks:
•
Configure the identification and dropping of ICMP packets that are larger than 1024
bytes.
[edit services ids rule rule-name term term-name then]
user@host# set icmp-large-packet-check
Configuring IP Bad Options Protection
To protect against bad IPv4 options or IPv6 extension header attacks:
1.
Configure the type of IPv4 options that the packet can include. If the packet includes
an option that is not configured, then the packet is blocked. If the packet includes a
configured option whose length is an illegal value, then the packet is dropped.
Specifying any allows all options.
[edit services ids rule rule-name term term-name then]
user@host# set allow-ip-options [ip-options]
The IPv4 options supported are any, loose-source-route, route-record, security,
stream-id, strict-source-route, and timestamp.
If you do not include the allow-ip-options statement in the IDS rule, packets with any
type of IPv4 option are blocked.
2. Configure the type of IPv6 extension headers that the packet can include. If the packet
includes an extension header that is not configured, then the packet is blocked. If the
packet includes configured extension headers that are incorrect, then the packet is
dropped. Specifying any allows all extension headers.
[edit services ids rule rule-name term term-name then]
user@host# set allow-ipv6-extension-header extension-header
The IPv6 extension headers supported are any, ah, dstopts, esp, fragment, hop-by-hop,
mobility, and routing.
If you do not include the allow-ipv6-extension-header statement in the IDS rule, packets
with any type of extension header are dropped.
454
Copyright © 2018, Juniper Networks, Inc.
Chapter 31: Network Attack Protection Configuration on MS-MPC
Configuring Land Attack Protection
To protect against land attacks:
•
Configure the identification and dropping of SYN packets that have the same source
and destination IP address or the same source and destination IP address and port.
[edit services ids rule rule-name term term-name then]
user@host# set land-attack-check (ip-only | ip-port)
To specify that the packets have the same source and destination IP address, use the
ip-only option; to specify that the packets have the same source and destination IP
address and port, use the ip-port option.
Configuring TCP SYN Fragment Protection
To protect against TCP SYN fragment attacks:
•
Configure the identification and dropping of TCP SYN packets that are IP fragments:
[edit services ids rule rule-name term term-name then]
user@host# set tcp-syn-fragment-check
Configuring WinNuke Protection
To protect against WinNuke attacks:
•
Configure the identification and dropping of TCP segments that are destined for port
139 and have the urgent (URG) flag set.
[edit services ids rule rule-name term term-name then]
user@host# set tcp-winnuke-check
Configuring the Service Set
To apply the IDS rule actions to a service set:
1.
Assign the IDS rule to a service set that is on an MS-MPC or MS-MIC.
[edit services]
user@host# set service-set service-set-name ids-rules rule-name
If the service set is associated with an AMS interface, then the session limits you
configure are applicable to each member interface.
2. Limit the packets that the IDS rule processes by configuring a stateful firewall rule
(see “Configuring Stateful Firewall Rules” on page 403). The stateful firewall rule can
identify either the traffic that should undergo IDS processing or the traffic that should
skip IDS processing:
•
To allow IDS processing on the traffic that matches the stateful firewall rule, include
accept at the [edit services stateful-firewall rule rule-name term term-name then]
hierarchy level.
Copyright © 2018, Juniper Networks, Inc.
455
Adaptive Services Interfaces Feature Guide for Routing Devices
•
To skip IDS processing on the traffic that matches the stateful firewall rule, include
accept skip-ids at the [edit services stateful-firewall rule rule-name term term-name
then] hierarchy level.
3. Assign the stateful firewall rule to the service set.
[edit services]
user@host# set service-set service-set-name stateful-firewall-rules rule-name
Configuring Protection Against Header Anomaly Attacks
Protect against header anomaly attacks by using either of the following methods to
enable a header integrity check, which drops any packets with header anomalies:
•
Configure a stateful firewall rule, a NAT rule, or an IDS rule and apply it to the service
set that is on an MS-MPC or MS-MIC. A header integrity check is automatically enabled.
•
Configure a header integrity check for the service set that is on an MS-MPC or MS-MIC.
[edit services]
user@host# set service-set service-set-name service-set-options
header-integrity-check enable-all
Related
Documentation
•
Understanding Network Attack Protection on an MS-MPC or MS-MIC on page 443
•
Configuring Logging of Network Attack Protection Packet Drops on an MS-MPC or
MS-MIC on page 456
Configuring Logging of Network Attack Protection Packet Drops on an MS-MPC or
MS-MIC
To configure the logging of packet drops resulting from header integrity, suspicious packet
pattern, and session limit checks performed by an MS-MPC or MS-MIC:
1.
Configure the logging of packet drops resulting from header integrity failures and
suspicious packet patterns.
[edit services set service-set service-set-name syslog host hostname class]
user@host# set packet-logs
2. Configure the logging of packet drops resulting from session limit violations.
[edit services set service-set service-set-name syslog host hostname class]
user@host# set ids-log
Related
Documentation
456
•
Configuring Protection Against Network Attacks on an MS-MPC or MS-MIC on page 448
Copyright © 2018, Juniper Networks, Inc.
CHAPTER 32
Monitoring Junos Network Secure
•
Monitoring Stateful Firewall Conversations on page 457
•
Monitoring CGN, Stateful Firewall, and Softwire Flows on page 457
•
Monitoring Global Stateful Firewall Statistics on page 458
Monitoring Stateful Firewall Conversations
Purpose
Action
Use the show services stateful-firewall conversations command to show conversations,
or collections of related flows.
user@host# show services stateful-firewall conversations
Interface: sp-0/0/0, Service set: sset
Conversation: ALG protocol: tcp
Number of initiators: 1, Number of responders: 1
Flow State Dir Frm
count
TCP 10.0.0.1:1025 -> 128.0.0.1:80 Forward I 372755
NAT source 10.0.0.1:1025 -> 129.0.0.1:1024
Softwire 2001:0:0:1::1 -> 1001::1
TCP 128.0.0.1:80 -> 129.0.0.1:1024 Forward O 794083
NAT dest 129.0.0.1:1024 -> 10.0.0.1:1025
Softwire 2001:0:0:1::1 -> 1001::1
Monitoring CGN, Stateful Firewall, and Softwire Flows
Purpose
Use the following commands to check the creation of the softwires, pre-NAT flows, and
post-NAT flows. Output can be filtered using more specific fields such as AFTR or B4
address or both for DS-Lite, and softwire-concentrator or softwire-initiator or both for
6rd.
•
show services stateful-firewall flows
•
show services softwire flows
Copyright © 2018, Juniper Networks, Inc.
457
Adaptive Services Interfaces Feature Guide for Routing Devices
Action
Related
Documentation
user@host# show services stateful-firewall flows
Interface: sp-0/1/0, Service set: dslite-svc-set2
Flow
State
Dir
TCP
200.200.200.2:80
->
44.44.44.1:1025 Forward O
NAT dest
44.44.44.1:1025
->
20.20.1.4:1025
Softwire
2001::2
->
1001::1
TCP
20.20.1.2:1025 -> 200.200.200.2:80
Forward I
NAT source
20.20.1.2:1025
->
44.44.44.1:1024
Softwire
2001::2
->
1001::1
TCP
200.200.200.2:80
->
44.44.44.1:1024 Forward O
NAT dest
44.44.44.1:1024
->
20.20.1.2:1025
Softwire
2001::2
->
1001::1
DS-LITE
2001::2
->
1001::1
Forward I
TCP
200.200.200.2:80
->
44.44.44.1:1026 Forward O
NAT dest
44.44.44.1:1026
->
20.20.1.3:1025
Softwire
2001::2
->
1001::1
TCP
20.20.1.3:1025 -> 200.200.200.2:80
Forward I
NAT source
20.20.1.3:1025
->
44.44.44.1:1026
Softwire
2001::2
->
1001::1
TCP
20.20.1.4:1025 -> 200.200.200.2:80
Forward I
NAT source
20.20.1.4:1025
->
44.44.44.1:1025
Softwire
2001::2
->
1001::1
•
Frm count
219942
110244
219140
988729
218906
110303
110944
Tunneling Services for IPv4-to-IPv6 Transition Overview on page 269
Monitoring Global Stateful Firewall Statistics
Purpose
Action
458
Use the show services stateful-firewall statistics command to observe statistics for
service sets containing softwire rules.
user@host# show services stateful-firewall statistics
Interface Service set Accept Discard Reject Errors
sp-0/0/0 dslite-svc-set2 118991296 0 0 0
sp-0/1/0 dslite-svc-set1 237615050 0 0 0
Copyright © 2018, Juniper Networks, Inc.
PART 6
Creating Secure Tunnels Using Junos VPN
Site Secure
•
Junos VPN Site Secure Overview on page 461
•
Junos VPN Site Secure Configuration Overview on page 475
•
Enhancing Security with Static IPSec over VRF on page 559
•
Dynamically Assigning Tunnels Using Junos VPN Site Secure on page 567
•
Enabling IPsec for the Services SDK on page 625
Copyright © 2018, Juniper Networks, Inc.
459
Adaptive Services Interfaces Feature Guide for Routing Devices
460
Copyright © 2018, Juniper Networks, Inc.
CHAPTER 33
Junos VPN Site Secure Overview
•
Understanding Junos VPN Site Secure on page 461
•
Authentication Algorithms on page 464
•
Encryption Algorithms on page 465
•
IPsec Protocols on page 466
•
IPsec Multipath Forwarding with UDP Encapsulation on page 468
•
Supported IPsec and IKE Standards on page 469
•
IPSec Terms and Acronyms on page 471
Understanding Junos VPN Site Secure
Junos VPN Site Secure is a suite of IPsec features supported on multiservices line cards
(MS-DPC, MS-MPC, and MS-MIC), and was referred to as IPsec services in Junos releases
earlier than 13.2. In Junos OS Release 13.2 and later, the term IPsec features is used
exclusively to refer to the IPsec implementation on Adaptive Services and Encryption
Services PICs. This topic provides you an overview of Junos VPN Site Secure, and has the
following sections:
•
IPsec on page 461
•
Security Associations on page 462
•
IKE on page 462
•
Non-Support for NAT-T on page 462
•
Comparison of IPsec on ES PICs and Junos VPN Site Secure on Multiservices LIne
Cards on page 463
IPsec
The IPsec architecture provides a security suite for the IP version 4 (IPv4) and IP version 6
(IPv6) network layers. The suite provides such functionality as authentication of origin,
data integrity, confidentiality, replay protection, and nonrepudiation of source. In addition
to IPsec, the Junos OS also supports the Internet Key Exchange (IKE), which defines
mechanisms for key generation and exchange, and manages security associations (SAs).
IPsec also defines a security association and key management framework that can be
used with any network-layer protocol. The SA specifies what protection policy to apply
to traffic between two IP-layer entities. IPsec provides secure tunnels between two peers.
Copyright © 2018, Juniper Networks, Inc.
461
Adaptive Services Interfaces Feature Guide for Routing Devices
Security Associations
To use IPsec security services, you create SAs between hosts. An SA is a simplex
connection that enables two hosts to communicate with each other securely by means
of IPsec. There are two types of SAs:
•
Manual SAs require no negotiation; all values, including the keys, are static and specified
in the configuration. Manual SAs statically define the security parameter index (SPI)
values, algorithms, and keys to be used, and require matching configurations on both
ends of the tunnel. Each peer must have the same configured options for
communication to take place.
•
Dynamic SAs require additional configuration. With dynamic SAs, you configure IKE
first and then the SA. IKE creates dynamic security associations; it negotiates SAs for
IPsec. The IKE configuration defines the algorithms and keys used to establish the
secure IKE connection with the peer security gateway. This connection is then used to
dynamically agree upon keys and other data used by the dynamic IPsec SA. The IKE
SA is negotiated first and then used to protect the negotiations that determine the
dynamic IPsec SAs.
IKE
IKE is a key management protocol that creates dynamic SAs; it negotiates SAs for IPsec.
An IKE configuration defines the algorithms and keys used to establish a secure connection
with a peer security gateway.
IKE performs the following tasks:
•
Negotiates and manages IKE and IPsec parameters.
•
Authenticates secure key exchange.
•
Provides mutual peer authentication by means of shared secrets (not passwords) and
public keys.
•
Provides identity protection (in main mode).
Two versions of the IKE protocol (IKEv1 and IKEv2) are supported now. IKE negotiates
security attributes and establishes shared secrets to form the bidirectional IKE SA. In IKE,
inbound and outbound IPsec SAs are established and the IKE SA secures the exchanges.
Starting with Junos OS Release 11.4, both IKEv1 and IKEv2 are supported by default on
all M Series, MX Series, and T Series routers. IKE also generates keying material, provides
Perfect Forward Secrecy, and exchanges identities.
Non-Support for NAT-T
Network Address Translation-Traversal (NAT-T) is not supported for the Junos VPN Site
Secure suite of IPsec features on the MX Series routers, and you must disable NAT-T on
the MX Series router to avoid running unsupported NAT-T (see “Disabling NAT-T on MX
Series Routers for Handling NAT with IPsec-Protected Packets” on page 534). NAT-T is
a method for getting around IP address translation issues encountered when data
protected by IPsec passes through a NAT device for address translation.
462
Copyright © 2018, Juniper Networks, Inc.
Chapter 33: Junos VPN Site Secure Overview
Comparison of IPsec on ES PICs and Junos VPN Site Secure on Multiservices LIne Cards
Table 22 on page 463 compares the top-level configuration of IPsec features on the ES
PIC interfaces, and IPsec on the Adaptive Services PICs and Junos VPN Site Secure on
Multiservices Line Cards .
Table 22: Statement Equivalents for ES and AS Interfaces
ES PIC Configuration
AS and MultiServices Line Cards Configuration
[edit security ipsec]
proposal {...}
[edit services ipsec-vpn ipsec]
proposal {...}
[edit security ipsec]
policy {...}
[edit services ipsec-vpn ipsec]
policy {...}
[edit security ipsec]
security-association sa-dynamic
{...}
[edit services ipsec-vpn rule rule-name]
term term-name match-conditions {...}
then dynamic {...}]
[edit security ipsec]
security-association sa-manual {...}
[edit services ipsec-vpn rule rule-name]
term term-name match-conditions {...}
then manual {...}]
[edit security ike]
proposal {...}
[edit services ipsec-vpn ike]
proposal {...}
[edit security ike]
policy {...}
[edit services ipsec-vpn ike]
policy {...}
Not available
[edit services ipsec-vpn]
rule-set {...}
Not available
[edit services ipsec-vpn]
service-set {...}
[edit interfaces es-fpc/pic/port]
tunnel source address
[edit services ipsec-vpn service-set set-name
ipsec-vpn local-gateway address]
[edit interfaces es-fpc/pic/port]
tunnel destination address
[edit services ipsec-vpn rule rule-name]
remote-gateway address
NOTE: Although many of the same statements and properties are valid on
both platforms (MultiServices and ES), the configurations are not
interchangeable. You must commit a complete configuration for the PIC type
that is installed in your router.
Related
Documentation
•
Authentication Algorithms on page 464
•
Encryption Algorithms on page 465
•
IPsec Protocols on page 466
•
Service Sets on page 526
Copyright © 2018, Juniper Networks, Inc.
463
Adaptive Services Interfaces Feature Guide for Routing Devices
•
Configuring Security Associations on page 477
Authentication Algorithms
Authentication is the process of verifying the identity of the sender. Authentication
algorithms use a shared key to verify the authenticity of the IPsec devices. The Junos OS
uses the following authentication algorithms:
•
Message Digest 5 (MD5) uses a one-way hash function to convert a message of arbitrary
length to a fixed-length message digest of 128 bits. Because of the conversion process,
it is mathematically infeasible to calculate the original message by computing it
backwards from the resulting message digest. Likewise, a change to a single character
in the message will cause it to generate a very different message digest number.
To verify that the message has not been tampered with, the Junos OS compares the
calculated message digest against a message digest that is decrypted with a shared
key. The Junos OS uses the MD5 hashed message authentication code (HMAC) variant
that provides an additional level of hashing. MD5 can be used with authentication
header (AH), Encapsulating Security Payload (ESP), and Internet Key Exchange (IKE).
Related
Documentation
464
•
Secure Hash Algorithm 1 (SHA-1) uses a stronger algorithm than MD5. SHA-1 takes a
message of less than 264 bits in length and produces a 160-bit message digest. The
large message digest ensures that the data has not been changed and that it originates
from the correct source. The Junos OS uses the SHA-1 HMAC variant that provides an
additional level of hashing. SHA-1 can be used with AH, ESP, and IKE.
•
SHA-256, SHA-384, and SHA-512 (sometimes grouped under the name SHA-2) are
variants of SHA-1 and use longer message digests. The Junos OS supports the SHA-256
version of SHA-2, which can process all versions of Advanced Encryption Standard
(AES), Data Encryption Standard (DES), and Triple DES (3DES) encryption.
•
Understanding Junos VPN Site Secure on page 461
•
Encryption Algorithms on page 465
Copyright © 2018, Juniper Networks, Inc.
Chapter 33: Junos VPN Site Secure Overview
Encryption Algorithms
Encryption encodes data into a secure format so that it cannot be deciphered by
unauthorized users. Like authentication algorithms, a shared key is used with encryption
algorithms to verify the authenticity of the IPsec devices. The Junos OS uses the following
encryption algorithms:
•
Data Encryption Standard cipher-block chaining (DES-CBC) is a symmetric secret-key
block algorithm. DES uses a key size of 64 bits, where 8 bits are used for error detection
and the remaining 56 bits provide encryption. DES performs a series of simple logical
operations on the shared key, including permutations and substitutions. CBC takes the
first block of 64 bits of output from DES, combines this block with the second block,
feeds this back into the DES algorithm, and repeats this process for all subsequent
blocks.
•
Triple DES-CBC (3DES-CBC) is an encryption algorithm that is similar to DES-CBC,
but provides a much stronger encryption result because it uses three keys for 168-bit
(3 x 56-bit) encryption. 3DES works by using the first key to encrypt the blocks, the
second key to decrypt the blocks, and the third key to re-encrypt the blocks.
•
Advanced Encryption Standard (AES) is a next-generation encryption method based
on the Rijndael algorithm developed by Belgian cryptographers Dr. Joan Daemen and
Dr. Vincent Rijmen. It uses a 128-bit block and three different key sizes (128, 192, and
256 bits). Depending on the key size, the algorithm performs a series of computations
(10, 12, or 14 rounds) that include byte substitution, column mixing, row shifting, and
key addition. The use of AES in conjunction with IPsec is defined in RFC 3602, The
AES-CBC Cipher Algorithm and Its Use with IPsec.
•
Starting In Junos OS Release 17.3R1, Advanced Encryption Standard in Galois/Counter
Mode (AES-GCM) is supported for MS-MPCs and MS-MICs. However, in Junos FIPS
mode, AES-GCM is not supported in Junos OS Release 17.3R1. Starting in Junos OS
Release 17.4R1, AES-GCM is supported in Junos FIPS mode. AES-GCM is an
authenticated encryption algorithm designed to provide both authentication and
privacy. AES-GCM uses universal hashing over a binary Galois field to provide
authenticated encryption and allows authenticated encryption at data rates of tens
of Gbps.
Release History Table
Related
Documentation
Release
Description
17.4R1
Starting in Junos OS Release 17.4R1, AES-GCM is supported in Junos FIPS
mode.
17.3R1
Starting In Junos OS Release 17.3R1, Advanced Encryption Standard in
Galois/Counter Mode (AES-GCM) is supported for MS-MPCs and MS-MICs.
•
Understanding Junos VPN Site Secure on page 461
•
Configuring IKE Proposals on page 498
Copyright © 2018, Juniper Networks, Inc.
465
Adaptive Services Interfaces Feature Guide for Routing Devices
•
Configuring IPsec Proposals on page 509
IPsec Protocols
IPsec protocols determine the type of authentication and encryption applied to packets
that are secured by the router. The Junos OS supports the following IPsec protocols:
•
AH—Defined in RFC 2402, AH provides connectionless integrity and data origin
authentication for IPv4 and IPv6 packets. It also provides protection against replays.
AH authenticates as much of the IP header as possible, as well as the upper-level
protocol data. However, some IP header fields might change in transit. Because the
value of these fields might not be predictable by the sender, they cannot be protected
by AH. In an IP header, AH can be identified with a value of 51 in the Protocol field of
an IPv4 packet and the Next Header field of an IPv6 packet. An example of the IPsec
protection offered by AH is shown in Figure 23 on page 466.
NOTE: AH is not supported on the T Series, M120, and M320 routers.
Figure 23: AH Protocol
466
Copyright © 2018, Juniper Networks, Inc.
Chapter 33: Junos VPN Site Secure Overview
•
ESP—Defined in RFC 2406, ESP can provide encryption and limited traffic flow
confidentiality, or connectionless integrity, data origin authentication, and an anti-replay
service. In an IP header, ESP can be identified a value of 50 in the Protocol field of an
IPv4 packet and the Next Header field of an IPv6 packet. An example of the IPsec
protection offered by ESP is shown in Figure 24 on page 467.
Figure 24: ESP Protocol
Related
Documentation
•
Bundle—When you compare AH with ESP, there are some benefits and shortcomings
in both protocols. ESP provides a decent level of authentication and encryption, but
does so only for part of the IP packet. Conversely, although AH does not provide
encryption, it does provide authentication for the entire IP packet. Because of this, the
Junos OS offers a third form of IPsec protocol called a protocol bundle. The bundle
option offers a hybrid combination of AH authentication with ESP encryption.
•
Understanding Junos VPN Site Secure on page 461
•
Configuring IPsec Proposals on page 509
•
Configuring Security Associations on page 477
•
protocol (IPsec) on page 1060
Copyright © 2018, Juniper Networks, Inc.
467
Adaptive Services Interfaces Feature Guide for Routing Devices
IPsec Multipath Forwarding with UDP Encapsulation
IPsec provides secure tunnels between two peers, and IPsec encapsulated packets have
IP headers that contain tunnel endpoint IPs that do not change. This results in the selection
of a single forwarding path between the peers, as shown in Figure 25 on page 468. When
IPsec traffic is flowing between data centers with thousands of hosts, this single path
selection limits the throughput.
Figure 25: IPsec with One Forwarding Path
You can overcome this problem by enabling UDP encapsulation of the IPsec packets,
which appends a UDP header after the ESP header, as shown in Figure 26 on page 468.
This provides Layer 3 and 4 information to the intermediate routers, and the IPsec packets
are forwarded over multiple paths, as shown in Figure 27 on page 469. You enable UDP
encapsulation for the service set.
Figure 26: Appended UDP Header
Packet after IPsec encapsulation
New IP
header
ESP header
Original
IP header
TCP header
Data
ESP header
Original
IP header
TCP header
ESP trailer
ESP
Authorization
New IP
header
468
UDP
header
Data
ESP trailer
ESP
Authorization
g043405
Packet after UDP header appended
Copyright © 2018, Juniper Networks, Inc.
Chapter 33: Junos VPN Site Secure Overview
Figure 27: IPsec with Multiple Forwarding Paths
You can configure the UDP destination port or use the default value of 4565. You cannot
configure 4500 as the destination port because it is a well-known port for NAT traversals.
Junos OS generates the source UDP port through a hash function that operates on the
following data:
•
Source IP address
•
Destination IP address
•
Transport protocol
•
Transport source port
•
Transport destination port
•
A random number
Only the last two bytes of the resulting hash are used, so the internal IP header details
are hidden.
When NAT-T is detected, only NAT-T UDP encapsulation occurs, not the UDP
encapsulation for IPsec packets.
Related
Documentation
•
Configuring IPsec Service Sets on page 526
Supported IPsec and IKE Standards
On routers equipped with one or more MS-MPCs, MS-MICs, or DPCs, the Canada and
U.S. version of Junos OS substantially supports the following RFCs, which define standards
for IP Security (IPsec) and Internet Key Exchange (IKE).
•
RFC 2085, HMAC-MD5 IP Authentication with Replay Prevention
•
RFC 2401, Security Architecture for the Internet Protocol (obsoleted by RFC 4301)
Copyright © 2018, Juniper Networks, Inc.
469
Adaptive Services Interfaces Feature Guide for Routing Devices
•
RFC 2402, IP Authentication Header (obsoleted by RFC 4302)
•
RFC 2403, The Use of HMAC-MD5-96 within ESP and AH
•
RFC 2404, The Use of HMAC-SHA-1-96 within ESP and AH (obsoleted by RFC 4305)
•
RFC 2405, The ESP DES-CBC Cipher Algorithm With Explicit IV
•
RFC 2406, IP Encapsulating Security Payload (ESP) (obsoleted by RFC 4303 and RFC
4305)
•
RFC 2407, The Internet IP Security Domain of Interpretation for ISAKMP (obsoleted by
RFC 4306)
•
RFC 2408, Internet Security Association and Key Management Protocol (ISAKMP)
(obsoleted by RFC 4306)
•
RFC 2409, The Internet Key Exchange (IKE) (obsoleted by RFC 4306)
•
RFC 2410, The NULL Encryption Algorithm and Its Use With IPsec
•
RFC 2451, The ESP CBC-Mode Cipher Algorithms
•
RFC 2460, Internet Protocol, Version 6 (IPv6)
•
RFC 3193, Securing L2TP using IPsec
•
RFC 3602, The AES-CBC Cipher Algorithm and Its Use with IPsec
•
RFC 3948, UDP Encapsulation of IPsec ESP Packets
•
RFC 4106, The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security
Payload (ESP)
•
RFC 4301, Security Architecture for the Internet Protocol
•
RFC 4302, IP Authentication Header
•
RFC 4303, IP Encapsulating Security Payload (ESP)
•
RFC 4305, Cryptographic Algorithm Implementation Requirements for Encapsulating
Security Payload (ESP) and Authentication Header (AH)
•
RFC 4306, Internet Key Exchange (IKEv2) Protocol
•
RFC 4307, Cryptographic Algorithms for Use in the Internet Key Exchange Version 2
(IKEv2)
•
RFC 4308, Cryptographic Suites for IPsec
NOTE: Only Suite VPN-A is supported in Junos OS.
470
•
RFC 4754, IKE and IKEv2 Authentication Using the Elliptic Curve Digital Signature
Algorithm (ECDSA)
•
RFC 4835, Cryptographic Algorithm Implementation Requirements for Encapsulating
Security Payload (ESP) and Authentication Header (AH)
•
RFC 5996, Internet Key Exchange Protocol Version 2 (IKEv2)
Copyright © 2018, Juniper Networks, Inc.
Chapter 33: Junos VPN Site Secure Overview
Junos OS partially supports the following RFCs for IPsec and IKE:
•
RFC 3526, More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key
Exchange (IKE)
•
RFC 5114, Additional Diffie-Hellman Groups for Use with IETF Standards
•
RFC 5903, Elliptic Curve Groups modulo a Prime (ECP Groups) for IKE and IKEv2
The following RFCs and Internet draft do not define standards, but provide information
about IPsec, IKE, and related technologies. The IETF classifies them as “Informational.”
Related
Documentation
•
RFC 2104, HMAC: Keyed-Hashing for Message Authentication
•
RFC 2412, The OAKLEY Key Determination Protocol
•
RFC 3706, A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers
•
Internet draft draft-eastlake-sha2-02.txt, US Secure Hash Algorithms (SHA and
HMAC-SHA) (expires July 2006)
•
Services Interfaces Overview for Routing Devices
•
MX Series Interface Module Reference
•
Accessing Standards Documents on the Internet
IPSec Terms and Acronyms
A
Adaptive Services PIC
A next-generation Physical Interface Card (PIC) that provides IPsec services and other services,
such as Network Address Translation (NAT) and stateful firewall, on M Series and T Series
platforms.
Advanced Encryption
Standard (AES)
A next-generation encryption method that is based on the Rijndael algorithm and uses a 128-bit
block, three different key sizes (128, 192, and 256 bits), and multiple rounds of processing to
encrypt data.
authentication header
(AH)
A component of the IPsec protocol used to verify that the contents of a packet have not
changed (data integrity), and to validate the identity of the sender (data source authentication).
For more information about AH, see RFC 2402.
C
certificate authority
(CA)
A trusted third-party organization that generates, enrolls, validates, and revokes digital
certificates. The CA guarantees the identity of a user and issues public and private keys for
message encryption and decryption.
certificate revocation
A list of digital certificates that have been invalidated before their expiration date, including
list (CRL)
the reasons for their revocation and the names of the entities that have issued them. A CRL
prevents usage of digital certificates and signatures that have been compromised.
Copyright © 2018, Juniper Networks, Inc.
471
Adaptive Services Interfaces Feature Guide for Routing Devices
cipher block chaining
(CBC)
A cryptographic method that encrypts blocks of ciphertext by using the encryption result of
one block to encrypt the next block. Upon decryption, the validity of each block of ciphertext
depends on the validity of all the preceding ciphertext blocks. For more information on how
to use CBC with DES and ESP to provide confidentiality, see RFC 2405.
D
Data Encryption
An encryption algorithm that encrypts and decrypts packet data by processing the data with
Standard (DES)
a single shared key. DES operates in increments of 64-bit blocks and provides 56-bit encryption.
digital certificate
Electronic file that uses private and public key technology to verify the identity of a certificate
creator and distribute keys to peers.
E
Encapsulating Security
Payload (ESP)
A component of the IPsec protocol used to encrypt data in an IPv4 or IPv6 packet, provide
data integrity, and ensure data source authentication. For more information about ESP, see
RFC 2406.
ES PIC
A PIC that provides first-generation encryption services and software support for IPsec on M
Series and T Series platforms.
H
Hashed Message
Authentication Code
(HMAC)
A mechanism for message authentication using cryptographic hash functions. HMAC can be
used with any iterative cryptographic hash function, such as MD5 or SHA-1, in combination
with a secret shared key. For more information on HMAC, see RFC 2104.
I
Internet Key Exchange
(IKE)
Establishes shared security parameters for any hosts or routers using IPsec. IKE establishes
the SAs for IPsec. For more information about IKE, see RFC 2407.
M
Message Digest 5
(MD5)
An authentication algorithm that takes a data message of arbitrary length and produces a
128-bit message digest. For more information, see RFC 1321.
P
Perfect Forward
Secrecy (PFS)
Provides additional security by means of a Diffie-Hellman shared secret value. With PFS, if
one key is compromised, previous and subsequent keys are secure because they are not derived
from previous keys.
public key
infrastructure (PKI)
A trust hierarchy that enables users of a public network to securely and privately exchange
data through the use of public and private cryptographic key pairs that are obtained and shared
with peers through a trusted authority.
R
registration authority
(RA)
472
A trusted third-party organization that acts on behalf of a CA to guarantee the identity of a
user.
Copyright © 2018, Juniper Networks, Inc.
Chapter 33: Junos VPN Site Secure Overview
Routing Engine
A PCI-based architectural portion of a Junos OS-based router that handles the routing protocol
process, the interface process, some of the chassis components, system management, and
user access.
S
Secure Hash Algorithm
1 (SHA-1)
An authentication algorithm that takes a data message of less than 264 bits in length and
produces a 160-bit message digest. For more information on SHA-1, see RFC 3174.
Secure Hash Algorithm
A successor to the SHA-1 authentication algorithm that includes a group of SHA-1 variants
2 (SHA-2)
(SHA-224, SHA-256, SHA-384, and SHA-512). SHA-2 algorithms use larger hash sizes and
are designed to work with enhanced encryption algorithms such as AES.
security association
(SA)
Security Association
Specifications that must be agreed upon between two network devices before IKE or IPsec
are allowed to function. SAs primarily specify protocol, authentication, and encryption options.
A database where all SAs are stored, monitored, and processed by IPsec.
Database (SADB)
Security Parameter
An identifier that is used to uniquely identify an SA at a network host or router.
Index (SPI)
Security Policy
Database (SPD)
A database that works with the SADB to ensure maximum packet security. For inbound packets,
IPsec checks the SPD to verify if the incoming packet matches the security configured for a
particular policy. For outbound packets, IPsec checks the SPD to see if the packet needs to be
secured.
Simple Certificate
Enrollment Protocol
(SCEP)
A protocol that supports CA and registration authority (RA) public key distribution, certificate
enrollment, certificate revocation, certificate queries, and certificate revocation list (CRL)
queries.
T
Triple Data Encryption
Standard (3DES)
An enhanced DES algorithm that provides 168-bit encryption by processing data three times
with three different keys.
Copyright © 2018, Juniper Networks, Inc.
473
Adaptive Services Interfaces Feature Guide for Routing Devices
474
Copyright © 2018, Juniper Networks, Inc.
CHAPTER 34
Junos VPN Site Secure Configuration
Overview
•
Minimum Security Association Configurations on page 475
•
Configuring Security Associations on page 477
•
Example: Configuring Manual SAs on page 483
•
Configuring IKE Proposals on page 498
•
Configuring IKE Policies on page 503
•
Configuring IPsec Proposals on page 509
•
Configuring IPsec Policies on page 514
•
Configuring IPsec Rules on page 518
•
Configuring IPsec Rule Sets on page 525
•
Service Sets on page 526
•
Configuring IPsec Service Sets on page 526
•
Disabling NAT-T on MX Series Routers for Handling NAT with IPsec-Protected
Packets on page 534
•
Tracing Junos VPN Site Secure Operations on page 535
•
Multitask Example: Configuring IPsec Services on page 538
•
Example: Configuring Junos VPN Site Secure on MS-MIC and MS-MPC on page 546
Minimum Security Association Configurations
The following sections show the minimum configurations necessary to set up security
associations (SAs) for IPsec services:
•
Minimum Manual SA Configuration on page 475
•
Minimum Dynamic SA Configuration on page 476
Minimum Manual SA Configuration
To define a manual SA configuration, you must include at least the following statements
at the [edit services ipsec-vpn rule rule-name term term-name then manual] hierarchy
level:
Copyright © 2018, Juniper Networks, Inc.
475
Adaptive Services Interfaces Feature Guide for Routing Devices
[edit services ipsec-vpn rule rule-name term term-name then manual]
direction (inbound | outbound | bidirectional) {
authentication {
algorithm (hmac-md5-96 | hmac-sha1-96);
key (ascii-text key | hexadecimal key);
}
encryption {
algorithm algorithm;
key (ascii-text key | hexadecimal key);
}
protocol (ah | esp | bundle);
spi spi-value;
}
Minimum Dynamic SA Configuration
To define a dynamic SA configuration, you must include at least the following statements
at the [edit services ipsec-vpn] hierarchy level:
[edit services ipsec-vpn]
ike {
proposal proposal-name {
authentication-algorithm (md5 | sha1 | sha-256);
authentication-method pre-shared-keys;
dh-group (group1 | group2 | group5 |group14 | group15 | group16 | group19 | group20 |
group24);
encryption-algorithm algorithm;
}
policy policy-name {
proposals [ ike-proposal-names ];
pre-shared-key (ascii-text key | hexadecimal key);
version (1 | 2);
mode (aggressive | main);
}
}
ipsec {
policy policy-name {
proposals [ ipsec-proposal-names ];
}
proposal proposal-name {
authentication-algorithm (hmac-md5-96 | hmac-sha1-96);
encryption-algorithm algorithm;
protocol (ah | esp | bundle);
}
}
NOTE:
476
•
Starting with Junos OS Release 11.4, both IKEv1 and IKEv2 are supported
by default on all M Series, MX Series, and T Series routers. The version
statement at the [edit services ipsec-vpn ike policy name] hierarchy level
allows you to configure the specific IKE version to be supported.
•
The mode statement at the [edit services ipsec-vpn ike policy name] hierarchy
level is required only if the version option is set to 1.
Copyright © 2018, Juniper Networks, Inc.
Chapter 34: Junos VPN Site Secure Configuration Overview
You must also include the ipsec-policy statement at the [edit services ipsec-vpn rule
rule-name term term-name then dynamic] hierarchy level.
Related
Documentation
•
Understanding Junos VPN Site Secure on page 461
•
Configuring Security Associations on page 477
•
Configuring IKE Proposals on page 498
•
Configuring IKE Policies on page 503
•
Configuring IPsec Proposals on page 509
•
Configuring IPsec Policies on page 514
Configuring Security Associations
To use IPsec services, you create a security association (SA) between hosts. An SA is a
simplex connection that enables two hosts to communicate with each other securely
using IPsec.
NOTE: Both OSPFv2 and OSPFv3 support IPsec authentication. However,
dynamic or tunnel mode IPsec SAs are not supported for OSPFv3. If you add
SAs into OSPFv3 by including the ipsec-sa statement at the [edit protocols
ospf3 area area-number interface interface-name] hierarchy level, your
configuration commit fails. For more information about OSPF authentication
and other OSPF properties, see the Junos OS Routing Protocols Library.
You can configure two types of SAs:
•
Manual—Requires no negotiation; all values, including the keys, are static and specified
in the configuration. As a result, each peer must have the same configured options for
communication to take place.
•
Dynamic—Specifies proposals to be negotiated with the tunnel peer. The keys are
generated as part of the negotiation and therefore do not need to be specified in the
configuration. The dynamic SA includes one or more proposal statements that prioritizes
a list of protocols and algorithms to be negotiated with the peer.
This section includes the following topics:
•
Configuring Manual Security Associations on page 477
•
Configuring Dynamic Security Associations on page 482
•
Clearing Security Associations on page 482
Configuring Manual Security Associations
Manual SAs require no negotiation; all values, including the keys, are static and specified
in the configuration. As a result, each peer must have the same configured options for
Copyright © 2018, Juniper Networks, Inc.
477
Adaptive Services Interfaces Feature Guide for Routing Devices
communication to take place. Manual SAs are best suited for small, static networks
where the distribution, maintenance, and tracking of keys are not difficult.
To configure a manual IPsec security association, include the following statements at
the [edit services ipsec-vpn rule rule-name term term-name then manual] hierarchy level:
[edit services ipsec-vpn rule rule-name term term-name then manual]
direction (inbound | outbound | bidirectional) {
authentication {
algorithm (hmac-md5-96 | hmac-sha-256-128 | hmac-sha1-96);
key (ascii-text key | hexadecimal key);
}
auxiliary-spi auxiliary-spi-value;
encryption {
algorithm (3des-cbc | aes-128-cbc | aes-192-cbc | aes-256-cbc | des-cbc);;
key (ascii-text key | hexadecimal key);
}
protocol (ah | esp | bundle);
spi spi-value;
}
To configure manual SA statements, do the following:
•
Configuring the Direction for IPsec Processing on page 478
•
Configuring the Protocol for a Manual IPsec SA on page 479
•
Configuring the Security Parameter Index on page 479
•
Configuring the Auxiliary Security Parameter Index on page 480
•
Configuring Authentication for a Manual IPsec SA on page 480
•
Configuring Encryption for a Manual IPsec SA on page 481
Configuring the Direction for IPsec Processing
The direction statement specifies inbound or outbound IPsec processing. If you want to
define different algorithms, keys, or security parameter index (SPI) values for each
direction, you configure the inbound and outbound options. If you want the same attributes
in both directions, use the bidirectional option.
To configure the direction of IPsec processing, include the direction statement at the
[edit services ipsec-vpn rule rule-name term term-name then manual] hierarchy level:
[edit services ipsec-vpn rule rule-name term term-name then manual]
direction (inbound | outbound | bidirectional) {
...
}
The following two examples illustrate this:
•
Example: Using Different Configuration for the Inbound and Outbound Directions
Define different algorithms, keys, and security parameter index values for each direction:
[edit services ipsec-vpn rule rule-name term term-name then manual]
direction bidirectional {
protocol ah;
478
Copyright © 2018, Juniper Networks, Inc.
Chapter 34: Junos VPN Site Secure Configuration Overview
spi 20001;
authentication {
algorithm hmac-md5-96;
key ascii-text 123456789012abcd;
}
}
direction outbound {
protocol esp;
spi 24576;
encryption {
algorithm 3des-cbc;
key ascii-text 12345678901234567890abcd;
}
}
•
Example: Using the Same Configuration for the Inbound and Outbound Directions
Define one set of algorithms, keys, and security parameter index values that is valid in
both directions:
[edit services ipsec-vpn rule rule-name term term-name then manual]
direction bidirectional {
protocol ah;
spi 20001;
authentication {
algorithm hmac-md5-96;
key ascii-text 123456789012abcd;
}
}
Configuring the Protocol for a Manual IPsec SA
IPsec uses two protocols to protect IP traffic: Encapsulating Security Payload (ESP) and
authentication header (AH). The AH protocol is used for strong authentication. A third
option, bundle, uses AH authentication and ESP encryption; it does not use ESP
authentication because AH provides stronger authentication of IP packets.
To configure the IPsec protocol, include the protocol statement and specify the ah, esp,
or bundle option at the [edit services ipsec-vpn rule rule-name term term-name then manual
direction direction] hierarchy level:
[edit services ipsec-vpn rule rule-name term term-name then manual direction direction]
protocol (ah | bundle | esp);
Configuring the Security Parameter Index
An SPI is an arbitrary value that uniquely identifies which SA to use at the receiving host.
The sending host uses the SPI to identify and select which SA to use to secure every
packet. The receiving host uses the SPI to identify and select the encryption algorithm
and key used to decrypt packets.
Copyright © 2018, Juniper Networks, Inc.
479
Adaptive Services Interfaces Feature Guide for Routing Devices
NOTE: Each manual SA must have a unique SPI and protocol combination.
Use the auxiliary SPI when you configure the protocol statement to use the
bundle option.
To configure the SPI, include the spi statement and specify a value (from 256 through
16,639) at the [edit services ipsec-vpn rule rule-name term term-name then manual direction
direction] hierarchy level:
[edit services ipsec-vpn rule rule-name term term-name then manual direction direction]
spi spi-value;
Configuring the Auxiliary Security Parameter Index
Use the auxiliary SPI when you configure the protocol statement to use the bundle option.
NOTE: Each manual SA must have a unique SPI and protocol combination.
To configure the auxiliary SPI, include the auxiliary-spi statement and specify a value
(from 256 through 16,639) at the [edit services ipsec-vpn rule rule-name term term-name
then manual direction direction] hierarchy level:
[edit services ipsec-vpn rule rule-name term term-name then manual direction direction]
auxiliary-spi auxiliary-spi-value;
Configuring Authentication for a Manual IPsec SA
To configure an authentication algorithm, include the authentication statement and
specify an authentication algorithm and a key at the [edit services ipsec-vpn rule rule-name
term term-name then manual direction direction] hierarchy level:
[edit services ipsec-vpn rule rule-name term term-name then manual direction direction]
authentication {
algorithm (hmac-md5-96 | hmac-sha1-96 | hmac-sha-256-128)
key (ascii-text key | hexadecimal key);
}
The algorithm can be one of the following:
•
hmac-md5-96—Hash algorithm that authenticates packet data. It produces a 128-bit
authenticator value and a 96-bit digest.
•
hmac-sha1-96—Hash algorithm that authenticates packet data. It produces a 160-bit
authenticator value and a 96-bit digest.
•
hmac-sha-256-128—Hash algorithm that authenticates packet data. It produces a
256-bit authenticator value 256-bit digest, truncated to 128 bits.
The key can be one of the following:
•
ascii-text—ASCII text key. With the hmac-md5-96 option, the key contains 16 ASCII
characters. With the hmac-sha1-96 option, the key contains 20 ASCII characters.
480
Copyright © 2018, Juniper Networks, Inc.
Chapter 34: Junos VPN Site Secure Configuration Overview
•
hexadecimal—Hexadecimal key. With the hmac-md5-96 option, the key contains
32 hexadecimal characters. With the hmac-sha1-96 option, the key contains
40 hexadecimal characters.
Configuring Encryption for a Manual IPsec SA
To configure IPsec encryption, include the encryption statement and specify an algorithm
and key at the [edit services ipsec-vpn rule rule-name term term-name then manual direction
direction] hierarchy level:
[edit services ipsec-vpn rule rule-name term term-name then manual direction direction]
encryption {
algorithm algorithm;
key (ascii-text key | hexadecimal key);
}
The algorithm can be one of the following:
•
des-cbc—Encryption algorithm that has a block size of 8 bytes; its key size is 64 bits
long.
•
3des-cbc—Encryption algorithm that has a block size of 24 bytes; its key size is 192 bits
long.
•
aes-128-cbc—Advanced Encryption Standard (AES) 128-bit encryption algorithm.
•
aes-192-cbc—Advanced Encryption Standard (AES) 192-bit encryption algorithm.
•
aes-256-cbc—Advanced Encryption Standard (AES) 256-bit encryption algorithm.
NOTE: For a list of Data Encryption Standard (DES) encryption algorithm
weak and semiweak keys, see RFC 2409, The Internet Key Exchange (IKE).
The AES encryption algorithms use a software implementation that has much
lower throughput, so DES remains the recommended option. For reference
information on AES encryption, see RFC 3602, The AES-CBC Cipher Algorithm
and Its Use with IPsec.
For 3des-cbc, the first 8 bytes should differ from the second 8 bytes, and the
second 8 bytes should be the same as the third 8 bytes.
If you configure an authentication proposal but do not include the encryption
statement, the result is NULL encryption. Certain applications expect this
result. If you configure no specific authentication or encryption values, the
Junos OS uses the default values of sha1 for the authentication and 3des-cbc
for the encryption.
The key can be one of the following:
•
ascii-text—ASCII text key. With the des-cbc option, the key contains 8 ASCII characters.
With the 3des-cbc option, the key contains 24 ASCII characters.
Copyright © 2018, Juniper Networks, Inc.
481
Adaptive Services Interfaces Feature Guide for Routing Devices
•
hexadecimal—Hexadecimal key. With the des-cbc option, the key contains
16 hexadecimal characters. With the 3des-cbc option, the key contains 48 hexadecimal
characters.
NOTE: You cannot configure encryption when you use the AH protocol.
Configuring Dynamic Security Associations
You configure dynamic SAs with a set of proposals that are negotiated by the security
gateways. The keys are generated as part of the negotiation and therefore do not need
to be specified in the configuration. The dynamic SA includes one or more proposals,
which allow you to prioritize a list of protocols and algorithms to be negotiated with the
peer.
To enable a dynamic SA, follow these steps:
1.
Configure Internet Key Exchange (IKE) proposals and IKE policies associated with
these proposals.
2. Configure IPsec proposals and an IPsec policy associated with these proposals.
3. Associate an SA with an IPsec policy by configuring the dynamic statement.
To configure a dynamic SA, include the dynamic statement and specify an IPsec policy
name at the [edit services ipsec-vpn rule rule-name term term-name then] hierarchy level.
The ike-policy statement is optional unless you use the preshared key authentication
method.
[edit services ipsec-vpn rule rule-name term term-name then]
dynamic {
ike-policy policy-name;
ipsec-policy policy-name;
}
NOTE: If you want to establish a dynamic SA, the attributes in at least one
configured IPsec and IKE proposal must match those of its peer.
Clearing Security Associations
You can set up the router software to clear IKE or IPsec SAs automatically when the
corresponding services PIC restarts or is taken offline. To configure this property, include
the clear-ike-sas-on-pic-restart or clear-ipsec-sas-on-pic-restart statement at the [edit
services ipsec-vpn] hierarchy level:
[edit services ipsec-vpn]
clear-ike-sas-on-pic-restart;
clear-ipsec-sas-on-pic-restart;
After you add this statement to the configuration, all the IKE or IPsec SAs corresponding
to the tunnels in the PIC will be cleared when the PIC restarts or goes offline.
482
Copyright © 2018, Juniper Networks, Inc.
Chapter 34: Junos VPN Site Secure Configuration Overview
Starting in Junos OS Release 17.2R1, you can enable the cleanup of IKE triggers and IKE
and IPsec SAs when an IPsec tunnel’s local gateway IP address goes down or the MS-MIC
or MS-MPC being used in the tunnel’s service set goes down. This reduces dropped traffic
and unnecessary IKE triggers. To enable this feature, include the gw-interface statement
at the [edit services service set service-set-name ipsec-vpn-options local-gateway address]
hierarchy level. If the local gateway IP address for an IPsec tunnel’s service set goes down
or the MS-MIC or MS-MPC that is being used in the service set goes down, the service
set no longer sends IKE triggers.
In addition, when the local gateway IP address goes down, the IKE and IPsec SAs are
cleared for next-hop service sets, and go to the Not Installed state for interface-style
service sets. The SAs that have the Not Installed state are deleted when the local gateway
IP address comes back up. If the local gateway IP address that goes down for a next-hop
service set is for the responder peer, then you need to clear the IKE and IPsec SAs on the
initiator peer so that the IPsec tunnel comes back up once the local gateway IP address
comes back up. You can either manually clear the IKE and IPsec SAs on the initiator peer
or enable dead peer detection on the initiator peer.
Release History Table
Related
Documentation
Release
Description
17.2R1
Starting in Junos OS Release 17.2R1, you can enable the cleanup of IKE triggers
and IKE and IPsec SAs when an IPsec tunnel’s local gateway IP address goes
down or the MS-MIC or MS-MPC being used in the tunnel’s service set goes
down.
•
Configuring IPsec Policies on page 514
•
Configuring IPsec Proposals on page 509
•
Configuring IKE Policies on page 503
•
Configuring IKE Proposals on page 498
Example: Configuring Manual SAs
This example shows how to create an IPsec tunnel by using manual security associations
(SAs), and contains the following sections:
•
Requirements on page 483
•
Overview and Topology on page 484
•
Configuration on page 484
•
Verification on page 496
Requirements
This example uses the following hardware and software components:
•
Four M Series, MX Series, or T Series routers with multiservices interfaces installed in
them.
Copyright © 2018, Juniper Networks, Inc.
483
Adaptive Services Interfaces Feature Guide for Routing Devices
•
Junos OS Release 9.4 and later.
No special configuration beyond device initialization is required before you can configure
this feature.
Overview and Topology
A security association (SA) is a simplex connection that enables two hosts to securely
communicate with each other by means of IPsec. There are two types of SAs: manual
SA and dynamic SA. This example explains a manual SA configuration.
Manual SAs require no negotiation; all values, including the keys, are static and specified
in the configuration. Manual SAs use statically defined security parameter index (SPI)
values, algorithms, and keys, and require matching configurations on both ends of the
tunnel. Each peer must have the same configured options for communication to take
place.
Manual SAs are best suited for small, static networks where the distribution, maintenance,
and tracking of keys are not difficult.
Figure 28 on page 484 shows an IPsec topology that contains a group of four routers:
Routers 1, 2, 3, and 4.
Figure 28: Manual SA Topology
Routers 2 and 3 establish an IPsec tunnel by using a multiservices PIC and manual SA
settings. Routers 1 and 4 provide basic connectivity and are used to verify that the IPsec
tunnel is operational.
Configuration
This example uses four routers, and involves the following configurations:
484
•
Routers 1 and 4 are configured for basic OSPF connectivity with Routers 2 and 3
respectively.
•
Routers 2 and 3 are configured for OSPF connectivity with Routers 1 and 4 respectively.
Routers 2 and 3 are also configured to create an IPsec tunnel by using manual SAs
between these two routers. To direct traffic to the IPsec tunnel through the multiservices
interface, next-hop style service sets are configured on Routers 2 and 3, and the
Copyright © 2018, Juniper Networks, Inc.
Chapter 34: Junos VPN Site Secure Configuration Overview
multiservices interfaces that are configured as the IPsec inside interface are added to
the OSPF configuration on the respective routers.
NOTE: The interface types shown in this example are for indicative purpose
only. For example, you can use so- interfaces instead of ge- and sp- instead
of ms-.
This section contains:
•
Configuring Router 1 on page 485
•
Configuring Router 2 on page 486
•
Configuring Router 3 on page 490
•
Configuring Router 4 on page 494
Configuring Router 1
CLI Quick
Configuration
To quickly configure this example, copy the following commands, paste them into a text
file, remove any line breaks, change any details necessary to match your network
configuration, and then copy and paste the commands into the CLI, at the [edit] hierarchy
level, of Router 1.
set interfaces ge-1/0/1 description "to R2 ge-1/0/1"
set interfaces ge-1/0/1 unit 0 family inet address 10.1.12.1/30
set interfaces lo0 unit 0 family inet address 10.0.0.1/32
set protocols ospf area 0.0.0.0 interface ge-1/0/1.0
set protocols ospf area 0.0.0.0 interface lo0.0
set routing-options router-id 10.0.0.1
Step-by-Step
Procedure
The following example requires you to navigate various levels in the configuration
hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration
Mode in the CLI User Guide.
To configure Router 1 for OSPF connectivity with Router 2:
1.
Configure an Ethernet interface and loopback interface.
[edit interfaces]
user@router1# set ge-1/0/1 description "to R2 ge-1/0/1"
user@router1# set ge-1/0/1 unit 0 family inet address 10.1.12.1/30
user@router1# set lo0 unit 0 family inet address 10.0.0.1/32
2.
Specify the OSPF area and associate the interfaces with the OSPF area.
[edit protocols]
user@router1# set ospf area 0.0.0.0 interface ge-1/0/1.0
user@router1# set ospf area 0.0.0.0 interface lo0.0
3.
Configure the router ID.
[edit routing-options]
Copyright © 2018, Juniper Networks, Inc.
485
Adaptive Services Interfaces Feature Guide for Routing Devices
user@router1# set router-id 10.0.0.1
Results
From configuration mode, confirm your configuration by entering the show interfaces,
show protocols ospf, and show routing-options commands. If the output does not display
the intended configuration, repeat the instructions in this example to correct the
configuration
user@router1# show interfaces
interfaces {
...
ge-1/0/1 {
description "to R2 ge-1/0/1";
unit 0 {
family inet {
address 10.1.12.1/30;
}
}
}
lo0 {
unit 0 {
family inet {
address 10.0.0.1/32;
}
}
}
...
}
user@router1# show protocols ospf
ospf {
area 0.0.0.0 {
interface ge-1/0/1.0;
interface lo0.0;
}
}
user@router1# show routing-options
routing-options {
router-id 10.0.0.1;
}
Configuring Router 2
CLI Quick
Configuration
Configuring Interfaces
and OSPF Connectivity
(with Router 1 and
Router 3) on Router 2
486
To quickly configure this example, copy the following commands, paste them into a text
file, remove any line breaks, change any details necessary to match your network
configuration, and then copy and paste the commands into the CLI, at the [edit] hierarchy
level, of Router 2.
set interfaces ge-1/0/0 unit 0 description "to R3 ge-1/0/0"
set interfaces ge-1/0/0 unit 0 family inet address 10.1.15.1/30
set interfaces ge-1/0/1 unit 0 description "to R1 ge-1/0/0"
set interfaces ge-1/0/1 unit 0 family inet address 10.1.12.2/30
set interfaces ms-1/2/0 unit 0 family inet
Copyright © 2018, Juniper Networks, Inc.
Chapter 34: Junos VPN Site Secure Configuration Overview
set interfaces ms-1/2/0 unit 1 family inet
set interfaces ms-1/2/0 unit 1 service-domain inside
set interfaces ms-1/2/0 unit 2 family inet
set interfaces ms-1/2/0 unit 2 service-domain outside
set interfaces lo0 unit 0 family inet address 10.0.0.2/32
set protocols ospf area 0.0.0.0 interface ge-1/0/1.0
set protocols ospf area 0.0.0.0 interface lo0.0
set protocols ospf area 0.0.0.0 interface ms-1/2/0.1
set services ipsec-vpn rule demo-rule-r1-manual-sa term demo-term-manual-sa then
remote-gateway 10.1.15.2
set services ipsec-vpn rule demo-rule-r1-manual-sa term demo-term-manual-sa then
manual direction bidirectional protocol esp
set services ipsec-vpn rule demo-rule-r1-manual-sa term demo-term-manual-sa then
manual direction bidirectional spi 261
set services ipsec-vpn rule demo-rule-r1-manual-sa term demo-term-manual-sa then
manual direction bidirectional authentication algorithm hmac-sha1-96
set services ipsec-vpn rule demo-rule-r1-manual-sa term demo-term-manual-sa then
manual direction bidirectional authentication key ascii-text demokeyipsecmanualsa
set services ipsec-vpn rule demo-rule-r1-manual-sa term demo-term-manual-sa then
manual direction bidirectional encryption algorithm des-cbc
set services ipsec-vpn rule demo-rule-r1-manual-sa term demo-term-manual-sa then
manual direction bidirectional encryption key ascii-text manualsa
set services ipsec-vpn rule demo-rule-r1-manual-sa match-direction input
set services service-set demo-ss-manual-sa next-hop-service inside-service-interface
ms-1/2/0.1
set services service-set demo-ss-manual-sa next-hop-service outside-service-interface
ms-1/2/0.2
set services service-set demo-ss-manual-sa ipsec-vpn-options local-gateway 10.1.15.1
set services service-set demo-ss-manual-sa ipsec-vpn-rules demo-rule-r1-manual-sa
Step-by-Step
Procedure
The following example requires you to navigate various levels in the configuration
hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration
Mode in the CLI User Guide.
To configure OSPF connectivity and IPsec tunnel parameters on Router 2:
1.
Configure interface properties. In this step, you configure two Ethernet interfaces
(ge-1/0/0 and ge-1/0/1), a loopback interface, and a multiservices interface
(ms-1/2/0).
[edit interfaces]
user@router2# set ge-1/0/0 unit 0 description "to R3 ge-1/0/0"
user@router2# set ge-1/0/0 unit 0 family inet address 10.1.15.1/30
user@router2# set ge-1/0/1 unit 0 description "to R1 ge-1/0/0"
user@router2# set ge-1/0/1 unit 0 family inet address 10.1.12.2/30
user@router2# set ms-1/2/0 unit 0 family inet
user@router2# set ms-1/2/0 unit 1 family inet
user@router2# set ms-1/2/0 unit 1 service-domain inside
user@router2# set ms-1/2/0 unit 2 family inet
user@router2# set ms-1/2/0 unit 2 service-domain outside
user@router2# set lo0 unit 0 family inet address 10.0.0.2/32
2.
Specify the OSPF area and associate the interfaces with the OSPF area.
[edit protocols]
Copyright © 2018, Juniper Networks, Inc.
487
Adaptive Services Interfaces Feature Guide for Routing Devices
user@router2# set ospf area 0.0.0.0 interface ge-1/0/1.0
user@router2# set ospf area 0.0.0.0 interface lo0.0
user@router2# set ospf area 0.0.0.0 interface ms-1/2/0.1
3.
Configure the router ID.
[edit routing-options]
user@router2# set router-ID 10.0.0.2
4.
Configure an IPsec rule. In this step, you configure an IPsec rule and specify manual
SA parameters, such as the remote-gateway address, authentication and encryption
properties, and so on.
[edit services ipsec-vpn]
user@router2# set rule demo-rule-r1-manual-sa term demo-term-manual-sa then
remote-gateway 10.1.15.2
user@router2# set rule demo-rule-r1-manual-sa term demo-term-manual-sa then
manual direction bidirectional protocol esp
user@router2# set rule demo-rule-r1-manual-sa term demo-term-manual-sa then
manual direction bidirectional spi 261
user@router2# set rule demo-rule-r1-manual-sa term demo-term-manual-sa then
manual direction bidirectional authentication algorithm hmac-sha1-96
user@router2# set rule demo-rule-r1-manual-sa term demo-term-manual-sa then
manual direction bidirectional authentication key ascii-text
demokeyipsecmanualsa
user@router2# set rule demo-rule-r1-manual-sa term demo-term-manual-sa then
manual direction bidirectional encryption algorithm des-cbc
user@router2# set rule demo-rule-r1-manual-sa term demo-term-manual-sa then
manual direction bidirectional encryption key ascii-text manualsa
user@router2# set rule demo-rule-r1-manual-sa match-direction input
5.
Configure a next-hop style service set, specify the local-gateway address, and
associate the IPsec VPN rule with the service set.
[edit services]
user@router2# set service-set demo-ss-manual-sa next-hop-service
inside-service-interface ms-1/2/0.1
user@router2# set service-set demo-ss-manual-sa next-hop-service
outside-service-interface ms-1/2/0.2
user@router2# set service-set demo-ss-manual-sa ipsec-vpn-options local-gateway
10.1.15.1
user@router2# set service-set demo-ss-manual-sa ipsec-vpn-rules
demo-rule-r1-manual-sa
6.
Commit the configuration.
[edit]
user@router2# commit
Results
488
From configuration mode, confirm your configuration by entering the show interfaces,
show protocols ospf, show routing-options, and show services commands. If the output
Copyright © 2018, Juniper Networks, Inc.
Chapter 34: Junos VPN Site Secure Configuration Overview
does not display the intended configuration, repeat the instructions in this example to
correct the configuration
user@router1# show interfaces
interfaces {
...
ge-1/0/0 {
unit 0 {
description "to R3 ge-1/0/0";
family inet {
address 10.1.15.1/30;
}
}
}
ge-1/0/1 {
unit 0 {
description "to R1 ge-1/0/1";
family inet {
address 10.1.12.2/30;
}
}
}
ms-1/2/0 {
unit 0 {
family inet;
}
unit 1 {
family inet;
service-domain inside;
}
unit 2 {
family inet;
service-domain outside;
}
}
lo0 {
unit 0 {
family inet {
address 10.0.0.2/32;
}
}
}
...
}
user@router2# show protocols ospf
protocols {
ospf {
area 0.0.0.0 {
interfaces ge-1/0/1.0;
interface lo0;
interface ms-1/2/0;
}
}
}
Copyright © 2018, Juniper Networks, Inc.
489
Adaptive Services Interfaces Feature Guide for Routing Devices
user@router2# show routing-options
routing-options {
router-id 10.0.0.2;
}
user@router2# show services
services {
ipsec-vpn {
rule demo-rule-r1-manual-sa {
term demo-term-manual-sa {
then {
remote-gateway 10.1.15.2;
manual {
direction bidirectional {
protocol esp;
spi 261;
authentication {
algorithm hmac-sha1-96;
key ascii-text "$ABC1223"; ## SECRET-DATA
}
encryption {
algorithm des-cbc;
key ascii-text "$ABC123"; ## SECRET-DATA
}
}
}
}
}
match-direction input;
}
}
service-set demo-ss-manual-sa {
next-hop-service {
inside-service-interface ms-1/2/0.1;
outside-service-interface ms-1/2/0.2;
}
ipsec-vpn-options {
local-gateway 10.1.15.1;
}
ipsec-vpn-rules demo-rule-r1-manual-sa;
}
}
Configuring Router 3
CLI Quick
Configuration
To quickly configure this example, copy the following commands, paste them into a text
file, remove any line breaks, change any details necessary to match your network
configuration, and then copy and paste the commands into the CLI, at the [edit] hierarchy
level, of Router 3.
set interfaces ge-1/0/1 unit 0 description "to R4 ge-1/0/1"
set interfaces ge-1/0/0 unit 0 family inet address 10.1.56.1/30
set interfaces ge-1/0/0 unit 0 description "to R2 ge-1/0/0"
set interfaces ge-1/0/0 unit 0 family inet address 10.1.15.2/30
set interfaces ms-1/2/0 unit 0 family inet
490
Copyright © 2018, Juniper Networks, Inc.
Chapter 34: Junos VPN Site Secure Configuration Overview
set interfaces ms-1/2/0 unit 1 family inet
set interfaces ms-1/2/0 unit 1 service-domain inside
set interfaces ms-1/2/0 unit 2 family inet
set interfaces ms-1/2/0 unit 2 service-domain outside
set interfaces lo0 unit 0 family inet address 10.0.0.3/32
set protocols ospf area 0.0.0.0 interface ge-1/0/1.0
set protocols ospf area 0.0.0.0 interface lo0.0
set protocols ospf area 0.0.0.0 interface ms-1/2/0.1
set routing-options router-id 10.0.0.3
set services ipsec-vpn rule demo-rule-r1-manual-sa term demo-term-manual-sa then
remote-gateway 10.1.15.1
set services ipsec-vpn rule demo-rule-r1-manual-sa term demo-term-manual-sa then
manual direction bidirectional protocol esp
set services ipsec-vpn rule demo-rule-r1-manual-sa term demo-term-manual-sa then
manual direction bidirectional spi 261
set services ipsec-vpn rule demo-rule-r1-manual-sa term demo-term-manual-sa then
manual direction bidirectional authentication algorithm hmac-sha1-96
set services ipsec-vpn rule demo-rule-r1-manual-sa term demo-term-manual-sa then
manual direction bidirectional authentication key ascii-text demokeyipsecmanualsa
set services ipsec-vpn rule demo-rule-r1-manual-sa term demo-term-manual-sa then
manual direction bidirectional encryption algorithm des-cbc
set services ipsec-vpn rule demo-rule-r1-manual-sa term demo-term-manual-sa then
manual direction bidirectional encryption key ascii-text manualsa
set services ipsec-vpn rule demo-rule-r1-manual-sa match-direction input
set services service-set demo-ss-manual-sa next-hop-service inside-service-interface
ms-1/2/0.1
set services service-set demo-ss-manual-sa next-hop-service outside-service-interface
ms-1/2/0.2
set services service-set demo-ss-manual-sa ipsec-vpn-options local-gateway 10.1.15.2
set services service-set demo-ss-manual-sa ipsec-vpn-rules demo-rule-r1-manual-sa
Step-by-Step
Procedure
The following example requires you to navigate various levels in the configuration
hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration
Mode in the CLI User Guide.
To configure OSPF connectivity and IPsec tunnel parameters on Router 3:
1.
Configure interface properties. In this step, you configure two Ethernet interfaces
(ge-1/0/0 and ge-1/0/1), a loopback interface, and a multiservices interface
(ms-1/2/0).
[edit interfaces]
user@router3# set ge-1/0/0 unit 0 description "to R4 ge-1/0/0"
user@router3# set ge-1/0/0 unit 0 family inet address 10.1.56.1/30
user@router3# set ge-1/0/1 unit 0 description "to R2 ge-1/0/1"
user@router3# set ge-1/0/1 unit 0 family inet address 10.1.15.2/30
user@router3# set ms-1/2/0 unit 0 family inet
user@router3# set ms-1/2/0 unit 1 family inet
user@router3# set ms-1/2/0 unit 1 service-domain inside
user@router3# set ms-1/2/0 unit 2 family inet
user@router3# set ms-1/2/0 unit 2 service-domain outside
user@router3# set lo0 unit 0 family inet address 10.0.0.3/32
2.
Specify the OSPF area and associate the interfaces with the OSPF area.
Copyright © 2018, Juniper Networks, Inc.
491
Adaptive Services Interfaces Feature Guide for Routing Devices
[edit protocols]
user@router3# set ospf area 0.0.0.0 interface ge-1/0/1.0
user@router3# set ospf area 0.0.0.0 interface lo0.0
user@router3# set ospf area 0.0.0.0 interface ms-1/2/0.1
3.
Configure a router ID.
[edit routing-options]
user@router3# set router-id 10.0.0.3
4.
Configure an IPsec rule. In this step, you configure an IPsec rule and specify manual
SA parameters, such as the remote-gateway address, authentication and encryption
properties, and so on.
[edit services ipsec-vpn]
user@router3# set rule demo-rule-r1-manual-sa term demo-term-manual-sa then
remote-gateway 10.1.15.1
user@router3# set rule demo-rule-r1-manual-sa term demo-term-manual-sa then
manual direction bidirectional protocol esp
user@router3# set rule demo-rule-r1-manual-sa term demo-term-manual-sa then
manual direction bidirectional spi 261
user@router3# set rule demo-rule-r1-manual-sa term demo-term-manual-sa then
manual direction bidirectional authentication algorithm hmac-sha1-96
user@router3# set rule demo-rule-r1-manual-sa term demo-term-manual-sa then
manual direction bidirectional authentication key ascii-text
demokeyipsecmanualsa
user@router3# set rule demo-rule-r1-manual-sa term demo-term-manual-sa then
manual direction bidirectional encryption algorithm des-cbc
user@router3# set rule demo-rule-r1-manual-sa term demo-term-manual-sa then
manual direction bidirectional encryption key ascii-text manualsa
user@router3# set rule demo-rule-r1-manual-sa match-direction input
5.
Configure a next-hop style service set, specify the local-gateway address, and
associate the IPsec VPN rule with the service set.
[edit services]
user@router3# set service-set demo-ss-manual-sa next-hop-service
inside-service-interface ms-1/2/0.1
user@router3# set service-set demo-ss-manual-sa next-hop-service
outside-service-interface ms-1/2/0.2
user@router3# set service-set demo-ss-manual-sa ipsec-vpn-options local-gateway
10.1.15.2
user@router3# set service-set demo-ss-manual-sa ipsec-vpn-rules
demo-rule-r1-manual-sa
6.
Commit the configuration.
[edit]
user@router3# commit
Results
492
From configuration mode, confirm your configuration by entering the show interfaces,
show protocols ospf, show routing-options, and show services commands. If the output
Copyright © 2018, Juniper Networks, Inc.
Chapter 34: Junos VPN Site Secure Configuration Overview
does not display the intended configuration, repeat the instructions in this example to
correct the configuration
user@router3# show interfaces
interfaces {
ge-1/0/1 {
unit 0 {
description "to R4 ge-1/0/1";
family inet {
address 10.1.56.1/30;
}
}
}
ge-1/0/0 {
unit 0 {
description "to R2 ge-1/0/0";
family inet {
address 10.1.15.2/30;
}
}
}
ms-1/2/0 {
unit 0 {
family inet;
}
unit 1 {
family inet;
service-domain inside;
}
unit 2 {
family inet;
service-domain outside;
}
}
lo0 {
unit 0 {
family inet {
address 10.0.0.3/32;