Once and for all COMPLETE Offbridge Port setup

RouterOS Useful user articles
1

Current (still experimental) version :
(fourth revision, 8th August 2025, but noone protested in the last few days, so ...)

As recommended by Rule #7:
The twelve Rules of Mikrotik Club

You shouldn't lock yourself out.

Unfortunately it is way too easy to lock oneself out, particularly when fiddling with VLANs, everything seems fine until you set "vlan-filtering=yes" on the bridge, and suddenly you cannot anymore access the device via Webfig or Winbox[1].

So here are the detailed instructions on how to take a port out of any bridge and set it available for management and emergency access to the Mikrotik device.

With many thanks to anav, Josephny, Amm0, rextended, lurker888, CGGXANNX and all the other usual suspects that contributed to the idea and its implementation.

The usual convention in Mikrotik is that the lowest numbered port (ether1) is WAN, if you have multiple WANs it is logical that they are ether2, ether3, etc., i.e. the lowest port numbers are towards the "outside".

The higher numbered ports are LAN or "inside".

Consequently the highest port number can become an emergency access port, not normally used, either temporarily (i.e. while you are fiddling with the configuration) or permanently (if you can afford a normally unused "spare" port).

Mikrotik routers mostly have 4, 5 or 8 ethernet ports, the following instructions are for reserving ether5, just replace ether5 with ether4 or ether8 according to your case.

Or you can completely ignore this mnemonic numeric order and choose any port you see fit (on some devices there are both 1 Gb and 100 Mb ports so it would make sense to use one 100 Mbit port for this - limited - use).

The default configuration of a Mikrotik SoHo device is with the interfaces categorized as either WAN or LAN:
WAN (outside, dangerous, here be lions) Ether1 is self-standing and assigned to category WAN.
LAN (inside, safe) ALL interfaces BUT ether1 are put into a bridge and the bridge is assigned to the category LAN.

Relevant default configuration snippets (The ether5 is part of the bridge, lists are WAN and LAN, bridge is LAN, anything not coming from LAN is dropped, the winbox access is allowed from LAN.):

...
/interface bridge port
add bridge=bridge comment=defconf interface=ether2 
add bridge=bridge comment=defconf interface=ether3
add bridge=bridge comment=defconf interface=ether4
add bridge=bridge comment=defconf interface=ether5
...

/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN
...

/interface list member
add comment=defconf interface=bridge list=LAN
add comment=defconf interface=ether1 list=WAN
...
/ip firewall filter
...
add chain=input action=drop in-interface-list=!LAN comment=“defconf: drop all not coming from LAN”
...

/tool mac-server mac-winbox
set allowed-interface-list=LAN

So step by step, following are three options, from simplest to (slightly) more complex:

NOTES:
[1] Just in case you have doubts whether using winbox or not, check this:
Why you should use Winbox

[2] What this rule does is to allow access (action accept) to the router (input chain) from interfaces categorized as management (interface list member MGMT), the "place-before=0" is used to insert the rule as the first one.

Please note that if the /ip firewall filter is completely empty the place-before=0 will generate an error, but that is the least of your problem, as it means that you ignored Rule #8, and are possibly exposing directly the router and devices connected to it to the internet.
And since if you ignored Rule #8 likely you ignored also Rule #3, you have a few seconds in case of an old device with user admin and blank password before your router will be pwned (on newer devices with non-blank passwords that will be more likely several days, but it still remains a risk).

2 Likes
2

This is a FIRST attempt to explain the "other" method making use of VLAN, still to be reviewed and corrrected
originally suggested by CGGXANNX in post
Once and for all COMPLETE Offbridge Port setup - #14 by CGGXANNX

From reading the first post, you may have come to the conclusions that:

  1. Implementing VLANs is complex
  2. Implementing VLANs is dangerous and you risk locking yourself out of a Mikrotik router if you make even a teeny-tiny mistake
  3. You should NOT EVEN THINK of implementing VLANs unless you have a safe way to connect to your router

Well, you would be right, but this doesn't mean that VLANs are evil (though Mikrotik's ways to deal with them sometimes can be border line with hell).

If properly used VLANs can actually be a precious resource.

To prove this, here is a way that makes use of a VLAN to give you a possible way out in case of (other) VLAN misconfigurations, ouroboros anyone? https://en.wikipedia.org/wiki/Ouroboros

BTW, this approach would solve the (not common, still ...) issue with devices that only have two ethernet ports (we take here the wAP Ax as an example, but the reasoning is the same for many other devices, from the mAP to various cAP models).

So, you have your brand new wAP Ax and you want to prepare it for one of its intended environments (countryside getaway, bus stop or rural gas station :wink: ), as an all in one device router/AP, possibly coupled with a separate (managed) switch for - say - IP cameras, NVR, cash register, whatever.

Typically you would have a bridge to which both the two radios and one ethernet port (ether2) are added (LAN) and the other ethernet port (ether1) as self-standing and connected to the ISP ONT/modem/router/whatever (WAN).

You don't have any spare port to reserve to management.

So you can create such a port virtually, by creating a VLAN interface on top of the bridge.

As seen in Rules #1 and #2:
The twelve Rules of Mikrotik Club

exception made for VLAN 1, any other number is game, you have available a 2-4094 range, we will use here 999, but you can change this as you like, as well the interface name (vlan-mgmt here) can be changed at will.

So, first thing we create a new VLAN interface on top of the bridge:

/interface vlan
add interface=bridge name=vlan-mgmt vlan-id=999

then we repeat the same steps as in the guide above from A2 to A5, only changing the name of the interface from ether5 to vlan-mgmt:

#A2 categorize correctly the newly added interface
/interface list
add comment="Management only" name=MGMT
add comment="Management and LAN" name=MGMTandLAN

/ip neighbor discovery-settings
set discover-interface-list=MGMTandLAN

/tool mac-server
set allowed-interface-list=MGMTandLAN

/tool mac-server mac-winbox
set allowed-interface-list=MGMTandLAN

/interface list member
add comment=OffBridge interface=vlan-mgmt  list=LAN

#A3 add a suitable IP address to the interface
/ip address
add address=10.10.10.1/24 interface=vlan-mgmt

#A4  configure a suitable DHCP server on the interface, ONLY IF you cannot remember that your PC should have
#a static IP of 10.10.10.10/24 to connect
/ip pool
add name=Offbridge-dhcp-pool ranges=10.10.10.1-10.10.10.254

/ip dhcp-server network
add address=10.10.10.0/24 gateway=10.10.10.1 dns-server=10.10.10.1,10.10.10.1

/ip dhcp-server
add address-pool=offbridge-dhcp-pool interface=vlan-mgmt name=offbridge-dhcp-server

/ip firewall filter
add place-before=0 chain=input action=accept in-interface-list=MGMT comment="modconf: allow from MGMT interface vlan-mgmt"

Now the additional step, make sure that ether2 (as port of the bridge) is correctly configured for VLAN 999 with frame-types admit-all (which basically means "do not be too picky with what you connect to")

/interface bridge port set [find interface=ether2] frame-types=admit-all pvid=999

At this point your wAP Ax will have 6 interfaces in total, of which only 3 are categorized as either WAN or LAN:

   -------------|   |
1. |ether1 (WAN)| F |
   -------------| i |-----------------------|
2.              | r |    vlan-mgmt (LAN)    |
                | e |-----------------------|
                | w |               |ether2 |
3.              | a |  bridge (LAN) |wlan1  |
                | l |               |wlan2  |
                | l |-----------------------|

The above (poor?) attempt at ASCII art should convey the idea that ether2, wlan1 and wlan2 are INSIDE (or slave to) the bridge whilst the vlan-mgmt one "SITS ON TOP" (or is at the same level) of the bridge.

This virtual interface is right now "inactive/doing nothing" because the bridge has by default a setting (that is usually not shown in a simple /export) of "vlan-filtering=no".

Until you leave that setting as is, this VLAN interface is like as if it wasn't existing at all.
The device conected through a physical ethernet cable to interface ether2 (actually the port ether2 of the interface bridge) will "see" the IP address assigned to the bridge, will receive from the DHCP running on the bridge (if any), etc.

Now what happens the moment you change the setting of the bridge to "vlan-filtering" on?

Actually nothing that you can see, but the vlan-mgmt interface is now ready to connect on VLAN 999, so if you change the settings on the connected device to use VLAN 999, the connection will "switch" to VLAN 999 and the connected device will get a new IP address from the "other" DHCP (the one running on VLAN 999).

In CGGXANNX's original post Once and for all COMPLETE Offbridge Port setup - #14 by CGGXANNX (all the credit for this should go to him):

3

Nice work !

On wAP AX, I have yet to see a case where I actually USE that second port (but that’s me).
I have several of them installed (same problem BTW with cAP AX, cAP AC, wAP AC, cAP XL AC … whatever device you can use as cap and has 2 ether ports)
So use it for mgmt access, I would say …

BUT … that’s only needed when you want to access such device via separate MGMT VLAN.
Because if you don’t, you don’t touch caps mode bridge settings (which do not have vlan filtering active anyhow).

In most cases ROMON is a real friend here too.

4

As always, your work is of wonderful value and gratefully appreciated.

My thoughts:

  1. I agree that the recommendation should be to use the highest number port for access. It makes it easier to look at a device and, in that time of stress of being locked out, know in an instant what port to connect to.

  2. I love the name “OffBridge” because it is a simple, one-word name that includes an explanation how it is used.

  3. Perhaps add a third option to Step 1 that simply omits the adding of ether5 to the bridge (so people can see what the final config might look like).

  4. Step 4: Without a DHCP server serving addresses on ether5, the user/admin needs to know the ip address and network size assigned to ether5. Therefore, I would suggest that a DHCP server on ether5 is necessary. However, I remember ANAV wisely advising against it so that a random user cannot simply plug in and get an ip that will provide management access. An alternative would be to assign an ip address to ether5 with a network size of /24 to make it a little easier to remember what IP to assign to the connecting device.

  5. Clarify that the firewall rule are only necessary if the admin requires access via webfig

Random notes:

Replace “no matter if already renamed to something else” with “take note of ether5’s name is use the correct name for this port if it has already been changed” and carry that throughout the tutorial – the “no matter” is unclear.

5
  1. OK
  2. OK
  3. I am not sure to understand, most people start (or should start) with default configuration, so the ether5 is normally added to the bridge.
  4. Yes, but it is optional and the choice of IP address 10.10.10.10 should make it easy to remember, the subnet mask on the PC should be irrelevant, it can be a /30 or a larger one, like the common /24, it shouldn’t change anything.
  5. I’ll try to format the text so that it is easier to see that.

The “no matter” was to introduce a “general” method, that can be used both if the eher5 is renamed or not, I’ll see if I can come out with something less confusing.

6

Clarification on this comment: I’m not a fan of daisy-chaining cap devices. That’s why I never use that second port.
In cases were I do need extra ether ports, I use ax2 or AX3 so I’m not limited in future by that single ether port.

7

Yep :smile:, but you have - I believe - no bus stops nor rural gas stations :wink: , in those cases a wAP Ax could be used as an all-in-one device, router, access point and wired switch for one device, let’s say the cash register or a surveillance camera, this latter would be bridged to the wi-fi, and the remaining port would be WAN, connected to the ISP ONT or router/modem.
And the LAN side could well use a VLAN (not needed, still …).

8

A little tip…

On peripherals with configurable RESET or MODE button,
during configuration (<SAFE MODE> still exist) you can enable it to remove filtering from the bridge in the event of a lockout… :wink:

/system routerboard mode-button
set enabled=yes on-event="/int bri set [find] vlan-filtering=no"

Or to be safe, on some devices press MODE and RESET within 1 minute to enable MAC access from the WAN…
And other cute ideas… :sweat_smile:

I have some recommendations to make,
such as DO NOT CHANGE THE NAME of the interface for any reason,
at most add AFTER what it is for, such as ether5-MGMT for example

9

The mode button trick could be a nice one.
Pressing at the same time the reset and mode button (didn’t know it was possible at all to sense that) might be safer, but probably difficult to put in practice.

Personally I don’t even think to change interface names, but a lot of people like so much to do that that it would be cruel to tell them not to.

When I find a configuration (with changed names) that I want to understand the first thing I do is to jolt down on a piece of paper a correspondence table.

I was thinking of letting the RoS build it, something loosely like:

{/interface
:put ( "default-name" . "\r\t\t=\t" . "name" )
:foreach counter=id in [find] do={
:put ([get $id value-name=default-name] . "\r\t\t=\t" . [get $id value-name=name] )
}}
10

Point 3:

It’s a very minor point but what I mean is that it might be helpful to show the final config indicating, for example on a 5-port hEX:

/interface bridge port
add bridge=bridge comment=defconf interface=ether2 
add bridge=bridge comment=defconf interface=ether3
add bridge=bridge comment=defconf interface=ether4

noting that ether1 is typically used for WAN and ether5 is OffBridge.

Point 4:

As others have wisely pointed out to me (more than once, I believe) regarding remembering things: Write them down!

However, without having the info written down and accessible, a DHCP server on OffBridge can easily make the difference between gaining access or now. As for the subnet mask, I was not referring to the subnet mask on the PC, but for the DHCP server. That is, for a situation where there is no DHCP on the MT device, a /24 would make it a little easier to remember. For example, I could say to myself: “I know I usually use 10.10.10.x for OffBridge, but I don’t know if I used 10.10.10.1/30 or 10.10.10.100/30” With a /24, all I need to remember is that I use 10.10.10.x

As far as “no matter,” that’s just a linguistic/stylistic issue that I have. I think using more and different words can make the instructions a lot clearer than using “no matter.”

11

Point 3:
It seems to me a first grade problem, you have five apples in a basket, one falls out, you eat one, how many apples remain in the basket?

Point 4:
you need 4 bytes of memory to remember 10.10.10.10 but only 3 to remember 4 x 10, but again 4 or more to remember 3 x 10 + any number in the range 1-254.
But of course everyone is free to use their own preferred IP addresses and netmask.

Another idea could be to NOT run a DHCP server on the Offbridge interface but assign to it address (say) 169.254.169.254/16 and let the DHCP client on the PC self-assign another APIPA address, cannot say if all the operating systems people may run on the device connected use APIPA, surely Windows and Mac use it, and some (many? most? all?) Linuxes use it, so It should be fine for the large majority.

12

Always good to have a clear guide.

However (there’s always one with me, isn’t there…) I would do two things differently:

  • also add a forward rule for the interface list - if the router otherwise has internet access, it’s sometimes easier to manage things while you have internet access
  • the dhcp server thing - MT’s dhcp server stops giving out addresses if the pool is exhausted, so if you disconnect a device then connect one with a different MAC, it won’t work. I think one of these should be done:
    • decrease the lease time to something short, like 1m
    • have a subnet and pool with at least 10 addresses (so a /28) - I don’t think there are that many people with 10+ devices lying around for debugging

Okay, a third:

  • I would add place-before=0 to the firewall rule (I tested, and it seems to work with with dynamic rules in a consistent way)
13

I think as a guide for beginners, we should try to minimize possible branching, to reduce the potential confusion. Currently the guide is almost twice as long as it has to be, because many steps have a branch for the case where the port has been renamed. And also many commands require [find].

It would be better if you either move step 2 to 0, and make it no longer optional, so that port ether5 is immediately renamed to OffBridge5 (if this is your choice), or at this step 0 rename the port back to its original name ether5 (if you prefer this instead).

Afterwards, all the other steps of the guide can directly use that OffBridge5 or ether5 name directly in the commands, and you don’t need the alternative path with [find] anymore.

14

Also my personal opinion, but with the current version von RouterOS 7, I don’t really see the appeal of moving a port out of the bridge for management anymore. It’s not more complicated or error prone to keep the management port in the bridge at all.

Let’s look at the starting point of the defconf configuration where most the ports are in the default bridge bridge and some other port are WAN port. Instead of moving a port out of the bridge, my “guide” would be the following, based on your guide:

  1. Add a VLAN 999 interface as management interface

    /interface vlan
add interface=bridge name=vlan-mgmt vlan-id=999

  2. Configure stuffs for vlan-mgmt similar to your guide (/ip address, optionally /ip pool, /ip dhcp-server, /ip dhcp-server network), add vlan-mgmt to LAN or MGMT (again, exactly like your guide)

  3. Now is the step that differs from yours: Set PVID of ether5 to 999 and make sure frame-types is the default admit-all (no need to change if starting from defconf) or admit-only-untagged-and-priority-tagged:

    /interface bridge port set [find interface=ether5] frame-types=admit-all pvid=999

    I prefer admit-all so that in the future I can use this management port as hybrid port and test multiple VLANs with my PC plugged to this port (Windows and Linux all support tagged VLANs).

Now you can do whatever other setups as you wish. As long as the bridge still has vlan-filtering=no as the starting value, the behavior of this port has not changed (still in the IP subnet of the original bridge interface). Once you turn on vlan-filtering=yes, this port behaves exactly the same as the port that you’ve taken out of the bridge from your guide. But with the following advantages:

  • It’s in the bridge so can have hardware offload with most of MikroTik devices with support for Bridge VLAN Filtering HW offload.

  • You don’t have to play DJ with your cable and ports while doing the configuration move, the PC used for configuration can be plugged to that same port from the beginning. If you use MAC WinBox to connect to the router then you don’t even have to do anything when switching from vlan-filtering=no to vlan-filtering=yes, WinBox will be shortly disconnected and will reconnect automatically. This is useful if your device is in a cabinet or in another room.

  • You have also already created your management VLAN, ready to be moved to other ports / switches.

  • You can use the port to test the other VLANs (or have quick access to other VLANs) in the future, as hybrid port. Also, in case you run out of ports in the future and no longer have the luxury of a dedicated port for management, then the config change is much easier. You don’t need to hunt your config and remove the added entries that directly reference ether5 at all.

Again, the difference in the steps required to be taken is instead of removing a port from the bridge, we add an entry under /interface vlan and change the pvid value of a port.

1 Like
15

@lurker888

  1. Whooosh! (that is the sound of the forward rule passing way over my head), you will need to be way more explicit in explaining to me this point
  2. the more I think about it, the more I think that using an APIPA address (if it works) and no DHCP server could be the easiest solution, using the /30 address (as I see it) is largely an exercise in style (in the sense that it only gives a false sense of security, if you cannot secure physical access to ether5 the highly specialized hacker that broke in your house to steal all your lolcat images will only be slowed down by a few minutes, I believe).
  3. that is a very good idea, and it costs nothing.

@CGGXANNX
I concur with you, and - between you and me - if it was only for me I would have completely bypassed the renaming part, if ether5 was baptized at birth as ether5, why would you change its name? (at the most bears of little brain could use the comment to remember what a port is supposed to do). But I have seen lots of people that (IMHO complicating their life, but gustibus non disputandum est ) like to rename interfaces, actually they do that first thing, before changing settings.
You are perfectly right that making these OR alternatives may confuse a new user, on the other hand I liked to show how powerful can be a minimal scripting knowledge.
The alternative, I’ll think about that could be to divide the suggested procedure in 3 branches:
A) Without renaming ether5
B) Renaming ether5 (and the suggestion by rextended of using - say - ether5-MGMT seems to me a good one)
C) General method using [find]
This way the first (simpler) method can be divided into the 4 or 5 explained steps, and the other two which are nothing but a variation of the first can be grouped each in a single CODE box.

The method using VLAN is interesting and nice :smile:, I think it can be added as a (separate) alternative.
I could re-use post #2 to that effect.
But I am not too convinced that it is “safe” enough.
I mean the “offbridge” port is intended to work, no matter the mess the user has done with VLANs setting both with vlan-filtering=no and vlan-filtering=yes, if I get right your approach this port will work with the PC NOT set to use VLAN999 if vlan-filtering=no and with the PC set to use VLAN999 if vlan-filtering=yes, but it also assumes that the bridge settings are correct.
While the Offbridge is for newcomers, your VLAN999 approach seems to me only apparently simple, and should be classified for “intermediate” experience users.

16

I meant a rule like this:

add chain=forward action=accept in-interface-list=MGMT comment=“modconf: allow from MGMT interface-ether5”

Yes, I know, it still needs an allow established rule in the correct place, etc. but I still think it’s way better to configure something with internet access if it only requires one rule.

I personally prefer these rules (applying to the MGMT ports only) at the very top of my firewall ruleset, because that’s where they’re the hardest to mess up.

The place-before=0 is not as marvelous an idea as I thought… if there are no rules present, it throws an error :frowning: I actually like Mikrotik’s cli syntax for its consistency, but I think it makes some really common things unnecessary difficult sometimes.

I think APIPA is not a very good idea. It’s support varies wildly, not only in whether it’s supported or not, but also the exact way it’s done. I genuinely think that a larger subnet with dhcp is the best. I usually allocate these from the 172.30 or 172.31 region.

17

I’ve already explained a million times not to use numbers in scripts.

Example for inserting sorted rules at the beginning…

/ip firewall mangle
add chain=test action=accept comment="RULE 5" ; move [find where comment="RULE 5"] destination=([find]->0)
add chain=test action=accept comment="RULE 4" ; move [find where comment="RULE 4"] destination=([find]->0)
add chain=test action=accept comment="RULE 3" ; move [find where comment="RULE 3"] destination=([find]->0)
add chain=test action=accept comment="RULE 2" ; move [find where comment="RULE 2"] destination=([find]->0)
add chain=test action=accept comment="RULE 1" ; move [find where comment="RULE 1"] destination=([find]->0)

and this is the final result (in export)

/ip firewall mangle
add action=accept chain=test comment="RULE 1"
add action=accept chain=test comment="RULE 2"
add action=accept chain=test comment="RULE 3"
add action=accept chain=test comment="RULE 4"
add action=accept chain=test comment="RULE 5"
18

@lurker888
Hmmm, all in all it doesn’t seem to me a good idea to give the inexperienced user “direct” access to the internet, as you say - in theory - /ip firewall filter could be completely empty, and in this case the possible error place-before-0 would cause would be a good thing, but if instead the user has only disabled the firewall rules, the MGMT PC could be instantly exposed to the internet without firewall.

About APIPA, I can only say:

  1. Windows (at least back to XP) supports it, II seem to remember 2000 also did, probably NT4 and some early WIn9x version do not
  2. MacOS is reported as supporting it
  3. Linux (AFAIK) may vary, I remember having read (some time ago) something about a misconfiguration in system.d (or whatever) that caused issues.
    Generally speaking Linux users tend to know how to fix or workaround such issues, so it shouldn’t be a problem.
  4. those using (say) a RPi, OS/2, FreeBSD, QNX, BeOS, etc. very likely know where their towel is and would have no issues.

But I have to first thing try if the idea works (assigning to ether5 a static address in the - rather large - APIPA range), but I don’t see why it shouldn’t.

@rextended
Sure, but come on, you cannot expect that kind of sophistication from beginners (the intended audience for this kind of article).

19

@jaclaz
No, it wasn't a suggestion, but an explanation...

If I say something isn't right, I explain why; I don't just say "because not"... [IT: vabé traduci "perché no!"...]

20

Same sentiments here.
It’s also a clear sign something is wrong somewhere if you see that range coming on client devices.