7.3 Firewall Filters & Policers

Firewall Filters & Policers

While routing policies control the exchange of routing information in the control plane, Firewall Filters inspect and control actual data packets traversing the router or destined to the local host. In Junos OS, firewall filters are stateless access control lists (ACLs) processed directly in the Packet Forwarding Engine (PFE) hardware ASICs at wire speed. Combined with Traffic Policers, firewall filters defend network infrastructure against denial-of-service (DoS) attacks, enforce quality of service (QoS) boundaries, and protect the Routing Engine (RE). Mastering firewall filter mechanics, action modifiers, and loopback filtering is critical for enterprise network security and the JNCIS-ENT examination.

---

1. Stateless Firewall Filter Architecture in Junos OS

Unlike stateful firewalls (such as the Juniper SRX Series running flow-based processing) that maintain dynamic session state tables for TCP and UDP flows, Junos stateless firewall filters evaluate each packet independently. Every packet is inspected against configured criteria without awareness of preceding or subsequent packets in the stream.

+---------------------------------------------------------------------------------------------------+
| JUNOS STATELESS HARDWARE PACKET FILTERING (PFE)                                                   |
+---------------------------------------------------------------------------------------------------+
|                                                                                                   |
|   Ingress Packet ===> [ PFE Hardware Parser ] ===> [ Ingress Firewall Filter ] ===> Lookup/FIB    |
|                                                              | (Term Match & Actions)             |
|                                                              v                                    |
|                                                   Accept / Count / Policer / Drop                 |
|                                                                                                   |
|   Egress Packet  <=== [ Physical Interface ] <=== [ Egress Firewall Filter ]  <=== Switching/QoS  |
|                                                                                                   |
+---------------------------------------------------------------------------------------------------+

Directionality and Interface Application

Firewall filters are configured under the [edit firewall family inet filter <filter-name>] hierarchy for IPv4, or family inet6 for IPv6, and applied to logical interfaces (unit):

[edit interfaces ge-0/0/0 unit 0 family inet]
set filter input transit-in
set filter output transit-out

• input: Evaluates packets arriving on the interface before the PFE performs route lookup.
• output: Evaluates packets after forwarding lookup and egress interface selection, immediately prior to frame transmission.

---

2. Filter Structure & Match Conditions

A Junos firewall filter is composed of ordered terms. Each term contains from match statements and then action statements:

[edit firewall family inet filter secure-edge]
term allow-web {
    from {
        source-address 192.168.1.0/24;
        destination-port [ 80 443 ];
        protocol tcp;
    }
    then {
        count web-counter;
        accept;
    }
}

Primary Match Conditions

• Layer 3 Addresses: source-address, destination-address, source-prefix-list, destination-prefix-list.
• Layer 4 Protocols: protocol tcp, protocol udp, protocol icmp, protocol ospf, protocol igmp.
• Port Numbers: source-port, destination-port, or port (matches either source or destination). Ports can be specified by number (22), symbolic name (ssh, bgp, ntp), lists ([ 80 443 8080 ]), or ranges (1024-65535).
• TCP Flags: tcp-flags "syn & !ack" (matches TCP connection initiation packets) or tcp-established (matches ACK or RST flags; it does not verify connection state).
• ICMP Criteria: icmp-type echo-request, icmp-type echo-reply, icmp-type destination-unreachable, icmp-code.
• QoS / CoS Markings: dscp, traffic-class, precedence.

---

3. Action Processing: Terminating vs. Action Modifiers

Actions inside a firewall filter term are divided into terminating actions and non-terminating action modifiers.

Terminating Actions

A terminating action determines the final forwarding disposition of the packet and stops further term evaluation:

When reject is configured, Junos can optionally return specific rejection codes:

• reject: Defaults to ICMP destination unreachable (host unreachable).
• reject tcp-reset: Returns a TCP RST packet for TCP connections, cleanly tearing down client sockets.
• reject icmp-admin-prohibited: Returns ICMP type 3 code 13 (administratively prohibited).

Non-Terminating Actions (Action Modifiers)

Action modifiers add counting, logging, policing or marking. A matching term with only nonterminating actions has an implicit accept; it does not automatically continue into the next term. Use a supported explicit next term when continuation is intended. Unmatched packets reaching the end of the whole filter encounter implicit discard:

• count <counter-name>: Increments a hardware packet and byte counter. Counters are inspected operationally via show firewall counter filter <filter> <counter>.
• log: Captures packet header metadata into a local buffer on the PFE, viewed with show firewall log.
• syslog: Transmits an alert to the system log daemon (syslogd).
• policer <policer-name>: Subjects matched traffic to a bandwidth and burst-size rate limiter.
• loss-priority (low | medium-low | medium-high | high): Sets packet drop precedence for CoS schedulers.
• forwarding-class <class-name>: Directs the packet into a designated egress queue (e.g., expedited-forwarding).

The Implicit Discard Rule

Critical Junos Firewall Rule: Every stateless firewall filter concludes with an implicit discard! If a packet does not match any configured term, Junos drops the packet silently. If an administrator creates a filter matching only SSH traffic with then accept and applies it to an interface, all other traffic (HTTP, DNS, OSPF, ICMP) will be dropped! To permit non-matching transit traffic, an explicit final term must be added:

[edit firewall family inet filter filter-name]
set term permit-all then accept

---

4. Traffic Policing: Token Bucket Rate Limiting

While firewall filters permit or deny packets based on header fields, Policers enforce bandwidth limits. A policer monitors traffic volume using a token bucket algorithm:

[edit firewall policer <policer-name>]
set if-exceeding bandwidth-limit <bps> burst-size-limit <bytes>
set then <action>

Single-Rate Two-Color Policer

A two-color policer classifies traffic into two states:

1. Conforming (Green / In-Profile): Traffic within the bandwidth and burst limits is forwarded normally.
2. Non-Conforming (Red / Out-of-Profile): Traffic exceeding the limits triggers the configured action (discard or loss-priority high).

[edit firewall policer limit-icmp]
set if-exceeding bandwidth-limit 1m burst-size-limit 62k
set then discard

Burst Size Formula: Configuring an adequate burst-size-limit is crucial to prevent premature packet drops during normal TCP window bursts. Juniper recommends sizing the burst bucket to accommodate at least 5 milliseconds of traffic at the burst rate: Burst Size (Bytes) = (Bandwidth Limit (bps) * 0.005 seconds) / 8

Two-Rate Three-Color Policer (trTCM / RFC 2698)

For advanced QoS, Junos supports two-rate three-color marking (trTCM) policers configured with:

• CIR (Committed Information Rate) & CBS (Committed Burst Size)
• PIR (Peak Information Rate) & PBS (Peak Burst Size)

Packets are metered into three colors: Green (conforming to CIR), Yellow (exceeding CIR but conforming to PIR), and Red (exceeding PIR, dropped or marked with high loss priority).

Policing vs. Shaping

---

5. Securing the Routing Engine: Loopback Protection (lo0.0)

In Junos architecture, transit traffic flows directly through the PFE switching fabric from ingress port to egress port and never impacts the Routing Engine. However, exception traffic (packets addressed directly to the router's own IP addresses, routing protocol sessions, and management connections) must be punted across the internal bus to the Routing Engine processor.

If malicious or misconfigured hosts flood the router with packets, the RE's CPU can be overwhelmed, leading to dropped OSPF/BGP keepalives, routing instability, and loss of management access. To protect the RE, enterprise administrators apply a stateless firewall filter to the loopback interface (lo0.0).

The Loopback Architecture Principle: Applying a filter to lo0.0 on ingress (input) filters all traffic destined to the local Routing Engine, regardless of which physical interface received the packet. Transit traffic flowing through the chassis is completely unaffected by the lo0.0 filter!

IPv4 protect-re Teaching Example

[edit policy-options]
set prefix-list mgmt-stations 10.200.1.0/24
set prefix-list bgp-neighbors 192.168.12.2/32

[edit firewall policer icmp-policer]
set if-exceeding bandwidth-limit 1m burst-size-limit 62k
set then discard

[edit firewall family inet filter protect-re]
term permit-established-tcp {
    from {
        protocol tcp;
        tcp-established;
    }
    then accept;
}
term permit-mgmt-ssh {
    from {
        source-prefix-list mgmt-stations;
        destination-port 22;
        protocol tcp;
    }
    then {
        count ssh-mgmt-count;
        accept;
    }
}
term permit-bgp {
    from {
        source-prefix-list bgp-neighbors;
        destination-port 179;
        protocol tcp;
    }
    then accept;
}
term permit-ospf {
    from {
        protocol ospf;
    }
    then accept;
}
term rate-limit-icmp {
    from {
        protocol icmp;
        icmp-type [ echo-request echo-reply ];
    }
    then {
        policer icmp-policer;
        count icmp-count;
        accept;
    }
}
term discard-all-other {
    then {
        count re-violation-count;
        discard;
    }
}

[edit interfaces lo0 unit 0 family inet]
set filter input protect-re

Operational Verification Commands

user@router> show firewall filter protect-re
user@router> show firewall counter filter protect-re ssh-mgmt-count
user@router> show firewall counter filter protect-re re-violation-count
user@router> clear firewall filter protect-re counter re-violation-count
user@router> show firewall log

Output note: Command output shown here is a schematic teaching example, not a captured device session. Field names and feature support depend on platform and Junos release.

This IPv4 example is deliberately limited. tcp-established only checks flags and can be spoofed; it is not a stateful security boundary. Before applying any RE filter, add the required management services, diagnostic ICMP errors, routing protocols, BFD and return traffic for that device. Protect IPv6 separately with family inet6. Test the policy and use a confirmed commit to avoid management lockout.