I am trying to set up a dedicated management port in RouterOS, kind of like how SWOS handles it, completely isolated from any other ports on the switch, meaning only devices connected to the management port can manage the switch.
I have tried a few things, but each has its own issues:
I tried creating one bridge for all ports and a separate bridge just for management, everything works fine. But I heard that having multiple bridges isn’t a good idea because of the hardware offloading, and could cause conflicts, so I ruled that out.
I tried taking the management port out of the bridge entirely, but then making configuration becomes difficult, and every time I make a change, the management port drops all packets (maybe CPU overload?)
I also tried using VLANs and moving the management port to another switch, but since they are still on the same bridge, other ports can still access the management panel. And if I remove the bridge, I run into issue #2 again.
Firewall isolation was another option I explored, but since the management port is still part of the bridge, I can’t isolate it at the interface level. I can add IP/MAC filtering, but that seems like a messy workaround with extra overhead.
Switching to SWOS, but SWOS is just so difficult to use and lack a lot of features..
It seems like the best approach is to keep the management port separate from the bridge, but then managing the switch configuration becomes a nightmare. I did a lot of searches in forum and Google searches, but no luck. How do you guys handle this? Any better ideas?
Create a separate VLAN with DHCP and make a firewall rule that you are accepting host inbound traffic (INPUT Chain) on port 80,22 or 8291 whatever your preferred management protocol and done or use VRF it’s not hard you just have to know your way around with MT
VRF approach let assume your ether5 will be your management VRF and 192.168.100.1/24 would be your management IP and both winbox and ssh is your management protocol
If you have a separate physical port available you do not need a vLAN. Your idea No. 2 is normal practice, remove a port from the bridge, give it a separate DHCP address, pool, server, and (after testing access) allow management / Winbox only from that port. It should all work normally. If it does not, export your configuration and post it here between code tags.
If you have a separate physical port available you do not need a vLAN. Your idea No. 2 is normal practice, remove a port from the bridge, give it a separate DHCP address, pool, server, and (after testing access) allow management / Winbox only from that port. It should all work normally. If it does not, export your configuration and post it here between code tags.
But as I mentioned in #2, whenever I make a config change, I will disconnect from the management port for several seconds everytime, I verified this with ping, every time i make config changes, there are several seconds of packet loss. Is this normal?
Create a separate VLAN with DHCP and make a firewall rule that you are accepting host inbound traffic (INPUT Chain) on port 80,22 or 8291 whatever your preferred management protocol and done or use VRF it’s not hard you just have to know your way around with MT
VRF approach let assume your ether5 will be your management VRF and 192.168.100.1/24 would be your management IP and both winbox and ssh is your management protocol
You got some good pointers, let me give my two cents.
This is actually a fully valid approach. Also, having only one bridge is solid advice, but a bit of a half-truth. The fully correct statement would be: you can have as many bridges as you like, but only one will be hardware offloaded, the others will be processed fully in software. For a management port this is not a problem.
How RouterOS selects which bridge will be offloaded is not exactly documented (I think it should be…), but I had good results with disabling HW offloading on all ports of the bridge (or bridges) that I don’t want offloaded. Maybe the order of creation (internal id) could play a part, honestly I don’t know - in all my setups I always created the port I want offloaded first…
This is also a solid solution. Setup should be exactly the same, just substitute you bridge.mgmt to your etherX-mgmt everywhere. The only reason I can imagine that this didn’t work for you correctly is that you messed up in changing the interface - they have to be changed in many places, and it’s easy to miss one.
Anyhow, please use interface lists (create an interface list mgmt, if you haven’t already.)
The #1 approach with the bridge has the advantage that you can really easily reshuffle where your mgmt port is just by replacing it as a bridge port. In the firewall and where available you should always use interface lists, but in some places it’s not possible (doesn’t make sense), such as DHCP server, IP address…
A management VLAN is also a fully correct solution. (And used quite frequently.) However it is conceptually different from having a physical management port. The two can be woven together with VLAN filtering and tagging the management port as the only (access) port to it, but it is still a different beast. If you want a real management port, stick to that.
Firewalling is always good practice. Allow input only from the management interface list (be it bridge or port), and also restrict forwarding. This is not a concern until you have an address assigned on your “real” bridge, which (even if you currently don’t have) may become useful or needed for some unforeseen use case in the future.
I would basically advise against SwOS. If you have your bridging and VLANs sorted, than you’ve tackled the hard part and are all set to use RouterOS.
I don’t understand this part. For this sort of isolation either a separate port or a separate VLAN are the usual solutions (that you have correctly identified).
If you want in-band management then you will have to select which service you trust enough to expose (obviously one will have to be…) The usual suggestions are (in order of my fully subjective preference): ssh (with key auth is possible), wireguard, openvpn. (Other VPN protocols are also included in RouterOS, such as IPSec and its variants, SSTP…) What I emphatically don’t suggest: exposing management interfaces (winbox/webfig/snmp/mac services…) with some sort of trickery, such as non-default ports, port knocking, etc. These can be useful in cutting down on plain dumb port scanning, but real security is provided by real cryptography, which usually only VPN protocols provide (ssh being the exception). Just a useful tip at the end: SSH actually fully supports port forwarding, so via an ssh login you are fully able to make use of the convenience or Winbox/Webfig - in this case SSH fully provides the auth/crypto part.
EDIT: Also, VRFs - while an elegant solution - are not needed in your case. And setting them up for the first time can be a real pain. So if you don’t consider yourself an expert in all things routing, forego them for now would be my advice. (Not to mention that you won’t really get much help on the forum for edge cases related to them - and there are quite a few.)
I configure during bootstrap device, ether5 as a real “out of band”/“emergency” mgmt port, no bridge, nothing else :
## configure ether5 as out of band management
/interface bridge port remove [find interface="ether5"]
/ip address add address=192.168.99.1/24 interface=ether5 network=192.168.99.0
/ip firewall filter add action=accept chain=input comment="admin mikrotik out-of-band eth5" in-interface=ether5
This work because, creating during the bootstrap and all filter rules are removed before.
I don’t set secure services with ip withlist, i only use filter rules.
I just create a emergency user able to connect from this interface :