Hello everyone,

I'm finally happy to start my RouterOS experience, it is impressive!

Just can't find a way to connect to the router via ssh from container (`alpine` for example).
My container can reach any external IPs but not the router itself, to which I want to connect via ssh.

I need to be able to connect from 172.17.0.2 ('veth1' veth, 'containers' bridge) ssh client to 192.168.88.1 ('bridge' bridge) ssh server.
(SSH server on router is accessible from the host machine and works fine)

Here is the container setup:
I tried this option (taken from viewtopic.php?t=195063), but in this case, I couldn't ping any IP at all:
Also, I've been trying some ways to configure my network with some changes in Firewall NAT, Bridge NAT, Bridge Ports, but can't find a solution for this moment.
Any suggestions will be highly appreciated!

I need to be able to connect from 172.17.0.2 ('veth1' veth, 'containers' bridge) ssh client to 192.168.88.1 ('bridge' bridge) ssh server.

There's a NAT layer in there, and I suspect you're running into the problem that RouterOS's NAT implementation doesn't do hairpinning by default.

Another option is to get rid of the NAT layer entirely, as shown in my iperf3 container's docs. That will put your container on the same subnet, so there is no more dual-subnet routing problem to overcome.

That said, my impression is that this question's unstated major premise is flawed. Shelling into an OS-style generic container (alpine:latest, in your example) and then shelling back out of there into a host OS feels like you have yet to acquire the "containers are not VMs" wisdom. In general, those whose container-fu is strong do not shell into a container except in a debugging emergency, and such a one certainly doesn't then shell right back out to issue more commands on yet another box. If one wants a VM, then one is advised to go spin up a VM, not arm-twist a tiny Linux container running on a 32-bit ARM router into service as a poor-man's VM.

The reason I gave you solutions before the scoldings is that there are cases where the best design does indeed involve the container issuing SSH commands on the host. My only worry is that you don't have such a situation.

For instance, you might want a single web UI button for your end users to click that does nothing but toggle a given firewall rule, but gives no further access to the router, reserving the power to enable/disable arbitrary firewall rules to the administrator. You could solve that with a container running nothing but lighttpd and a Busybox instance to run an Almquist shell script to handle the CGI requests for the button. Add a stripped-down SSH client that has SSH keys baked in for running RouterOS commands under the "admin" account out on the host router, and you've got everything you need to solve this.

I believe you could pack that into a meg, fully running, if carefully pared down according to the principles you see in my iperf3 container's Dockerfile. Contrast a hand-rolled VM-style "container" based on alpine:latest, which is likely to end up ten times that size due to all of the "OS" stuff inside the container needed to provide an interactive user shell, a package manager, a login system, etc.

Thank you for such a detailed answer)

I already have a working set of .rsc scripts that monitor some firewall data and independently send it through the /fetch.
Then I just thought that it would be good to transfer this code to a container and collect data from there by connecting to the router via ssh. The implementation is really tiny and first of all it's like a client part of the experimental client-server project.

Having launched a 10 MB image, I saw that the CPU and RAM resources remained almost at the same level (which surprised me).

Thank you very much for the advice on iperf3, I’ll definitely try it!

Thank you very much for your iperf3 container. It works like a charm!