# 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.