Forward chain lets the internet reach your internal network

What the audit found

There is no active rule in the forward chain of the firewall filter that stops new connections arriving on the WAN side from being routed into your internal network. Traffic addressed to the router is handled by the input chain; traffic through the router — from the internet to a PC, a printer or a NAS behind it — goes through the forward chain, and yours lets it pass.

The audit reports this as medium when the router does source NAT (masquerade), because NAT hides the private addresses and makes the LAN harder to reach. It is reported as high when there is no NAT either, because internal hosts are then directly routable from the WAN side.

Why it matters

Most people assume NAT protects their network. It helps, but only by accident: NAT rewrites addresses, it does not decide what is allowed. With a masquerade rule and no forward filtering, anyone who can send a packet to your router with a destination address inside your LAN — 192.168.88.20, say — will have it forwarded.

Who can do that? Not the whole internet, because private addresses are not routed across it. But everybody on the same WAN segment can: other customers of your ISP on a shared uplink, neighbours on a wireless ISP, anyone on the same cable segment. They need only add a static route pointing your LAN range at your router's WAN address, and your internal hosts answer. Printers, cameras, NAS admin pages, Windows file sharing — all reachable.

Without NAT, the situation is worse: internal hosts are directly reachable from the upstream network, exactly as if they were plugged into the ISP's switch.

The forward chain is also what makes port forwards selective. A proper drop rule means only the ports you explicitly forwarded (dst-nat) get through; everything else is stopped. Without it, the port forwards are not exceptions to a rule — there is no rule.

What it looks like in Winbox

Open IP → Firewall → Filter Rules and look at the Chain column. A healthy router has rules with chain forward: one accepting established and related connections, one dropping invalid ones, and one that drops new connections coming in on the WAN interface unless they were port-forwarded. If you see no forward rules, or none that mentions your WAN interface with action drop, this is the finding.

How to fix it

First make sure your WAN interface is a member of an interface list called WAN (Interfaces → Interface List). If no such list exists, create it and add the WAN interface as its only member — the rules below match on the list rather than on a named interface, so they keep working when you change uplinks.

Then add three rules to the forward chain under IP → Firewall → Filter Rules. Order matters: accept rules first, the drop last. The first accepts connections in the established, related and untracked states — this is what lets replies to your outgoing connections come back. The second drops packets in the invalid state. The third drops any new connection arriving from the WAN list whose connection NAT state is not dst-nat, which means "drop everything from the internet that was not created by one of my port forwards". Your dst-nat rules keep working because the drop rule specifically excludes them.

Use Safe Mode while you add the rules. The forward chain does not affect your own Winbox session to the router, but a mistake in the interface list (putting your LAN in WAN by accident) would cut internal traffic, and Safe Mode rolls it back.

Afterwards, from a host on the WAN side — a laptop plugged into the same ISP segment, or a VPS with a route to your public address — try to reach an internal address through the router; it should not respond, while your port forwards still work and outgoing browsing from the LAN is unaffected. Then re-run the audit.

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

Will this break my port forwards?

No. The drop rule matches only connections whose NAT state is not dst-nat, which means "not port-forwarded". Connections that hit one of your dst-nat rules are explicitly excluded from the drop and pass as before.

I have NAT. Isn't that enough?

NAT hides your addresses from the wider internet but not from anyone on the same upstream segment, who can route to your private range directly. The forward drop rule costs nothing and closes that gap.

Does this affect traffic between my own VLANs?

Not with these rules — they only match traffic arriving on interfaces in the WAN list. If you want to separate VLANs from each other, add further forward rules with the relevant interfaces; that is a separate exercise.