Junos Firewall Filters: Terms, Match Conditions and Actions

Junos firewall filters are the platform's stateless ACL mechanism: ordered lists of terms that inspect packets and take actions, applied per interface and per protocol family. Because a filter without an explicit match ends in an implicit discard, a wrongly written term can silently blackhole traffic - so the term/from/then structure deserves to be understood precisely. This guide walks through Junos firewall filter configuration with real examples, covering match conditions, actions, loopback protection, verification and the mistakes that turn a filter change into an outage.

Filter Structure: Terms, from, then

A firewall filter lives under [edit firewall] and is specific to a protocol family. IPv4 filters are configured at family inet (which is equivalent to the top-level firewall hierarchy); IPv6 requires family inet6. Each filter contains one or more terms, evaluated top to bottom. A term is:

firewall {
    family inet {
        filter FILTER1 {
            term DISCARD-ICMP {
                from {
                    source-address 172.16.1.1/32;
                    destination-address 172.16.2.1/32;
                    protocol icmp;
                }
                then reject;
            }
            term PERMIT-ALL {
                then accept;
            }
        }
    }
}

Conditions inside one from are ANDed - a packet must match all of them. If from is omitted, the term matches everything. The first term whose conditions match wins: a terminating action (accept, discard, reject) ends evaluation, and if no term matches, the implicit final action is discard. That is why a well-formed filter ends with an explicit then accept term.

Three properties of that model are worth memorising, because almost every filter bug traces back to one of them:

• Order is the whole semantics. Terms are evaluated strictly top to bottom. The first term whose from conditions match decides the fate of the packet; every later term is skipped.
• Matching is terminating by default. accept, discard and reject stop evaluation immediately. Only action modifiers such as count, log and syslog are non-terminating.
• The last action is implicit. There is an invisible then discard at the bottom of every filter. Junos has no implicit accept, so a filter that "does not seem to work" is usually just dropping everything.

A term that carries only modifiers - a pure counting or logging term - falls through to the next term automatically, exactly as if you had written then next term explicitly.

Setting It Up: Junos CLI Example

The same filter built with set commands:

set firewall family inet filter FILTER1 term DISCARD-ICMP from source-address 172.16.1.1/32
set firewall family inet filter FILTER1 term DISCARD-ICMP from destination-address 172.16.2.1/32
set firewall family inet filter FILTER1 term DISCARD-ICMP from protocol icmp
set firewall family inet filter FILTER1 term DISCARD-ICMP then reject
set firewall family inet filter FILTER1 term PERMIT-ALL then accept
set interfaces ge-0/0/0 unit 0 family inet filter input FILTER1

Filters bind to an interface unit and a direction: filter input for ingress, filter output for egress. On EX/QFX switches, Layer 2 traffic is filtered under family ethernet-switching instead of family inet, and the same filter names appear in show configuration firewall with a different family wrapper.

Match Conditions in Detail

from is where filters earn their keep, and Junos matches on considerably more than addresses and ports. The most useful conditions, grouped by what they inspect:

Conditions combine with logical AND inside a term. There is no OR inside a single from block - to express "source A or source B", list both prefixes inside the same source-address statement, or split the logic across multiple terms that share the same action. Negation is available through the except keyword, for example from { source-address { 10.0.0.0/8 except; 0.0.0.0/0; } }, which matches everything outside 10.0.0.0/8.

Using prefix-list instead of inline addresses keeps large filters readable and maintainable. A single named list can be referenced from an input filter, an output filter and a routing policy without duplication, so adding a new management subnet is a one-line change rather than a search-and-replace across the configuration.

Actions and Action Modifiers

A term's then clause contains at most one terminating action, optionally preceded by any number of modifiers.

• Terminating actions: accept (forward the packet), discard (silently drop), reject (drop and return an ICMP unreachable, or a TCP RST for TCP traffic). On some platforms reject accepts a qualifier such as reject tcp-reset or reject admin-prohibited.
• Counters: count COUNTER-NAME. Counters are the primary evidence that a term is working and are read with show firewall filter. Give every term a unique name so statistics cannot be confused.
• Logging: log writes the packet header to the local firewall log buffer, syslog sends it to a configured syslog host, and sample copies the packet to a configured flow-server for analysis.
• QoS marking: forwarding-class, loss-priority, dscp, precedence. A filter that only reclassifies traffic must still fall through, so it cannot carry a terminating action.
• Rate limiting: policer POLICER-NAME applies a two- or three-color policer defined under [edit firewall policer]. A policer is a terminating action when it discards out-of-profile traffic.
• Control flow: next term continues evaluation, and routing-instance or next-hop can redirect matched traffic.

The interface-specific statement, added directly under the filter (not under a term), is essential when the same filter is attached to many interfaces: without it the counters aggregate across all attachment points, which makes per-port troubleshooting impossible.

Protecting the Routing Engine with a Loopback Filter

The classic production use of a firewall filter is a loopback filter that limits which protocols may reach the control plane. Because every protocol destined to the router itself is delivered through the loopback, a filter applied to lo0 input gives you a single choke point for management and routing-plane access:

set firewall family inet filter PROTECT-RE term ALLOW-SSH from protocol tcp
set firewall family inet filter PROTECT-RE term ALLOW-SSH from destination-port ssh
set firewall family inet filter PROTECT-RE term ALLOW-SSH from source-prefix-list MGMT-SUBNETS
set firewall family inet filter PROTECT-RE term ALLOW-SSH then accept
set firewall family inet filter PROTECT-RE term ALLOW-BGP from protocol tcp
set firewall family inet filter PROTECT-RE term ALLOW-BGP from destination-port bgp
set firewall family inet filter PROTECT-RE term ALLOW-BGP then accept
set firewall family inet filter PROTECT-RE term ALLOW-ICMP from protocol icmp
set firewall family inet filter PROTECT-RE term ALLOW-ICMP then accept
set firewall family inet filter PROTECT-RE term DENY-REST then count DENIED-RE
set firewall family inet filter PROTECT-RE term DENY-REST then discard
set interfaces lo0 unit 0 family inet filter input PROTECT-RE

Note the deliberate design: SSH is permitted only from the management prefix list, BGP is permitted from anyone but must come from port 179, ICMP is allowed so path-MTU discovery keeps working, and everything else is counted and discarded. Always combine such a filter with a trusted out-of-band path or a console session before committing.

Junos Filters, SRX Policies and Cisco ACLs

It helps to know which problem each tool solves. Junos firewall filters are stateless: every packet is judged in isolation, return traffic needs its own term, and there is no session table. On SRX platforms you normally use stateful security zones and policies instead, which track sessions and permit return traffic automatically. Cisco IOS relies on extended ACLs - conceptually similar to filters, but with a different syntax, an implicit deny any at the end of every ACL, and different placement rules. If you are translating configuration between vendors, the multi-vendor cheat sheet maps the equivalent constructs side by side, and the ArubaOS-CX ACL walkthrough shows how the same logic is expressed on a completely different switch OS.

Verifying Filter Operation

show configuration firewall                        # current filter config
show firewall filter FILTER1                       # packet/byte counters per term
show firewall                                      # all filters and policers with counters
show interfaces ge-0/0/0 statistics                # interface-level drops
show firewall log                                  # packets matched by log
show firewall log detail                           # with addresses and ports
show interfaces filters                            # which filters are attached where

Counters are the fastest way to prove a term is (or is not) being hit - incrementing counters confirm the filter matches; a silent filter usually means the term conditions are too strict or the filter is attached to the wrong family/direction. Clear the counters before a controlled test so you are reading fresh numbers:

clear firewall filter FILTER1
clear firewall all

When watching a live problem, show firewall with a short sleep loop is often more useful than a packet capture, because it tells you exactly which term in your own policy is responsible for the drop.

Troubleshooting Common Filter Mistakes

• Wrong family. An IPv4 filter under family inet6, or a Layer 2 filter applied where an inet filter is required, is silently useless. Compare show interfaces filters with the hierarchy you configured.
• Missing final accept. The implicit discard at the bottom of every filter is the number one cause of "the filter blocked everything".
• Source and destination swapped. In an input filter, the source is the remote device and the destination is your local address; in an output filter the roles are reversed.
• Port match without a protocol. destination-port 22 with no protocol tcp matches far more than SSH.
• Reusing one filter name across families. Filter names are scoped per family; two filters with the same name and different families cause confusing counters.
• Aggregated counters. Forgetting interface-specific makes per-port diagnosis impossible.

Safe Change Practices

Because a bad filter can cut management access, always pair filter edits with commit confirmed so an unreachable change rolls back automatically, and stage filters on the loopback first where the blast radius is limited to the control plane. Keep an alternate management path (console, out-of-band, or a second interface with a filter that explicitly permits your source) open for the duration of the change. Remember that Junos safety features like storm control are separate from firewall filters and do not protect the routing engine, and that stateless filters do not replace stateful security policy.

For stateful security policies rather than stateless filters, SRX platforms use security zones and policies - see our Juniper SRX 配置教程 for that model, and the Cisco prefix-list and route-map guide if your filtering task is about routing policy rather than packet forwarding.

原文链接：https://www.juniper.net/documentation/us/en/software/junos/routing-policy/topics/task/firewall-filter-ex-series-cli.html