Junos Firewall Filter Builder

Build Junos firewall filters and policers with correct term structure, counters and the final term that decides what happens to everything else.

Config generator Juniper / Junos Runs in your browser
Blank for any.
Try:

Result

Filter
PROTECT-RE
Term
ALLOW-SSH-MGMT → accept
Match
tcp/22 from 10.0.0.0/8 to any
Policer
none
Filter term
set firewall family inet filter PROTECT-RE term ALLOW-SSH-MGMT from source-address 10.0.0.0/8
set firewall family inet filter PROTECT-RE term ALLOW-SSH-MGMT from protocol tcp
set firewall family inet filter PROTECT-RE term ALLOW-SSH-MGMT from destination-port 22
set firewall family inet filter PROTECT-RE term ALLOW-SSH-MGMT then count ALLOW-SSH-MGMT-COUNT
set firewall family inet filter PROTECT-RE term ALLOW-SSH-MGMT then accept
Final term (explicit deny with logging)
set firewall family inet filter PROTECT-RE term FINAL-DISCARD then count FINAL-DISCARD-COUNT
set firewall family inet filter PROTECT-RE term FINAL-DISCARD then syslog
set firewall family inet filter PROTECT-RE term FINAL-DISCARD then discard
Apply to interface
set interfaces lo0 unit 0 family inet filter input PROTECT-RE
Verification
show firewall filter PROTECT-RE
show firewall counter filter PROTECT-RE ALLOW-SSH-MGMT-COUNT
clear firewall filter PROTECT-RE
show configuration firewall | display set | match PROTECT-RE
Implicit discard
A Junos filter has an implicit discard at the end, so any term you forget silently drops traffic. Always end with an explicit final term that counts and logs, and always attach a counter to every term - a filter you cannot measure is a filter you cannot debug.
Control plane filter
Applying a filter to lo0.0 protects the routing engine - and locks you out if it is wrong. Include your management source ranges, permit BGP, OSPF, SSH, NTP, DNS and ICMP first, and always use commit confirmed.

About Junos Firewall Filter Builder

Junos firewall filters are ordered lists of terms, each with match conditions and actions, ending in an implicit discard. Add counters and policers and they become a genuine diagnostic instrument rather than just a blocking mechanism.

Policers versus shaping

A policer measures rate with a token bucket and discards or re-marks anything above the limit — it does not queue. That makes it right for protecting the control plane, where dropping excess is exactly what you want, and wrong for customer traffic, where a shaper that buffers and smooths gives far better TCP behaviour. Sizing the burst matters: too small and normal bursts are punished, too large and the policer stops being a limit. A burst of roughly 5 ms of the configured bandwidth is a sensible starting point.

Counters change everything

then count attaches a named counter to a term at effectively no cost. When a rule "is not working", show firewall tells you immediately whether traffic reached the term at all - which distinguishes a wrong match condition from a wrong action. Applying filters without counters is the main reason firewall debugging takes hours.

Common use cases

  • Building a routing-engine protection filter on lo0.
  • Rate-limiting ICMP or a specific protocol at the edge.
  • Adding a targeted block during an incident with logging to confirm it fired.

Edge cases and gotchas

  • The implicit discard at the end of a filter means an incomplete filter drops everything you did not name.
  • Applying an input filter to lo0.0 can lock you out - use commit confirmed without exception.

Frequently asked questions

How do I test a filter without locking myself out?
Use commit confirmed 5. If the filter cuts your management path, the router rolls back automatically after five minutes. Adding a counter to every term also lets you confirm what matched before committing permanently.
Why did my filter drop management traffic?
The implicit final discard. Any protocol not explicitly accepted - SSH, NTP, DNS, BGP, ICMP - is dropped. This is why the generated filter includes an explicit final term you can see.