interface list behaviors

RouterOS Beginner Basics
1

Hi,
I am experimenting with different configurations for my own learning and enjoyment (i.e., not a production environment) and I noticed something that made me curious about how interface lists work. At the moment, these two devices are just managed by CAPsMAN from another device (my main router), nothing special.

One device is an AC2 on my learning network and I had the interface list configured this way:

[admin@MikroTik hAP AC2 (Upstairs)] /interface/list> export 
# jun/26/2023 10:43:32 by RouterOS 7.1.3
# model = RBD52G-5HacD2HnD
/interface list
add name=WAN
add name=LAN
/interface list member
add interface=ether1 list=WAN
add interface=ether2 list=LAN
add interface=ether3 list=LAN
add interface=ether4 list=LAN
add interface=ether5 list=LAN
add interface=wlan2 list=LAN
add interface=wlan1 list=LAN

On a different part of the same network, I have an AC3 with the list this way:

[admin@MikroTik hAP AC3] /interface/list> export
# jun/26/2023 06:24:59 by RouterOS 7.1.3
# model = RBD53iG-5HacD2HnD
/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN
/interface list member
add comment=defconf interface=bridge-AC3 list=LAN
add comment=defconf interface=ether1 list=WAN

(bridge-AC3 contains ether1-5 and wlan1-2)

Functionally, the results seem to be indistinguishable. I was wondering if it might have some functional differences relating to this post:

http://forum.mikrotik.com/t/interface-list-usage-question/129410/1

But, basically, I am hoping to understand more about the differences between these two seemingly-equal ways of interface listing. Is one a better practice? or more secure? or allows/limits some other functionality? I’ve read the mikrotik documentation but it doesn’t explain very deep beneath the surface.

Thank you for the education!

[edit] Clarification to my question: Which device (the AC2 or the AC3) is set up more ‘correctly?’ They both seem to work equally well, but I am ignorant what the unintended consequences may be of using one method over the other, and wish to learn about best practices. Or is either way OK?

2

Interface lists are good for TWO reasons.

  1. they help simplify all kinds of firewall rules, input chain, forward chain, nat etc…

In general one should use interfaces to describe more than one subnet, assuming we are talking whole subnets.
The exception is the management subnet which may be a single subnet but is normally put in its own interface list. For the home scenario,
this could simply be the trusted subnet. For a single subnet simply use dst or src address to describe the subnet .0/24.

For a bunch of users from within a subnet OR a group of users from different subnets then a firewall address list is best.
This also includes a MIX of users and whole subnets…use firewall address list.

  1. The other reason to use interface lists is because they are used throughout the config for various purposes.
    neighbour discovery, winbox mac server etc…
3

Thanks for the reply! Your answer is helpful to understanding the big picture. To clarify my original question, I also wanted to ask about this more specific case: I have two devices; the first device builds the interface list by adding each physical port individually by name; the other device builds the interface list by adding a the interface bridge-AC3 instead of individually adding each port. My question is: between these two methods, is one superior to the other? If there are any substantial differences between these methods, what are the pros/cons of each method?

Thanks,
Colm

4

It depends on what you want to use it for.
When it is for configuration of the firewall, as these WAN and LAN interface lists commonly are, the correct configuration is to make the bridge interface member of the list, not the individual member ports.
But when it is for purposes like neighbor discovery lists it can be useful to make ports a member and not the bridge.

5

As pe1chl stated you are mixing up apples and oranges.

There is interface lists for the purposes I stated and then there is also a bridge with its bridge ports.
If there are no vlans then one simply has a single subnet going over the bridge and only /interface bridge ports where each port is identified as belonging to the bridge and for interface list rules, one only needs to identify the bridge as being a member of the LAN interface for example.

In the case where one has multiple subnets and vlans, then we also need /interface bridge vlans to help ensure that the bridge ports are correctly identified as trunk, access or hybrid ports and then using /interface bridge vlans to detail the assignment of vlans to those ports… In this case for interface lists each vlan needs to be added as a LAN interface member and the bridge is not.

6

Thank you anav and pe1chl for the further explanations!

So if I understand correctly: Either way works, and the preferred method is situational.

For a flat network with no VLANs or complex firewall rules, the method of “just assign the whole bridge to the list” is simplest, and it works fine for a ‘flat’ network like mine.

For a more complex network, the method of “assigning ports directly to lists” can be used for the assignment of ports to VLANs, and configuring subnets & trunks, and for firewall rules (probably among other things). And this can help with Neighbor Discovery too.

pe1chl, could you please elaborate on how Neighbor Discovery is assisted by making the ports as individual members as opposed to how it is impeded by the other method? Are you specifically referring to NDP in IPv6, or, ARP/ICMP processes in IPv4, or both?

I think my next experiment will be to practice configuring some VLANs, so this is all very relevant. I really appreciate the teaching, thank you again.

7

Actually in a flat bridged network like yours, the interface-list has no barring as you are not using firewall rules. The firewall is being bypassed by the bridge. That is why you prescieve no difference between the two. If you set both up has routers, with all interfaces belonging to the bridge, you see that the firewall rules of the router with the individual Interfaces named would not work. Interfaces belonging to a bridge are only as the bridge.

8

croak croak
/interface list
add name=LAN
/interface list members
add interface=bridge list=LAN

add chain=forward action=accept in-interface-list=LAN out-interface-list=WAN.

There are many ways to skin the italian cat as long as one understands that, many ways are viable, such as not using interface lists when not necessary.
its just a good skill set to have in one’s pocket.

9

Very interesting points. I have always been afraid to alter my default firewall settings at the router, knowing how easy it is to misconfigure the firewall. But I can practice on an internal firewall using this information. Eventually I want to host a server in a DMZ that can be accessed from the scary outside world, but I have much to learn before then :slight_smile:

10

What???

11

Just checkin to see if you review all my work… :wink:)

12

The best way to host a server is have people wireguard in to your router and then through firewall allow them to access the server. At least from a security perspective.
Exposing ports to the net without such protection is a dicey proposition.
Why I have been requesting MT add zerotrust cloudflare tunnel as part of RoS or an options package because that allows one to setup a server without exposing the port to the internet.

13

Thank you again- I have been able to review your work :slight_smile:

I had some life events distract me this summer (I’ll spare everyone the details) but now I have some time to return to this education, once again.

Your point about having people wireguard in, to protect the server, is a good one. I am starting another thread about wireguard since I decided to experiment with your suggestion, but I am getting stuck on newbie troubles.