Junos for Security Platforms
1
Lab 4
Implementing IPsec VPNs
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.
All devices are connected to a common management network which facilitates access to the CLI.
These exercises assume you already have some basic understanding of the JUNOS CLI interfaces
and you have attended the IJS and JRE training.
Note that your lab login (password given to you separately) grants you all permissions needed to
complete this lab; however, some restrictions have been made to prevent loss of connectivity to the
devices. Please be careful, and have fun!
By completing this lab, you will perform the following tasks:
•
Configure a route-‐based IPsec VPN.
•
Alter security policies to allow traffic between the it and eng security zones.
•
Configure and monitor a secure tunnel interface.
•
Verify and monitor an IPsec VPN tunnel.
Please refer to the next page lab diagram to perform this exercise:
Junos for Security Platforms
2
Lab Diagram
Junos for Security Platforms
3
Key Commands
Key operational mode commands used in this lab include the following:
show interfaces st0
show security ike security-associations
show security ipsec security-associations
clear security ipsec statistics
show security ipsec statistics
Part 1:
Configuring a Route-‐Based IPsec VPN
In this lab part, you will configure a route-based IPsec VPN tunnel. This IPsec VPN tunnel will be
utilized for all traffic between the eng and it security zones.
Step 1.1
Restore your POD’s devices to the state they should be after finished LAB 3. Remember that these
devices are used by multiple students every day in various virtual training activities and always
before a new lab session resetted to a default state. To get started from point where you finished the
last lab you need to load a saved configuration file using the command load override
/var/home/instructor/JSEC_Virtual/lab4_start. Do not forget to commit your
configuration after successful load operation.
[edit]
lab@host1-d# load override /var/home/instructor/JSEC_Virtual/lab4_start
load complete
[edit]
lab@host1-d# commit
commit complete
Step 1.2
Enter configuration mode and navigate to the [edit interfaces] hierarchy.
lab@host1-d> configure
Entering configuration mode
[edit]
lab@host1-d# edit interfaces
[edit interfaces]
lab@host1-d#
Step 1.3
Configure a secure tunnel interface st0. Configure logical unit 0 with an IP address of
192.168.100.x, where x is 1 for srxX-1 or 2 for srxX-2.
Junos for Security Platforms
4
[edit interfaces]
lab@host1-d# set st0 unit 0 family inet address 192.168.100.1
Step 1.4
Add the st0.0 interface to the untrust security zone.
[edit interfaces]
lab@host1-d# top set security zones security-zone untrust interfaces st0.0
Step 1.5
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
• lifetime: 600.
[edit interfaces]
lab@host1-d# top edit security ike
[edit security ike]
lab@host1-d# set proposal phase1 authentication-method pre-shared-keys
[edit security ike]
lab@host1-d# set proposal phase1 dh-group group2
[edit security ike]
lab@host1-d# set proposal phase1 authentication-algorithm md5
[edit security ike]
lab@host1-d# set proposal phase1 encryption-algorithm 3des-cbc
[edit security ike]
lab@host1-d# set proposal phase1 lifetime-seconds 600
[edit security ike]
lab@host1-d# show proposal phase1
authentication-method pre-shared-keys;
dh-group group2;
authentication-algorithm md5;
encryption-algorithm 3des-cbc;
lifetime-seconds 600;
[edit security ike]
lab@host1-d#
Junos for Security Platforms
5
Step 1.6
Configure an IKE phase one policy named phase1-policy. The policy should use main mode,
reference the proposal you created in the previous step, and use an ASCII pre-shared key of
juniper.
[edit security ike]
lab@host1-d# set policy phase1-policy mode main
[edit security ike]
lab@host1-d# set policy phase1-policy proposals phase1
[edit security ike]
lab@host1-d# set policy phase1-policy pre-shared-key ascii-text juniper
[edit security ike]
lab@host1-d# show policy phase1-policy
mode main;
proposals phase1;
pre-shared-key ascii-text "$9$WeiXNb4aU.PQs2PQFnpu8X7"; ## SECRET-DATA
[edit security ike]
lab@host1-d#
Step 1.7
Configure an IKE gateway named phase1-gateway. Reference the IKE policy you created in the
previous step. For the gateway IP address, use the IP address associated with the ge-0/0/3
interface on the remote team’s device. Use your device’s ge-0/0/3 interface as the external
interface for establishing an IPsec VPN between srxX-1 and srxX-2. Configure your device to
send a dead peer detection (DPD) request packet every 20 seconds and to consider the IKE
neighbor down after five sequences of waiting 20 seconds and sending a DPD request packet.
[edit security ike]
lab@host1-d# set gateway phase1-gateway ike-policy phase1-policy
[edit security ike]
lab@host1-d# set gateway phase1-gateway address 172.18.2.2
[edit security ike]
lab@host1-d# set gateway phase1-gateway dead-peer-detection interval 20
[edit security ike]
lab@host1-d# set gateway phase1-gateway dead-peer-detection threshold 5
[edit security ike]
lab@host1-d# set gateway phase1-gateway external-interface ge-0/0/3.0
[edit security ike]
lab@host1-d# show gateway phase1-gateway
ike-policy phase1-policy;
address 172.18.2.2;
dead-peer-detection {
interval 20;
threshold 5;
Junos for Security Platforms
6
}
external-interface ge-0/0/3.0;
[edit security ike]
lab@host1-d#
Step 1.8
Navigate to the [edit security ipsec] configuration hierarchy. You define IKE phase 2 configuration
parameters at this level.
[edit security ike]
lab@host1-d# up
[edit security]
lab@host1-d# edit ipsec
[edit security ipsec]
lab@host1-d#
Step 1.9
Define an IKE phase two proposal named phase2. Use the Encapsulating Security Payload (ESP)
protocol, an authentication algorithm of hmac-md5-96, an encryption algorithm of 3des-cbc, and a
lifetime value of 3200 seconds.
[edit security ipsec]
lab@host1-d# set proposal phase2 protocol esp
[edit security ipsec]
lab@host1-d# set proposal phase2 authentication-algorithm hmac-md5-96
[edit security ipsec]
lab@host1-d# set proposal phase2 encryption-algorithm 3des-cbc
[edit security ipsec]
lab@host1-d# set proposal phase2 lifetime-seconds 3200
[edit security ipsec]
lab@host1-d# show proposal phase2
protocol esp;
authentication-algorithm hmac-md5-96;
encryption-algorithm 3des-cbc;
lifetime-seconds 3200;
[edit security ipsec]
lab@host1-d#
Step 1.10
Create a phase two policy named phase2-policy. Configure Perfect Forward Secrecy (PFS) to
use Diffie-Helman group2 as the method the device uses to generate the encryption key.
Junos for Security Platforms
7
[edit security ipsec]
lab@host1-d# set policy phase2-policy perfect-forward-secrecy keys group2
[edit security ipsec]
lab@host1-d# set policy phase2-policy proposals phase2
[edit security ipsec]
lab@host1-d# show policy phase2-policy
perfect-forward-secrecy {
keys group2;
}
proposals phase2;
[edit security ipsec]
lab@host1-d#
Step 1.11
Configure the IPsec VPN tunnel and name the VPN to-srxX, where X represents the host number
of the remote team’s assigned device. Bind the st0.0 interface to this tunnel. Associate the IKE
phase1-gateway and phase2-policy with the VPN tunnel. Ensure the VPN tunnel is established
without the need for a triggering mechanism.
[edit security ipsec]
lab@host1-d# set vpn to-srx2 bind-interface st0.0
[edit security ipsec]
lab@host1-d# set vpn to-srx2 ike gateway phase1-gateway
[edit security ipsec]
lab@host1-d# set vpn to-srx2 ike ipsec-policy phase2-policy
[edit security ipsec]
lab@host1-d# set vpn to-srx2 establish-tunnels immediately
[edit security ipsec]
lab@host1-d# show vpn to-srx2
bind-interface st0.0;
ike {
gateway phase1-gateway;
ipsec-policy phase2-policy;
}
establish-tunnels immediately;
[edit security ipsec]
lab@host1-d#
Step 1.12
All traffic between the eng and the it zones will use the IPsec VPN you created. Navigate to the
[edit routing-options] configuration hierarchy. Create a static route for the remote /24 IP
subnet (either the subnet associated with the it zone or the subnet associated with the eng zone
depending on your assigned device). The next hop should point to the st0.0 interface.
Junos for Security Platforms
8
[edit routing-options]
lab@host1-d# set static route 172.20.208.0/24 next-hop st0.0
Question: Why is this step necessary?
Answer: In a route-based VPN, traffic associates using a route rather than a security
policy. Without this step, traffic would not use the IPsec VPN tunnel.
Question: What are the two valid next hops for this static route?
Answer: The st0.0 interface can be specified as the next-hop as shown in the example.
You could also use the remote IP address of the st0 interface.
Step 1.13
Navigate to the [edit security policies] configuration hierarchy. Review the security
policies in place that allow traffic to and from the untrust zone with respect to the eng or it zones,
depending on your assigned device.
[edit routing-options]
lab@srxB-1# top edit security policies
[edit security policies]
lab@host1-d# show from-zone untrust to-zone eng
policy webserver {
match {
source-address host2-d;
destination-address vr207;
application [ junos-telnet junos-http ];
}
then {
permit;
}
}
[edit security policies]
lab@host1-d#
And from device 2 in your POD.
[edit security policies]
Junos for Security Platforms
9
lab@host2-d# show from-zone untrust to-zone it
[edit security policies]
lab@host2-d#
Question: What does the output of these two commands show you?
Answer: There is no policy configured from zone untrust to zone it in device 2.
[edit security policies]
lab@host1-d# show from-zone eng to-zone untrust
policy internet-eng {
match {
source-address vr207;
destination-address any;
application any;
}
then {
permit;
}
}
[edit security policies]
lab@host1-d#
And from device 2 in your POD.
lab@host2-d# show from-zone it to-zone untrust
policy internet-it {
match {
source-address vr208;
destination-address any;
application any;
}
then {
permit;
}
}
[edit security policies]
lab@host2-d#
Junos for Security Platforms
10
Question: What changes must you make to the [edit security policies]
hierarchy?
Answer: You must make a new policy for traffic coming from the untrust zone that
originates on the remote virtual router. A security policy is already in place to allow all
traffic to the untrust zone that originates on the local virtual router (eng and it zones).
Step 1.14
Create a new security policy that permits traffic from the untrust zone destined to the virtual router
attached to your assigned device (either eng or it, depending on your device). Name the security
policy ipsec. The policy should match only traffic sourced from the remote virtual router (either eng
or it, depending on your device). Use the configuration option any for the destination address and
application.
[edit security policies]
lab@host1-d# edit from-zone untrust to-zone eng
[edit security policies from-zone untrust to-zone eng]
lab@host1-d# set policy ipsec match source-address vr208
[edit security policies from-zone untrust to-zone eng]
lab@host1-d# set policy ipsec match destination-address any
[edit security policies from-zone untrust to-zone eng]
lab@host1-d# set policy ipsec match application any
[edit security policies from-zone untrust to-zone eng]
lab@host1-d# set policy ipsec then permit
[edit security policies from-zone untrust to-zone eng]
lab@host1-d# show
policy ipsec {
match {
source-address vr208;
destination-address any;
application any;
}
then {
permit;
}
}
[edit security policies from-zone untrust to-zone eng]
lab@host1-d#
Junos for Security Platforms
11
Step 1.15
Commit your configuration and return to operational mode.
[edit security policies from-zone untrust to-zone eng]
lab@host1-d# commit and-quit
commit complete
Exiting configuration mode
lab@host1-d#
Step 1.16
Repeat steps 1.1 – 1.15 with your POD’s other device before proceeding to Part 2.
Junos for Security Platforms
12
Part 2:
Verifying and Monitoring IPsec
In this lab part, you will 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@host1-d> 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@host1-d> show security ike security-associations
Index Remote Address State Initiator cookie Responder cookie Mode
22 172.18.2.2 UP be4c43b499307939 326b683bffbacad4 Main
Question: What is the state of the IKE phase 1 security association?
Answer: As shown in the output, the state should be up. If you do not see a security
association, try clearing the phase 1 and phase 2 security associations on both devices
within your pod.
Step 2.3
Check the state of the phase 2 security association using the show security ipsec security-
associations command.
lab@host1-d> show security ipsec security-associations
Total active tunnels: 1
ID Gateway Port Algorithm SPI Life:sec/kb Mon vsys
<131073 172.18.2.2 500 ESP:3des/md5 549e070a 3147/ unlim - 0
>131073 172.18.2.2 500 ESP:3des/md5 397f7941 3147/ unlim - 0
Junos for Security Platforms
13
Question: Is a phase 2 security association present?
Answer: As shown in the output, at least one successful phase 2 security association
should be present, represented by an inbound row and an outbound row.
Question: What is the index number used to represent the phase 2 security association?
Answer: The answer can vary. In the example, the index number, represented by the ID
column, is 131073.
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@host1-d> show security ipsec security-associations index 131073
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)
DF-bit: clear
Direction: inbound, SPI: 549e070a, AUX-SPI: 0
, VPN Monitoring: -
Hard lifetime: Expires in 1764 seconds
Lifesize Remaining: Unlimited
Soft lifetime: Expires in 1145 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
Direction: outbound, SPI: 397f7941, AUX-SPI: 0
, VPN Monitoring: -
Hard lifetime: Expires in 1764 seconds
Lifesize Remaining: Unlimited
Soft lifetime: Expires in 1145 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
Direction: inbound, SPI: 397b2ab0, AUX-SPI: 0
, VPN Monitoring: -
Junos for Security Platforms
14
Hard lifetime: Expires in 1768 seconds
Lifesize Remaining: Unlimited
Soft lifetime: Expires in 1213 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
Direction: outbound, SPI: 801f84bc, AUX-SPI: 0
, VPN Monitoring: -
Hard lifetime: Expires in 1768 seconds
Lifesize Remaining: Unlimited
Soft lifetime: Expires in 1213 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
Question: Is anti-replay enabled for the IPsec VPN tunnel?
Answer: Yes as shown in the output.
Step 2.5
Issue the clear security ipsec statistics command followed by the show security
ipsec statistics command.
lab@host1-d> clear security ipsec statistics
lab@host1-d> show security ipsec statistics
ESP Statistics:
Encrypted bytes: 0
Decrypted bytes: 0
Encrypted packets: 0
Decrypted packets: 0
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
Junos for Security Platforms
15
Question: Do all the counters show a value of 0?
Answer: The answer should be yes, as shown in the example output.
Step 2.6
Open a separate Telnet session to the virtual router attached to your team device. You need to open a
new ssh session to the Jump Server and from there establish a telnet session to the virtual device.
Observe that you have only very limited access to the virtual device and should follow the lab
instructions as written very strictly.
Use the login credentials from the table here below.
Virtual Router Login Details
Student Device
User Name
Password
srxA-‐1
a1
lab123
srxA-‐2
a2
lab123
srxB-‐1
b1
lab123
srxB-‐2
b2
lab123
srxC-‐1
c1
lab123
srxC-‐2
c2
lab123
srxD-‐1
d1
lab123
srxD-‐2
d2
lab123
[timo@js2 ~]$ telnet 10.210.14.139
Trying 10.210.14.139...
Connected to j2350.lab2.cavellgroup.com (10.210.14.139).
Escape character is '^]'.
vr-device (ttyp0)
login: d1
Password:
--- JUNOS 9.2R1.10 built 2008-08-07 06:45:07 UTC
NOTE: This router is divided into many virtual routers used by different teams.
Please only configure your own virtual router.
You must use 'configure private' to configure this router.
d1@vr-device>
Junos for Security Platforms
16
Step 2.7
Commit your configuration and return to operational mode.
[edit security policies from-zone untrust to-zone eng]
lab@host1-d# commit and-quit
commit complete
Exiting configuration mode
lab@host1-d>
Step 2.8
Open a separate Telnet session to the virtual router attached to your team device. You need to open a
new ssh session to the Jump Server and from there establish a telnet session to the virtual device.
Observe that you have only very limited access to the virtual device and should follow the lab
instructions as written very strictly.
Use the login credentials from the table here below.
Virtual Router Login Details
Student Device
User Name
Password
srxA-‐1
a1
lab123
srxA-‐2
a2
lab123
srxB-‐1
b1
lab123
srxB-‐2
b2
lab123
srxC-‐1
c1
lab123
srxC-‐2
c2
lab123
srxD-‐1
d1
lab123
srxD-‐2
d2
lab123
[timo@js2 ~]$ telnet 10.210.14.139
Trying 10.210.14.139...
Connected to j2350.lab2.cavellgroup.com (10.210.14.139).
Escape character is '^]'.
vr-device (ttyp0)
login: d1
Password:
--- JUNOS 9.2R1.10 built 2008-08-07 06:45:07 UTC
NOTE: This router is divided into many virtual routers used by different teams.
Please only configure your own virtual router.
You must use 'configure private' to configure this router.
d1@vr-device>
Junos for Security Platforms
17
Step 2.9
Initiate a Telnet session that traverses the IPsec tunnel. Source the Telnet session from your virtual
router that is associated with the eng or it security zone, depending on your device. As a destination
address, use the IP address associated with the virtual router attached to the remote student device
(either eng or it, depending on your device). Use the same login credentials as used for your current
vr-device Telnet session.
d1@vr-device> telnet 172.20.208.10 routing-instance vr207
Trying 172.20.208.10...
Connected to 172.20.208.10.
Escape character is '^]'.
vr-device (ttyp2)
login: d1
Password:
--- JUNOS 9.2R1.10 built 2008-08-07 06:45:07 UTC
NOTE: This router is divided into many virtual routers used by different teams.
Please only configure your own virtual router.
You must use 'configure private' to configure this router.
d1@vr-device>
Step 2.10
Return to the terminal session opened to your assigned device and view the flow session table.
lab@host1-d> show security flow session
Session ID: 42097, Policy name: N/A, Timeout: N/A
In: 172.18.2.2/37051 --> 172.18.1.2/59932;esp, If: ge-0/0/3.0
Session ID: 42098, Policy name: N/A, Timeout: N/A
In: 172.18.2.2/0 --> 172.18.1.2/0;esp, If: ge-0/0/3.0
Session ID: 42229, Policy name: internet-eng/8, Timeout: 1790
In: 172.20.207.10/50282 --> 172.20.208.10/23;tcp, If: ge-0/0/4.207
Out: 172.20.208.10/23 --> 172.20.207.10/50282;tcp, If: st0.0
3 sessions displayed
Question: What sessions associate with the secure tunnel interface?
Answer: The output can vary, but Telnet sessions, indicated by TCP port 23, that are
between virtual routers should show interface st0.0 for either the inbound or outbound
flow.
Junos for Security Platforms
18
Step 2.11
Issue the show security ipsec statistics command.
lab@host1-d> show security ipsec statistics
ESP Statistics:
Encrypted bytes: 2872
Decrypted bytes: 1490
Encrypted packets: 26
Decrypted packets: 20
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
Question: How many packets have received encryption?
Answer: The answer varies, but both the encrypted and decrypted packets counters
should have a non-zero value.
Step 2.12
Return to the session opened with the vr-device and exit the virtual router Telnet session using the
exit command.
d1@vr-device> exit
Connection closed by foreign host.
d1@vr-device>
You have completed Lab 4 !