Juniper SRX Firewall Configuration: From Zones and NAT to Working Traffic

The fastest way to understand an SRX configuration is to follow one connection from a known client to a known server. When that connection works, expand the design deliberately. When it fails, inspect the first missing dependency instead of changing several unrelated settings at once.

This guide uses an original, narrowly scoped lab to explain interfaces, zones, policy and source NAT. It is not a complete production configuration, a hardware benchmark or a replacement for the documentation for your Junos release. Commands are illustrative and have not been executed on a physical SRX for this article. The cover depicts conceptual equipment.

Start with One Connection

Write the expected connection in ordinary language: “Client 10.20.30.10 may initiate HTTPS to the lab server 203.0.113.80 through this firewall.” Then identify the ingress interface, route, egress zone, policy and translation required to make that statement true. Keep the return path visible in the drawing.

Juniper security policies match transit traffic within a source-zone and destination-zone context. Host-inbound settings control services reached on the SRX itself. Mixing these two questions often leads to an unnecessary management exposure without fixing the client connection. Allowing SSH to the firewall is not the same action as allowing a workstation through it.

If you are still selecting hardware, first use our SRX series comparison. Configuration syntax alone does not establish that a model can handle a particular inspected workload.

Define the Lab Before Entering Commands

The WAN and server addresses are documentation addresses, not public services you can reach on the internet. Build the corresponding lab network or substitute your approved addressing. Use a test hostname and certificate arrangement appropriate to that lab; a certificate-name error is different from a network timeout.

Begin with working console access and an existing secured administrator account. Inspect the current configuration, interface modes, policies and NAT rules. The example assumes the chosen ports are available Layer 3 interfaces in a standalone IPv4 flow-mode lab. A factory switch configuration, an IRB-based LAN or a chassis cluster requires a different interface design. Do not clear a working configuration simply to make the example fit.

Give the Packet a Routed Path

The following commands are entered in configuration mode. They define the two routed interfaces, the lab default route and zone membership. Review interface names against the actual hardware before applying them.

set interfaces ge-0/0/0 unit 0 family inet address 192.0.2.2/30
set interfaces ge-0/0/1 unit 0 family inet address 10.20.30.1/24
set routing-options static route 0.0.0.0/0 next-hop 192.0.2.1
set security zones security-zone LAB-TRUST interfaces ge-0/0/1.0
set security zones security-zone LAB-UNTRUST interfaces ge-0/0/0.0

These lines do not configure the client, the upstream router or DNS. Keep those responsibilities explicit. An interface can be physically up while the client's gateway is wrong or the upstream router lacks the route needed to return the response.

Permit the Intended Flow

Use address objects for the single test client and server. This makes the example easy to inspect and avoids an unrestricted outbound policy while establishing the baseline.

set security address-book global address LAB-CLIENT 10.20.30.10/32
set security address-book global address LAB-WEB 203.0.113.80/32
set security policies from-zone LAB-TRUST to-zone LAB-UNTRUST policy LAB-HTTPS match source-address LAB-CLIENT
set security policies from-zone LAB-TRUST to-zone LAB-UNTRUST policy LAB-HTTPS match destination-address LAB-WEB
set security policies from-zone LAB-TRUST to-zone LAB-UNTRUST policy LAB-HTTPS match application junos-https
set security policies from-zone LAB-TRUST to-zone LAB-UNTRUST policy LAB-HTTPS then permit
set security policies from-zone LAB-TRUST to-zone LAB-UNTRUST policy LAB-HTTPS then log session-close

Review the surrounding policy order. Junos applies the first matching policy, so an earlier rule can change the outcome even when the new stanza is correct. The predefined HTTPS application is a basic service match; this example does not configure TLS decryption, threat prevention or URL filtering. Logging also needs an appropriate platform-specific destination before you can rely on retained records.

Translate Only Where Required

For this lab, translate the test client's source to the egress interface address. The NAT match is deliberately limited to the same client and server so that an unexpected test does not silently exercise a broader rule.

set security nat source rule-set LAB-SNAT from zone LAB-TRUST
set security nat source rule-set LAB-SNAT to zone LAB-UNTRUST
set security nat source rule-set LAB-SNAT rule LAB-WEB match source-address 10.20.30.10/32
set security nat source rule-set LAB-SNAT rule LAB-WEB match destination-address 203.0.113.80/32
set security nat source rule-set LAB-SNAT rule LAB-WEB then source-nat interface

Source NAT changes the address used for the matching session; it does not grant policy permission. Conversely, a permit policy does not provide translation. In an internal routed network with an appropriate return route, translation might not be required at all. Decide that from the addressing design, not from the habit of enabling NAT everywhere.

Commit with a Verification Window

Review the candidate difference and validate syntax before activation. Then use a confirmed commit while you test from the real client:

show | compare
commit check
commit confirmed 10

The ten-minute window is a recovery mechanism, not a proof that the network works. Confirm administrator access, the intended client connection and the restricted scope. Only after those checks, issue commit in configuration mode to retain the change. Coordinate other sessions and automation: a separate confirming commit can remove the rollback protection before your checks finish.

Find the First Broken Dependency

Run these read-only checks from operational mode and generate a fresh client connection while observing the result:

show interfaces terse
show route 203.0.113.80
show security policies from-zone LAB-TRUST to-zone LAB-UNTRUST
show security nat source rule all
show security flow session source-prefix 10.20.30.10/32
show system commit

A ping from the SRX is supporting evidence, not a substitute for the client test. Likewise, one successful flow does not validate unrelated destinations or protocols. Record the exact source, destination and time so the session output and logs can be correlated.

What Changes Before Production

Replace the lab requirement with the approved application matrix. Add only the services the users need, including a deliberate DNS design. Review management access, authentication, IPv6, logging, backups, software maintenance and any subscription-based security services. An HA or VPN project needs its own design and test plan.

The adjacent switch matters too: use our Juniper EX switching guide to keep VLAN and uplink responsibilities clear. For hardware and support budgeting, consult the Juniper price-list catalog and match the exact model, licenses and service terms.

Keep a short handover containing the approved flows, interface map, tested software version, recovery procedure and verification results. That document turns a successful lab session into something another administrator can maintain.

Official Sources

• Juniper: security policy configuration and ordering
• Juniper: source NAT and interface translation
• Juniper: host-inbound system services
• Junos commit command and confirmed rollback
• Juniper: inspect sessions by source prefix