Lab3-JSEC-NAT_0315

JNCIS-SEC Bootcamp

1

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

2

Lab Diagram

Lab Diagram

srxsrxsrxsrxXXXX----2222srxsrxsrxsrxXXXX----1111

gegegege----0/0/3

0/0/3

0/0/3

0/0/3gegegege----0

/0/3

0/0/

3

0/0/

3

0/0/

3

lo0: 192.168.1.1 lo0: 192.168.2.1

172.

18.1

.0/3

0 172.18.2.0/30

(.1) (.1)

(.2) (.2)

XXXX = Pod = Pod = Pod = Pod

(A, B, C, or D)(A, B, C, or D)(A, B, C, or D)(A, B, C, or D)

Virtual RoutersVirtual RoutersVirtual RoutersVirtual Routers

gegegege----0/0/4.200/0/4.200/0/4.200/0/4.20vvvv

172.20.20v.0/24

(.1)

(.10)

Host 172.31.15.1

Tagged InterfaceTagged InterfaceTagged InterfaceTagged Interface

(see VLAN Assignments table)(see VLAN Assignments table)(see VLAN Assignments table)(see VLAN Assignments table)

VLAN AssignmentsVLAN AssignmentsVLAN AssignmentsVLAN Assignments

((((vvvv=remainder of =remainder of =remainder of =remainder of vlanvlanvlanvlan----id)id)id)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

vr10vr10vr10vr10vvvv

(.10)

172.20.10v.0/24

gegegege----0/0/4.100/0/4.100/0/4.100/0/4.10vvvv


gegegege----0/0/4.200/0/4.200/0/4.200/0/4.20vvvv

172.20.20v.0/24

(.1)

(.10)


(.10)

172.20.10v.0/24

gegegege----0/0/4.100/0/4.100/0/4.100/0/4.10vvvv


HR ZoneHR ZoneHR ZoneHR Zone Eng ZoneEng ZoneEng ZoneEng Zone DC ZoneDC ZoneDC ZoneDC Zone IT ZoneIT ZoneIT ZoneIT Zone

UntrustUntrustUntrustUntrust ZoneZoneZoneZone UntrustUntrustUntrustUntrust ZoneZoneZoneZone

InternetInternetInternetInternet

JNCIS-SEC Bootcamp

3

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

4

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

5

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

6

____________________________ 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 vr-device. 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

7

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



d1@vr-device>

JNCIS-SEC Bootcamp

8

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-set: internet-bound Rule-Id : 1 Rule position : 1 From interface : 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

9

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

10

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?

JNCIS-SEC Bootcamp

11

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 {

JNCIS-SEC Bootcamp

12

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:

JNCIS-SEC Bootcamp

13

____________________________ 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



d1@vr-device>

JNCIS-SEC Bootcamp

14

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

JNCIS-SEC Bootcamp

15

[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



d1@vr-device>

Question: Why did the device 1 not respond to the Telnet request and instead the remote virtual router did?

JNCIS-SEC Bootcamp

16

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 : webserver Pool id : 1 Total address : 1 Translation hits: 1 Address range Port 172.20.207.10 - 172.20.207.10 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.

JNCIS-SEC Bootcamp

17

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 !

Documents

Lab3-JSEC-NAT_0315