Which sequence correctly configures the input firewall to accept established/related connections and drop all other traffic?

Which sequence correctly configures the input firewall to accept established/related connections and drop all other traffic?

• A. /ip firewall filter add chain=input action=drop; /ip firewall filter add chain=input connection-state=established,related action=accept
• B. /ip firewall filter add chain=input protocol=tcp dst-port=80 action=accept
• C. /ip firewall filter add chain=input connection-state=established,related action=accept; /ip firewall filter add chain=input action=drop
• D. /ip firewall filter add chain=output connection-state=established,related action=accept

Answer: (C)

Stateful filtering: allow established or related connections on the input path, then drop everything else. This approach relies on connection tracking so the device can recognize ongoing conversations and permit their traffic even as new attempts are blocked. The correct configuration does exactly that: it first accepts input traffic for connections that are already established or related to an existing connection, and only afterward does it drop any other input. This order is crucial because if the drop rule runs first, it will block even legitimate responses to existing connections. Why this works well here: the input chain handles traffic destined for the device itself, so you want to permit the continuation of existing conversations while denying new, unapproved attempts. A final catch-all drop rule ensures no stray traffic slips through. Contrast with the other approaches: one option drops unmatched input before allowing established/related traffic, which would inadvertently block legitimate connections. Another option accepts only traffic to a specific port and doesn’t address the broader need to permit established/related sessions. A rule targeting the output chain doesn’t control incoming traffic at all, so it wouldn’t achieve the goal of protecting input connections. So the best pattern is to accept established/related on the input chain first, then drop other input traffic.

Stateful filtering: allow established or related connections on the input path, then drop everything else. This approach relies on connection tracking so the device can recognize ongoing conversations and permit their traffic even as new attempts are blocked.

The correct configuration does exactly that: it first accepts input traffic for connections that are already established or related to an existing connection, and only afterward does it drop any other input. This order is crucial because if the drop rule runs first, it will block even legitimate responses to existing connections.

Why this works well here: the input chain handles traffic destined for the device itself, so you want to permit the continuation of existing conversations while denying new, unapproved attempts. A final catch-all drop rule ensures no stray traffic slips through.

Contrast with the other approaches: one option drops unmatched input before allowing established/related traffic, which would inadvertently block legitimate connections. Another option accepts only traffic to a specific port and doesn’t address the broader need to permit established/related sessions. A rule targeting the output chain doesn’t control incoming traffic at all, so it wouldn’t achieve the goal of protecting input connections.

So the best pattern is to accept established/related on the input chain first, then drop other input traffic.