DEVNET.

Basic Juniper SRX Setup

This guide goes over the basics for setting up a Juniper SRX firewall. The bullet points below identify what is covered in this article.

Root password setup
Basic IP address configration
Remote access managment: HTTP & HTTPS setup (for J-Web browser application), and SSH
Ping to the SRX
Basic security zone & policy configuration. I will permit R2 (untrust zone) to ping R1 (trust zone)
Note: The SRX I’m using is a virtual platform on GNS3, and has been loaded with factory default configuration.

Diagarm

Basic_Juniper_SRX_Setup

Root password configuration:
Before you can commit any configuration, a root password must be set.

set system root-authentication plain-text-password
#type-in-your-password

IP address configuration
See the topology for IP address details.

set interfaces ge-0/0/0.0 family inet address 10.99.0.254/24
set interfaces ge-0/0/1.0 family inet address 192.168.0.254/24
set interfaces ge-0/0/2.0 family inet address 13.0.0.254/24
commit

root# run show interfaces terse | match ge
ge-0/0/0 up up
ge-0/0/0.0 up up inet 10.99.0.254/24
ge-0/0/1 up up
ge-0/0/1.0 up up inet 192.168.0.254/24
ge-0/0/2 up up
ge-0/0/2.0 up up inet 13.0.0.254/24

HTTP, HTTPS, SSH, and Ping Configuration
To understand how to configure these settings, you have to understand very basic security zones. From the output below, you can see that there are two zones by default: “trust” and “untrust”.

root# show security zones
security-zone trust {
tcp-rst;
}
security-zone untrust {
screen untrust-screen;
interfaces {
ge-0/0/0.0 {
host-inbound-traffic {
system-services {
http;
https;
ssh;
telnet;
dhcp;
As you can see, ge-0/0/0.0 has (by default on this platform) been allocated to the untrust zone. This is my management interface, and I want to apply it to the trust zone. First I have to delete it out the untrust zone.

edit security zones security-zone untrust
delete interfaces ge-0/0/0.0
commit

exit

root# run show security zones
security-zone trust {
tcp-rst;
}
security-zone untrust {
screen untrust-screen;
Now I need to add ge-0/0/0.0 to the trust zone and allow management access to the box.

edit security zones security-zone trust
set interfaces ge-0/0/0.0
set interfaces ge-0/0/0.0 host-inbound-traffic system-services ping
set interfaces ge-0/0/0.0 host-inbound-traffic system-services http
set interfaces ge-0/0/0.0 host-inbound-traffic system-services https
set interfaces ge-0/0/0.0 host-inbound-traffic system-services ssh
Note: I also included ping traffic to the SRX because by default, it is not possible the firewalls interface.

Next, a admin user account needs to be configured.

set system login user test class super-user authentication plain-text-password
#type-in-your-password
commit
Finally, for https to work, you just need to create a certificate. Here I use a self-signed certificate as I am only in a lab.

set system services web-management https system-generated-certificate
commit
Everything is now available.

Basic Security Zones and Policies
I want to configure R2 to be part of an untrusted zone, R1 as part of a trusted zone, then allow R2 to ping R1. Let’s take a re-cap on what our zones look like so far:

test# show security zones
security-zone trust {
tcp-rst;
interfaces {
ge-0/0/0.0 {
host-inbound-traffic {
system-services {
ping;
http;
ssh;
https;
}
}
}
}
}
security-zone untrust {
screen untrust-screen;
So we have two zones, trust and untrust with ge-0/0/0.0 allocated to the trust zone. Let’s add ge-0/0/1.0 to the trust zone, and ge-0/0/2.0 to the untrust zone.

test# edit security zones
set security-zone trust interfaces ge-0/0/1.0
set security-zone untrust interfaces ge-0/0/2.0
commit
We need to understand what policies are in use for communication between these zones, so let’s look at the current (factory default) configuration.

test# show security policies
from-zone trust to-zone trust {
policy default-permit {
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
}
}
}
from-zone trust to-zone untrust {
policy default-permit {
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
}
}
}
from-zone untrust to-zone trust {
policy default-deny {
match {
source-address any;
destination-address any;
application any;
}
then {
deny;
}
}
}
This is similar to most firewalls. Basically:

Trusted to Trusted = Permit
Trusted to Untrusted = Permit
Untrusted to Trusted = Deny
So let’s configure a security policy that allows a simple ping from the R2 (untrust zone) to R1 (trust zone). The first thing to do is make an address book for each host under the relevant security-zone.

set security zones security-zone trust address-book address R1 192.168.0.1/32
set security zones security-zone untrust address-book address R2 13.0.0.1/32
Address books are simply a way of naming a host within a zone (or globally if required). Address books are used as a point of reference within any security policy configuration.

Now to create the policy:

edit security policies from-zone untrust to-zone trust
set policy R2_TO_R1_POLICY match source-address R2
set policy R2_TO_R1_POLICY match destination-address R1
set policy R2_TO_R1_POLICY match application junos-icmp-ping
set policy R2_TO_R1_POLICY then permit
commit
Now annoyingly, the new policy is actually created underneath any existing security policy for that zone. So if we take a look at the security policy as it stands you will see what I mean:

test# show security policies from-zone untrust to-zone trust
policy default-deny {
match {
source-address any;
destination-address any;
application any;
}
then {
deny;
}
}
policy R2_TO_R1_POLICY {
match {
source-address R2;
destination-address R1;
application junos-icmp-ping;
}
then {
permit;
}
}
Basically if I left the configuration like this, everything would be denied by the first policy. What needs to happen is the new policy needs to be inserted before the default deny rule. Let’s do it.

edit security policies from-zone untrust to-zone trust
insert policy R2_TO_R1_POLICY before policy default-deny
The policy is then re-ordered, as shown below:

test# show security policies from-zone untrust to-zone trust
policy R2_TO_R1_POLICY {
match {
source-address R2;
destination-address R1;
application junos-icmp-ping;
}
then {
permit;
}
}
policy default-deny {
match {
source-address any;
destination-address any;
application any;
}
then {
deny;
}
}
Done.

Share:

Share on facebook
Facebook
Share on twitter
Twitter
Share on linkedin
LinkedIn

Leave a Reply

Your email address will not be published. Required fields are marked *

Become a member

Full Access to 739 Lessons. New Lessons Added Every Week!

Awesome Deal! Get 2 Months for FREE!

No Obligations. Cancel At Any Time!