67 lines
3.4 KiB
Markdown
67 lines
3.4 KiB
Markdown
# 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.
|