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 !