No rule dropping invalid connections

What the audit found

The input chain of the IP firewall filter on your router has active rules, but none of them drops packets whose connection state is invalid. An invalid packet is one the connection tracker cannot match to any existing connection and cannot treat as the start of a new one — for example a TCP packet with flags that make no sense on their own, or a reply to a connection the router never saw.

The audit reports this as medium when the chain does not end with a rule that drops everything from WAN anyway; if such a final drop is in place, invalid packets are already caught by it.

Why it matters

Invalid packets are not part of normal traffic. Legitimate clients do not send them, so dropping them costs nothing. They are, however, exactly what port scanners and evasion tools produce: crafted TCP segments with unusual flag combinations (the classic Xmas, FIN and NULL scans) that probe how a host responds, or fragments and out-of-window packets designed to slip past state-based rules.

Without an explicit drop, these packets fall through to whatever comes next. If your chain relies on an established,related accept followed by specific accepts and nothing else, an invalid packet may reach a service, elicit a response, and tell the scanner that the port is live — or, in the worst case, exercise code paths in a service that were never meant to see such input.

This is a hardening measure rather than an open door on its own, which is why it is rated medium. It matters most on routers that expose anything at all to the internet and on routers whose input chain is otherwise incomplete. The rule is part of the RouterOS default firewall for a reason: it is cheap, safe and removes a class of noise entirely.

What it looks like in Winbox

Open IP → Firewall → Filter Rules and filter or sort by Chain = input. Look for a row whose Connection State column shows invalid and whose Action is drop. In a healthy configuration it sits near the top, right after the established,related accept. If it is missing, or present but greyed out (disabled), you have this finding.

How to fix it

The fix is one rule in the input chain: match on the invalid connection state and drop. It is added under IP → Firewall → Filter Rules like any other rule, with the connection-state match on the General tab and the action set to drop.

Placement is what needs care. The rule should sit after the accept for established and related connections and before any rule that accepts new traffic. That way the connection tracker has already waved through everything it recognises, and the invalid drop only ever sees traffic that belongs to nothing. In Winbox you can drag the rule into position in the list; if you add it at the bottom by mistake, it still works but only catches what the earlier rules let through. For reference, a complete minimal input chain is: accept established/related, drop invalid, accept ICMP, then drop everything not arriving from the LAN interface list.

The same drop is worth adding to the forward chain as well, so that malformed packets are not passed on to the devices behind the router. Neither rule can lock you out: your own management session is an established connection and is accepted before the invalid check runs. Using Safe Mode is still good practice whenever you edit the firewall.

Afterwards, confirm in the filter list that the rule is present, enabled and in the right position. After a few minutes of normal use its Packets counter will usually show a small but non-zero number — that is the background noise it now discards. Re-run the audit; the finding disappears.

The full MKRouterKit report gives the exact commands for your configuration — with your interface names and subnets filled in, in the order that will not lock you out.

FAQ

Could dropping invalid packets break any of my applications?

In practice, no. Normal TCP and UDP traffic is always tracked as new, established or related. Very rare cases involve asymmetric routing, where the router sees only one direction of a connection; those setups usually also break NAT and are worth fixing for their own sake. If you suspect it, watch the rule counter and use Torch to see what is being dropped.

I already have a final drop rule for WAN. Do I still need this?

If the final drop is in place, invalid packets from the WAN side are already discarded, and the audit does not raise this finding. The explicit rule is still worthwhile: it drops invalid packets from the LAN side too, keeps the chain readable, and stays correct if someone later loosens the final rule.

Is invalid the same as new?

No. A new packet starts a connection the tracker can follow — a TCP SYN, or a first UDP datagram. An invalid packet cannot be attributed to any connection at all. You accept selected new connections; you never need to accept invalid ones.