A rural broadband cooperative applies a firewall filter to a subscriber-facing interface with two terms: one permits DHCP, and one permits DNS. A subscriber's device then sends an ICMP echo request that matches neither term. What happens to that packet?
Select an answer to reveal the explanation.
Short Explanation
A Junos firewall filter isn't permissive by default — it's the opposite. If a filter is applied and a packet doesn't match anything the operator wrote, an invisible last term catches it and throws it away. That hidden safety net is the implicit deny, and it's why every filter needs at least one explicit permit for the traffic you actually want.
Full Explanation
Every Junos stateless firewall filter carries an implicit final term that discards any packet not matched by an earlier, explicitly configured term. In this scenario the filter only has two terms — one for DHCP and one for DNS — so an ICMP echo request that matches neither falls through to that implicit discard and is dropped, not forwarded. Forwarding it normally would be wrong because Junos filters default to deny, not permit; nothing in the configuration accepts unmatched traffic. The idea of queuing unmatched packets for manual classification describes a workflow that doesn't exist in Junos packet forwarding — there is no holding area for undecided traffic. Rewriting an unmatched packet to fit an unrelated term (DNS, here) also has no basis; firewall filters match and act, they don't reclassify packet content to force a fit. This implicit-deny behavior is exactly why filter authors add an explicit final term of their own, often paired with a count action, when they want visibility into what is being silently dropped rather than losing that traffic with no record. To confirm the implicit deny is responsible for a given loss, check whether traffic recovers after adding an explicit permit term for it, and inspect 'show firewall filter <name>' for a term whose counter climbs even though the operator never wrote it.