Juniper SRX Firewall Configuration: 14-Step Guide

2026年8月29日 LOG admin

Setting up a Juniper SRX for internet connectivity is a well-defined sequence of configuration blocks — get the zones, policies and NAT right and everything else follows. This 14-step guide walks through a production SRX deployment from console access to firmware upgrade, with the exact set commands for each stage, suitable for both first-time SRX users and engineers refreshing their Junos firewall skills.

Before Step 1: What You Need on the Bench

The SRX family covers a very wide range: branch boxes such as the SRX300/320/345, mid-range SRX1500 and SRX4100, and the virtual vSRX. The configuration below applies to all of them with two adjustments — the interface names (ge-0/0/x on branch models, ge-0/0/x or xe- on the larger chassis) and whether the unit is a chassis cluster member. A brand-new SRX ships in factory-default mode, where all interfaces are in the trust zone, DHCP is running on the untrust side on some models, and a default permit-all policy lets the branch office work out of the box. That default is fine for a lab and unacceptable for production, which is why the first thing this guide does is remove it.

Have ready: a console cable and a terminal at 9600-8-N-1, the public WAN addressing from your ISP (IP, mask, next hop), the LAN subnet plan, and the firmware image you intend to run. Note the serial number; you will need it for licensing if the unit requires advanced security features.

Steps 1-4: Initial Access and Identity

Connect via console (Putty or similar), take the SRX out of factory state, and set the root password — by default there is no root password on SRX, so this is mandatory. Create an operational account and set the hostname:

set system root-authentication plain-text-password
set system login user admin class super-user authentication plain-text-password
set system host-name srx-internet
commit

A common alternative for a new device is load factory-default followed by delete system autoinstallation and commit, which gives you a clean, known base instead of a half-configured branch default. Do that first if the unit has any history. Junos will not let you commit a configuration that has no root password, so if commit refuses with an authentication error, that is the reason. Also set the interface you are using for management into a management zone before you remove the factory configuration, or you will lock yourself out of the box at the next commit.

Steps 5-8: SSH, DNS, Time and NTP

set system services ssh
set system services ssh root-login deny
set system name-server 8.8.8.8
set system name-server 1.1.1.1
set system time-zone Asia/Shanghai
set system ntp server 203.0.113.1
commit

Accurate time on the firewall matters for logging correlation and certificate validation — configure NTP before the device handles production traffic. If the NTP server is reachable only through the internet path you have not built yet, configure it now anyway and revisit it after Step 13; the SRX retries and will sync once the route and NAT exist. Verify the clock rather than assuming it worked:

show system uptime
show ntp associations
show ntp status
show system services

If you intend to manage the box over SSH from an internal subnet only, pair host-inbound-traffic on the management zone with an explicit policy; by default SSH is listened for but the zone must allow it.

set security zones security-zone MGMT host-inbound-traffic system-services ssh
set security zones security-zone MGMT host-inbound-traffic system-services ping

Steps 9-11: Zones, Interface IPs and Security Policies

set security zones security-zone EXTERNAL-ZONE interfaces ge-0/0/1
set security zones security-zone INTERNAL-ZONE interfaces ge-0/0/2
set interfaces ge-0/0/1 unit 0 family inet address 203.0.113.10/30
set interfaces ge-0/0/2 unit 0 family inet address 192.168.1.1/24
set security policies from-zone INTERNAL-ZONE to-zone EXTERNAL-ZONE policy INTERNET-RULE \
  match source-address any destination-address any application junos-https permit

Zone-based policy is the SRX security model: traffic between zones is denied by default, so every permitted flow needs an explicit policy. The minimal internet policy needs at least three applications — web, secure web and DNS — and a matching return path, which is why the standard approach is to permit a named application set rather than a single application:

set applications application-set INTERNET-APPS application junos-http
set applications application-set INTERNET-APPS application junos-https
set applications application-set INTERNET-APPS application junos-dns-udp
set applications application-set INTERNET-APPS application junos-dns-tcp
set applications application-set INTERNET-APPS application junos-ping
set security policies from-zone INTERNAL-ZONE to-zone EXTERNAL-ZONE policy INTERNET-RULE \
  match source-address any destination-address any application INTERNET-APPS
set security policies from-zone INTERNAL-ZONE to-zone EXTERNAL-ZONE policy INTERNET-RULE then permit
set security policies from-zone INTERNAL-ZONE to-zone EXTERNAL-ZONE policy INTERNET-RULE then log session-init
commit

Traffic that the firewall itself originates — NTP, DNS lookups, firmware downloads — is governed by host-inbound-traffic on the interface’s zone, not by a security policy. That distinction is the source of a large share of “the policy is right but the box cannot resolve” tickets. If you need the SRX to reach the internet for its own services, allow them explicitly on the external zone.

Steps 12-13: Routing and Source NAT

set routing-options static route 0.0.0.0/0 next-hop 203.0.113.9
set security nat source rule-set SOURCE-NAT-RULE from zone INTERNAL-ZONE to zone EXTERNAL-ZONE
set security nat source rule-set SOURCE-NAT-RULE rule RULE-NAT match source-address 192.168.1.0/24
set security nat source rule-set SOURCE-NAT-RULE rule RULE-NAT then source-nat interface
commit

Source NAT (SNAT) translates private RFC 1918 addresses to the public interface address so internal hosts can reach the internet; destination NAT (DNAT) exposes internal services to the outside. Order matters: the default route must exist before NAT is useful, and NAT must be inside the zone pair that the policy already permits, otherwise the translated packet is dropped on the way back. Verify both directions after the commit rather than testing from a browser.

show route 0.0.0.0/0
show security nat source summary
show security flow session source-prefix 192.168.1.0/24
show security policies hit-count
ping 203.0.113.9 count 5 source 192.168.1.1
ping 8.8.8.8 count 5 source 192.168.1.1

If pings to the ISP next hop work but pings to 8.8.8.8 fail, the problem is usually NAT or a policy in the reverse direction, not routing. If nothing leaves the box at all, check the interface is up and the zone assignment took effect with show interfaces ge-0/0/1 terse and show security zones. For a destination-NAT example — publishing an internal web server — the rule-set is the mirror image of the SNAT rule, plus a policy from the external zone to the internal zone that matches the translated address.

set security nat destination pool WEB-POOL address 192.168.1.10/32
set security nat destination rule-set DNAT-RULE from zone EXTERNAL-ZONE
set security nat destination rule-set DNAT-RULE rule WEB-RULE match destination-address 203.0.113.10/32
set security nat destination rule-set DNAT-RULE rule WEB-RULE then destination-nat pool WEB-POOL
set security policies from-zone EXTERNAL-ZONE to-zone INTERNAL-ZONE policy WEB-IN match source-address any \
  destination-address WEB-SERVER application junos-https
set security policies from-zone EXTERNAL-ZONE to-zone INTERNAL-ZONE policy WEB-IN then permit

Step 14: Upgrade Firmware Safely

Copy the image to /var/tmp/, back up the config, read the release notes, then request system software add /var/tmp/junos-srx.tgz and request system reboot. Always test in a lab before production.

file copy tftp://192.168.1.100/junos-srx.tgz /var/tmp/
request system configuration rescue save
show system storage
request system software add /var/tmp/junos-srx.tgz no-validate
request system reboot

Two habits make this step safe. First, save a rescue configuration (request system configuration rescue save) before the upgrade; if the new image rejects the configuration, rollback rescue restores a known-good state. Second, check free space on /var and remove old images, because a failed upgrade from a full file system is far harder to recover than a failed upgrade from a bad image. Junos upgrades must follow a supported path; do not jump several major releases in one step — stage through the documented intermediate versions. On a chassis cluster, upgrade the secondary node first, verify failover works, then upgrade the primary.

Verifying the Complete Configuration

Run this short checklist after Step 14 to prove the deployment is finished rather than merely committed. Every line should return output you can explain.

show configuration | display set | match "security policies"
show security zones
show security policies
show security nat source summary
show route summary
show chassis alarms
show system alarms
show interfaces terse

Then test from a real host behind the firewall: ping the gateway, ping the ISP next hop, resolve a public name, and open an HTTPS page. That sequence isolates a failure to layer 1, routing, DNS or policy in four steps and saves an hour of show output.

Common Mistakes That Break Internet Access

Interface not in a zone. An interface with an IP address but no zone assignment participates in no policy; the SRX drops everything on it.
Return-direction policy missing. The SRX is stateful, so established return traffic needs no separate policy — but new sessions initiated from the outside (DNAT, ping from the WAN) do.
NAT rule in the wrong zone pair. SNAT must be defined for the same from-zone/to-zone pair the policy permits, or the rule never matches.
Default route missing or pointing at the wrong next hop. Check show route 0.0.0.0/0 before blaming the policies.
host-inbound-traffic not configured. The firewall itself cannot use DNS, NTP or SSH until the zone allows those system services.
Commit rejected silently. commit prints errors above the prompt; always read the output, and use commit check for a dry run.

Quick Answers to the Usual Questions

Do I need a license for source NAT? No. Source NAT, destination NAT and the zone-based policy model are base features on SRX. Licences matter for UTM services (IPS, application security, antivirus).

Can I configure the SRX with a hostname instead of an IP? Not on a branch SRX without a DNS server reachable at commit time; use addresses for interfaces, zones and NAT rules, and use hostnames only for log servers and NTP once name resolution works.

What is the fastest sanity test after Step 13? Ping the ISP next hop from the SRX itself, then ping a public address from a host behind it. The first proves routing, the second proves NAT and policy together.

Is there a GUI? Yes — J-Web for branch SRX and Junos Space Security Director for larger deployments — but the CLI in this guide remains the reference because it is what appears in a support case and what can be scripted.