FIREWALL / OUTPUT CHAIN

Output chain.

The output chain matches traffic originating from the router itself: NTP queries, DNS lookups, package fetches, IPsec keepalives, our own /tool fetch. Most setups never customise this chain — the default of "let everything out" is correct. The two cases where you do want a rule:

1. Block outbound SMTP from the router

Routers should never originate email. If the router suddenly starts talking to tcp/25, something compromised it. Drop the traffic preemptively — costs nothing if you're not using the router as a mail relay, and provides a tripwire if it ever gets owned.

block-smtp.rsc v6 4 lines · 185 bytes

# block outbound SMTP from the router itself (v6)
/ip firewall filter
add chain=output action=drop protocol=tcp dst-port=25,465,587 \
  comment="mtkf: router shouldn't be sending email"

block-smtp.rsc v7 4 lines · 185 bytes

# block outbound SMTP from the router itself (v7)
/ip/firewall/filter
add chain=output action=drop protocol=tcp dst-port=25,465,587 \
  comment="mtkf: router shouldn't be sending email"

2. Rate-limit DNS responses (DDoS amplification)

If your router runs a public DNS resolver (rare but possible), it's a candidate for DNS-amplification abuse. The cleanest fix is to disable allow-remote-requests on /ip dns, but if you need a public resolver, rate-limit the output side:

dns-rate-limit.rsc v6 6 lines · 263 bytes

/ip firewall filter
add chain=output action=accept protocol=udp src-port=53 \
  limit=200,50:packet \
  comment="mtkf: cap DNS replies at 200pps with 50 burst"
add chain=output action=drop protocol=udp src-port=53 \
  comment="mtkf: drop DNS replies over the cap"

dns-rate-limit.rsc v7 6 lines · 263 bytes

/ip/firewall/filter
add chain=output action=accept protocol=udp src-port=53 \
  limit=200,50:packet \
  comment="mtkf: cap DNS replies at 200pps with 50 burst"
add chain=output action=drop protocol=udp src-port=53 \
  comment="mtkf: drop DNS replies over the cap"

Don't run a public DNS resolver casually. Even with rate-limiting, the operational burden (open-resolver lists, abuse complaints, amplification-attack reports) usually outweighs the upside. If you don't actively need it, set /ip dns set allow-remote-requests=no and skip both rules.

Why this chain is mostly empty

The router itself is the trust root for your network — its outbound traffic is, by definition, traffic you are emitting. There's little to defend against on its own behalf. The output chain becomes interesting only as a tripwire (case 1) or in narrow public-service scenarios (case 2). For everything else, leaving the chain empty is the right call.