Feature Request | Configurable Listen Address for /ip/service

RouterOS General
1

Short summary

I would like to suggest adding a configurable listen address / bind address to /ip/service, allowing services such as WinBox, SSH, API and WebFig to listen only on explicitly selected local IP addresses instead of all addresses assigned to the router.

This would make it possible to completely avoid exposing management services on public-facing IP addresses without requiring firewall rules.

Detailed description

Consider a MikroTik router with multiple IP addresses, for example:

  • a private management IP
  • one or more internal/service IPs
  • a public Internet-facing IP

Currently, services configured under /ip/service, such as WinBox, SSH, API or WebFig, are listening on the router's addresses. The address / "Available From" setting can restrict which source addresses are allowed to use the service, but this is an access restriction rather than a configurable local bind address.

From a network perspective, I would prefer the service to not listen at all on addresses where it is not required.

For example, I would like to be able to configure something conceptually similar to:

/ip/service set winbox listen-address=10.0.0.1

or perhaps reference an address configured under /ip/address.

The result should be that WinBox actually opens TCP/8291 only on 10.0.0.1, while TCP/8291 is not opened by the service on the router's public IP address at all.

The same would apply to SSH, API, API-SSL, HTTP/HTTPS, etc.

Of course, this can currently be achieved from a security perspective by using the RouterOS firewall and dropping connections to the respective service ports on unwanted interfaces or destination addresses.

However, that means the firewall has to process the traffic in the first place. In a router handling a large amount of traffic, adding firewall processing for something that may only be relevant to perhaps one out of a million packets seems unnecessary when the application could simply not bind to that IP address in the first place.

I also see a conceptual difference between these two configurations:

Available From:
"The service is listening here, but only these remote addresses are permitted to use it."

Listen Address:
"The service does not exist on this local IP address at all."

I think both settings have their purpose and could complement each other.

Ideally, listen-address could either accept one or multiple local IP addresses directly, or possibly reference addresses configured under /ip/address.

For routers with dedicated management addresses, loopbacks, public transit addresses and customer-facing interfaces, this would provide a very clean way of explicitly defining where RouterOS management services should actually be exposed.

How important/useful would such a feature be for other RouterOS users?

Do you generally solve this exclusively with firewall rules, or would you also prefer the individual RouterOS services to support explicit local address binding?

Support-Ticket-ID: SUP-225438

rextended 2

:+1: :+1: :+1:

3

We’ve been asking for it for quite some time... Let's hope so...

4

I think it would be better to give it an interface list to listen on, not an IP address.

IP addresses are bound to interfaces, so one follows from the other.

5

I prefer the idea of using interface-list for that!

6

Similar to most other OSes like Linux listen address, "*" for all or "some.specific.ip.address"... yeah that would be preferred behaviour.

7

MikroTik might argue that all the services mentioned above already support specifying a VRF, which can be used to cleanly isolate them to a (management) VRF (which narrows down the list of interfaces / listening IP addresses) without requiring firewall rules.

8

What is not a bat argue!

A definition like this cannot simply point to a non-indexed object.
It cannot work the way "available-from" currently does—as an open field where you simply enter the desired IP address.

It has to point to an object linked to something indexed—some kind of list, or something similar.

Another point is that we cannot be lax and fail to make IPv6 usage mandatory. This shouldn't become an ordeal, nor should it require constantly creating separate "Object-Name-v4" and "Object-Name-v6" entries.

And the more important aspect in this conversation is that it should start with the concept of separation in data plane, control plane, and management plane.

Multi VRF support on each /ip/service is able to give us this.

9

If the definition of VRF on each /IP/service, instead of being single-value, becomes a multivalued array of VRFs...
This matter would be solved.

10

Yes, VRFs can be used to achieve a similar result, but in my opinion that is a rather complex workaround for what should essentially be a simple socket binding option.

If I only want WinBox or SSH to listen on one specific local IP address, using a dedicated management VRF means introducing additional network architecture just for that purpose.

Depending on the setup, this may involve:

  • creating a dedicated loopback/interface and management /32
  • creating and maintaining a separate VRF
  • providing routing between mgmt and main where required
  • VRF leaking or additional routing policies
  • advertising/transporting the management prefix through OSPF/BGP
  • making sure all required management systems have appropriate reachability to that VRF

All of this is perfectly valid if I actually want VRF-based management-plane isolation.

But that is a different requirement from simply saying:

SSH: bind only to 10.0.0.1

or:

WinBox: bind only to 10.0.0.1 and 10.0.0.2

Most network services on other operating systems provide the concept of a local listen/bind address independently of routing tables or VRFs.

I would therefore see VRF support and a listen-address option as complementary features, rather than one replacing the other.

If I need isolation, I can use a VRF. If I simply do not want a service to open a socket on a particular public IP address, a bind/listen-address would be the much simpler and more explicit solution.