GNS3 Juniper SRX Lab And CLI Commands - Part 1

I have done a few projects with Juniper SRX firewalls. They are very different from Cisco, especially the CLI. But they are fun once you understand some basics.

I used the CBTNuggets JNCIA and JNCIS-SEC to further get a good grip on the Juniper family.

This is the GNS3 lab I used during my studies. The SRX is running inside of Oracle VirtualBOX which has direct integration with GNS3. You can follow this simple tutorial on setting it up.GNS3 and VirtualBOX are both free and you can get the SRX image by doing some googling for "juniper vsrx mega.nz".


Some GNS3 quirks to keep in mind:

• Remember to use increase the number of NICs and use the paravirtualized network setting for SRX NICs in GNS3.
• At times everything looks great but the SRX won't respond to pings, so you may have to just shutdown GNS3 and VB and restart(NOT THE PC!) the whole thing.
• Similarly the interfaces don't show up in the "show interfaces terse" command the first time you initialize them, so again you have to restart(AGAIN—NOT THE PC!) the whole thing.
• To simulate external networks and servers(e.g. DMZ), you can simply use a Cisco IOS router in GNS3 and enable telnet, SSH, HTTP services which you can then hit through the SRX by creating the required firewall security policies.
• You can simulate end users with windows PCs in VirtualBOX and use them for testing purposes.
• To connect your own host to the SRX use the GNS3 cloud and add your current WI-FI/LAN adapter to the cloud and add additional IPs your NIC separate from your actual network subnet. This gives you web-mgmt and putty access then which much more comfortable than simply using the VirtualBOX console.
• The SRX interfaces are names as ethernet 0,1 and so on, just right-click and rename them.

Don't let this discourage you, just get it set up once and you are good to go. With that we can start with some config!

We begin the SRX base config which begins with the configuration of the security zones and interfaces. Let's configure the trusted zone(aka inside network in Cisco speak).

Interfaces in JunOS are separated into physical and logical components. All the configuration parameters like the IP address are done on the logical interface by assigning an unit to the physical interface, most often unit 0 is used.  

## statements are my comments, do not copy them!

INTERFACE and ZONES CONFIG

#to assign logical interface and IP address to an interface
admin@SRX1# set interfaces ge-0/0/1 unit 0 family inet address 192.168.3.1/24
admin@SRX1# commit # Juniper only applies new changes after the commit

 The unit 0 can be replaced with . as below

#to assign logical interface and IP address to an interface 
admin@SRX1# set interfaces ge-0/0/1.0 family inet address 192.168.3.1/24
admin@SRX1# commit #as stated, commit is must everytime!

The interface then must be assigned to a zone - trust and untrusted are the default zones. We assign ge-0/0/1 to the trust zone.

admin@SRX1# set security zones security-zone trust interfaces ge-0/0/1

To enable ping, SSH, HTTP and HTTPS on the interface we need to enable it on the physical interface and the logical interface. The physical interface settings take precedence over the logical interface settings.

admin@SRX1# set security zones security-zone trust interfaces ge-0/0/1 host-inbound-traffic system-services ping
admin@SRX1# set security zones security-zone trust interfaces ge-0/0/1.0 host-inbound-traffic system-services ping
admin@SRX1# commit

Similarly SSH, HTTP, HTTPS etc can be allowed on the interface.

To see the config on the ge-0/0/1 interface we can use the following show commands.

admin@SRX1# show interfaces ge-0/0/1
unit 0 {
    family inet {
        address 192.168.3.1/24;
    }
}

#"run" is used to execute a operator mode command in the config mode
admin@SRX1# run show configuration interfaces
ge-0/0/0 {
    unit 0 {
        family inet {
            address 192.168.2.1/24;
        }
    }
}
ge-0/0/1 {
    unit 0 {
        family inet {
            address 192.168.3.1/24;
        }
    }
}
ge-0/0/2 {
    unit 0 {
        family inet {
            address 172.16.1.1/24;
        }
    }
}

[edit]
admin@SRX1# run show interfaces ge-0/0/1 brief
Physical interface: ge-0/0/1, Enabled, Physical link is Up
  Link-level type: Ethernet, MTU: 1514, Speed: 1000mbps, Loopback: Disabled,
  Source filtering: Disabled, Flow control: Enabled, Auto-negotiation: Enabled,
  Remote fault: Online
  Device flags   : Present Running
  Interface flags: SNMP-Traps Internal: 0x4000
  Link flags     : None

  Logical interface ge-0/0/1.0
    Flags: SNMP-Traps 0x4000 Encapsulation: ENET2
    Security: Zone: trust
    Allowed host-inbound traffic : http https ping ssh telnet
    inet  192.168.3.1/24

Juniper needs some additional config for web-management along with allowing it on both the logical and physical interface.

admin@SRX1# set system services web-management http
admin@SRX1# set system services web-management https
admin@SRX1# set system services web-management https system-generated-certificate
admin@SRX1# commit

There's not interface mentioned in the above commands, doesn't mean they are activated on all interfaces but only on the ones already allow the protocols http, https etc. SSH is allowed by default by just allowing it on the logical and physical interface.

The system services allowed can be viewed as show here:

admin@SRX1# run show configuration | match "set system services" | display set
set system services ssh
set system services telnet
set system services web-management http interface ge-0/0/0.0
set system services web-management https system-generated-certificate
set system services dhcp pool 172.16.1.0/24 address-range low 172.16.1.50
set system services dhcp pool 172.16.1.0/24 address-range high 172.16.1.60
set system services dhcp pool 172.16.1.0/24 default-lease-time infinite
set system services dhcp pool 172.16.1.0/24 domain-name maslab.com
set system services dhcp pool 172.16.1.0/24 name-server 8.8.8.8
set system services dhcp pool 172.16.1.0/24 router 172.16.1.1 

The Inside-R at 192.168.3.2/24 is a Cisco router which we can use to ping, ssh, telnet to the ge-0/0/1 interface to test our config. And goes without saying never enable telnet in an production environment!

GNS3 doesn't have any other telnet and ssh client as of now, I can also test this using the "allwyn" PC (my host machine) and the WIN7 on VB at 192.168.3.50/24. Below is the output from Inside-R.

Inside-R#show ip interface brief
Interface                  IP-Address      OK? Method Status                Protocol
FastEthernet0/0            192.168.3.2     YES NVRAM  up                    up
FastEthernet0/1            unassigned      YES NVRAM  administratively down down
Serial1/0                  unassigned      YES NVRAM  administratively down down
Serial1/1                  unassigned      YES NVRAM  administratively down down
Serial1/2                  unassigned      YES NVRAM  administratively down down
Serial1/3                  unassigned      YES NVRAM  administratively down down

Inside-R#ping 192.168.3.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.3.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/12/20 ms

Inside-R#ssh -l admin 192.168.3.1

Password:
--- JUNOS 12.1X47-D15.4 built 2014-11-12 02:13:59 UTC
admin@SRX1>

With this we confirm that the inside/trusted part is configured. 

Now we can configure the outside/untrusted and DMZ interfaces similarly and create security policies.

SECURITY POLICY CONFIG

Once you get the ge-0/0/0 interface set up just as we did above and assign it to the untrust zone, we can start creating policies from the Trust-Zone to the Untrust-Zone.

Policies in SRX are created between zones. To view policies from trust to untrust zone.

admin@SRX1# run show security policies from-zone trust to-zone untrust
From zone: trust, To zone: untrust
   Policy: default-permit, State: enabled, Index: 6, Scope Policy: 0, Sequence number: 2
    Source addresses: any
    Destination addresses: any
    Applications: any
    Action: permit

This is the default policy which allows all traffic from trust to untrust zone. For this lab I will set this to deny-all and then create custom user defined policies to only allow required services like ping, ssh, http etc for our testing purposes and log it as well.

*this puts you in the security policy context
admin@SRX1# edit security policies from-zone trust to-zone untrust

#edit is a really helpful way to jump around the different heirarchies of the JunOS and really narrow down the length and scope of commands both for configuration and during troubleshooting.

[edit security policies from-zone trust to-zone untrust]
admin@SRX1# set policy IN-OUT match source-address any destination-address any application junos-ping application junos-http application junos-ssh
admin@SRX1# set policy IN-OUT then permit
admin@SRX1# set policy IN-OUT then log session-close session-init
admin@SRX1# commit

The policy is created, but we have to change the order of the policies. Policies work top-down. We must put our policy before the default policy.

[edit security policies from-zone trust to-zone untrust] 
admin@SRX1#  top #brings to the top heirarchy in the OS
[edit]
admin@SRX1# insert security policies from-zone trust to-zone untrust policy IN-OUT before policy default-permit

And now viewing the policies again, we see our custom user defined IN-OUT policy is before the default with logging enabled and permits only a few chosen services.

[edit security policies from-zone trust to-zone untrust]
admin@SRX1# show
policy IN-OUT {
    match {
        source-address any;
        destination-address any;
        application [ junos-telnet junos-ping junos-http junos-ssh ];
    }
    then {
        permit;
        log {
            session-init;
            session-close;
        }
        count;
    }
}
policy default-permit {
    match {
        source-address any;
        destination-address any;
        application any;
    }
    then {
        deny;
    }
}

To test this policy I have put a Cisco IOS router on the outside/untrusted network at 192.168.2.2/24 with some services enabled. Here's the cisco config if you need to replicate this.

And here's our results for testing from from Inside-R router.

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 100 percent (5/5), round-trip min/avg/max = 20/21/28 ms

Inside-R#telnet 192.168.2.2
Trying 192.168.2.2 ... Open

User Access Verification

Password:
Outside-R>who #shows our connected user
    Line       User       Host(s)              Idle       Location
* 98 vty 0                idle                 00:00:00 192.168.3.2

  Interface    User               Mode         Idle     Peer Address

Outside-R>ssh -l bob 192.168.2.2

Password:

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

  Interface    User               Mode         Idle     Peer Address

As we can see the incoming IP of 192.168.3.2 this shows that our connection is not NATed by the SRX yet and so the router on the outside needs to have a route to the inside network, in this case the SRX is the default gateway for it.

I will stop this part here and in another post we will see some more config on the SRX.