Restrict local port forwarding via SSH

Hello,
I want to run simple port forwarding for a user:
[user windows 10]–INTERNET–>[RB1100 with ssh forwarding]->[local host with vnc].
In general it is easy to setup local post forwarding:

  1. On Windows side:
    START->RUN and type:
    CMD /C ssh -N -L localhost:5902:192.168.1.1:5900 sshvpn@20.30.40.50
  2. On MT side:
    /ip/ssh/set forwarding-enabled=local

But is it possible to restrict tunnel to exactly one local address (e.g. 192.168.1.1) ?
I assume not, but I’d rather be sure.

Well in the associated dst-nat rule you would have to use src-address of the public IP of that user.

No NAT rule necessarily required, they are doing the ssh session with the mik directly and using it as a port forward via ssh tunnel.

To answer your question, you can do firewall filter rules on input tcp port 22, but it’ll restrict normal SSH access, there’s no way to differentiate between an SSH connection for management or an SSH connection with tunneling/forwarding attached (that I’m aware of).

@anav: It’s different thing. This is when you use ssh to connect to router and forward port from local machine to otherwise unreachable remote device (but reachable from router, which will act as proxy).

Restricting it is possible, but way to do it is not great. Since any such proxied connection will be from router, they’ll be in output chain as any other connection from router. So it’s possible to block it. But the challenge is how to do it without affecting router’s other connections, because I don’t see any way how to distinguish them (correct me, if I missed something). It may be easy e.g. if you know for sure that router doesn’t need to initiate connections to anything in LAN, then you can block everything going there, with the exception of 192.168.1.1. But generally it’s problematic, if router can access something, so can the client.

Ahh okay so its a case of
external client establishing an SSH tunnel to the router?

Then one port forwards a port to the remote client? (through the tunnel).

But where is the request to access the remote server and thus that port coming from?
Okay I get it, the remote site cannot port forward so basically you get external users in this case to come in the Local Router and they get port forwarded to the server at the remote site.

Seems not the best way to me… seeing as its a single user.
I would use wireguard to establish the tunnel and simply use firewall rules and allowed addresses at both ends to connect the client via wireguard all the way through.
I would not use port forwarding

ssh -N -L localhost:5902:192.168.1.1:5900 sshvpn@20.30.40.50

If you run this as client, you connect to SSH server 20.30.40.50 as user sshvpn and your SSH client also starts listening on local port 5902. Then if you connect to localhost:5902, it will tell remote server to connect to 192.168.1.1:5900 and it will forward data for this connection. AFAIK this traffic in tunnel is not seen by any firewall, because it’s handled internally by SSH. Apart from this lack of control (*1), it’s not bad, SSH is encrypted and secure, not worse than average VPN. One advantage over VPN is that it’s basically proxy (in fact, it also supports working as SOCKS5 proxy), so it can be used even when VPN would be problematic, e.g. to access remote networks with overlapping subnets, without any NAT tricks.

(*1) Other servers may have something, I’m not sure, but in RouterOS it seems to be all or nothing.

Hi guys!
Port/host restriction using SSH forwarding is possible, No one guessed :wink:
In following example:
MT IP 192.168.1.254.
COMPUTER IP: 192.168.1.1
Allow only forward to: 192.168.1.1:5900 drop other connections.

/ip firewall filter
add action=drop chain=output connection-mark=lelo log=yes



/ip firewal mangle 
add action=mark-connection chain=postrouting dst-address=!192.168.1.1 dst-port=\
    5900 log=yes new-connection-mark=lelo passthrough=yes protocol=tcp \
    src-address=192.168.1.254

Hey, I wrote about output chain. You just made it more “interesting” by allowing first packet to pass and only blocking subsequent ones. :slight_smile:

Yes but any solution requiring mangling is a cop out :stuck_out_tongue_winking_eye: ( or a weakness in MT design, why cant I assign a destination address in routing rules… cmon MT get with the program )

Like this?

ip/firewall/nat
add action=drop chain=dstnat dst-address=192.168.1.1 src-address=20.30.40.50

In my configuration it doesn’t catch any packet

Simple output chain does not work for me:

/ip firewall filter
add action=drop chain=output dst-address=192.168.1.1 src-address=192.168.1.254