6.2 Stateless Firewall Filters

Why Stateless Firewall Filters Matter

Stateless firewall filters are the Junos OS tool for matching and acting on individual packets in the forwarding plane. They are called stateless because each packet is evaluated independently — the filter does not track sessions, connection state, or return traffic. This is different from a stateful firewall on an SRX security device, and the JNCIA-Junos exam expects you to know that core distinction.

Firewall filters are used to:

• Permit or deny traffic transiting the device.
• Protect the Routing Engine (RE) from unwanted or excessive control-plane traffic.
• Classify, count, log, or rate-limit traffic.

Reinforce the control-plane vs forwarding-plane split from section 6.1: routing policy = routes; firewall filters = packets.

Filter Structure: Terms, From, Then

Firewall filters are configured under [edit firewall family inet filter <name>] and, like routing policy, are built from ordered terms:

• from — match conditions. With no from, the term matches every packet.
• then — the action and any action-modifiers.

firewall {
    family inet {
        filter protect-mgmt {
            term allow-ssh {
                from {
                    source-address {
                        192.168.10.0/24;
                    }
                    protocol tcp;
                    destination-port ssh;
                }
                then accept;
            }
            term log-and-drop {
                then {
                    count dropped-pkts;
                    log;
                    discard;
                }
            }
        }
    }
}

The Implicit Discard

Every firewall filter has an implicit, terminating discard at the end. Any packet that matches no term is silently dropped. Because of this, a filter that only contains "deny" terms will drop all traffic — you almost always need at least one explicit accept term for legitimate traffic. This implicit-discard behavior is one of the most heavily tested JNCIA-Junos firewall facts.

Terms are evaluated top to bottom, and unlike routing policy, a basic accept/discard/reject action is terminating — the packet's fate is decided and no further terms are checked.

Match Conditions, Actions, and Action-Modifiers

Common from Match Conditions

Actions vs Action-Modifiers

Terminating actions decide the packet and stop term evaluation:

• accept — let the packet through.
• discard — drop the packet silently (no notification to the sender).
• reject — drop the packet and send an ICMP/protocol-unreachable message back (you can specify the reject type).

Action-modifiers can be combined with an action and do not stop evaluation by themselves:

• count <name> — increment a named counter.
• log / syslog — record the match (log is a local kernel cache; syslog goes to the system log).
• policer <name> — apply a rate limiter.
• forwarding-class / loss-priority — set CoS handling.
• next term — explicitly continue to the next term (without it, an action is terminating).

Know the discard vs reject difference cold: discard is silent; reject notifies the sender. Exam questions phrase this as "which action drops the packet without informing the source?"

Applying Filters to Interfaces and Protecting the RE

A filter does nothing until it is applied to an interface, under a specific address family and direction:

interfaces {
    ge-0/0/0 {
        unit 0 {
            family inet {
                filter {
                    input  protect-mgmt;
                    output egress-acl;
                }
                address 10.1.1.1/24;
            }
        }
    }
}

Routing Engine (RE) Protection

Applying an input filter to the loopback interface lo0 filters traffic destined to the device's own Routing Engine — SSH, SNMP, BGP, OSPF, ping to the device, etc. This is the standard Junos technique for RE protection / control-plane protection: permit only required management and routing protocols from trusted sources, then discard the rest. A lo0 filter does not affect transit traffic forwarded through the device; transit traffic is filtered on the data interfaces it actually traverses.

Policer Basics

A policer enforces a traffic rate. It is defined with two key parameters:

• Bandwidth limit — the sustained rate (bits per second).
• Burst-size limit — how much traffic can briefly exceed the rate (bytes).

Traffic that conforms is forwarded normally; traffic that exceeds the policer is handled by the configured action (commonly discard or marking a higher loss priority). Policers are referenced from a filter term as the policer action-modifier, which is the typical way to rate-limit a specific class of traffic such as ICMP toward the RE.