Академический Документы
Профессиональный Документы
Культура Документы
12.a
Juniper Networks reserves the right to change, modify, transfer, or otherwise revise this publication without notice.
YEAR 2000 NOTICE
Juniper Networks hardware and software products do not suffer from Year 2000 problems and hence are Year 2000 compliant. The Junos operating system has
no known time-related limitations through the year 2038. However, the NTP application is known to have some difficulty in the year 2036.
SOFTWARE LICENSE
The terms and conditions for using Juniper Networks software are described in the software license provided with the software, or to the extent applicable, in an
agreement executed between you and Juniper Networks, or Juniper Networks agent. By using Juniper Networks software, you indicate that you understand and
agree to be bound by its license terms and conditions. Generally speaking, the software license restricts the manner in which you are permitted to use the Juniper
Networks software, may contain prohibitions against certain uses, and may state conditions under which the license is automatically terminated. You should
consult the software license for further details.
Contents
Lab 1: Configuring and Monitoring Zones (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-1
Part 1: Logging In Using the CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2
Part 2: Verifying Network Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-6
Part 3: Configuring Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-10
Part 4: Monitoring and Verifying the Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-14
This three-day course covers the configuration, operation, and implementation of SRX Series
Services Gateways in a typical network environment. Key topics within this course include security
technologies such as security zones, security policies, intrusion detection and prevention (IDP),
Network Address Translation (NAT), and high availability clusters, as well as details pertaining to
basic implementation, configuration, and management. The course includes extensive hands-on
labs, in which you configure and monitor the Junos operating system using SRX Series devices.
This course is based on Junos OS Release 12.1R1.9.
Objectives
After successfully completing this course, you should be able to perform the following:
Describe traditional routing and security and the current trends in internetworking.
Provide an overview of SRX Series devices and software architecture.
Describe the logical packet flow and session creation performed by SRX Series
devices.
Describe, configure, and monitor zones.
Describe, configure, and monitor security policies.
Describe, configure, and monitor firewall user authentication.
Describe various types of network attacks.
Configure and monitor SCREEN options to prevent network attacks.
Explain, implement, and monitor NAT, as implemented on Junos security platforms.
Explain the purpose and mechanics of IP Security (IPsec) virtual private networks
(VPNs).
Implement and monitor policy-based and route-based IPsec VPNs.
Utilize and update the IDP signature database.
Configure and monitor IDP policy with policy templates.
Describe, configure, and monitor high availability chassis clusters.
Intended Audience
The course content is aimed at operators of SRX Series devices. These operators include network
engineers, administrators, support personnel, and reseller support personnel.
Course Level
Junos Security is an intermediate-level course.
Prerequisites
Students should have basic networking knowledge and an understanding of the Open Systems
Interconnection (OSI) reference model and the TCP/IP protocol suite. Students should also attend
the Introduction to the Junos Operating System (IJOS) course and the Junos Routing Essentials
(JRE) course, or have equivalent experience prior to attending this class.
Day 1
Chapter 1: Course Introduction
Chapter 2: Introduction to Junos Security
Chapter 3: Zones
Lab 1: Configuring and Monitoring Zones
Chapter 4: Security Policies
Lab 2: Security Policies
Day 2
Chapter 5: Firewall User Authentication
Lab 3: Configuring Firewall Authentication
Chapter 6: Screen Options
Lab 4: Implementing Screen Options
Chapter 7: Network Address Translation
Lab 5: Network Address Translation
Day 3
Chapter 8: IPsec VPNs
Lab 6: Implementing IPsec VPNs
Chapter 9: Introduction to Intrusion Detection and Prevention
Lab 7: Implementing IDP
Chapter 10: High Availability Clustering Theory
Chapter 11: High Availability Clustering Implementation
Lab 8: Implementing High Availability Techniques
Appendix A: SRX Series Hardware and Interfaces
Franklin Gothic Normal text. Most of what you read in the Lab Guide
and Student Guide.
CLI Input Text that you must enter. lab@San_Jose> show route
GUI Input Select File > Save, and type
config.ini in the Filename field.
CLI Undefined Text where the variables value Type set policy policy-name.
is the users discretion and text
ping 10.0.x.y
where the variables value as
GUI Undefined shown in the lab guide might Select File > Save, and type
differ from the value the user filename in the Filename field.
must input.
Overview
In this lab, you will configure a baseline network for your pod, including interface
addressing, routing, and assigning interfaces to zones.
The lab is available in two formats: a high-level format designed to make you think through
each step and a detailed format that offers step-by-step instructions complete with
sample output from most commands.
The lab is also designed for modularity, where you might be directed to load a starting
configuration at the beginning of each lab part. If you are completing the lab from start to
finish, there is no need to load the starting configuration for each lab part.
By completing this lab, you will perform the following tasks:
Use the Junos operating system CLI to setup a baseline network.
Implement routing so that all networks are reachable.
Assign interfaces to security zones.
Monitor the effects of your configuration.
In this lab part, you become familiar with the access details used to access the lab
equipment. Once you are familiar with the access details, you will use the CLI to log
in to your teams designated station.
Note
Depending on the class, the lab equipment
used might be remote from your physical
location. The instructor will inform you as to
the nature of your access and will provide
you the details needed to access your
assigned device.
Step 1.1
Ensure that you know to which student device you have been assigned. Check with
your instructor if you are not certain. Consult the Management Network Diagram to
determine the management address of your student device.
Step 1.2
Access the command-line interface (CLI) at your station using either the console,
Telnet, or SSH as directed by your instructor.
login: lab
Password:
[edit]
lab@srxA-1# load override jsec/lab1-start.config
load complete
[edit]
lab@srxA-1# commit
commit complete
[edit]
lab@srxA-1#
Note
You might receive a warning message upon
committing that you have changed to MPLS
flow mode, and that you must reboot the
SRX device. If you receive this warning,
reboot your assigned SRX device and log
back in as user lab once the device
finishes rebooting.
Step 1.4
View the current configuration of your assigned device.
[edit]
lab@srxA-1# show security
forwarding-options {
family {
mpls {
mode packet-based;
}
}
}
Step 1.5
Navigate to the [edit interfaces] hierarchy. Configure the IP address for the
ge-0/0/3 interface. Refer to the lab diagram for the appropriate IP address.
[edit]
lab@srxA-1# edit interfaces
[edit interfaces]
lab@srxA-1# set ge-0/0/3 unit 0 family inet address local-Internet-interface/
mask
[edit interfaces]
lab@srxA-1#
Step 1.6
Configure the lo0 loopback interface IP address. Refer to the lab diagram for the IP
address assigned to your device.
[edit interfaces]
lab@srxA-1# set lo0 unit 0 family inet address local-loopback-address
Step 1.7
Configure the ge-0/0/4 interface. Enable VLAN-tagging and configure two logical
units. Each logical unit number should match its associated VLAN-ID. Refer to the
VLAN assignments listed on the network diagram for Labs 17. Assign the IP
address shown on the lab diagram. Note that the third octet of the IP address should
also match the logical units associated VLAN-ID.
[edit interfaces]
lab@srxA-1# set ge-0/0/4 vlan-tagging
[edit interfaces]
lab@srxA-1# set ge-0/0/4 unit local-Juniper-unit vlan-id local-Juniper-VLAN
[edit interfaces]
lab@srxA-1# set ge-0/0/4 unit local-ACME-unit vlan-id local-ACME-VLAN
[edit interfaces]
lab@srxA-1# set ge-0/0/4 unit local-ACME-unit family inet address
local-ACME-interface/mask
Step 1.8
Configure a static default route that points to the IP address associated with the
remote end of the ge-0/0/3 interface for your device. Commit the configuration and
return to operational mode.
[edit interfaces]
lab@srxA-1# up
[edit]
lab@srxA-1# edit routing-options
[edit routing-options]
lab@srxA-1# set static route 0/0 next-hop remote-Internet-address
[edit routing-options]
lab@srxA-1# commit and-quit
commit complete
Exiting configuration mode
lab@srxA-1>
STOP Ensure that the remote student team within your pod has finished
Part 2 before continuing.
In this lab part, you verify network connectivity within your pod.
Step 2.1
Enter configuration mode, or go to the top of the configuration hierarchy if you are
already in configuration mode, and load the lab1-part2-start.config from
the /var/home/lab/jsec/ directory. Commit the configuration when complete.
[edit]
lab@srxA-1# load override jsec/lab1-part2-start.config
load complete
[edit]
lab@srxA-1# commit
commit complete
Step 2.2
Check the status of your configured interfaces using the run show interfaces
terse command.
[edit]
lab@srxA-1# run show interfaces terse |no-more
Interface Admin Link Proto Local Remote
ge-0/0/0 up up
ge-0/0/0.0 up up inet 10.210.35.131/26
gr-0/0/0 up up
ip-0/0/0 up up
lsq-0/0/0 up up
lt-0/0/0 up up
mt-0/0/0 up up
sp-0/0/0 up up
sp-0/0/0.0 up up inet
sp-0/0/0.16383 up up inet 10.0.0.1 --> 10.0.0.16
10.0.0.6 --> 0/0
128.0.0.1 --> 128.0.1.16
128.0.0.6 --> 0/0
ge-0/0/1 up up
ge-0/0/2 up up
ge-0/0/3 up up
ge-0/0/3.0 up up inet 172.18.1.2/30
ge-0/0/4 up up
ge-0/0/4.101 up up inet 172.20.101.1/24
ge-0/0/4.201 up up inet 172.20.201.1/24
ge-0/0/4.32767 up up
ge-0/0/5 up down
ge-0/0/6 up up
ge-0/0/7 up up
ge-0/0/8 up up
ge-0/0/9 up up
ge-0/0/10 up up
ge-0/0/11 up up
ge-0/0/12 up down
ge-0/0/13 up down
ge-0/0/14 up up
Lab 16 Configuring and Monitoring Zones (Detailed) www.juniper.net
Junos Security
ge-0/0/15 up up
fxp2 up up
fxp2.0 up up tnp 0x1
gre up up
ipip up up
irb up up
lo0 up up
lo0.0 up up inet 192.168.1.1 --> 0/0
lo0.16384 up up inet 127.0.0.1 --> 0/0
lo0.16385 up up inet 10.0.0.1 --> 0/0
10.0.0.16 --> 0/0
128.0.0.1 --> 0/0
128.0.0.4 --> 0/0
128.0.1.16 --> 0/0
lo0.32768 up up
lsi up up
mtun up up
pimd up up
pime up up
pp0 up up
ppd0 up up
ppe0 up up
st0 up up
tap up up
vlan up up
Step 2.3
Verify reachability to the remote peer in your pod across the Internet using the ping
command.
[edit]
lab@srxA-1# run ping remote-srx-Internet-address rapid
Note
The next lab steps require you to log in to
the virtual router attached to your teams
device. The virtual routers are logical
devices created on a J Series Services
Router. Refer to the Management Network
Diagram for the IP address of the vr-device.
Although you have two virtual routers
attached to your student device, you only
need to establish a single session.
Open a separate Telnet session to the virtual router attached to your team device.
vr-device (ttyd0)
login: username
Password:
NOTE: This router is divided into many virtual routers used by different teams.
Please only configure your own virtual router.
a1@vr-device>
Step 2.5
From the Telnet session established with the virtual router, verify reachability to the
remote virtual routers connected to the device of your peers using the ping
command. Be sure to source your ping from the correct virtual-router routing
instance.
Note
Keep in mind that when working with
virtual routers and routing instances,
command syntax is different. If needed,
please reference the detailed lab guide for
sample command syntax for the individual
verification tasks performed within this lab.
In this lab part, you remove the current zone configuration and reassign your device
interfaces to various security and functional zones.
Step 3.1
Enter configuration mode, or go to the top of the configuration hierarchy if you are
already in configuration mode, and load the lab1-part3-start.config from
the /var/home/lab/jsec/ directory. Commit the configuration when complete.
[edit]
lab@srxA-1# load override jsec/lab1-part3-start.config
load complete
[edit]
lab@srxA-1# commit
commit complete
[edit security]
lab@srxA-1#
Step 3.3
View the [edit security] configuration stanza and answer the questions that
follow.
[edit security]
lab@srxA-1# show
forwarding-options {
family {
mpls {
mode packet-based;
}
}
}
[edit security]
lab@srxA-1# show
Step 3.5
Refer to the lab diagram and configure the untrust security zone, as well as your
local Juniper and ACME security zones, as labeled on the lab diagram. Add the
appropriate network interfaces under each security zone. Be sure to configure only
the security zones associated with your assigned device.
[edit security]
lab@srxA-1# set zones security-zone Juniper-local interfaces
ge-0/0/4.local-Juniper-unit
[edit security]
lab@srxA-1# set zones security-zone ACME-local interfaces
ge-0/0/4.local-ACME-unit
[edit security]
lab@srxA-1# set zones security-zone untrust interfaces ge-0/0/3.0
[edit security]
lab@srxA-1# show
zones {
security-zone Juniper-SV {
interfaces {
ge-0/0/4.101;
}
}
security-zone ACME-SV {
interfaces {
ge-0/0/4.201;
}
}
security-zone untrust {
interfaces {
ge-0/0/3.0;
}
}
}
Step 3.6
Next, configure a functional zone and associate it with your devices management
interface.
[edit security]
lab@srxA-1# set zones functional-zone ?
Possible completions:
Step 3.7
Configure the functional zone so that it allows SSH, telnet, ping, traceroute, HTTP,
and SNMP local inbound traffic.
[edit security]
lab@srxA-1# edit zones functional-zone management
Step 3.8
Commit your configuration and exit configuration mode.
[edit security zones functional-zone management]
lab@srxA-1# commit and-quit
commit complete
Exiting configuration mode
lab@srxA-1>
In this lab part, you use show commands to monitor the zones you just created. You
will also test host inbound traffic.
Step 4.1
Enter configuration mode, or go to the top of the configuration hierarchy if you are
already in configuration mode, and load the lab1-part4-start.config from
the /var/home/lab/jsec/ directory. Commit the configuration when complete.
[edit]
lab@srxA-1# load override jsec/lab1-part4-start.config
load complete
[edit]
lab@srxA-1# commit and-quit
commit complete
Exiting configuration mode
lab@srxA-1>
Step 4.2
Issue the show security zones command and answer the following questions.
Logical interface ge-0/0/0.0 (Index 69) (SNMP ifIndex 533) (Generation 134)
Flags: SNMP-Traps 0x0 Encapsulation: ENET2
Traffic statistics:
Input bytes : 297963
Output bytes : 0
Input packets: 2219
Output packets: 0
Local statistics:
Input bytes : 297963
Output bytes : 0
Input packets: 2219
Output packets: 0
Transit statistics:
Input bytes : 0 0 bps
Output bytes : 0 0 bps
Input packets: 0 0 pps
Output packets: 0 0 pps
Security: Zone: Management
Allowed host-inbound traffic : http ping snmp ssh telnet traceroute
Flow Statistics :
Flow Input statistics :
Self packets : 0
ICMP packets : 0
srxA-1 (ttyp0)
login: ^C
Overview
In this lab, you will implement security policies designed to allow only necessary traffic
between zones within your pod. You will configure custom applications, a scheduler, and
security logging and monitor the effects of your changes.
The lab is available in two formats: a high-level format designed to make you think through
each step and a detailed format that offers step-by-step instructions complete with
sample output from most commands.
The lab is also designed for modularity, where you might be directed to load a starting
configuration at the beginning of each lab part. If you are completing the lab from start to
finish, there is no need to load the starting configuration for each lab part.
By completing this lab, you will perform the following tasks:
Define zone address books necessary for security policy.
Implement security policies between zones within your assigned pod.
Assign schedulers to security policies.
Implement security logging to a remote syslog server.
Monitor the effects of your configuration.
In this lab part, you become familiar with the access details used to access the lab
equipment. Once you are familiar with the access details, you will use the CLI to log
in to your designated station. Next, you will load the starting configuration for Lab 2.
Then, you will monitor the default policy configuration that denies all traffic between
zones.
Note
Depending on the class, the lab equipment
used might be remote from your physical
location. The instructor will inform you as to
the nature of your access and will provide
you the details needed to access your
assigned device.
Step 1.1
Ensure that you know to which student device you have been assigned. Check with
your instructor if you are not certain. Consult the Management Network Diagram to
determine the management address of your student device.
Step 1.2
Access the CLI at your station using either the console, Telnet, or SSH as directed by
your instructor. Refer to the Management Network Diagram for the IP address
associated with your workstation. The following example is based on simple Telnet
access using the Secure CRT program.
Step 1.3
Log in as user lab with the password lab123. Enter configuration mode and load
the lab2-start.config from the /var/home/lab/jsec/ directory. After you have
finished loading the configuration, commit the changes and exit to operational
mode.
srxC-1 (ttyu0)
login: lab
Password:
[edit]
lab@srxC-1# load override jsec/lab2-start.config
[edit]
lab@srxC-1# commit
commit complete
[edit]
lab@srxC-1#
Note
The next lab steps require you to log in to
the virtual router attached to your teams
device. The virtual routers are logical
devices created on a J Series Services
Router. Refer to the Management Network
Diagram for the IP address of the vr-device.
Step 1.5
Log in to the virtual router using the login information shown in the following table:
login: c1
Password:
NOTE: This router is divided into many virtual routers used by different teams.
Please only configure your own virtual router.
c1@vr-device>
In this lab part, you configure the address book entries necessary for implementing
security policies within your pod.
Step 2.1
Return to the Telnet session established with your assigned SRX device.
[edit]
lab@srxC-1# edit security zones security-zone untrust
Do not proceed to the next lab part until directed by the instructor to do
STOP
so.
In this lab part, you will establish and configure security policies that enable the
necessary traffic flow between the security zones.
Note
Pay close attention to the instructions
throughout this lab. Some tasks might not
be relevant to your assigned device.
[edit]
lab@srxC-1# load override jsec/lab2-part3-start.config
[edit]
lab@srxC-1# commit
commit complete
[edit]
lab@srxC-1#
Step 3.2
Create security policies named intrazone-Juniper-local and
intrazone-ACME-local that allows all intra-zone traffic associated with your
attached virtual routers to pass through your assigned device. (Hint: Use the any
keyword to save keystrokes.)
[edit]
lab@srxC-1# edit security policies from-zone Juniper-local to-zone
Juniper-local policy intrazone-Juniper-local
Step 3.7
Return to the Telnet session established with your assigned SRX device.
From the Telnet session established with assigned SRX device, reorder the policies
so that the deny-ftp-Juniper-local policy appears in the list before the
internet-Juniper-local policy. Commit your configuration.
[edit security policies from-zone Juniper-SV to-zone untrust policy
deny-ftp-Juniper-SV]
lab@srxC-1# up
Note
Keep in mind that when working with
virtual routers and routing instances,
command syntax can differ. If needed,
please reference the Detailed Lab Guide for
sample command syntax for the individual
verification tasks performed within this lab.
c1@vr-device>
[edit]
lab@srxC-1# edit applications application Juniper-gizmo
[edit applications]
lab@srxC-1# edit application-set internal-apps
[edit]
lab@srxC-1# edit security policies from-zone untrust to-zone Juniper-local
Step 3.12
Create a scheduler named internal-apps-scheduler. The scheduler should
allow traffic between the hours of 3 a.m. and 11 p.m., Monday through Friday. Apply
the new scheduler to the Juniper-remote-to-Juniper-local security
policy.
[edit security policies from-zone untrust to-zone Juniper-SV]
lab@srxC-1# top
[edit]
lab@srxC-1# edit security policies from-zone untrust to-zone Juniper-local
lab@srxC-1>
STOP Do NOT continue to the next lab part until both teams within your
assigned pod have reached this point.
In this lab part, you monitor the results of your configuration with command outputs
and logging.
Step 4.1
Enter configuration mode, or go to the top of the configuration hierarchy if you are
already in configuration mode, and load the lab2-part4-start.config from
the /var/home/lab/jsec/ directory. Commit the configuration when complete.
[edit]
lab@srxC-1# load override jsec/lab2-part4-start.config
[edit]
lab@srxC-1# commit
commit complete
[edit]
lab@srxC-1#
Step 4.2
View the security policies in effect on your assigned device by issuing the
show security policies command and answer the following questions.
lab@srxC-1> show security policies
Default policy: deny-all
From zone: Juniper-SV, To zone: Juniper-SV
Policy: interazone-Juniper-SV, State: enabled, Index: 4, Scope Policy: 0,
Sequence number: 1
Source addresses: any
Destination addresses: any
Applications: any
Action: permit
From zone: Juniper-SV, To zone: untrust
Policy: deny-ftp-Juniper-SV, State: enabled, Index: 7, Scope Policy: 0,
Sequence number: 1
Source addresses: any
Destination addresses: any
Applications: junos-ftp
Action: reject
Policy: internet-Juniper-SV, State: enabled, Index: 6, Scope Policy: 0,
Sequence number: 2
Source addresses: vr105
Destination addresses: any
Applications: any
Action: permit
From zone: ACME-SV, To zone: ACME-SV
Policy: intrazone-ACME-SV, State: enabled, Index: 5, Scope Policy: 0, Sequence
number: 1
Source addresses: any
Destination addresses: any
Applications: any
Action: permit
From zone: ACME-SV, To zone: untrust
Policy: internet-ACME-SV, State: enabled, Index: 8, Scope Policy: 0, Sequence
number: 1
Source addresses: vr205
Destination addresses: any
Applications: any
Action: permit
From zone: untrust, To zone: Juniper-SV
Step 4.4
Return to the Telnet session established with the virtual router.
From the Telnet session established with the virtual router, open a Telnet session
between the virtual router associated with your local Juniper zone and the virtual
router associated with the remote Juniper zone. Be sure to source the Telnet session
from the appropriate routing instance. Log in with the same username and
password as your current session.
c1@vr-device> telnet remote-Juniper-VR routing-instance local-Juniper-VR
Trying 172.20.106.10...
Connected to 172.20.106.10.
Escape character is '^]'.
vr-device(ttyp0)
login: username
Password:
NOTE: This router is divided into many virtual routers used by different teams.
Please only configure your own virtual router.
c1@vr-device>
Step 4.5
Return to the Telnet session established with your assigned SRX device.
From the Telnet session established with assigned SRX device, issue the
show security flow session command.
lab@srxC-1> show security flow session
Session ID: 24149, Policy name: Juniper-SV-to-Juniper-WF/9, Timeout: 1766,
Valid
In: 172.20.106.10/51545 --> 172.20.105.10/23;tcp, If: ge-0/0/3.0, Pkts: 27,
Bytes: 1567
Out: 172.20.105.10/23 --> 172.20.106.10/51545;tcp, If: ge-0/0/4.105, Pkts: 22,
Bytes: 1596
Step 4.6
Using the session ID, view a more detailed output of the open Telnet session and
answer the following question. Use the session ID identified in the previous step.
lab@srxC-1> show security flow session session-identifier session-id
Session ID: 24149, Status: Normal
Flag: 0x40
Policy name: Juniper-SV-to-Juniper-WF/9
Source NAT pool: Null, Application: junos-telnet/10
Dynamic application: junos:UNKNOWN,
Maximum timeout: 1800, Current timeout: 1716
Session State: Valid
Start time: 112401, Duration: 91
In: 172.20.106.10/51545 --> 172.20.105.10/23;tcp,
Interface: ge-0/0/3.0,
Session token: 0xa, Flag: 0x21
Route: 0x110010, Gateway: 172.18.1.1, Tunnel: 0
Port sequence: 0, FIN sequence: 0,
FIN state: 0,
Pkts: 27, Bytes: 1567
Out: 172.20.105.10/23 --> 172.20.106.10/51545;tcp,
Interface: ge-0/0/4.105,
Session token: 0x7, Flag: 0x20
Route: 0x120010, Gateway: 172.20.105.10, Tunnel: 0
Port sequence: 0, FIN sequence: 0,
FIN state: 0,
Pkts: 22, Bytes: 1596
Total sessions: 1
c1@vr-device>
Step 4.8
Return to the Telnet session established with your assigned SRX device.
From the Telnet session established with assigned SRX device, view the
configuration hierarchy associated with the syslog settings.
lab@srxC-1> show configuration system syslog
user * {
any emergency;
}
file messages {
any any;
authorization info;
}
file interactive-commands {
interactive-commands any;
}
Step 4.9
View security policy log entries by issuing the show log messages | match
RT_FLOW command.
Note
Recall that the security policy log action
configuration was only for specific traffic
ingressing your assigned device from the
untrust zone. To see log entries, you must
ensure the other team in your pod has
initiated (and exited) the Telnet session
associated with this lab part.
Step 4.10
Issue the show interfaces extensive command for the ge-0/0/3 interface.
lab@srxC-1> show interfaces extensive ge-0/0/3
Physical interface: ge-0/0/3, Enabled, Physical link is Up
Interface index: 137, SNMP ifIndex: 509, Generation: 140
Link-level type: Ethernet, MTU: 1514, Link-mode: Full-duplex, Speed: 1000mbps,
BPDU Error: None, MAC-REWRITE Error: None, Loopback: Disabled,
Source filtering: Disabled, Flow control: Enabled, Auto-negotiation: Enabled,
Remote fault: Online
Device flags : Present Running
Interface flags: SNMP-Traps Internal: 0x0
Link flags : None
CoS queues : 8 supported, 8 maximum usable queues
Hold-times : Up 0 ms, Down 0 ms
Current address: 00:26:88:02:70:83, Hardware address: 00:26:88:02:70:83
Last flapped : 2012-06-08 18:58:16 UTC (2d 19:26 ago)
Statistics last cleared: Never
Traffic statistics:
Input bytes : 146684438 0 bps
Output bytes : 141583713 0 bps
Input packets: 407769 0 pps
Lab 226 Security Policies (Detailed) www.juniper.net
Junos Security
Output packets: 395543 0 pps
Input errors:
Errors: 0, Drops: 0, Framing errors: 0, Runts: 0, Policed discards: 0,
L3 incompletes: 0, L2 channel errors: 0, L2 mismatch timeouts: 0,
FIFO errors: 0, Resource errors: 0
Output errors:
Carrier transitions: 1, Errors: 0, Drops: 0, Collisions: 0, Aged packets: 0,
FIFO errors: 0, HS link CRC errors: 0, MTU errors: 0, Resource errors: 0
Egress queues: 8 supported, 4 in use
Queue counters: Queued packets Transmitted packets Dropped packets
0 best-effort 395537 395537 0
1 expedited-fo 0 0 0
2 assured-forw 0 0 0
3 network-cont 0 0 0
Queue number: Mapped forwarding classes
0 best-effort
1 expedited-forwarding
2 assured-forwarding
3 network-control
Active alarms : None
Active defects : None
MAC statistics: Receive Transmit
Total octets 154136086 148687961
Total packets 409029 395537
Unicast packets 407893 395491
Broadcast packets 1135 46
Multicast packets 1 0
CRC/Align errors 0 0
FIFO errors 0 0
MAC control frames 0 0
MAC pause frames 0 0
Oversized frames 0
Jabber frames 0
Fragment frames 0
VLAN tagged frames 0
Code violations 0
Filter statistics:
Input packet count 0
Input packet rejects 0
Input DA rejects 0
Input SA rejects 0
Output packet count 0
Output packet pad count 0
Output packet error count 0
CAM destination filters: 2, CAM source filters: 0
Autonegotiation information:
Negotiation status: Complete
Link partner:
Link mode: Full-duplex, Flow control: None, Remote fault: OK,
Link partner Speed: 1000 Mbps
Local resolution:
Flow control: None, Remote fault: Link OK
Packet Forwarding Engine configuration:
Destination slot: 0
CoS information:
Logical interface ge-0/0/3.0 (Index 67) (SNMP ifIndex 516) (Generation 144)
Flags: SNMP-Traps 0x0 Encapsulation: ENET2
Traffic statistics:
Input bytes : 834550
Output bytes : 45741
Input packets: 3829
Output packets: 425
Local statistics:
Input bytes : 16796
Output bytes : 38756
Input packets: 299
Output packets: 306
Transit statistics:
Input bytes : 817754 0 bps
Output bytes : 6985 0 bps
Input packets: 3530 0 pps
Output packets: 119 0 pps
Security: Zone: untrust
Flow Statistics :
Flow Input statistics :
Self packets : 286
ICMP packets : 291
VPN packets : 0
Multicast packets : 0
Bytes permitted by policy : 6074
Connections established : 1
Flow Output statistics:
Multicast packets : 0
Bytes permitted by policy : 40881
Flow error statistics (Packets dropped due to):
Address spoofing: 0
Authentication failed: 0
Incoming NAT errors: 0
Invalid zone received packet: 0
Multiple user authentications: 0
Multiple incoming NAT: 0
No parent for a gate: 0
No one interested in self packets: 0
No minor session: 0
No more sessions: 0
No NAT gate: 0
No route present: 0
No SA for incoming SPI: 0
No tunnel found: 0
No session for a gate: 0
No zone or NULL zone binding 0
Policy denied: 0
Step 4.11
Return to the Telnet session established with the virtual router.
From the Telnet session established with the virtual router, issue a Telnet session to
the remote virtual router associated with your partner teams Juniper zone. But this
time, source the Telnet session from the virtual router associated with your local
ACME zone.
c1@vr-device> telnet remote-Juniper-VR routing-instance local-ACME-VR
Trying 172.20.106.10...
^C
c1@vr-device>
STOP Ensure that the remote student team within your pod has finished the
previous step before proceeding.
Step 4.12
Once this has been confirmed, return to your assigned device and issue the
show interfaces extensive command for the ge-0/0/3 interface again.
lab@srxC-1> show interfaces extensive ge-0/0/3 | find "Flow Statistics"
Flow Statistics :
Overview
In this lab, you will implement firewall user authentication. You will enable FTP access
between networks and secure the access with authentication. You will test and monitor
the effects of firewall user authentication. The configuration tasks performed within this
lab and subsequent labs will build upon one another.
The lab is available in two formats: a high-level format designed to make you think through
each step and a detailed format that offers step-by-step instructions complete with
sample output from most commands.
The lab is also designed for modularity, where you might be directed to load a starting
configuration at the beginning of each lab part. If you are completing the lab from start to
finish, there is no need to load the starting configuration for each lab part.
By completing this lab, you will perform the following tasks:
Define clients within an access profile.
Create a default client group and associate clients with the group.
Configure firewall user authentication parameters.
Add and alter security policies that have an extended permit action specifying
firewall user authentication.
Monitor the effects of your configuration using operational mode commands
and traceoptions.
In this lab part, you define clients within an access profile, create a default client
group and associate clients with the group, and configure firewall user
authentication parameters.
Step 1.1
Ensure that you know to which student device you have been assigned. Check with
your instructor if you are not certain. Consult the Management Network Diagram to
determine the management address of your student device.
Step 1.2
Access the command-line interface (CLI) at your station using either the console,
Telnet, or SSH as directed by your instructor.
Step 1.3
Log in as user lab with the password lab123. Enter configuration mode and load
the lab3-start.config from the /var/home/lab/jsec/ directory. Commit the
configuration and exit to operational mode when complete.
srxA-1 (ttyu0)
login: lab
Password:
[edit]
lab@srxA-1# load override jsec/lab3-start.config
load complete
[edit]
lab@srxA-1# commit and-quit
commit complete
Exiting configuration mode
lab@srxA-1>
Step 1.4
Navigate to the [edit access] hierarchy.
[edit]
lab@srxA-1# edit access
[edit access]
lab@srxA-1#
Step 1.5
Create an access profile named ftp-users. Configure two clients named walter
and nancy with passwords of walter123 and nancy123, respectively.
[edit access]
lab@srxA-1# edit profile ftp-users
[edit access]
lab@srxA-1# show
profile ftp-users {
client nancy {
firewall-user {
password "$9$lJ8vLNdVYZUHKMi.PfzFcyrvX7"; ## SECRET-DATA
}
}
client walter {
firewall-user {
password "$9$a1UqfTQnApB36pBREKv4aJUk.5QF"; ## SECRET-DATA
}
}
}
[edit access]
lab@srxA-1# show
profile ftp-users {
client nancy {
firewall-user {
password "$9$lJ8vLNdVYZUHKMi.PfzFcyrvX7"; ## SECRET-DATA
}
}
client walter {
firewall-user {
password "$9$a1UqfTQnApB36pBREKv4aJUk.5QF"; ## SECRET-DATA
}
}
session-options {
client-group ftp-group;
}
}
Step 1.7
Associate the ftp-users profile with pass-through firewall user authentication.
[edit access]
lab@srxA-1# edit firewall-authentication
[edit]
lab@srxA-1# edit security policies
Step 1.10
Define a security policy to allow the nancy client and walter client FTP access
from your local Juniper customer network zone to the remote student teams Juniper
customer network zone. Configure the source-address to match the address-set
for your local Juniper customer network. For your policys destination-address
match, use the existing address book entry for the remote student teams Juniper
customer network.
[edit security policies]
lab@srxA-1# edit from-zone Juniper-local to-zone untrust policy
outbound-ftp-auth
Step 1.12
Insert the outbound-ftp-auth policy before the deny-ftp-Juniper-local
policy.
[edit security policies from-zone Juniper-SV to-zone untrust]
lab@srxA-1# insert policy outbound-ftp-auth before policy
deny-ftp-Juniper-local
Step 1.15
Commit your configuration and return to operational mode.
[edit security policies from-zone untrust to-zone Juniper-SV]
lab@srxA-1# commit and-quit
commit complete
Exiting configuration mode
lab@srxA-1>
STOP Do NOT continue to the next lab part until both teams within your
assigned pod have reached this point.
In this lab part, you verify the results of your configuration through testing. You will
also monitor firewall user authentication using traceoptions and operational mode
commands.
Step 2.1
Enter configuration mode, or go to the top of the configuration hierarchy if you are
already in configuration mode, and load the lab3-part2-start.config from
the /var/home/lab/jsec/ directory. Commit the configuration when complete.
[edit]
lab@srxA-1# load override jsec/lab3-part2-start.config
load complete
[edit]
lab@srxA-1# commit
commit complete
Step 2.2
Note
This lab step requires you to open a
separate Telnet session to the virtual router
to emulate an external host.
Keep the current Telnet session
established with your assigned SRX device
open to monitor results.
The virtual router is a J Series Services
Router configured as several logical
devices. Refer to the Management Network
Diagram for the IP address of the vr-device.
Open a separate Telnet session to the virtual router attached to your team device.
vr-device (ttyd0)
login: username
Password:
NOTE: This router is divided into many virtual routers used by different teams.
Please only configure your own virtual router.
a1@vr-device>
Step 2.4
From the Telnet session established with the virtual router, initiate an FTP session
between the virtual router associated with your local Juniper customer network zone
and the virtual router associated with the remote student teams Juniper customer
network zone. Note that the ftp command is hidden and does not auto-complete.
Remember to source the command from the appropriate routing instance. When
prompted for firewall user authentication, use the credentials you created for the
user nancy.
a1@vr-device> ftp remote-Juniper-VR routing-instance local-Juniper-VR
Connected to 172.20.108.10.
220 Junos Rocks!
Name (172.20.108.10:d1): nancy
331 Password Required
Password:
Authentication - Accepted (Closed connection - reconnect to server)
ftp: Login failed.
421 Service not available, remote server has closed connection.
ftp>
Note
If you test the FTP connection multiple
times, the remote student device will need
to clear out the firewall authentication user
session by issuing the operational-mode
command clear security
firewall-authentication users.
Step 2.5
Note
Check with the remote team in your pod
and ensure they have completed the
previous step.
Return to the Telnet session established with your assigned SRX device.
From the Telnet session established with your assigned SRX device, issue the show
security firewall-authentication users command.
lab@srxA-1> show security firewall-authentication users
Firewall authentication data:
Total users in table: 1
Id Source Ip Src zone Dst zone Profile Age Status User
3 172.20.102.10 untrust Juniper-SV ftp-user 1 Success nancy
ftp> bye
Step 2.7
Leave the current session with the vr-device open and open a second session to the
vr-device using Telnet. Refer to the Management Network Diagram as needed.
vr-device (ttyp1)
login: username
Password:
NOTE: This router is divided into many virtual routers used by different teams.
Please only configure your own virtual router.
a1@vr-device>
Step 2.8
Attempt another FTP session using the same procedure. This time, use the walter
username for firewall authentication and log into the FTP server with your vr-device
credentials.
a1@vr-device> ftp remote-Juniper-VR routing-instance local-Juniper-VR
Connected to 172.20.102.10.
220 vr-device FTP server (Version 6.00LS) ready.
Name (172.20.102.10:a1): walter
331 Password required for walter.
Password:
530 Login incorrect.
ftp: Login failed.
ftp> bye
221 Goodbye.
Step 2.9
Exit both FTP sessions and close the second session you opened to the vr-device.
ftp> bye
a1@vr-device>
ftp> bye
a1@vr-device> exit
Lab 316 Configuring Firewall Authentication (Detailed) www.juniper.net
Junos Security
Step 2.10
Return to the Telnet session established with your assigned SRX device.
From the Telnet session established with your assigned SRX device, clear the entries
in the firewall authentication users table, if any exist.
lab@srxA-1> clear security firewall-authentication users
Return to the Telnet session established with your assigned SRX device.
From the Telnet session established with your assigned SRX device, issue the show
security firewall-authentication users command followed by the
show security firewall-authentication history command.
Step 2.14
View the firewall user authentication entries in your data plane log by issuing the
show log messages | match RT_AUTH command.
Note
If the remote team has not performed the
required verification tasks, you will not see
any logs. To view log entries from the
remote device, reference the name of the
remote device instead of your devices
name in the previous sample command.
Overview
In this lab, you will implement the Junos operating system Screen options. You will set up
various Screens to protect your assigned device from suspicious or malicious traffic
entering your device from the untrust zone.
The lab is available in two formats: a high-level format designed to make you think through
each step and a detailed format that offers step-by-step instructions complete with
sample output from most commands.
The lab is also designed for modularity, where you might be directed to load a starting
configuration at the beginning of each lab part. If you are completing the lab from start to
finish, there is no need to load the starting configuration for each lab part.
By completing this lab, you will perform the following tasks:
Define various Screen options (called ids-options).
Associate the Screen with a security zone.
Test your your implementation.
Monitor the effects of your configuration.
In this lab part, you become familiar with the access details used to access the lab
equipment. Once you are familiar with the access details, you will use the CLI to log
in to your designated station. Then, you will load the starting configuration for Lab 4.
Then, In this lab part, you will configure Screen protection.
Note
Depending on the class, the lab equipment
used might be remote from your physical
location. The instructor will inform you as to
the nature of your access and will provide
you the details needed to access your
assigned device.
Step 1.1
Ensure that you know to which student device you have been assigned. Check with
your instructor if you are not certain. Consult the Management Network Diagram to
determine the management address of your student device.
Step 1.2
Access the CLI at your station using either the console, Telnet, or SSH as directed by
your instructor. Refer to the Management Network Diagram for the IP address
associated with your workstation. The following example is based on simple Telnet
access using the Secure CRT program.
login: lab
Password:
[edit]
lab@srxC-1# load override jsec/lab4-start.config
[edit]
lab@srxC-1# commit
commit complete
[edit]
lab@srxC-1#
Step 1.4
Navigate to the [edit security screen] hierarchy.
[edit]
lab@srxC-1# edit security screen
Step 1.7
Add protection from packets that are using the IP Record Route option to the
internet-protect Screen.
[edit security screen]
lab@srxC-1# set ids-option internet-protect ip record-route-option
STOP Before proceeding, ensure that the remote team within your pod is
ready to continue on to Part 2.
In this lab part, you verify the results of your Screen configuration
Note
The next lab steps require you to log in to
the virtual router attached to your teams
device. The virtual routers are logical
devices created on a J Series Services
Router. Refer to the Management Network
Diagram for the IP address of the vr-device.
Step 2.1
Enter configuration mode, or go to the top of the configuration hierarchy if you are
already in configuration mode, and load the lab4-part2-start.config from
the /var/home/lab/jsec/ directory. Commit the configuration when complete.
[edit security screen]
lab@srxC-1# top
[edit]
lab@srxC-1# load override jsec/lab4-part2-start.config
[edit]
lab@srxC-1# commit
commit complete
[edit]
lab@srxC-1#
Step 2.3
Log in to the vr-device using the login information shown in the following table:
vr-device (ttyp0)
login: username
Password:
NOTE: This router is divided into many virtual routers used by different teams.
Please only configure your own virtual router.
c1@vr-device>
Step 2.5
Issue the same ping request again, but this time specify a size of 1100 bytes. This
size is larger than 1024 bytes and should trigger the ICMP large Screen option,
provided the remote team properly configured it on their device.
c1@vr-device> ping remote-Juniper-VR routing-instance local-Juniper-VR rapid
size 1100
PING 172.20.106.10 (172.20.106.10): 1100 data bytes
!!!!!
--- 172.20.106.10 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 4.291/4.762/5.371/0.359 ms
Step 2.6
Return to the Telnet session established with your assigned SRX device.
From the Telnet session established with assigned SRX device, apply the
internet-protect Screen option to the untrust security zone. Commit your
configuration and exit configuration mode.
[edit]
lab@srxC-1# edit security zones security-zone untrust
lab@srxC-1>
STOP Ensure that the remote student team within your pod has finished the
previous step before proceeding.
Step 2.8
Determine the physical maximum transmission unit (MTU) of your virtual routers
interface (associated with the your local Juniper zone) that connects to your
assigned device by issuing the show interfaces ge-0/0/1 media |
match mtu command.
c1@vr-device> show interfaces ge-0/0/1 media | match mtu
Link-level type: Ethernet, MTU: 1518, Link-mode: Full-duplex, Speed: 1000mbps,
BPDU Error: None, MAC-REWRITE Error: None,
Step 2.9
Issue another ping between the virtual routers associated with the
Juniper-local and Juniper-remote security zones. This time specify a size
of 2000 bytes, ensuring ICMP packet fragmentation occurs. Do not forget to source
the ping from the proper routing instance!
c1@vr-device> ping remote-Juniper-VR routing-instance local-Juniper-VR rapid
size 2000
PING 172.20.106.10 (172.20.106.10): 2000 data bytes
Step 2.10
Issue another ping between the virtual routers associated with the
Juniper-local and Juniper-remote security zones. This time specify the
record-route option.
c1@vr-device> ping remote-Juniper-VR routing-instance local-Juniper-VR rapid
record-route
PING 172.20.106.10 (172.20.106.10): 56 data bytes
.....
--- 172.20.106.10 ping statistics ---
5 packets transmitted, 0 packets received, 100% packet loss
Step 2.11
Within your current vr-device Telnet session, open a new Telnet session to the
remote virtual router associated with the Juniper-local and
Juniper-remote security zones. Use the same login credentials as used for your
current vr-device Telnet session.
Note
Remember to reference the appropriate
instance name when sourcing Telnet traffic
from a virtual router. The instance names
match the names of the virtual routers
listed on the network diagram.
vr-device (ttyp0)
login: username
Password:
NOTE: This router is divided into many virtual routers used by different teams.
Please only configure your own virtual router.
c1@vr-device>
Step 2.12
Open a new, separate Telnet session to the vr-device.
vr-device (ttyd0)
login: username
Password:
NOTE: This router is divided into many virtual routers used by different teams.
Please only configure your own virtual router.
c1@vr-device>
Step 2.14
Within the new vr-device session, attempt to open a second Telnet connection
between the virtual routers associated with the Juniper-local and
Juniper-remote security zones.
Note
Remember to reference the appropriate
instance name when sourcing Telnet traffic
from a virtual router. The instance names
match the names of the virtual routers
listed on the network diagram.
Note
Leave both Telnet sessions opened to the
vr-device for the time being. You return to
these sessions in the next part of the lab.
STOP Before proceeding, ensure that the remote team within your pod is
ready to continue on to Part 3.
In this lab part, you monitor the effects of Screen protection. You must coordinate
some of the monitoring efforts with the remote student team in your pod.
Step 3.1
Return to the Telnet session established with your assigned SRX device.
From the Telnet session established with assigned SRX device, enter configuration
mode, or go to the top of the configuration hierarchy if you are already in
configuration mode, and load the lab4-part3-start.config from the
/var/home/lab/jsec/ directory. Commit the configuration when complete.
[edit security screen]
lab@srxC-1# top
[edit]
lab@srxC-1# load override jsec/lab4-part3-start.config
[edit]
lab@srxC-1# commit
commit complete
[edit]
lab@srxC-1#
Step 3.2
Issue the run show security screen statistics zone untrust
command and review the output.
[edit]
lab@srxC-1# run show security screen statistics zone untrust
Step 3.3
View the Screen option entries in your log by issuing the
run show log messages | match RT_SCREEN command.
[edit]
lab@srxC-1# run show log messages | match RT_SCREEN
Nov 5 14:22:21 srxC-1 RT_IDS: RT_SCREEN_SESSION_LIMIT: Dst IP session limit!
destination: 172.20.107.10, zone name: untrust, interface name: ge-0/0/3.0
Step 3.4
Delete the Screen option internet-protect from the [edit security
zone security-zone untrust] configuration hierarchy. Commit the
configuration and return to operational mode.
[edit]
lab@srxC-1# edit security zones security-zone untrust
lab@srxC-1>
STOP Ensure that the remote student team within your pod has finished the
previous step before proceeding.
Step 3.5
Return to the Telnet sessions established with the virtual router.
From the Telnet sessions established with the virtual router, attempt to open two
Telnet sessions between the virtual routers associated with the Juniper-local
and Juniper-remote zones again. You must re-establish sessions if any of your
sessions timed out.
Note
Remember to reference the appropriate
instance name when sourcing Telnet traffic
from a virtual router. The instance names
match the names of the virtual routers
listed on the network diagram.
vr-device (ttyp0)
login: username
Password:
NOTE: This router is divided into many virtual routers used by different teams.
Please only configure your own virtual router.
c1@vr-device>
login: username
Password:
NOTE: This router is divided into many virtual routers used by different teams.
Please only configure your own virtual router.
c1@vr-device>
c1@vr-device> exit
Note
At this point, you should have only one
Telnet session opened to the vr-device.
Step 3.7
Return to the remaining Telnet session that is established with the virtual router.
From the remaining Telnet session established with the virtual router, type exit to
end the Telnet session between the remote virtual routers.
c1@vr-device> exit
c1@vr-device>
Step 3.8
Attempt to ping between the remote virtual routers associated with the
Juniper-local and Juniper-remote zones. Specify a size of 2000 bytes.
Note
Remember to reference the appropriate
instance name when sourcing Telnet traffic
from a virtual router. The instance names
match the names of the virtual routers
listed on the network diagram.
Overview
In this lab, you will implement Network Address Translation (NAT). You will configure and
monitor both source and destination NAT, including pool-based NAT and interface-based
NAT.
The lab is available in two formats: a high-level format designed to make you think through
each step and a detailed format that offers step-by-step instructions complete with
sample output from most commands.
The lab is also designed for modularity, where you might be directed to load a starting
configuration at the beginning of each lab part. If you are completing the lab from start to
finish, there is no need to load the starting configuration for each lab part.
By completing this lab, you will perform the following tasks:
Configure and monitor interface-based source NAT.
Configure and monitor pool-based destination NAT.
Configure and monitor pool-based source NAT.
Configure and verify proxy ARP.
In this lab part, you enable interface-based source NAT. Traffic originating from the
virtual routers attached to your assigned device and destined for the Internet host
will be subject to NAT.
Step 1.1
Ensure that you know to which student device you have been assigned. Check with
your instructor if you are not certain. Consult the Management Network Diagram to
determine the management address of your student device.
Step 1.2
Access the command-line interface (CLI) at your station using either the console,
Telnet, or SSH as directed by your instructor.
Step 1.3
Log in as user lab with the password lab123. Enter configuration mode and load
the lab5-start.config from the /var/home/lab/jsec/ directory. Commit the
configuration when complete.
srxD-1 (ttyu0)
login: lab
Password:
[edit]
lab@srxD-1# load override jsec/lab5-start.config
load complete
[edit]
lab@srxD-1# commit
commit complete
[edit]
lab@srxD-1#
Step 1.4
Navigate to the [edit security nat source] hierarchy.
[edit]
lab@srxD-1# edit security nat source
lab@srxD-1>
Note
The next lab steps require you to log in to
the virtual router attached to your teams
device. The virtual routers are logical
devices created on a J Series Services
Router. Refer to the Management Network
Diagram for the IP address of the vr-device.
Step 1.8
Open a separate Telnet session to the virtual router attached to your team device.
Lab 54 Network Address Translation (Detailed) www.juniper.net
Junos Security
Step 1.9
Log in to the virtual router using the login information shown in the following table:
Virtual Router Login Details
vr-device (ttyd0)
login: username
Password:
NOTE: This router is divided into many virtual routers used by different teams.
Please only configure your own virtual router.
d1@vr-device>
vr-device (ttyp0)
login: username
Password:
NOTE: This router is divided into many virtual routers used by different teams.
Please only configure your own virtual router.
d1@vr-device>
Step 1.11
Return to the Telnet session established with your assigned SRX device.
From the Telnet session established with your assigned SRX device, view the session
table.
lab@srxD-1> show security flow session
Session ID: 58859, Policy name: internet-Juniper-SV/10, Timeout: 1118, Valid
In: 172.20.107.10/65026 --> 172.31.15.1/23;tcp, If: ge-0/0/4.107, Pkts: 27,
Bytes: 1567
Out: 172.31.15.1/23 --> 172.18.1.2/23879;tcp, If: ge-0/0/3.0, Pkts: 22, Bytes:
1596
Total sessions: 1
Step 1.12
Issue the show security nat source rule all command and answer the
question that follows.
Step 1.13
Return to the Telnet session established with the virtual router.
From the Telnet session established with the virtual router, exit the extra Telnet
session using the exit command.
d1@vr-device> exit
d1@vr-device>
In this lab part, you configure pool-based destination NAT for traffic originating from
the remote device in your assigned pod. You will use the loopback IP address of your
assigned device as a public address that will be translated to an internal address
belonging to a virtual router attached to your device.
Step 2.1
If necessary, return to your assigned SRX device.
From your assigned SRX device, enter configuration mode, or go to the top of the
configuration hierarchy if you are already in configuration mode, and load the
lab5-part2-start.config from the /var/home/lab/jsec/ directory. Commit
the configuration when complete.
www.juniper.net Network Address Translation (Detailed) Lab 57
Junos Security
[edit]
lab@srxD-1# load override jsec/lab5-part2-start.config
load complete
[edit]
lab@srxD-1# commit
commit complete
Step 2.2
Navigate to the [edit security nat destination] hierarchy.
[edit]
lab@srxD-1# edit security nat destination
Step 2.6
In the next two steps, you will create a security policy to allow traffic from the remote
student team destined to your local ACME customer network. Navigate to the [edit
security policy from-zone untrust to-zone ACME-local]
configuration hierarchy.
[edit security nat destination]
lab@srxD-1# top edit security policies from-zone untrust to-zone ACME-local
STOP Before proceeding, ensure that the remote student team within your
pod is ready to continue on to the next step.
When both teams in your assigned pod finish performing the above configuration,
attempt a Telnet session to the loopback IP address of your remote teams device.
Initiate this Telnet session from your assigned SRX Series device. When prompted
for a login, use the login information shown in the following table:
vr-device (ttyp0)
login: username
Password:
NOTE: This router is divided into many virtual routers used by different teams.
Please only configure your own virtual router.
d1@vr-device>
Step 2.10
Open a second Telnet session to your assigned device for monitoring the sessions in
progress. Log in as user lab.
srxD-1 (ttyp0)
login: lab
Password:
Step 2.12
Issue the show security nat destination pool all command and
answer the question that follows.
lab@srxD-1> show security nat destination pool all
Total destination-nat pools: 1
Step 2.13
Return to the initial session established with your assigned SRX device.
From the initial session established with your assigned SRX device, exit the Telnet
session opened with the remote virtual router.
d1@vr-device> exit
lab@srxD-1>
In this lab part, you configure pool-based source NAT between the virtual routers
attached to your assigned device. You will enable an overflow pool should the source
NAT pool become exhausted.
Step 3.1
If necessary, return to your assigned SRX device.
From your assigned SRX device, enter configuration mode, or go to the top of the
configuration hierarchy if you are already in configuration mode, and load the
lab5-part3-start.config from the /var/home/lab/jsec/ directory. Commit
the configuration when complete.
[edit]
lab@srxD-1# load override jsec/lab5-part3-start.config
load complete
[edit]
lab@srxD-1# commit
commit complete
Step 3.2
Navigate to the [edit security nat source] configuration hierarchy.
[edit]
lab@srxD-1# edit security nat source
lab@srxD-1>
Step 3.11
Open a separate Telnet session to the virtual router attached to your team device.
Step 3.12
Log in to the virtual router using the login information shown in the following table:
Virtual Router Login Details
vr-device (ttyd0)
login: username
Password:
d1@vr-device>
Step 3.13
From the Telnet session established with the virtual router, initiate a Telnet session
between the virtual routers attached to your assigned device in either direction. Use
the same login credentials used in the previous step.
Note
Remember to reference the appropriate
instance name when sourcing Telnet traffic
from a virtual router. The instance names
match the names of the virtual routers
listed on the network diagram.
Step 3.14
Return to the Telnet session established with your assigned SRX device.
From the Telnet session established with your assigned SRX device, issue the show
security flow session command and answer the questions that follow.
lab@srxD-1> show security flow session
Session ID: 64720, Policy name: Juniper-to-ACME/13, Timeout: 8, Valid
In: 172.20.107.10/55688 --> 172.20.207.10/23;tcp, If: ge-0/0/4.107, Pkts: 5,
Bytes: 288
Out: 172.20.207.10/23 --> 172.20.207.2/55688;tcp, If: ge-0/0/4.207, Pkts: 0,
Bytes: 0
Total sessions: 1
Note
Because the TCP three-way handshake
does not complete, the session only shows
in the session table for a few seconds. If
you do not see the session, try issuing the
Telnet command on the vr-device,
immediately followed by the
show security flow session
command on your assigned device.
Step 3.15
Enter configuration mode and navigate to the [edit security nat
proxy-arp] configuration hierarchy.
lab@srxD-1> configure
Entering configuration mode
[edit]
lab@srxD-1# edit security nat proxy-arp
lab@srxD-1>
Step 3.18
Return to the Telnet session established with the virtual router.
From the Telnet session established with the virtual router, attempt to establish a
Telnet session between the virtual routers once again.
Note
Remember to reference the appropriate
instance name when sourcing Telnet traffic
from a virtual router. The instance names
match the names of the virtual routers
listed on the network diagram.
vr-device (ttyp0)
login: username
Password:
d1@vr-device>
Step 3.19
Return to the terminal session connected to your assigned device and issue the
show security flow session command.
lab@srxD-1> show security flow session
Session ID: 65071, Policy name: Juniper-to-ACME/13, Timeout: 1740, Valid
In: 172.20.107.10/65306 --> 172.20.207.10/23;tcp, If: ge-0/0/4.107, Pkts: 28,
Bytes: 1631
Out: 172.20.207.10/23 --> 172.20.207.5/65306;tcp, If: ge-0/0/4.207, Pkts: 22,
Bytes: 1596
Total sessions: 1
Total rules: 3
Rule name Rule set From To Action
1 internet-bound ge-0/0/4.107 untrust interface
1 ge-0/0/4.207
Juniper-to-ACME vr107 Juniper-SV ACME-SV vr107
ACME-to-Juniper vr207 ACME-SV Juniper-SV vr207
Step 3.21
Issue the show security nat source pool all command.
lab@srxD-1> show security nat source pool all
Total pools: 2
Step 3.22
Return to the session opened to the vr-device and exit the Telnet session between
virtual routers.
d1@vr-device> exit
d1@vr-device>
Overview
In this lab, you will implement a route-based IPsec VPN. You will configure and monitor the
IKE phase one and phase two tunnel establishment.
The lab is available in two formats: a high-level format designed to make you think through
each step and a detailed format that offers step-by-step instructions complete with
sample output from most commands.
By completing this lab, you will perform the following tasks:
Configure a route-based IPsec VPN.
Alter security policies to allow traffic between the ACME security zones.
Configure and monitor a secure tunnel interface.
Verify and monitor an IPsec VPN tunnel.
In this lab part, you configure a route-based IPsec VPN tunnel. This IPsec VPN tunnel
will be utilized for all traffic between the ACME customer security zones.
Step 1.1
Ensure that you know to which student device you have been assigned. Check with
your instructor if you are not certain. Consult the Management Network Diagram to
determine the management address of your student device.
Step 1.2
Access the command-line interface (CLI) at your station using either the console,
Telnet, or SSH as directed by your instructor.
Step 1.3
Log in as user lab with the password lab123. Enter configuration mode and load
the lab6-start.config from the /var/home/lab/jsec/ directory. Commit the
configuration and exit to operational mode when complete.
srxD-1 (ttyu0)
login: lab
Password:
[edit]
lab@srxD-1# load override jsec/lab6-start.config
load complete
[edit]
lab@srxD-1# commit and-quit
commit complete
Exiting configuration mode
lab@srxD-1>
Step 1.4
Navigate to the [edit interfaces] configuration hierarchy.
[edit]
lab@srxD-1# edit interfaces
[edit interfaces]
lab@srxD-1#
Step 1.5
Configure a secure tunnel interface. If your assigned device is srx1, configure logical
unit 0 with an IP address of 192.168.100.1. If your assigned device is srx2,
configure logical unit 0 with an IP address of 192.168.100.2.
[edit interfaces]
lab@srxD-1# set st0 unit 0 family inet address tunnel-interface-address
Step 1.6
Add the st0.0 interface to the untrust security zone, and allow the interface to
accept IKE packets.
[edit interfaces]
lab@srxD-1# top set security zones security-zone untrust interfaces st0.0
[edit interfaces]
lab@srxD-1# top set security zones security-zone untrust interfaces st0.0
host-inbound-traffic system-services ike
Step 1.7
Navigate to the [edit security ike] configuration hierarchy. Create an
Internet Key Exchange (IKE) phase 1 proposal named phase1. The proposal should
use the following parameters:
Authentication method: pre-shared-keys;
dh-group: group2;
authentication algorithm: md5;
encryption algorithm: 3des-cbc; and
lifetime: 86400.
[edit security]
lab@srxD-1# edit ipsec
[edit routing-options]
lab@srxD-1# set static route remote-ACME-subnet next-hop st0.0
[edit routing-options]
lab@srxD-1# show
static {
route 0.0.0.0/0 next-hop 172.18.1.1;
route 172.20.208.0/24 next-hop st0.0;
}
Question: What are the two valid next hops for this
static route?
Step 1.15
Navigate to the [edit security policies] configuration hierarchy. Review
the security policies in place that allow traffic between the untrust zone and your
local ACME customer network zone.
[edit routing-options]
lab@srxD-1# top edit security policies
Step 1.16
Create a new security policy that permits traffic from the untrust zone destined to
your local ACME customer zone. Name the security policy ipsec. Configure the
source-address to match the address-book entry for the remote student teams
ACME customer network. Use the configuration option any for the destination
address and application. When finished review the configuration, and answer the
question below.
[edit security policies]
lab@srxD-1# edit from-zone untrust to-zone ACME-local
Step 1.17
Commit your configuration and return to operational mode.
[edit security policies from-zone untrust to-zone ACME-SV]
lab@srxD-1# commit and-quit
commit complete
Exiting configuration mode
lab@srxD-1>
STOP Do NOT continue to the next lab part until both teams within your
assigned pod reach this point.
In this lab part, you check IKE phase one and phase two tunnel security associations
and monitor the IPsec VPN on your assigned device by initiating traffic from the
virtual router.
Step 2.1
Issue the show interfaces st0 terse command.
lab@srxD-1> show interfaces st0 terse
Interface Admin Link Proto Local Remote
st0 up up
st0.0 up up inet 192.168.100.1 --> 0/0
Step 2.2
Check the state of the IKE phase 1 security association using the show security
ike security-associations command.
lab@srxD-1> show security ike security-associations
Index State Initiator cookie Responder cookie Mode Remote Address
976176 UP f347d504ef032fcc fed0a0e871ade192 Main 172.18.2.2
Step 2.3
Check the state of the phase 2 security association using the show security
ipsec security-associations command.
lab@srxD-1> show security ipsec security-associations
Total active tunnels: 1
ID Algorithm SPI Life:sec/kb Mon vsys Port Gateway
<131073 ESP:3des/md5 768fe3ba 3106/ unlim - root 500 172.18.2.2
>131073 ESP:3des/md5 e9444a8e 3106/ unlim - root 500 172.18.2.2
Step 2.4
Issue the show security ipsec security-associations index
number command, where number represents the index number obtained in the
previous step.
lab@srxD-1> show security ipsec security-associations index index-number
Virtual-system: root
Local Gateway: 172.18.1.2, Remote Gateway: 172.18.2.2
Local Identity: ipv4_subnet(any:0,[0..7]=0.0.0.0/0)
Remote Identity: ipv4_subnet(any:0,[0..7]=0.0.0.0/0)
Version: IKEv1
DF-bit: clear
Direction: inbound, SPI: 768fe3ba, AUX-SPI: 0
, VPN Monitoring: -
Hard lifetime: Expires in 3042 seconds
Lifesize Remaining: Unlimited
Soft lifetime: Expires in 2464 seconds
Mode: Tunnel, Type: dynamic, State: installed
Protocol: ESP, Authentication: hmac-md5-96, Encryption: 3des-cbc
Anti-replay service: counter-based enabled, Replay window size: 64
Step 2.5
Issue the clear security ipsec statistics command followed by the
show security ipsec statistics command.
lab@srxD-1> clear security ipsec statistics
Step 2.6
Note
This lab step requires you to open a
separate Telnet session to the virtual router
to emulate an external host.
Keep the current Telnet session
established with your assigned SRX device
open to monitor results.
The virtual router is a J Series Services
Router configured as several logical
devices. Refer to the Management Network
Diagram for the IP address of the vr-device.
Open a separate Telnet session to the virtual router attached to your team device.
Step 2.7
Log in to the virtual router using the login information shown in the following table:
vr-device (ttyd0)
login: username
Password:
NOTE: This router is divided into many virtual routers used by different teams.
Please only configure your own virtual router.
d1@vr-device>
vr-device (ttyp1)
login:
Step 2.9
Return to the Telnet session established with your assigned SRX device.
From the Telnet session established with your assigned SRX device, view the flow
session table.
lab@srxD-1> show security flow session
Session ID: 1, Policy name: N/A, Timeout: N/A, Valid
In: 172.18.2.2/33021 --> 172.18.1.2/5392;esp, If: ge-0/0/3.0, Pkts: 0, Bytes:
0
Step 2.10
Issue the show security ipsec statistics command.
lab@srxD-1> show security ipsec statistics
ESP Statistics:
Encrypted bytes: 3496
Decrypted bytes: 1706
Encrypted packets: 32
Decrypted packets: 24
AH Statistics:
Input bytes: 0
Output bytes: 0
Input packets: 0
Output packets: 0
Errors:
AH authentication failures: 0, Replay errors: 0
ESP authentication failures: 0, ESP decryption failures: 0
Bad headers: 0, Bad trailers: 0
Step 2.11
Return to the Telnet session established with the virtual router.
From the Telnet session established with the virtual router, exit the virtual router
Telnet session using the exit command.
d1@vr-device> exit
d1@vr-device>
Overview
In this lab, you will implement intrusion detection and prevention (IDP). You will install the
security package from Juniper Networks, customize a policy template and perform
verification tasks.
The lab is available in two formats: a high-level format designed to make you think through
each step and a detailed format that offers step-by-step instructions complete with
sample output from most commands.
The lab is also designed for modularity, where you might be directed to load a starting
configuration at the beginning of each lab part. If you are completing the lab from start to
finish, there is no need to load the starting configuration for each lab part.
By completing this lab, you will perform the following tasks:
Install and verify IDP licensing.
Install and verify the Juniper Networks security package, including the attack
database and IDP policy templates.
Configure and customize IDP policy using IDP policy templates.
Verify and monitor the IDP implementation.
Part 1: Retrieving and Installing the Security Package and IDP License
In this lab part, you become familiar with the access details used to access the lab
equipment. Once you are familiar with the access details, you will use the CLI to log
in to your designated station. Then, you will load the starting configuration for Lab 7.
Then, you will download the security package normally made available by Juniper
Networks as well as the necessary IDP licensing.
Note
Depending on the class, the lab equipment
used might be remote from your physical
location. The instructor will inform you as to
the nature of your access and will provide
you the details needed to access your
assigned device.
Step 1.1
Ensure that you know to which student device you have been assigned. Check with
your instructor if you are not certain. Consult the Management Network Diagram to
determine the management address of your student device.
Step 1.2
Access the CLI at your station using either the console, Telnet, or SSH as directed by
your instructor. Refer to the Management Network Diagram for the IP address
associated with your workstation. The following example is based on simple Telnet
access using the Secure CRT program.
Step 1.3
Log in as user lab with the password lab123. Enter configuration mode and load
the lab7-start.config from the /var/home/lab/jsec/ directory. Commit the
configuration when complete.
srxC-1 (ttyu0)
login: lab
Password:
[edit]
lab@srxC-1# load override jsec/lab7-start.config
[edit]
lab@srxC-1# commit
commit complete
[edit]
lab@srxC-1#
Note
This lab requires that you have root access
in the UNIX shell of the device. In the next
few steps, you change the root password of
your assigned device. Be sure to follow the
steps closely to avoid disabling access to
the device.
[edit]
lab@srxD-1#
Step 1.5
Commit your configuration and return to operational mode.
[edit]
lab@srxD-1# commit and-quit
commit complete
Exiting configuration mode
lab@srxD-1>
Note
In the next series of lab steps, you obtain
an IDP license and the IDP security
package from the server within your
assigned lab rack. Because of differing lab
environments, you obtain these files
unconventionally. In a non-lab environment,
you obtain the license directly from Juniper
Networks while you download the security
package directly from Juniper Networks
using an Internet connection.
Step 1.6
Enter the UNIX shell mode of your assigned device with the start shell
command.
lab@srxD-1> start shell
%
Step 1.7
At the % prompt type su root to switch the user to the root user. This level of
permissions is necessary for the next few steps. When prompted for the new
password, use the lab123 password you just defined in the configuration.
% su root
Password:
root@srxD-1%
Step 1.8
Change your working directory to /var/tmp by entering the cd /var/tmp
command at the % prompt.
Note
Be sure to include the trailing period in the
command. The period in this command
instructs SCP to copy the remote files to
your current working directory.
root@srxD-1% ls sec-download/sub-download
root@srxD-1%
Note
Be sure to include the trailing period in the
command. The period in this command
instructs SCP to copy the remote files to
your current working directory.
Step 1.15
Exit the UNIX shell by issuing the exit command twice.
root@srxD-1% exit
exit
% exit
exit
lab@srxD-1>
In this lab part, you install the license required for the IDP attack database and
policy template updates. After verifying the validity of the license, you will then
proceed with the installation of the IDP security package and policy templates.
Step 2.1
Issue the show system license command to list the installed licenses on your
assigned device.
lab@srxD-1> show system license
License usage: none
Step 2.2
Install the IDP license you downloaded in the last lab part by using the
request system license add command. Specify the file as
/var/tmp/assigned-device.txt, where assigned-device represents
the hostname of your assigned device.
lab@srxD-1> request system license add /var/tmp/assigned-device.txt
JUNOS204211: successfully added
add license complete (no errors)
Step 2.3
View the active licenses on your assigned device using the
show system license command.
Note
The output shown for this command can
vary depending on the device or license
type used in your environment.
Licenses installed:
License identifier: JUNOS220951
License version: 2
Valid for device: AH2909AA0068
Features:
idp-sig - IDP Signature
date-based, 2009-09-15 19:00:00 CDT - 2014-09-03 19:00:00 CDT
Step 2.5
Check the status of your installation over the next few minutes using the
request security idp security-package install status
command. Do not continue to the next step until you receive an indication that the
installation was successful.
lab@srxD-1> request security idp security-package install status
In progress:performing DB update for an xml (groups.xml)
lab@srxD-1> configure
Entering configuration mode
[edit]
lab@srxD-1# set system scripts commit file templates.xsl
[edit]
lab@srxD-1# commit
commit complete
[edit]
lab@srxD-1#
Step 2.9
Verify that the policy templates were added to your configuration. You could view the
configuration file for verification, but for a quicker check, issue the
set security idp active-policy ? configuration mode command.
[edit]
lab@srxD-1# set security idp active-policy ?
Possible completions:
<active-policy> Set active policy
DMZ_Services
DNS_Service
In this lab part, you customize the Recommended policy template and apply the
modified policy to your assigned device.
Step 3.1
Navigate to the [edit security idp] configuration hierarchy.
[edit]
lab@srxD-1# edit security idp
Note
For specific information regarding
predefined attacks or attack groups,
consult the following link:
https://services.netscreen.com/restricted/
sigupdates/nsm-updates/HTML/
index.html
Step 3.4
Delete all of the rules, except rule 3, from the Recommended IDP policy.
[edit security idp]
lab@srxD-1# delete idp-policy Recommended rulebase-ips rule 1
[edit]
lab@srxD-1# delete system scripts
[edit]
lab@srxD-1# commit and-quit
commit complete
Exiting configuration mode
lab@srxD-1>
Step 3.8
Issue the show security policies policy-name webserver detail
command.
lab@srxD-1> show security policies policy-name webserver detail
Policy: webserver, action-type: permit, State: enabled, Index: 12, Scope Policy:
0
Policy Type: Configured
Sequence number: 1
From zone: untrust, To zone: ACME-SV
Source addresses:
srxD-2: 172.18.2.0/30
Destination addresses:
vr207: 172.20.207.0/24
Application: junos-telnet
IP protocol: tcp, ALG: 0, Inactivity timeout: 1800
Step 3.9
View the memory allocation for IDP services using the
show security idp memory command.
lab@srxD-1> show security idp memory
Step 3.10
Check the version of the attack database currently installed on your assigned device
using the show security idp security-package-version command.
lab@srxD-1> show security idp security-package-version
Attack database version:2125(Thu Apr 26 12:37:13 2012)
Detector version :12.6.160120404
Policy template version :N/A
Overview
In this lab, you will implement high availability chassis clustering. You will work with the
remote team in your pod to combine your assigned devices into a single chassis cluster.
You will then generate traffic flows from the attached virtual routers. You will monitor the
traffic flows to determine the path taken through the chassis cluster.
The lab is available in two formats: a high-level format designed to make you think through
each step and a detailed format that offers step-by-step instructions complete with
sample output from most commands.
The lab is also designed for modularity, where you might be directed to load a starting
configuration at the beginning of each lab part. If you are completing the lab from start to
finish, there is no need to load the starting configuration for each lab part.
By completing this lab, you will perform the following tasks:
Use the Junos command-line interface (CLI) to load the baseline configuration.
Build the chassis cluster.
Configure an active/active chassis cluster.
Monitor traffic flows through the chassis cluster.
Disable the chassis cluster.
In this lab part, you become familiar with the access details used to access the lab
equipment. Once you are familiar with the access details, you will use the CLI to log
in to your designated station. Then, you will load the starting configuration for Lab 8.
Note
Depending on the class, the lab equipment
used might be remote from your physical
location. The instructor will inform you as to
the nature of your access and will provide
you the details needed to access your
assigned device.
Step 1.1
Ensure that you know to which student device you have been assigned. Check with
your instructor if you are not certain. Consult the Management Network Diagram to
determine the management address of your student device.
Step 1.2
Access the CLI at your station using either the console, Telnet, or SSH as directed by
your instructor. Refer to the Management Network Diagram for the IP address
associated with your workstation. The following example is based on simple Telnet
access using the Secure CRT program.
login: lab
Password:
[edit]
lab@srxC-1# load override jsec/lab8-start.config
[edit]
lab@srxC-1# commit
commit complete
[edit]
lab@srxC-1#
In this lab part, you adjust the configuration and enable high availability chassis
clustering. You will work with the remote team in your assigned pod to make some
configuration adjustments and then join your assigned devices into a single virtual
device using chassis clustering.
Note
Throughout this lab, you work as a team
with all the members in your assigned lab
pod. Because a chassis cluster combines
two physical devices into one logical device,
it is important to follow the steps in order
and in tandem as a team. Perform the next
several steps on the SRX1 and SRX2
devices.
Step 2.1
Navigate to the [edit interfaces] hierarchy.
[edit]
lab@srxC-1# edit interfaces
[edit interfaces]
lab@srxC-1#
Step 2.3
Remove the ge-0/0/0 and ge-0/0/4 interfaces.
[edit interfaces]
lab@srxC-1# delete ge-0/0/0
[edit interfaces]
lab@srxC-1# delete ge-0/0/4
Step 2.4
Navigate to the [edit system] hierarchy level and delete the host-name
statement.
[edit interfaces]
lab@srxC-1# up 1 edit system
[edit system]
lab@srxC-1# delete host-name
[edit system]
lab@srxC-1#
Step 2.12
The next several steps will be performed on the SRX1 and SRX2 devices.
From the Telnet session of your assigned SRX device, commit the configuration and
exit to operational mode.
[edit groups node1]
lab@srxC-1# commit and-quit
commit complete
Exiting configuration mode
lab@srxC-1>
lab@srxC-1>
*** FINAL System shutdown message from root@srxC-1 ***
System going down IMMEDIATELY
srxC-1 (ttyu0)
login: lab
Password:
Note
Perform the next several steps only on the
SRX1 device. Both teams should be
working only from SRX1!
Step 2.16
The next several steps will be performed on the only on the SRX1 device.
From the Telnet session of SRX1, issue the command show chassis cluster
status.
{primary:node0}
lab@srxC-1> show chassis cluster status
Cluster ID: 1
Node Priority Status Preempt Manual failover
Step 2.17
Issue the command show chassis cluster interfaces.
{primary:node0}
lab@srxC-1> show chassis cluster interfaces
Control link status: Up
Control interfaces:
Index Interface Status
0 fxp1 Up
Fabric interfaces:
Name Child-interface Status
(Physical/Monitored)
fab0
fab0
Step 2.18
Enter configuration mode, navigate to the [edit interfaces] hierarchy, and
configure the fab0 and fab1 interfaces that comprise the fabric link. Refer to your
Lab 8 network diagram for the appropriate member interfaces. When you are
finished, commit the configuration and return to operational mode.
Note
When chassis clustering is enabled
commits can only be issued from the top of
the configuration hierarchy.
{primary:node0}
lab@srxC-1> configure
warning: Clustering enabled; using private edit
warning: uncommitted changes will be discarded on exit
Entering configuration mode
{primary:node0}[edit]
lab@srxC-1# edit interfaces
{primary:node0}[edit interfaces]
lab@srxC-1# set fab0 fabric-options member-interfaces ge-0/0/2
{primary:node0}[edit interfaces]
lab@srxC-1# top
{primary:node0}[edit]
lab@srxC-1# commit and-quit
node0:
configuration check succeeds
node1:
commit complete
node0:
commit complete
Exiting configuration mode
{primary:node0}
lab@srxC-1>
Step 2.19
Issue the command show chassis cluster interfaces.
{primary:node0}
lab@srxC-1> show chassis cluster interfaces
Control link status: Up
Control interfaces:
Index Interface Status
0 fxp1 Up
Fabric interfaces:
Name Child-interface Status
(Physical/Monitored)
fab0 ge-0/0/2 Up / Up
fab0
fab1 ge-5/0/2 Up / Up
fab1
Do not proceed to the next lab part until directed by the instructor to do
STOP
so.
In this lab part, you configure redundancy group 1 and redundancy group 2 in an
active/active cluster configuration.
Step 3.1
Enter configuration mode and load the lab8-part3-start.config from the
/var/home/lab/jsec/ directory. Commit the configuration when complete.
lab@srxC-1> configure
warning: Clustering enabled; using private edit
warning: uncommitted changes will be discarded on exit
Entering configuration mode
[edit]
lab@srxC-1# load override jsec/lab8-part3-start.config
[edit]
lab@srxC-1# commit
commit complete
[edit]
lab@srxC-1#
Step 3.2
Navigate to the [edit chassis cluster] hierarchy level. Next configure
redundancy group 1 to have Node 0 with a priority of 200 and Node 1 with a
priority of 100.
{primary:node0}[edit]
lab@srxC-1# edit chassis cluster
{primary:node0}[edit interfaces]
lab@srxC-1# set ge-0/0/4 gigether-options redundant-parent reth0
{primary:node0}[edit interfaces]
lab@srxC-1# set ge-5/0/4 gigether-options redundant-parent reth0
{primary:node0}[edit interfaces]
lab@srxC-1# set reth0 redundant-ether-options redundancy-group 1
{primary:node0}[edit interfaces]
lab@srxC-1# set reth0 vlan-tagging
{primary:node0}[edit interfaces]
lab@srxC-1# set reth0 unit reth0-vlan-id family inet address reth0-address/mask
Step 3.6
Configure the reth1 interface to consist of interfaces ge-0/0/5 and ge-5/0/5. Next
associate reth1 with redundancy group 2. Then configure reth1 to accept and
transmit 802.1Q frames, and configure it with the proper VLAN ID and IP address.
Please refer to your Lab 8 network diagram for the correct VLAN and IP address
values.
{primary:node0}[edit interfaces]
lab@srxC-1# set ge-0/0/5 gigether-options redundant-parent reth1
{primary:node0}[edit interfaces]
lab@srxC-1# set ge-5/0/5 gigether-options redundant-parent reth1
{primary:node0}[edit interfaces]
lab@srxC-1# set reth1 redundant-ether-options redundancy-group 2
{primary:node0}[edit interfaces]
lab@srxC-1# set reth1 vlan-tagging
{primary:node0}[edit interfaces]
lab@srxC-1# set reth1 unit reth1-vlan-id vlan-id reth1-vlan-id
{primary:node0}[edit interfaces]
lab@srxC-1# set reth1 unit reth1-vlan-id family inet address reth1-address/mask
Step 3.7
Configure the ge-5/0/3 interface with the 172.18.2.2/30 address. Commit the
configuration when you are finished.
{primary:node0}[edit interfaces]
lab@srxC-1# set ge-5/0/3 unit 0 family inet address 172.18.2.2/30
{primary:node0}[edit interfaces]
lab@srxC-1# show
ge-0/0/3 {
unit 0 {
family inet {
address 172.18.1.2/30;
}
}
}
ge-0/0/4 {
gigether-options {
redundant-parent reth0;
}
}
ge-0/0/5 {
gigether-options {
redundant-parent reth1;
reth0 {
vlan-tagging;
redundant-ether-options {
redundancy-group 1;
}
unit 223 {
vlan-id 223;
family inet {
address 172.20.30.1/24;
}
}
}
reth1 {
vlan-tagging;
redundant-ether-options {
redundancy-group 2;
}
unit 233 {
vlan-id 233;
family inet {
address 172.30.30.1/24;
}
}
}
{primary:node0}[edit interfaces]
lab@srxC-1# top
{primary:node0}[edit]
lab@srxC-1# commit
[edit chassis cluster]
'redundancy-group 1'
redundancy-group-id (1) cannot exceed reth-count (0)
{primary:node0}[edit]
lab@srxC-1#
Step 3.8
Navigate to the [edit chassis cluster] hierarchy level and increase the reth
count to 2. Commit the configuration when you are finished.
{primary:node0}[edit]
lab@srxC-1# edit chassis cluster
{primary:node0}[edit]
lab@srxC-1# commit
node0:
configuration check succeeds
node1:
commit complete
node0:
commit complete
Control interfaces:
Index Interface Status
0 fxp1 Up
Fabric interfaces:
Name Child-interface Status
(Physical/Monitored)
fab0 ge-0/0/2 Up / Up
fab0
fab1 ge-5/0/2 Up / Up
fab1
Redundant-ethernet Information:
Name Status Redundancy-group
reth0 Down 1
reth1 Down 2
Interface Monitoring:
Interface Weight Status Redundancy-group
ge-5/0/3 255 Up 2
Step 3.10
Issue the command run show chassis cluster status.
{primary:node0}[edit]
lab@srxC-1# run show chassis cluster status
Cluster ID: 1
Node Priority Status Preempt Manual failover
Step 3.11
Configure Node 1 to have a higher priority value than Node 0 for redundancy
group 0. Commit the configuration when you are finished.
{primary:node0}[edit]
lab@srxC-1# set chassis cluster redundancy-group 0 node 1 priority 254
{primary:node0}[edit]
lab@srxC-1# commit
node0:
configuration check succeeds
node1:
commit complete
{primary:node0}[edit]
lab@srxC-1#
{primary:node0}[edit]
lab@srxC-1# edit security
{primary:node0}[edit security]
lab@srxC-1# set policies default-policy permit-all
lab@srxC-1# show
zones {
security-zone untrust {
{primary:node0}[edit routing-options]
lab@srxC-1# delete static route 0/0
{primary:node0}[edit routing-options]
lab@srxC-1# set static route 0/0 qualified-next-hop 172.18.1.1
{primary:node0}[edit routing-options]
lab@srxC-1# set static route 0/0 qualified-next-hop 172.18.2.1 preference 10
{primary:node0}[edit routing-options]
lab@srxC-1# top
{primary:node0}[edit]
lab@srxC-1# commit and-quit
node0:
{primary:node0}
lab@srxC-1>
Step 3.17
Issue the show route 0/0 exact command.
lab@srxC-1> show route 0/0 exact
Step 3.18
Check connectivity by issuing pings to both virtual router interface addresses. Next,
ping both interface addresses that belong to the ISP, and then ping the Internet
host. Use the detail option to ensure the pings are egressing the correct
interface. Please refer to your Lab 8 network diagram for these addresses.
{primary:node0}
lab@srxC-1> ping reth0-VR detail count 2
PING 172.20.30.2 (172.20.30.2): 56 data bytes
64 bytes from 172.20.30.2 via reth0.223: icmp_seq=0 ttl=64 time=1.678 ms
64 bytes from 172.20.30.2 via reth0.223: icmp_seq=1 ttl=64 time=1.726 ms
{primary:node0}
lab@srxC-1> ping reth1-VR detail count 2
{primary:node0}
lab@srxC-1> ping 172.18.1.1 detail count 2
PING 172.18.1.1 (172.18.1.1): 56 data bytes
64 bytes from 172.18.1.1 via ge-0/0/3.0: icmp_seq=0 ttl=64 time=1.974 ms
64 bytes from 172.18.1.1 via ge-0/0/3.0: icmp_seq=1 ttl=64 time=1.507 ms
{primary:node0}
lab@srxC-1> ping 172.18.2.1 detail count 2
PING 172.18.2.1 (172.18.2.1): 56 data bytes
64 bytes from 172.18.2.1 via ge-5/0/3.0: icmp_seq=0 ttl=64 time=8.307 ms
64 bytes from 172.18.2.1 via ge-5/0/3.0: icmp_seq=1 ttl=64 time=17.362 ms
{primary:node0}
lab@srxC-1> ping 172.31.15.1 detail count 2
PING 172.31.15.1 (172.31.15.1): 56 data bytes
64 bytes from 172.31.15.1 via ge-0/0/3.0: icmp_seq=0 ttl=64 time=1.740 ms
64 bytes from 172.31.15.1 via ge-0/0/3.0: icmp_seq=1 ttl=64 time=1.691 ms
Do not proceed to the next lab part until directed by the instructor to do
STOP
so.
In this lab part, you generate traffic from the attached virtual routers and monitor
the traffic flows. You will also examine the path which these flows take and the
effect of asymmetric flows on the chassis cluster.
Step 4.1
Enter configuration mode and load the lab8-part4-start.config from the
/var/home/lab/jsec/ directory. Commit the configuration when complete.
lab@srxC-1> configure
warning: Clustering enabled; using private edit
warning: uncommitted changes will be discarded on exit
Entering configuration mode
[edit]
lab@srxC-1# load override jsec/lab8-part4-start.config
[edit]
lab@srxC-1# commit
commit complete
[edit]
lab@srxC-1#
Step 4.2
Open a separate Telnet session to the virtual router attached to your teams device.
vr-device (ttyp0)
login: username
Password:
NOTE: This router is divided into many virtual routers used by different teams.
Please only configure your own virtual router.
d1@vr-device>
Step 4.4
Generate traffic to the Internet host from the virtual router associated with reth0 by
issuing the ping 172.31.15.1 rapid count 1000000
routing-instance reth0-VR command.
d1@vr-device> ping 172.31.15.1 rapid count 1000000 routing-instance reth0-VR
PING 172.31.15.1 (172.31.15.1): 56 data bytes
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
...
Step 4.5
Return to the Telnet session established with your assigned SRX device.
From the Telnet session established with SRX1, issue the run monitor
interface traffic command. You must find the correct interfaces in the
output to answer the following questions. Press Ctrl + d or Ctrl + u to scroll down or
up.
Note
Examine the packets -per-second(pps)
field to see the current packets traveling
through an interface.
Note
Examine your Lab 8 diagram to help trace
the path of the traffic flow.
Step 4.6
Return to the Telnet session established with the virtual router.
From the Telnet session established with the virtual router, press Ctrl + c to stop the
ping traffic.
...
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!^C
--- 172.31.15.1 ping statistics ---
408110 packets transmitted, 408110 packets received, 0% packet loss
round-trip min/avg/max/stddev = 2.750/4.292/23.411/2.107 ms
Step 4.7
Generate traffic to the Internet host from the virtual router associated with reth1 by
issuing the ping 172.31.15.1 rapid count 1000000
routing-instance reth1-VR command.
d1@vr-device> ping 172.31.15.1 rapid count 1000000 routing-instance reth1-VR
PING 172.31.15.1 (172.31.15.1): 56 data bytes
{primary:node0}[edit]
lab@srxC-1# edit interfaces
{primary:node0}[edit interfaces]
lab@srxC-1# set ge-5/0/3 disable
{primary:node0}[edit interfaces]
lab@srxC-1# top
{primary:node0}[edit]
lab@srxC-1# commit
node0:
configuration check succeeds
node1:
commit complete
node0:
commit complete
{primary:node0}[edit]
lab@srxC-1#
Step 4.10
Issue the run show chassis cluster interfaces command.
{primary:node0}[edit]
lab@srxC-1# run show chassis cluster interfaces
Control link status: Up
Control interfaces:
Index Interface Status
0 fxp1 Up
Redundant-ethernet Information:
Name Status Redundancy-group
reth0 Up 1
reth1 Up 2
Interface Monitoring:
Interface Weight Status Redundancy-group
ge-5/0/3 255 Down 2
Step 4.11
Issue the run show chassis cluster status command.
{primary:node0}[edit]
lab@srxC-1# run show chassis cluster status
Cluster ID: 1
Node Priority Status Preempt Manual failover
Step 4.12
Return to the Telnet session established with the virtual router.
If the ping test is still running from the Telnet session established with the virtual
router, cancel it with the Ctrl+c key combination. Then issue the ping
172.31.15.1 rapid count 1000000 routing-instance reth1-VR
command.
...
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!^C
--- 172.31.15.1 ping statistics ---
166596 packets transmitted, 166594 packets received, 0% packet loss
round-trip min/avg/max/stddev = 2.812/4.997/64.120/2.839 ms
Step 4.14
Remove the disable option that was placed on the ge-5/0/3 interface. Once you
are finished, commit the configuration and exit to operational mode.
{primary:node0}[edit]
lab@srxC-1# delete interfaces ge-5/0/3 disable
{primary:node0}[edit]
lab@srxC-1# commit and-quit
{primary:node0}
lab@srxC-1>
Step 4.15
Issue the show chassis cluster status command.
{primary:node0}
lab@srxC-1> show chassis cluster status
Cluster ID: 1
Node Priority Status Preempt Manual failover
Step 4.16
Return to the Telnet session established with the virtual router.
From the Telnet session established with the virtual router, press Ctrl + c to stop the
ping traffic. Then, log out of the vr-device.
...
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!^C
--- 172.31.15.1 ping statistics ---
409132 packets transmitted, 409132 packets received, 0% packet loss
c1@vr-device> exit
In this lab part, you break down the chassis cluster implementation. You will then
load the reset configuration on each node.
Step 5.1
Return to the Telnet session established with your assigned SRX device.
From the Telnet session established with SRX1, issue the set chassis
cluster disable reboot command.
{primary:node0}
lab@srxC-1> set chassis cluster disable reboot
Successfully disabled chassis cluster. Going to reboot now{primary:node0}
lab@srxC-1>
*** FINAL System shutdown message from root@srxC-1 ***
System going down IMMEDIATELY
Step 5.2
Once the SRX1 device reboots, log in using the lab user account.
Note
The Amnesiac banner is displayed and
there is no host name for Node 0. Recall
that apply-groups were used to implement
the host name during chassis clustering.
SrxX-1 currently has no configured host
name.
Amnesiac (ttyu0)
login: lab
Password:
[edit]
lab# load override jsec/reset.config
load complete
[edit]
lab# commit and-quit
commit complete
Exiting configuration mode
lab@srxC-1>
Step 5.4
Log in to the SRX2 device using the lab user account. Issue the set chassis
cluster disable reboot command.
srxC-2 (ttyu0)
login: lab
Password:
{primary:node1}
lab@srxC-2> set chassis cluster disable reboot
Successfully disabled chassis cluster. Going to reboot now
{primary:node1}
lab@srxC-2>
Amnesiac (ttyu0)
login: lab
Password:
[edit]
lab# load override jsec/reset.config
load complete
[edit]
lab# commit and-quit
commit complete
Exiting configuration mode
lab@srxC-2>