These are some posts I wrote while preparing for the JNCIA. They’ll help you setup a lab and work with it and prepare for the certification or just learn juniper – it’s fun!

• GNS3 Juniper SRX Lab And CLI Commands – Part 1
• GNS3 Juniper SRX Lab And CLI Commands – Part 2
• Juniper CLI Modes and Hierarchies

To be updated. .

Part-1 is here.

We will continue with our network diagram, just putting it here for ref.

In part-1 we created policies to allow traffic from the trusted to the untrusted zone without NAT. Let’s do NAT and confirm it on the destination test router Outside-R as well.

We will start with Source NAT using the egress interface, then do it using a pool of IP addresses and also see a weird situation I came across.

Just jump to the config mode and then go to the nat hierarchy:

[edit]
admin@SRX1# edit security nat source rule-set IN-OUT

#”IN-OUT is the rule-set name

[edit security nat source rule-set IN-OUT]
admin@SRX1# set from zone trust

[edit security nat source rule-set IN-OUT]
admin@SRX1# set to zone untrust

[edit security nat source rule-set IN-OUT]
admin@SRX1# edit rule IN-OUT

#the rule name can be same or different, comes under the rule-set

[edit security nat source rule-set IN-OUT rule IN-OUT] #now under “rule” not “rule-set”
admin@SRX1# set match source-address 192.168.3.0/24

[edit security nat source rule-set IN-OUT rule IN-OUT]
admin@SRX1# set match destination-address all

[edit security nat source rule-set IN-OUT rule IN-OUT]
admin@SRX1# set then source-nat interface

#the interface is chosen based on the “to zone” – we’re using “untrusted”

[edit security nat source rule-set IN-OUT rule IN-OUT]
admin@SRX1# commit check
configuration check succeeds

The same can be as below, you can copy this by just pasting to notepad and making your changes and then paste to the CLI

[edit]
admin@SRX1# edit security nat source

[edit security nat source] #make sure you are here in the hierarchy
set rule-set IN-OUT from zone trust
set rule-set IN-OUT to zone untrust
set rule-set IN-OUT rule IN-OUT match source-address 192.168.3.0/24
set rule-set IN-OUT rule IN-OUT match destination-address 0.0.0.0/0
set rule-set IN-OUT rule IN-OUT then source-nat interface

Now goto the Inside-R router to confirm this.

Inside-R#ssh -l bob 192.168.2.2

Password:

Outside-R#who
Line       User       Host(s)              Idle       Location
* 99 vty 1     bob        idle                 00:00:00 192.168.2.1 #the egress interface IP

Interface    User               Mode         Idle     Peer Address

We see our incoming connection on the destination router. This is one reason why GNS3 is so much fun, allows you instant confirmation of your config.

Source NAT Using A Pool

Now instead of using the egress interface we will NAT the source IP address using a per-defined pool of  addresses.

We just change the NAT rule on top for this, but first create the pool.

[edit security nat] #in the security NAT hierarchy
admin@SRX1# set source pool IN-OUT-POOL address 192.168.2.50 to 192.168.2.100

Now go to the above NAT rules and just add pool instead of the interface. It automatically replaces it in the config.

[edit security nat source]
admin@SRX1# edit rule-set IN-OUT

[edit security nat source rule-set IN-OUT]
admin@SRX1# edit rule IN-OUT

[edit security nat source rule-set IN-OUT rule IN-OUT]
admin@SRX1# set then source-nat pool IN-OUT-POOL

#using pool instead of the interface in the last line

[edit security nat source rule-set IN-OUT rule IN-OUT]
admin@SRX1# commit
commit complete

Always, always remember to commit!

Doing the SSH test from Inside-R to the Outside-R again.

IT DOESN’T WORK!

Then I had to troubleshoot and found a post on Juniper forums. It said proxy-arp is not required if the IP pool range is the same as the range of the egress interface, but a different NAT troubleshooting guide yet recommends configuring proxy arp for the pool. In our case 192.168.2.50 to 192.168.2.100.

As below.

[edit]
admin@SRX1# edit security nat proxy-arp

[edit security nat proxy-arp]
admin@SRX1# set interface ge-0/0/0 address 192.168.2.50 to 192.168.2.100 #our egress

And then testing again from the Inside-R

Inside-R#ssh -l bob 192.168.2.2

Password:

Outside-R#who
Line       User       Host(s)              Idle       Location
* 99 vty 1     bob        idle                 00:00:00 192.168.2.62

Interface    User               Mode         Idle     Peer Address

And the weird situation I saw here, which I don’t yet have a reason for is SSH worked but ping doesn’t work!

Inside-R#ping 192.168.2.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.2.2, timeout is 2 seconds:
…..
Success rate is 0 percent (0/5)

This only happens with source NAT using a pool and not when using the egress interface. 

I will definitely get to this and update in the future. Do leave a comment if you have an answer.

This could very be a GNS3 issue because of the proxy-arp or something and have nothing to do with anything else but still SSH has worked, so it’s worth figuring out.

This is too long now and we will do destination NAT in a new post.

The Juniper CLI architecture is indeed really nicely done. No wonder it is the primary method of managing and configuring the Juniper devices. If you are coming from a Cisco background which most of start with then this way of doing things is indeed new, but just spend a few hours and get a GNS3 lab going and it will grow on you in no time.

Here’s the architecture at a glance.

Of course this is not what you see when you login into a new JunOS device.

What we see there is the different modes a user can get into and a hierarchical division in which the configuration can be performed.

The two modes are:

1. The operator mode
2. The configuration mode

Unix Shell

This is NOT really a mode and hence I want to get it out of the way quickly.

Since the Juniper kernel is based on FreeBSD, this is the root shell aka the c shell. On a new device, which only has the root user with no password, this is the prompt (shown by the %) the root user is dropped too.

Of course it’s never recommended t o use this account for anything but the initial setup.

login as: root
Using keyboard-interactive authentication.
— JUNOS 12.1X47-D15.4 built 2014-11-12 02:13:59 UTC

root@SRX1%

The Operator Mode

This mode provides only means to monitoring, troubleshooting and displaying the current status of the device with show commands.

On a new device the root user must use the “cli” command to jump to the operator mode from the c shell. And immediately create admin accounts for the future device configuration.

Any custom user accounts created fall straight to the operator mode prompt which is show my the ‘>’ prompt.

login as: admin
Using keyboard-interactive authentication.
Password:
— JUNOS 12.1X47-D15.4 built 2014-11-12 02:13:59 UTC
admin@SRX1>

The Configuration Mode

This is the mode where an admin would live and breathe. All configuration and changes to the system are done here. As show below, you must use the “configure” or the “edit” command to jump to this mode. Hence for some admins this is also the “edit mode”.

login as: admin
Using keyboard-interactive authentication.
Password:
— JUNOS 12.1X47-D15.4 built 2014-11-12 02:13:59 UTC
admin@SRX1> configure
Entering configuration mode

[edit]
admin@SRX1#

The edit command is also a amazing feature which sets JunOS CLI apart from other CLIs. It can be used as an “cd” command (as in windows cmd) to jump across and into the various configuration hierarchies. This really brings the CLI to life giving you a complete view of where and what is to be configured.

The above figure is a good reference here. Here are some config examples using the edit command and the same config without it.

Here we are setting the host-name for the SRX from the config mode using the set command.

admin@SRX1> configure
Entering configuration mode

admin@SRX1# set system host-name ?
Possible completions:
<host-name>          Hostname for this router

[edit]
admin@SRX1# set system host-name SRX2 #press enter to set the name to SRX2

We can do the same thing using edit to go under the system hierarchy

[edit] #this shows us our current level in the hierarchy which is global
admin@SRX1# edit system

#and here we are under the system hierarchy and only have access to those commands
[edit system]
admin@SRX1# set host-name SRX2

And when you do a show command here, it only shows you the config under that hierarchy which makes troubleshooting extremely smooth and easy!

[edit system]
admin@SRX1# show
host-name SRX1;
root-authentication {
encrypted-password “$1$mEHemrS1$PZOVox.e6.YpxXFLiWZmA.”; ## SECRET-DATA
}
login {
user admin {
uid 2000;
class super-user;
authentication {
encrypted-password “$1$G28me91/$HfoIQrKZBBAMJM3hFfBNE.”; ## SECRET-DATA
}
}
}
services {
ssh;
telnet;
web-management {
http {
interface ge-0/0/0.0;
}
https {
system-generated-certificate;
}
}

Similarly we can go into different levels of the hierarchy and configure just those parameters.

Let’s look at one more example with interfaces. This is using the set command in the global hierarchy.

[edit] #just edit means the global hierarchy
admin@SRX1# set interfaces ge-0/0/0 unit 0 family inet address 192.168.2.1/24

And the same thing can be done with the edit command. Then you do the show command and see the settings just under that interface.

admin@SRX1# edit interfaces ge-0/0/0

[edit interfaces ge-0/0/0] #the interfaces hierarchy
admin@SRX1# show
unit 0 {
family inet {
address 192.168.2.1/24;
}
}

Juniper provides a nice document for further reference on the CLI.