hermes-skills/skills/devops/infrastructure-automation/references/routeros-firewall-optimization.md

RouterOS Firewall Optimization

When the user asks you to audit a MikroTik firewall for duplicate or redundant rules, follow this process.

Initial scan

Fetch the full rule list:

/ip firewall filter print detail
/ip firewall nat print detail
/ip firewall mangle print detail

Use print detail (not print stats) — it shows the actual rule text, not counters.

What to look for

1. Rules covered by broader rules above them

If rule 8 accepts ALL traffic from subnet X to WAN interface, any later rule like "allow UDP 5060 from subnet X to WAN" is fully redundant — the broader rule already passes it.

This is the most common redundancy in MikroTik firewalls. Signal: protocol=tcp/udp + specific port + same src-address + same out-interface as an earlier accept-all rule.

2. Disabled rules with stale references

Rules with disabled=yes and comments referencing interfaces, IPs, or services that don't exist (e.g., "RemoteWinboxVPN5 not ready"). These are dead weight.

3. Rules serving the same purpose

Two separate rules for "Allow VPN to LAN" and "Allow VPN to WAN" are not redundant if they cover different destination networks. But check if the src-address-list is consistently populated across both — if one uses VPN_CLIENTS and the other also does, they serve different purposes and are fine.

4. Subnet overlap

If rule 15 allows SSH+Winbox from 10.1.0.0/24 and rule 16 allows Winbox from 10.1.1.0/24, check whether 10.1.1.0/24 is a subset of 10.1.0.0/24. If so, rule 16 is redundant. If they're separate subnets, fine.

Sensitivity analysis

Not all technically-redundant rules are safe to remove. Flag these cases:

• "Allow established/related" with untracked — Adding untracked to the established/related rule is intentional. Traffic that bypasses connection tracking (via raw rules) still needs to pass through the firewall. Removing this untracked flag could break that traffic.

• Rules with counters — A rule that's "covered" by a broader rule but has a non-zero packet counter is still doing something — it's matching and counting traffic that the broader rule hasn't reached yet (due to earlier specific matches). Don't remove it just because it looks redundant on paper.

• Dynamic rules — Rules with dynamic=yes (usually at index 0) are system-generated and should not be removed.

Removal process

1. Present your findings clearly: what's redundant, what's worth noting, why
2. Wait for user confirmation before any changes
3. Remove with /ip firewall filter remove [find comment="..." or for specific rule numbers]

For rule-number-based removal:

/ip firewall filter remove numbers=10,11,12

For comment-based removal (safer — works across RouterOS versions):

/ip firewall filter remove [find comment="Allow VOICE VLAN to WAN SIP UDP 5060"]

Pitfalls

• Index shift after removal — Removing rules 10-12 shifts remaining rules down. If you reference rule numbers in your report vs what the user expects, clarify that indexes are just insertion order, not intrinsic IDs.
• /export shows the full rule set — if the user shares an export instead of live access, work from that. The rules are in the /ip firewall filter section.
• Some rules look redundant but serve as traffic shapers — A rule accepting all VOICE→WAN doesn't make a later port-specific rule wrong if the port rule also has a connection-mark or packet-mark for QoS. Check for marks.