SSH port forwarding (tunnelling) is enabled

What the audit found

The SSH service on your router has its Forwarding Enabled setting at something other than no — local, remote, both or yes. This lets an SSH client that has logged in open tunnels through the router: forwarding a local port to a host behind the router, or the reverse.

The audit reports this as medium when SSH is reachable from the internet, and as low when it is restricted to the internal network. The setting is off by default in RouterOS, so it was enabled deliberately at some point.

Why it matters

SSH port forwarding turns an SSH login into a general-purpose tunnel. That is convenient when you use it, and dangerous when anyone else does.

Consider a router with SSH reachable from the internet and a user account with a modest password, or an account created for a script or a contractor. If that account is compromised, the attacker does not just get a RouterOS shell. With forwarding enabled they can bind a local port on their machine to 192.168.88.20:3389 behind the router and open a remote desktop session to an internal PC — or to the NAS, the printer, the camera system — as if they were plugged into your LAN. The router's forward chain never sees this traffic as a new connection from WAN, because it originates on the router itself.

Remote forwarding works the other way: the attacker exposes a service on their own machine through the router's address, turning it into a relay. This is one of the ways compromised routers end up in proxy networks.

Even for legitimate users the setting is worth questioning. A router is not a jump host. If staff need to reach internal systems from outside, a VPN (WireGuard on RouterOS 7 is simple) gives them controlled access that shows up in the firewall and the logs, rather than a tunnel that bypasses both.

For an SSH service that is limited to the LAN, the risk is smaller — someone already on the LAN gains little from tunnelling through the router — but the setting still lets a low-privilege account reach places its group permissions would not otherwise allow.

What it looks like in Winbox

Open IP → SSH. The Forwarding Enabled drop-down shows no, local, remote or both; anything except no is the finding. IP → Services shows whether SSH is enabled and which addresses may connect.

How to fix it

The fix is to set the Forwarding Enabled drop-down under IP → SSH to no. This takes effect for new sessions immediately and does not affect ordinary SSH logins, so your own shell access continues to work and Safe Mode is not needed.

If you genuinely use SSH tunnels through the router — for example to reach a Winbox port on a remote site — consider the alternatives before re-enabling it. A WireGuard or IPsec VPN gives you the same reach with proper firewall control, and the traffic shows up in the firewall and the logs rather than bypassing both.

If you must keep forwarding, limit the damage: restrict SSH to your management addresses with the Available From field under IP → Services, enable strong-crypto in the SSH settings, use key-based authentication instead of passwords, and make sure the accounts that can log in over SSH are few and well protected.

Afterwards, log in from an SSH client and try to open a local port forward through the router: the session should connect but the forward should be refused (the client reports "administratively prohibited" or the port simply does not work). Confirm that IP → SSH shows forwarding disabled, 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

I use an SSH tunnel to reach Winbox on a remote router. What should I do instead?

Set up WireGuard between the sites (or from your laptop to the router). It is a few lines of configuration, faster than an SSH tunnel, and the traffic passes through the firewall where you can see and control it. Until then, keep SSH restricted to known addresses and use key authentication.

Does this affect SFTP or scp for backups?

No. File transfer over SSH does not use port forwarding; it is a separate SSH subsystem. Disabling forwarding leaves SFTP, scp and normal shell sessions working.

If SSH is only reachable from my LAN, is this still worth changing?

It is a one-line change with no downside, so yes. It stops a limited account from using the router as a pivot, and it means you will not have to remember to change it if SSH is ever exposed later.