Juniper JunOS Firewall Filter (ACL)
Stateless packet filtering on JunOS: term-based filters, loopback protection for the routing engine, policers for rate limiting, and apply-path for dynamic prefix lists.
What is it?
A firewall filter is how JunOS does stateless packet filtering - the Juniper equivalent of an ACL on Cisco. A filter is a named list of terms, each with a `from` clause that matches traffic and a `then` clause that says what to do with it. Terms are evaluated in order, and the first match wins. The most important use is not filtering traffic through the router but protecting the router itself: a filter applied to the loopback interface lo0.0 sees every packet addressed to the routing engine, no matter which physical interface it arrived on, which makes it the single place to control management access.
When to use
- ·Protecting the routing engine - a filter on lo0.0 is the standard, and arguably mandatory, hardening step on any JunOS device reachable from an untrusted network
- ·Restricting management access to SSH, SNMP and NTP from a trusted prefix only
- ·Anti-spoofing on edge interfaces: discarding inbound packets that claim an internal source address
- ·Rate limiting ICMP or other control traffic to the RE with a policer, so a flood cannot starve the control plane
- ·Counting traffic you want to measure rather than block - a term with `count` and `accept` is a free traffic counter
- ·Dropping bogon and martian source addresses at the edge
When NOT to use
- ·Stateful inspection - firewall filters are stateless and do not track sessions. For stateful policy on SRX, use security policies instead
- ·Application-layer filtering - there is no App-ID equivalent here. If you need to identify applications rather than ports, this is the wrong tool
- ·NAT - that is a separate configuration hierarchy, not something a filter does
- ·As the only control on an SRX. SRX runs security policies in flow mode; firewall filters still exist but security policies are the primary mechanism
- ·Replacing routing policy. A filter decides what to do with packets; a routing policy decides what to do with routes. Filtering a prefix does not remove it from the routing table
How it compares
Prerequisites
- →JunOS 10.0 or later for apply-path in prefix lists
- →Know which prefixes legitimately need management access before writing the first term - a filter on lo0.0 that omits your own source address will lock you out
- →Console or out-of-band access available while applying an lo0.0 filter for the first time
- →`commit confirmed` understood and used - see the troubleshooting section
- →Existing BGP group names, if using the apply-path example to build the peer list dynamically
Config Generator
Use a name that says what it protects, not where it is applied
Source network allowed to reach SSH/SNMP/NTP on the routing engine
Peers allowed to open TCP 179 to this router
Bandwidth limit for ICMP to the RE, e.g. 1m for 1 Mbps
Interface for the transit filter example
Used for the anti-spoofing term on the transit filter
Verification commands
show firewall filter PROTECT-REShow per-term packet and byte counters
ExpectedOne line per counter defined in the filter. SSH-ACCEPTED and BGP-ACCEPTED should increment during normal operation; a rising RE-DISCARDED counter is the first thing to look at when something stops working.
show interfaces lo0.0 detail | match filterConfirm the filter is actually applied to the loopback
ExpectedShows the input filter name. A filter that is configured but not applied counts nothing and protects nothing - this is the most common reason a filter 'does not work'.
show policy-options prefix-list BGP-PEERSShow what apply-path resolved to
ExpectedThe actual neighbor addresses pulled from the BGP configuration. An empty list means the apply-path expression does not match your configuration hierarchy.
show firewall policer ICMP-POLICERShow how much traffic the policer has discarded
ExpectedOut-of-specification packet count. A steadily rising count means legitimate ICMP is being dropped and the rate needs raising.
Debug commands
monitor start messages | match PROTECT-REWatch filter log output live as traffic is denied
WarningThe `log` action writes to the kernel log buffer on the RE. On a busy filter this is noisy and consumes CPU - use `syslog` to send to a server instead, and never leave `log` on a term that matches high volumes of traffic.
show firewall logShow recent packets matched by a term with the log action
WarningThis buffer is small and wraps quickly. It shows what was filtered recently, not a complete record.
clear firewall allReset all filter counters to zero before a test
WarningClears counters for every filter on the device, not just the one you are testing.
Common mistakes & fixes
Further learning
Recommended books to go deeper on this topic.
Juniper SRX Series: A Comprehensive Guide to Security Services on the SRX Series
Brad Woodberg, Rob Cameron · O'Reilly Media · Security zones, policies and the relationship between stateless firewall filters and SRX flow processing
Juniper Junos Network Associate - Student Guide
Maher Haddad · Independently Published · JNCIA-level Junos fundamentals, including firewall filter syntax and the term-based structure
Juniper JNCIA-SEC Study Guide (JN0-232)
R. Parvin · Independently published · SRX architecture, security zones, policies, NAT and troubleshooting for the JNCIA-SEC exam