Juniper SRX Security Policy Configuration: Zones to Policy Rules

Juniper SRX security policies are the core mechanism for controlling transit traffic between security zones, and mastering their configuration is essential for any firewall administrator. This guide breaks down the policy elements every SRX rule is built from — source and destination zones, address books, applications, and match-and-action logic — and shows real set commands you can paste into configuration mode. You will learn how to build a complete policy set that allows HTTP, telnet and ICMP while explicitly denying and logging everything else.

Understanding Juniper SRX Security Policy Elements

A security policy on Junos OS is a set of statements that control traffic flowing from a specific source to a specific destination while using a specific service. Each policy is unidirectional and contains:

• A unique policy name
• A from-zone to to-zone direction, for example set security policies from-zone untrust to-zone trust
• Matching criteria based on source/destination IP addresses and applications
• Actions such as permit, deny or reject
• Accounting and auditing options such as count and session logging

Policy Rules and Match Criteria

Each security policy rule is identified by its zone pair and a set of match characteristics: source zone, destination zone, one or many source address names, destination address names, and application names. Every policy has an action linked to it — permit, deny, reject, count, log, or tunnel (VPN). With flow-based forwarding enabled via set security forwarding-options family inet6 mode flow-based, IPv6 policies are also supported.

Configuring SRX Security Policies with set Commands

In the scenario below the SRX connects the 172.168.10.0/24 subnet (incoming zone) to the outgoing zone. Four policies are configured: ALLOW-WEB, ALLOW-TELNET, ALLOW-ICMP and an explicit DENY-ALL with logging.

set security policies from-zone incoming to-zone outgoing policy ALLOW-WEB match source-address NET_172_168_10_0__24
set security policies from-zone incoming to-zone outgoing policy ALLOW-WEB match destination-address any
set security policies from-zone incoming to-zone outgoing policy ALLOW-WEB match application junos-http
set security policies from-zone incoming to-zone outgoing policy ALLOW-WEB then permit
set security policies from-zone incoming to-zone outgoing policy ALLOW-WEB then log session-init
set security policies from-zone incoming to-zone outgoing policy ALLOW-WEB then log session-close
set security policies from-zone incoming to-zone outgoing policy ALLOW-WEB then count

set security policies from-zone incoming to-zone outgoing policy ALLOW-TELNET match source-address NET_172_168_10_0__24
set security policies from-zone incoming to-zone outgoing policy ALLOW-TELNET match destination-address any
set security policies from-zone incoming to-zone outgoing policy ALLOW-TELNET match application junos-telnet
set security policies from-zone incoming to-zone outgoing policy ALLOW-TELNET then permit
set security policies from-zone incoming to-zone outgoing policy ALLOW-TELNET then log session-init
set security policies from-zone incoming to-zone outgoing policy ALLOW-TELNET then log session-close
set security policies from-zone incoming to-zone outgoing policy ALLOW-TELNET then count

set security policies from-zone incoming to-zone outgoing policy ALLOW-ICMP match source-address NET_192_168_10_0__24
set security policies from-zone incoming to-zone outgoing policy ALLOW-ICMP match destination-address any
set security policies from-zone incoming to-zone outgoing policy ALLOW-ICMP match application junos-icmp-all
set security policies from-zone incoming to-zone outgoing policy ALLOW-ICMP then permit
set security policies from-zone incoming to-zone outgoing policy ALLOW-ICMP then log session-init
set security policies from-zone incoming to-zone outgoing policy ALLOW-ICMP then count

set security policies from-zone incoming to-zone outgoing policy DENY-ALL match source-address any
set security policies from-zone incoming to-zone outgoing policy DENY-ALL match destination-address any
set security policies from-zone incoming to-zone outgoing policy DENY-ALL match application any
set security policies from-zone incoming to-zone outgoing policy DENY-ALL then reject
set security policies from-zone incoming to-zone outgoing policy DENY-ALL then log session-init
set security policies from-zone incoming to-zone outgoing policy DENY-ALL then count
set security policies pre-id-default-policy then log session-close

Verifying Security Policies on Junos

After committing the configuration with commit, verify the policy set and session behavior using operational commands such as show security policies, show security policy hits and show security flow session. The count and log actions configured above make it easy to confirm that only expected traffic is permitted.

Security Zones and Zone Pairs

Before a single policy rule can be written, the SRX needs security zones. A zone is a logical grouping of interfaces that share the same trust level, and every zone-pair is unidirectional. Traffic from the untrust zone to the trust zone is evaluated by one policy set; return traffic is evaluated by a separate set. If you only configure one direction, the traffic will be dropped in the reverse direction even though the forward session was permitted.

set security zones security-zone trust host-inbound-traffic system-services ping
set security zones security-zone trust host-inbound-traffic system-services ssh
set security zones security-zone trust interfaces ge-0/0/1.0
set security zones security-zone untrust interfaces ge-0/0/0.0
set security zones security-zone dmz interfaces ge-0/0/2.0

Two configuration details catch people out constantly. First, an interface can belong to only one zone — reusing the same logical unit in two zones produces a commit error. Second, host-inbound-traffic controls which services are allowed to terminate on the SRX itself. It has nothing to do with transit traffic: a policy can permit SSH between zones while the device still refuses management traffic because host-inbound was never enabled.

Address Books and Address Sets

Policies match on named addresses, not raw prefixes. Address books can be defined globally and referenced by any zone, or locally within a zone. For anything beyond a handful of hosts, an address set keeps policies readable.

set security address-book global address NET_172_168_10_0__24 172.168.10.0/24
set security address-book global address WEB_SERVER_1 203.0.113.10/32
set security address-book global address WEB_SERVER_2 203.0.113.11/32
set security address-book global address-set WEB_SERVERS address WEB_SERVER_1
set security address-book global address-set WEB_SERVERS address WEB_SERVER_2
set security address-book global address-set INTERNAL_NETS address NET_172_168_10_0__24

Address names are also used by NAT rules, so a consistent naming convention pays off later. A practical scheme is NET_<prefix> for subnets, HOST_<purpose> for servers, and SET_<group> for sets. When a NAT rule and a policy rule both reference the same object, changing the object in one place updates every rule that uses it.

Applications and Application Sets

Junos ships with hundreds of predefined applications. The junos- prefix identifies them, and they understand protocols that need helper sessions, which is what makes them preferable to a bare junos-tcp or junos-udp definition.

show configuration groups junos-defaults applications | display set | match "junos-http"
set applications application-set WEB_APPS application junos-http
set applications application-set WEB_APPS application junos-https
set applications application CUSTOM_APP_8080 protocol tcp destination-port 8080-8090
set applications application CUSTOM_APP_8080 inactivity-timeout 1800

Custom applications are worth defining whenever a service uses a non-standard port, or whenever you need a longer inactivity timeout than the default. For protocols that open dynamic data channels — FTP, SIP, H.323 — always use the predefined application; a hand-rolled TCP entry will allow the control channel and then silently drop the data connection.

Policy Ordering and First-Match Logic

Security policies are evaluated top to bottom within a zone-pair, and the first rule whose match criteria are satisfied wins. There is no implicit "most specific wins" behaviour and no automatic reordering. Two rules that match the same traffic mean the one higher in the list takes effect, and the second never registers a hit.

show security policies from-zone untrust to-zone trust
show security policies hit-count
show security policies | display set | match from-zone

Order matters most with a broad deny rule. If DENY-ALL is placed above the specific permit rules, everything is blocked and the permit rules show zero hits — a mistake that is easy to make when appending rules and easy to spot once you look at hit counts. Use insert rather than set when a rule has to go in above an existing one, or use the configuration-mode insert ... before ... syntax.

Building the Policy Set Step by Step

The scenario below connects the 172.168.10.0/24 subnet in the incoming zone to the outgoing zone with four policies: ALLOW-WEB, ALLOW-TELNET, ALLOW-ICMP and an explicit DENY-ALL with logging.

set security policies from-zone incoming to-zone outgoing policy ALLOW-WEB match source-address NET_172_168_10_0__24
set security policies from-zone incoming to-zone outgoing policy ALLOW-WEB match destination-address any
set security policies from-zone incoming to-zone outgoing policy ALLOW-WEB match application junos-http
set security policies from-zone incoming to-zone outgoing policy ALLOW-WEB then permit
set security policies from-zone incoming to-zone outgoing policy ALLOW-WEB then log session-init
set security policies from-zone incoming to-zone outgoing policy ALLOW-WEB then log session-close
set security policies from-zone incoming to-zone outgoing policy ALLOW-WEB then count

set security policies from-zone incoming to-zone outgoing policy ALLOW-TELNET match source-address NET_172_168_10_0__24
set security policies from-zone incoming to-zone outgoing policy ALLOW-TELNET match destination-address any
set security policies from-zone incoming to-zone outgoing policy ALLOW-TELNET match application junos-telnet
set security policies from-zone incoming to-zone outgoing policy ALLOW-TELNET then permit
set security policies from-zone incoming to-zone outgoing policy ALLOW-TELNET then log session-init
set security policies from-zone incoming to-zone outgoing policy ALLOW-TELNET then count

set security policies from-zone incoming to-zone outgoing policy ALLOW-ICMP match source-address NET_172_168_10_0__24
set security policies from-zone incoming to-zone outgoing policy ALLOW-ICMP match destination-address any
set security policies from-zone incoming to-zone outgoing policy ALLOW-ICMP match application junos-icmp-all
set security policies from-zone incoming to-zone outgoing policy ALLOW-ICMP then permit
set security policies from-zone incoming to-zone outgoing policy ALLOW-ICMP then count

set security policies from-zone incoming to-zone outgoing policy DENY-ALL match source-address any
set security policies from-zone incoming to-zone outgoing policy DENY-ALL match destination-address any
set security policies from-zone incoming to-zone outgoing policy DENY-ALL match application any
set security policies from-zone incoming to-zone outgoing policy DENY-ALL then deny
set security policies from-zone incoming to-zone outgoing policy DENY-ALL then log session-init
set security policies from-zone incoming to-zone outgoing policy DENY-ALL then count

A deny action is silent toward the client, while reject sends a TCP RST or ICMP unreachable. Logging the deny rule is what turns a black box into an observable system — without it, users report "the firewall is blocking me" and you have no evidence in either direction.

Global Policies and the Default Deny

Every Junos device has an implicit deny-all policy at the end of each zone-pair, plus a set of default policies that handle a few system behaviours. You can inspect and modify the default logging behaviour, but you cannot delete the implicit deny.

show security policies default-policy
set security policies pre-id-default-policy then log session-init
set security policies pre-id-default-policy then log session-close
set security policies default-policy then log session-close

Global policies apply across all zone-pairs and sit above the per-zone-pair sets. They are convenient for a universal rule such as blocking a known-bad host everywhere, but they are also a common source of confusion: traffic blocked by a global policy will never appear in the zone-pair policy hit counts, so always check show security policies global before concluding a rule is broken.

Logging, Counting and Troubleshooting

The count action is the cheapest debugging tool on the platform. It increments per-rule counters that you can read without enabling any trace options, and it shows which rule is actually catching a given flow.

show security policies hit-count
show security flow session source-prefix 172.168.10.0/24
show security flow session destination-port 80
clear security flow session all
show log messages | match RT_FLOW
show log messages | last 50

Typical failure modes and their fixes: a policy that permits traffic but nothing passes usually means the reverse zone-pair has no matching rule, or NAT is rewriting the source address into an object that the policy does not match. A policy that shows zero hits while users complain means the traffic is being caught earlier by a global policy, or the session never reaches the SRX. A session that appears in show security flow session but stops mid-transfer is often an application timeout or MTU issue rather than a policy problem.

The session table is authoritative. If a session exists with the expected source, destination and ports, the policy layer has already done its job and the problem is downstream. If no session exists at all, the drop happened before policy evaluation — routing, zone assignment, screen options, or MSS handling.

Security Policy Best Practices

• Name policies after intent, not numbers: ALLOW-WEB survives personnel changes, POLICY-17 does not.
• Always put an explicit logged deny at the bottom of a policy set, even though an implicit deny already exists.
• Enable count on every rule during initial deployment, then remove it from high-volume rules once traffic is understood.
• Prefer application sets and address sets over per-rule objects; one set change beats twenty policy edits.
• Keep zone-pair policy sets short. If a set grows past roughly thirty rules, group servers into address sets instead of adding more rules.
• Test the reverse direction deliberately. Simpler firewalls infer return traffic; SRX does not, and forgetting the return policy is the single most common configuration mistake.
• Document the zone map before touching policy, and keep the SRX HA pair in sync with show configuration | compare.

Verification Checklist

1. Zones exist and every interface is assigned to exactly one zone.
2. host-inbound-traffic permits the management services you need on the right interfaces.
3. Address books and application sets contain what you expect: show configuration security address-book.
4. Policy order is correct — broad denies last, specific permits first.
5. Both directions of each flow are covered by policy.
6. NAT rules, if any, reference the same objects the policies use.
7. commit check passes before commit, and commit confirmed 5 protects remote sessions.
8. Hit counts and flow sessions confirm real traffic is matching the intended rules.

For operational commands to keep beside the configuration, see our Juniper SRX troubleshooting commands cheat sheet. If you prefer a Chinese walkthrough of the same workflow, read the Juniper SRX firewall configuration tutorial. Policy is only half of a working edge: pair it with route-based site-to-site IPsec VPN configuration for branch connectivity, and remember that stateless filtering can still be layered on top with Junos firewall filters.

Related Juniper Resources

For more Junos troubleshooting and configuration practice, see our guides on troubleshooting IRB VLAN interfaces on Juniper EX and inter-VLAN communication issues on EX switches. You can also review BGP security with ASPA and route-leak prevention for edge-firewall best practices.

原文链接：https://networkinterview.com/how-to-configure-juniper-srx-security-policy/