Question about interface lists

Hi there,

I have (basic?) questions about interface lists.
My new RB5009 comes with two interface lists: WAN and LAN.

By default, the bridge interface is the only member of the LAN list:

/interface list member
add comment=defconf interface=bridge list=LAN

The LAN list is then used in several places:

/ip firewall filter
add action=drop chain=input comment="defconf: drop all not coming from LAN" in-interface-list=!LAN
/ip neighbor discovery-settings
set discover-interface-list=LAN
/tool mac-server
set allowed-interface-list=LAN
/tool mac-server mac-winbox
set allowed-interface-list=LAN

So far so good. Now I added some VLANs, for example:

/interface vlan
add interface=bridge name=vlan-10-trusted vlan-id=10
/ip pool
add name=dhcp_pool2 ranges=10.0.10.2-10.0.10.254
/ip dhcp-server
add address-pool=dhcp_pool2 interface=vlan-10-trusted name=dhcp-10-trusted
/interface bridge port
add bridge=bridge comment=defconf frame-types=admit-only-untagged-and-priority-tagged interface=ether4 pvid=10
add bridge=bridge comment=defconf frame-types=admit-only-untagged-and-priority-tagged interface=ether7 pvid=10
/interface bridge vlan
add bridge=bridge tagged=ether1,bridge vlan-ids=10
/ip address
add address=10.0.10.1/24 interface=vlan-10-trusted network=10.0.10.0
/ip dhcp-server network
add address=10.0.10.0/24 gateway=10.0.10.1

As you can see, I setup a VLAN interface (vlan-10-trusted) which is a child of the bridge and I also configured a DHCP server for that network.

I then disabled the above mentioned firewall rule (just for resting):

add action=drop chain=input comment="defconf: drop all not coming from LAN" in-interface-list=!LAN

The first thing I noticed is that in Winbox, neighbor discovery was not working when my PC was in my VLAN 10.

This makes sense to me because of this sentence from the docs:

Care must be taken when working with bridges and lists. Adding a bridge as a member is not the same as adding all its ports! And adding all slave ports as members is not the same as adding the bridge itself. This can particularly impact functionality of neighbor discovery.

OK, so when I added vlan-10-trusted to the LAN list, neighbor discovery was working from VLAN 10 as expected.

But let us assume, I did not add vlan-10-trusted to LAN list.
Since allowed-interface-list of the mac-winbox server was set to LAN as well, I assumed that I cannot connect using Winbox.
But it works. Why is that? :open_mouth:
It looks a bit inconsitent to me, compared to the neighbor discovery case above.

If I enable the firewall rule again, I cannot connect via Winbox anymore from my VLAN.
The firewall rule referenced the LAN list. And since I did not add vlan-10-trusted to that list explicitly, incoming traffic from the VLAN is blocked. So this is similar to the neighbor discovery case.

But now comes the bonus question:
Let us say, I do not add vlan-10-trusted to LAN list, so the list contains just the bridge, and I keep the firewall rule as it is (blocking everything not coming via LAN … the bridge).
I would assume that DHCP traffic from the VLAN to the router is blocked just like the winbox traffic.
But it is not. All my VLAN clients successfully get an IP address from the router. Why? :astonished:

Can somebody give me some insights here on what I am missing? :slight_smile:

I am not an expert, still a beginner but I believe I have VLANs working successfully on my Hex S. I followed this guide http://forum.mikrotik.com/t/using-routeros-to-vlan-your-network/126489/1 and read this https://help.mikrotik.com/docs/spaces/ROS/pages/28606465/Bridge+VLAN+Table too.
From the looks of things you may have forgotten:

/interface bridge set bridge1 vlan-filtering=yes

Beware of this - I have locked myself out a few times when learning how VLANs work. A top tip is to take a single port off the bridge so you can always go plug in, set your IP manually on your machine and then access the router. Or, just use Safe Mode https://help.mikrotik.com/docs/spaces/ROS/pages/328155/Configuration+Management#ConfigurationManagement-SafeMode (saved me many times too).

Yup the correct vlan reference article was provided!

If you will notice, there is one bridge all vlans, so the bridge does no dhcp or subnet work............. simply create a vlan for that subnet as well.

To make changes worry free!!!
Actually the best thing to do is take ether5 off the bridge and do all the config from a safe location.
Okay how to create an offbridge port. REMOVE ether5 from /interface bridge ports

/interface ethernet
set [ find default-name=ether5 ] comment=OffBridge5

/interface list
add list=TRUSTED

/interface list member
add interface=OffBridge5 list=TRUSTED
add interface=OffBridge5 list=LAN

/ip address
add address=192.168.77.1/30 interface=OffBridge5 network=192.168.77.0

Now simply plug in laptop to ether5 on the router, change IPV4 settings on the laptop to 192.168.77.2 and you should be in!!
Repeat for any mikrotik device when doing vlans and bridge.

\

On interface lists, the bridge is removed and the vlans are the interfaces as members of the LAN list.

Thank you both for your replies.

I forgot to say that VLANs are working fine. I also already know (and read) the linked documentation. Of course, I enabled vlan-filtering on the bridge, I just forgot to mention it above :slight_smile: So VLANs are working fine, that’s not a problem at all.

My questions are really only regarding the interface lists and its kind-of-inconsistent behavior.


You mean that vlan interfaces which are childs of the bridge, will be automatically members of the interface list if that list contains the bridge? Or do you mean I have to manually add the vlan interfaces to the list?

Because as I showed above, I have to manually add the vlan interfaces to the LAN list, so that the firewall rule does not block traffic from VLAN and neighbor discovery works as expected.
But on the other hand, I can connect to the mac-winbox-server from my VLAN even if the vlan interface is not added to the LAN list. Although the mac-winbox-server uses that same LAN list.

Correct, manually entered.

Typically, once you have vlans, one has to indicate which is a Trusted or the Management vlan, if nothing else for proper security.
This is done through creating a TRUSTED interface list… This ripples through the config
a. the input chain, users ONLY need access to services in-interface-list to DNS udp/tcp and maybe ntp
b. the input chain ONLY the admin needs access to the router and we do this through
i. typically in-interface-list=TRUSTED and which may need to be supplemented by firewall address list if deemed necessary by the admin.

c.Then one ensure the iP Neighbours setting is set to interface-list=TRUSTED
d. Tools settings are such that mac-server is set to NONE and mac-server mac-Winbox is set to TRUSTED
e. ensure interface list members has

add interface=vlan-mgmt list=TRUSTED could be the trusted home vlan…
add interface=OffBridge5 list=TRUSTED

I just did a quick test. Here is my interface list:

/interface list
add name=Management

/interface list member
add interface=vlan-10-Management list=Management

So only that single vlan interface is part of the Management list. Nothing else, no bridge, no other vlan interfaces.
Now I use that list for neighbor discovery and the winbox server:

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

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

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

I do not block anything on the firewall input chain yet.
Network discovery is indeed only working from VLAN 10, not on other VLANs.
But I can connect from all VLANs to the router via Winbox. So I don’t understand that allowed-interface-list setting of the mac-server. It looks to me like it does nothing.

Of course, I can use firewall rules to allow access from the Management list and block everything else. And it also allows me to accept certain IPs from other VLANs:

/ip firewall filter
add action=accept chain=input in-interface-list=Management
add action=accept chain=input src-address=10.0.30.254
add action=drop chain=input

But I don’t get the meaning of mac-servers’ allowed-interface-list setting. Or is this a bug?

Yes, that should not happen,
You should only be able to access the router via Winbox from the management VLAN with those settings…
I would need to see your whole config to comment accurately though…
/export file=anynameyouwish ( minus router serial number, any public WANIP information, keys)

There are a number of places one can control access to the router.
a. SYSTEM USERS – full or partial access
b. IP SERVICES - winbox, here you delineate which vlans can access winbox ( if left empty all vlans can )
c. TOOLS: MAC-BOX MAC-WINBOX should limit access to winbox via mac address (wont show automatically) to only those vlans on INTERFACE LIST>
( you have raised a good point, in that, it may be still possible to enter winbox from a non-interface list vlan, using IP ADDRESS:PORT number.

Can you confirm that when using winbox from the trusted vlan, all devices are seen in winbox neighbours aka their mac address etc. and that when in a non-trusted VLAN, none of the devices with their mac address show up??

d. The final level of granularity is the input chain rule. Here you can limit by interface list or by IP address access to the router, as you have discovered - the buck stops here.

+++++++++++++++++++++++

Based on this the Tools setting may only limit the automated viewing of mac addresses of MT devices, and one can still access via IP address from any VLAN.
The use of the IP settings, allows one to limit access to vlans, regardless of mac or IP…
The use of the firewall rules, provides further granularity if required, here the use of the interface list will stop cold not trusted vlans… one can further limit by IP address if or lists if required.

As surmized: Behaviour is normal:

MAC server

MAC server section allows you to configure MAC Telnet Server, MAC WinBox Server and MAC Ping Server on RouterOS device.
MAC Telnet is used to provide access to a router that has no IP address set. It works just like IP telnet. MAC telnet is possible between two MikroTik RouterOS routers only.
MAC WinBox is used to provide Winbox access to the router via MAC address.
MAC Ping is used to allow MAC pings to the router’s MAC address.

In summary, the real security aspects are provided by IP Services, winbox allowed addresses and Input chain.
The mac-winbox and ip neighbours discovery enable the admin quick and easy access to devices on the management vlan/subnet.

Because DHCP uses raw sockets and is not affected by the /ip firewall filter table’s rules. You can read this recent thread for more discussion, especially @lurker8888 posts:

http://forum.mikrotik.com/t/bootp-dhcp-bypasses-nat-firewall/182385/21

OMG, I don’t know how I could miss the word “mac” in “mac-server”. Now it makes sense. When I try to connect via Winbox using the routers’ MAC address, it only works from the vlans listed in the Management list. Just like neighbor discovery is only working for those vlans.
However, this does not affect connecting via IP addresses. This is still possible from all VLANs, unless I specify allowed IPs/Networks in “IP → Services → Winbox”.

Thank you for your hints @anav !


I stumbled upon an older post mentioning that this was the case for RouterOS 4 or so. Good to know that this is still the case with RouterOS 7. Thank you @CGGXANNX .

So everything is clear now. Thanks everybody!