JNCIS-SEC Bootcamp

Lab 3
Network Address Translation

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.
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
or you have read the JNCIA-JUNOS documentation or similar.
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 and monitor interface-based source NAT.

Configure and monitor pool-based destination NAT.

Please refer to the next page lab diagram to perform this exercise:

JNCIS-SEC Bootcamp

Lab Diagram

Lab Diagram
VLAN Assignments
(v=remainder of vlanvlan-id)
Hostname

VLAN-ID

srxA-1

101, 201

srxA-2

102, 202

srxB-1

103, 203

srxB-2

104, 204

srxC-1

105, 205

srxC-2

106, 206

srxD-1

107, 207

srxD-2

108, 208

Internet
Host 172.31.15.1

)
( .2

X = Pod
(A, B, C, or D)
0

(. 2

Untrust Zone

ge
-0
/0
/3

srxX
srxX-1

srxX
srxX-2
lo0: 192.168.2.1

(.10)

17
2.
18
.2
.0
/3

lo0: 192.168.1.1

172.20.10v.0/24

HR Zone

2.
17

.1
18

0
/3
.0

3
0/ Untrust Zone
/
-0
ge

gege-0/0/4.10v
0/0/4.10v

vr10v
vr10v

(. 1
)

)
( .1

ge-0/0/4.20v
0/0/4.20v
(.1) ge172.20.20v.0/24

Tagged Interface
(see VLAN Assignments table)

gege-0/0/4.10v
0/0/4.10v
172.20.10v.0/24

(.10)

(.10)

vr20v
vr20v

Eng Zone

Virtual Routers

ge-0/0/4.20v
0/0/4.20v
(.1) ge172.20.20v.0/24
(.10)

vr10v
vr10v

vr20v
vr20v

DC Zone

IT Zone

JNCIS-SEC Bootcamp

Key Commands
Key operational mode commands used in this lab include the following:
configure
show security flow session
show security nat source rule all
show security nat destination pool all

Part 1: Interface-Based Source NAT

In this lab part, you will 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.
This part has to be configured in both devices of your assigned POD. Otherwise exercises in
Part 2 will not work as designed!

Step 1.1
Restore your PODs devices to the state they should be after finished LAB 2. Remember that these
devices are used by multiple students every day in various virtual training activities and always
before a new lab session they are 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/lab3_start. Do not forget to commit
your configuration after successful load operation.

[edit]
lab@host1-d# load override /var/home/instructor/JSEC_Virtual/lab3_start
load complete
[edit]
lab@host1-d# commit
commit complete

____________________ Did everything go okay? _________________

What was the status of your SRX box before you started your lab? Was it in
packet mode or in flow mode? The answer will depend on what the student
assigned to this pod did before you: a routing lab or a security lab. If he was
doing a security lab then you are good as the SRX will be in flow mode, which is
what you need here. However, if he was doing a routing lab the box will be in
packet mode and the results of this lab will not be the expected.
How to find it out? Just issue the following command:
lab@host1-d> show security flow status
Flow forwarding mode:
Inet forwarding mode: packet based (reboot needed to change to flow
based)
Inet6 forwarding mode: drop
MPLS forwarding mode: packet based (reboot needed to change to drop)
ISO forwarding mode: drop

JNCIS-SEC Bootcamp
Flow trace status
Flow tracing status: off

If the box says it is in flow mode, then you are good to carry on and you can
go directly to step 1.2. In the other hand, if the output reports the SRX being in
packet mode, as the above message suggest, please reboot the machine by
issuing a request system reboot and keep going.
__________________________________________________________________

____________________________ Note__________________________
Remember that to change the forwarding mode on an SRX from packet mode to
flow mode (or vice versa) a reboot is needed.
This needs to be checked in both your assigned SRX boxes!
__________________________________________________________________

Step 1.2
Enter configuration mode and navigate to the [edit security nat source] hierarchy.

lab@host1-d> configure
Entering configuration mode
[edit]
lab@host1-d# edit security nat source
[edit security nat source]
lab@host1-d#

Step 1.3
Create a rule-set named internet-bound. Associate the rule-set with a from context matching
traffic coming from both interfaces connected to the virtual routers (vr10v and vr20v corresponding to
the hr and eng zone on host1-X or to zone dc and it on host 2-X) and destined to the untrust
zone.

[edit security nat source]

lab@host1-d# set rule-set internet-bound from interface ge-0/0/4.107
[edit security nat source]
lab@host1-d# set rule-set internet-bound from interface ge-0/0/4.207
[edit security nat source]
lab@host1-d# set rule-set internet-bound to zone untrust
Question: What other contexts could you use for the from statement?

JNCIS-SEC Bootcamp
Answer: You could use a from context referencing the source security zones, but in this
case, two rule-sets would be necessary. Because no configured routing-instances are on
your assigned device, the from routing-instance context is not applicable to this
step.

Step 1.4
Navigate to the [edit security nat source rule-set internet-bound] configuration
hierarchy. Create a NAT rule named 1. The rule should apply interface-based NAT to all traffic with a
destination address of the Internet host as depicted on your lab diagram. Dont forget to commit your
changes.

[edit security nat source]

lab@host1-d# edit rule-set internet-bound
[edit security nat source rule-set internet-bound]
lab@host1-d# set rule 1 match destination-address 172.31.15.1/32
[edit security nat source rule-set internet-bound]
lab@host1-d# set rule 1 then source-nat interface
[edit security nat source rule-set internet-bound]
lab@host1-d# show
from interface [ ge-0/0/4.107 ge-0/0/4.207 ];
to zone untrust;
rule 1 {
match {
destination-address 172.31.15.1/32;
}
then {
source-nat interface;
}
}
[edit security nat source rule-set internet-bound]
lab@host1-d# commit and-quit
commit complete
Exiting configuration mode
lab@host1-d>

Step 1.5
Repeat steps 1.2 - 1.4 in your PODs second device.

Part 2: Monitoring Interface-Based Source NAT

In this part you will monitor the effect of the configured Interface-based Source NAT.

JNCIS-SEC Bootcamp

____________________________ Note__________________________
The next lab steps require you to log in to the virtual router attached to your SRX
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 vrdevice. Although you have two virtual routers attached to your student device,
you only need to establish a single session.
__________________________________________________________________

Step 2.1
Open a separate ssh session to the Jump Server (ssh js2.lab2.cavellgroup.com using port 7037) and
from there launch a telnet session to the virtual router device

[luis@js2 ~]$ telnet 10.210.x.139

Trying 10.210.14.139...
Connected to 10.210.14.139 (10.210.14.139).
Escape character is '^]'.
vr-device (ttyp0)
login:

____________________________ Note _________________________

The x value depends on the pod you have been assigned. PODs A,B,C & D have
and address of 10.210.14.139 whereas PODs E,F,G & H use 10.210.8.139
Refer to your lab diagram for the IP address of your vr-device
__________________________________________________________________

Log in to the virtual router attached to your srx device using the login information shown in the
following table:

Virtual Router Login Details

Student Device

Username

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

JNCIS-SEC Bootcamp

Here is a login example corresponding to the host1-d virtual router. Observe that you have only
very limited access to the virtual device and should follow the lab instructions as written very strictly.

[luis@js2 ~]$ telnet 10.210.14.139

Trying 10.210.14.139...
Connected to 10.210.14.139 (10.210.14.139).
Escape character is '^]'.
vr-device (ttyp0)
login: d1
Password:
--- JUNOS 10.3R1.9 built 2010-08-13 12:12:19 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.2
Initiate a Telnet session to the Internet host device from one of the virtual routers attached to your
assigned device (source the session from one of your directly connected vr10v or vr20v
devices). Use the same login credentials as used for your current vr-device Telnet session.
NOTE! The Internet host resides also within the vr-device, thus use your assigned login!

d1@vr-device> telnet 172.31.15.1 routing-instance vr107

Trying 172.31.15.1...
Connected to 172.31.15.1.
Escape character is '^]'.
vr-device (ttyp0)
login: d1
Password: lab123
--- JUNOS 10.3R1.9 built 2010-08-13 12:12:19 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>

JNCIS-SEC Bootcamp

Step 2.3
Return to the terminal session opened to your assigned device and view the session table.

lab@host1-d> show security flow session

...
Session ID: 27483, Policy name: internet-hr/7, Timeout: 1792, Valid
In: 172.20.107.10/60919 --> 172.31.15.1/23;tcp, If: ge-0/0/4.107, Pkts: 25,
Bytes: 1463
Out: 172.31.15.1/23 --> 172.18.1.2/6655;tcp, If: ge-0/0/3.0, Pkts: 20, Bytes:
1490
Total sessions: 2
Question: Do the session table results indicate expected behavior?

Answer: Yes. As indicated by the output taken from host1-d, the Telnet session sources
from the internal IP address 172.20.107.10, but the return traffic has a destination of the
WAN interface address.

Step 2.4
Issue the show security nat source rule all command and answer the question that
follows.

lab@host1-d> show security nat source rule all

Total rules: 1
Total referenced IPv4/IPv6 ip-prefixes: 1/0
source NAT rule: 1
Rule-Id
Rule position
From interface

Rule-set: internet-bound
1
1
ge-0/0/4.107
ge-0/0/4.207
To zone
untrust
Destination addresses
172.31.15.1
- 172.31.15.1
Destination port
0
- 0
Action
: interface
Persistent NAT type
: N/A
Persistent NAT mapping type : address-port-mapping
Inactivity timeout
: 0
Max session number
: 0
Translation hits
: 1
:
:
:
:
:
:
:

Question: How many hits has this NAT rule received?

JNCIS-SEC Bootcamp

Answer: The answer might vary, but the Translation hits counter should show one
hit at a minimum.

Step 2.5
Return to the session opened with the vr-device and exit the extra Telnet session using the exit
command..

b1@vr-device> exit
Connection closed by foreign host.
b1@vr-device>

Part 3: Pool-Based Destination NAT

In this lab part, you will 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.

In this part you will only configure device 1 in your assigned POD!

Step 3.1
Enter configuration mode and navigate to the [edit security nat destination] hierarchy.
[lab@host1-d> configure
Entering configuration mode
[edit]
lab@host1-d# edit security nat destination
[edit security nat destination]
lab@host1-d#

Step 3.2
Configure a destination NAT pool named webserver that contains a single host address. The host
address should match the IP address of the virtual router associated with the eng zone since you
are configuring to device nr. 1 (host1-X) in your POD.

[edit security nat destination]

lab@host1-d# set pool webserver address 172.20.207.10/32

JNCIS-SEC Bootcamp

Step 3.3
Configure a destination NAT rule-set named from-internet. The associated context should be
from the untrust zone.

[edit security nat destination]

lab@host1-d# set rule-set from-internet from zone untrust

Step 3.4
Under the from-internet rule-set, configure a destination NAT rule named 1. The rule should
apply destination NAT to traffic that originates from the network associated with your SRX host2-X
ge-0/0/3 interface and that has your loopback address as its destination. This translation should
utilize the webserver pool you configured.
[edit security nat destination]
lab@host1-d# edit rule-set from-internet rule 1
[edit security nat destination rule-set from-internet rule 1]
lab@host1-d# set match source-address 172.18.2/30
[edit security nat destination rule-set from-internet rule 1]
lab@host1-d# set match destination-address 192.168.1.1/32
[edit security nat destination rule-set from-internet rule 1]
lab@host1-d# set then destination-nat pool webserver
[edit security nat destination rule-set from-internet rule 1]
lab@host1-d# up 2
[edit security nat destination]
lab@host1-d# show
pool webserver {
address 172.20.207.10/32;
}
rule-set from-internet {
from zone untrust;
rule 1 {
match {
source-address 172.18.2.0/30;
destination-address 192.168.1.1/32;
}
then {
destination-nat pool webserver;
}
}
}
Question: Are any changes required to your security policy configuration to allow this
traffic?

10

JNCIS-SEC Bootcamp

Answer: Yes. Currently, no security policy exists in the configuration that allows traffic
from the untrust zone to the eng zone.

Step 3.5
Navigate to the [edit security policy from-zone untrust to-zone zone-name],
where zone-name is the eng of your assigned device.

[edit security nat destination]

lab@host1-d# top edit security policies from-zone untrust to-zone eng
[edit security policies from-zone untrust to-zone eng]
lab@host1-d#

Step 3.6
Configure a security policy that allows HTTP and Telnet traffic sourced from your other PODs
device 2 (host2-X) to reach the virtual router associated with the eng zone. The necessary address
book entries should already exist in your zone configuration hierarchies. Name the new security
policy webserver.

[edit security policies from-zone untrust to-zone eng]

lab@host1-d# top show security zones security-zone untrust address-book
address vr108 172.20.108.0/24;
address vr208 172.20.208.0/24;
address host2-d 172.18.2.0/30;
address internet-host 172.31.15.1/32;
[edit security policies from-zone untrust to-zone eng]
lab@host1-d# top show security zones security-zone eng address-book
address vr207 172.20.207.0/24;
[edit security policies from-zone untrust to-zone eng]
lab@host1-d# set policy webserver match source-address host2-d
[edit security policies from-zone untrust to-zone eng]
lab@host1-d# set policy webserver match destination-address vr207
[edit security policies from-zone untrust to-zone eng]
lab@host1-d# set policy webserver match application junos-telnet
[edit security policies from-zone untrust to-zone eng]
lab@host1-d# set policy webserver match application junos-http
[edit security policies from-zone untrust to-zone eng]
lab@host1-d# set policy webserver then permit
[edit security policies from-zone untrust to-zone eng]
lab@host1-d# show
policy webserver {

11

JNCIS-SEC Bootcamp
match {
source-address host2-d;
destination-address vr207;
application [ junos-telnet junos-http ];
}
then {
permit;
}
}

Step 3.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>

Part 4: Monitoring Pool-Based Destination NAT

In this part you will monitor the effect of the configured Pool-based Destination NAT.

____________________________ Note__________________________
The next lab steps require you to log in to the virtual router attached to your SRX
device. At this point in time you are already familiar with the functionality of this
device in our lab environment and how to log into it. 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.
__________________________________________________________________

Step 4.1
If you still have your session opened to the vr-device from the previous lab steps, go ahead and
skip to step 4.2. If not, open a separate ssh session to the Jump Server (ssh js2.lab2.cavellgroup.com
using port 7037) and from there launch a telnet session to the virtual router device

[luis@js2 ~]$ telnet 10.210.x.139

Trying 10.210.14.139...
Connected to 10.210.14.139 (10.210.14.139).
Escape character is '^]'.
vr-device (ttyp0)
login:

12

JNCIS-SEC Bootcamp

____________________________ Note _________________________

The x value depends on the pod you have been assigned. PODs A,B,C & D have
and address of 10.210.14.139 whereas PODs E,F,G & H use 10.210.8.139
Refer to your lab diagram for the IP address of your vr-device
__________________________________________________________________

Log in to the virtual router attached to your srx device using the login information shown in the
following table:

Virtual Router Login Details

Student Device

Username

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

Here is a login example corresponding to the host1-d virtual router. Observe that you have only
very limited access to the virtual device and should follow the lab instructions as written very strictly.

[luis@js2 ~]$ telnet 10.210.14.139

Trying 10.210.14.139...
Connected to 10.210.14.139 (10.210.14.139).
Escape character is '^]'.
vr-device (ttyp0)
login: d1
Password:
--- JUNOS 10.3R1.9 built 2010-08-13 12:12:19 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>

13

JNCIS-SEC Bootcamp

Step 4.2
Open a Telnet session to the loopback address of device 1 in your POD. Source the session from
the vr-devices routing instance belonging to your PODs device 2 (host2-X).

d1@vr-device> telnet 192.168.1.1 routing-instance vr108

Trying 192.168.1.1...
Question: From your observations, is destination NAT operating correctly on your
partnering teams assigned device?

Answer: As displayed above the Telnet session cannot be established from vr108 (DC
Zone) to device 1s loopback address.

Question: Why did the Telnet session fail to connect?

Answer: Recall that source NAT in device 2 is configured only when destination of
packets is 172.31.15.1/32.

Step 4.3
Modify the source NAT rule in your PODs device 2 (host2-X) and add your PODs device 1s
(host1-X) loopback address to the destinations.
[edit]
lab@host2-d# edit security nat source rule-set internet-bound
[edit security nat source rule-set internet-bound]
lab@host2-d# show
from interface [ ge-0/0/4.108 ge-0/0/4.208 ];
to zone untrust;
rule 1 {
match {
destination-address 172.31.15.1/32;
}
then {
source-nat {
interface;
}
}
}
[edit security nat source rule-set internet-bound]
lab@host2-d# set rule 1 match destination-address 192.168.1.1/32

14

JNCIS-SEC Bootcamp
[edit security nat source rule-set internet-bound]
lab@host2-d# show
from interface [ ge-0/0/4.108 ge-0/0/4.208 ];
to zone untrust;
rule 1 {
match {
destination-address [ 172.31.15.1/32 192.168.1.1/32 ];
}
then {
source-nat {
interface;
}
}
}
Do not forget to commit your configuration changes:

[edit security nat source rule-set internet-bound]

lab@host2-d# commit and-quit
commit complete
Exiting configuration mode
lab@host2-d>

Step 4.4
Try again to establish the Telnet session from vr108 routing-instance to device 1s loopback address.

d1@vr-device> telnet 192.168.1.1 routing-instance vr108

Trying 192.168.1.1...
Connected to 192.168.1.1.
Escape character is '^]'.
vr-device (ttyp3)
login: d1
Password: lab123
--- JUNOS 10.3R1.9 built 2010-08-13 12:12:19 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>
Question: Why did the device 1 not respond to the Telnet request and instead the remote
virtual router did?

15

JNCIS-SEC Bootcamp
Answer: Recall that destination NAT occurs before routing and policy checks in the
packet flow. So the destination address of the packet in device 1 is 172.20.207.10 instead
of 192.168.1.1.

Step 4.5
Issue the show security flow session command and answer the question that follows.

lab@host1-d> show security flow session

Session ID: 36867, Policy name: webserver/10, Timeout: 1212
In: 172.18.2.2/64508 --> 192.168.1.1/23;tcp, If: ge-0/0/3.0
Out: 172.20.207.10/23 --> 172.18.2.2/64508;tcp, If: ge-0/0/4.207
Session ID: 37013, Policy name: self-traffic-policy/1, Timeout: 1800
In: 10.210.14.130/56662 --> 10.210.14.137/23;tcp, If: ge-0/0/0.0
Out: 10.210.14.137/23 --> 10.210.14.130/56662;tcp, If: .local..0
2 sessions displayed
Question: What sessions are present in the session table?

Answer: As displayed in the output there are two flows currently active. One is the Telnet
session from vr208 (source NATed to 172.18.2.2) to 192.168.1.1 where we see the
return traffic being sent from 172.20.207.10 to 172.18.2.2. The other session seen is the
Telnet session active from the Jump Server to the management interface ge-0/0/0 of
this device.

Step 4.6
Issue the show security nat destination pool all command and answer the question
that follows.
lab@host1-d> show security nat destination pool all
Total destination-nat pools: 1
Pool name
:
Pool id
:
Total address
:
Translation hits:
Address range
172.20.207.10 -

webserver
1
1
1
172.20.207.10

Port
0

Question: Are translation hits present for your destination NAT pool?

Answer: Yes. There is one hit corresponding to the initiated Telnet session destined for
your loopback IP address. The translation hits counter should show one hit.

16

JNCIS-SEC Bootcamp

Step 4.7
Return to the initial session opened to your device and exit the Telnet session opened with the
remote virtual router.
d1@vr-device> exit
Connection closed by foreign host.
d1@vr-device>

STOP

You have completed Lab 3 !

17