Difference between two Interface Lists

alex3025 · Sat Nov 16, 2024 12:13 pm

Hello,
what's the difference between the following two interface lists (I want to use them in the firewall rules):

Interface List with the only item added being the main bridge

Interface List with all of the single VLAN interfaces

The following picture explains better maybe:

wrkq · Sat Nov 16, 2024 2:22 pm

Well, an interface list is just a list, it doesn't have any power by itself.
You can put interfaces in a list, and then use the name of the list in other parts of ROS config, e.g. firewall.

The "LAN" list is in factory default config the one that includes the internal network which your router might be offering internet access to but could be used for something else.
The "VLANS" list is something custom.
You need to look through rest of the config to know how both of those lists are used in it.

I wonder - did you mean to ask "what is the difference between the-bridge-itself interface and the vlan interfaces"?
(Happy to answer but don't want to infodump if that's not what you want...)

Lokamaya · Sat Nov 16, 2024 2:25 pm

If your vlans are in the bridge, simply use LAN for default firewall rule.

If you wan to manage each vlan in firewall, for example block certain vlan, use it carefully.

anav · Sat Nov 16, 2024 3:18 pm

In short once you assign vlans to the bridge, then dont use the bridge for dhcp of any subnets.
In terms of interface list members, once the bridge is off the hook and just does bridging, it should not be used on interface list members, BUT all vlans if applicable should be identified as LAN membersl

alex3025 · Sat Nov 16, 2024 3:37 pm

You need to look through rest of the config to know how both of those lists are used in it.

I wonder - did you mean to ask "what is the difference between the-bridge-itself interface and the vlan interfaces"?
(Happy to answer but don't want to infodump if that's not what you want...)

Sorry I'm going to clarify better:

First, I'm working no default configuration and I've manually created the LAN and VLANS interface lists.

My question is:
If I create a firewall rule for e.g. dropping traffic between vlans, what's the difference of using an interface list containing "directly" the bridge versus using the "VLANS" interface list where ALL of the bridge vlans are added individually? Are them just two ways to obtain the same thing?

wrkq · Sat Nov 16, 2024 4:22 pm

So the super short version ignoring very exotic needs:
If you have bridge without vlans, you "do stuff" directly on the bridge-interface (set IP of your router, etc).
If you have bridge with vlans, you hook the vlan-subinterfaces to the bridge-interface, and do everything else on the vlan-subinterfaces.

If you'll try to set firewall rules on the big bridge interface it'll be able to do very little because it will not see ethernet packets of type IP that it knows what to do with.
It will see ethernet packets of type "vlan container" - the IP packets are hiding inside. (I think you could do some filtering on MAC addreses and so on but again, unusual/exotic need).

Not sure how much profit you will have from a single list with "all the vlan subinterfaces" either, fair chance you will need to divide it further.
But some generic rules can work on such. The list with "just the bridge" will be basically useless for what you want.

As of why:
The bridge "object" is something that connects a bunch of interfaces (ethernet ports, ppp tunnels, bunch of other things) together.
From RouterOS' point of view, when you select the bridge-interface somewhere, you select the connection between the inside-of-bridge and logic/services inside of ROS.
You can have a "just passing through" bridge that's basically ignored by RouterOS functions if you don't hook up the bridge-itself interface to other processing by e.g. assigning an IP address there.

Once you activate vlan functionality on the bridge, you can have access/untagged ports which connect a single "normal" client device into a single vlan (add the vlan-tag if entering via this port, remove the vlan-tag and show the data inside when exiting via this port), or you can have trunk/tagged ports which pipe one or more vlans to destination keeping the vlan-tag intact.
(You can also do funky in-between mixes but that's for very special needs).
You do this vlan configuration in the bridge->vlans and bridge->ports sections, not in the interface->vlans menu, as those are properties of the bridge.

The "connection from bridge to RouterOS" interface is treated the same as any other bridge member here.
Typically you want your router to see/interact with many vlans (so it can deliver services, provide routing between them and so on).
So to do that, you set up the "bridge itself" interface to be a trunk port with many vlans tagged.
And if you do that, you have all those different streams of data flow out of the bridge interface, still hidden/wrapped inside vlan tags, so ROS will basically ignore them (in most cases).

Then you go to the "Interface->Vlan" menu, and create subinterfaces which will hang off the big trunked bridge pipe, and perform the job of adding/removing vlan tags.
Each of those subinterfaces is your router's pipe to "inside of that vlan", so you can work with the data - routing, firewalling, answering DHCP requests, everything else.

alex3025 · Sat Nov 16, 2024 4:59 pm

Woah thanks, for the exaustive reply.

So, the LAN interface list with the "main" bridge is useless because, due to the vlans, when using the firewall, it doesn't know what's going on inside with the vlan packets, right?

I'm making a rule to block all the inter-vlan traffic, and I created the VLANS interface list with all of the single subinterfaces, so if I put that list as In Interface List and Out Interface List it should work?

mkx · Sat Nov 16, 2024 5:03 pm

My question is:

In short: interface is the thing which delivers frame to RouterOS. Most often it has IP address set.
This "property" is not passed to parent entities.

E.g. if you have a few ether ports members of a bridge and teaffuc is tagged so there's also a VLAN interface anchored off bridge, like this:

/interface bridge
add name=bridge vlan-filtering=yes
/interface/bridge/port
add bridge=bridge interface=ether1  # trunk port
add bridge=bridge interface=ether2 pvid=100
add bridge=bridge interface=ether3 pvid=200
/interface/bridge/vlan
add bridge=bridge tagged=bridge,ether1 untagged=ether2 vlan-ids=100
add bridge=bridge tagged=bridge,ether1 untagged=ether3 vlan-ids=200
/interface/vlan
add name=vlan100 interface=bridge vlan-id=100
add name=vlan200 interface=bridge vlan-id=200
/ip/address
add interface=vlan100 address=192.168.100.100/24
add interface=vlan200 address=192.168.200.20/24

In this case, interface seen by ROS (the L3, e.g. firewall or DHCP server) will be vlan100 and not bridge nor ether1 nor ether2.

Likewise when one uses PPPoE for WAN ... interface for WAN will be pppoe-out1 interface and not e.g. ether1.
In this case it is sensible to add ether1 to WAN interface list ... but because it's used to access ISP's modem management interface. But has nothing to do with internet traffic.

wrkq · Sat Nov 16, 2024 5:18 pm

I'm making a rule to block all the inter-vlan traffic, and I created the VLANS interface list with all of the single subinterfaces, so if I put that list as In Interface List and Out Interface List it should work?

It might be much easier for you to approach this differently.
Setup the firewall like this:

Maybe, a temporary rule to always allow everything from your management station, so you won't lock yourself out. (Stil, use safe mode!)
"always applicable" rules that will be hit the most.
Allow already-established connections, drop invalid connections, and the like.
The default configuration is a good starting point for this, more examples on wiki and forums here.
If needed, precise deny rules if you need to block something which would otherwise qualify to pass in the next section.
Allow rules. It's much easier to list what you actually want to be flowing through than everything to block.
Deny-all final rule (becomes "deny everything else").

There are two main styles firewall processing.
One is "follow rules from top, to bottom, stop on first match and execute" - like here with MT.
The other is "evaluate all deny-rules, if any matches, deny. Evaluate all allow-rules, if any matches, allow. Otherwise, deny." Windows Filtering Platform is an example.

alex3025 · Sun Nov 17, 2024 1:53 am

Likewise when one uses PPPoE for WAN ... interface for WAN will be pppoe-out1 interface and not e.g. ether1.
In this case it is sensible to add ether1 to WAN interface list ... but because it's used to access ISP's modem management interface. But has nothing to do with internet traffic.

"off-topic": Why you should add the eth port that is connected to the isp modem to the WAN list? (I'm using PPPoE)

mkx · Sun Nov 17, 2024 11:01 am

"off-topic": Why you should add the eth port that is connected to the isp modem to the WAN list? (I'm using PPPoE)

It depends. In my case ISP's modem has management interface (Web-based UI) and for that it has "LAN" IP address. Even though I put it in bridge mode and run PPPoE client on MT router, I still want to be able to access modem's UI. So I added IP address (from modem's "LAN" IP subnet) to my ether port linking with modem. Modem is remotely managed by ISP even when it's in bridge mode (and hence modem doesn't have internet connectivity). Every ISP will claim that their devices are safely managed, but why risk if one can defend even against connections coming from modem? Additionally, if I want to access modems UI from within my LAN, my router has to perform SRC NAT ... which with default config will be done for all traffic exiting via any of interfaces members of WAN interface list. So the easiest (by far) way of securing LAN from ISP's network and adding SRC NAT function is by doing a single sction: add ether port linking with modem to WAN interface list.
If physical port linking with modem doesn't have IP address set, then it my not be necessary to add it to WAN interface list. But one has to be careful also with non-IP services (MAC telnet and MAC winbox), they have separate access control settings.

Kentzo · Tue Nov 19, 2024 9:39 pm

So I added IP address (from modem's "LAN" IP subnet) to my ether port linking with modem.

Any particular reason you chose this approach rather than adding <IP>/32 route? The latter should work for both PPPoE and bridged

mkx · Wed Nov 20, 2024 9:18 am

So I added IP address (from modem's "LAN" IP subnet) to my ether port linking with modem.
Any particular reason you chose this approach rather than adding <IP>/32 route? The latter should work for both PPPoE and bridged

Simplicity.
BTW, adding /32 route doesn't make it any more secure (than adding usual /24 IP) as long as ISP modem can talk to my router (enabling it is the basic idea). Since I have little control (almost none) over modem's configuration, it could enable SRC NAT on its LAN interface ... Or run some kind of proxy service ... in any case, traffic would seem as coming from ISP modem. So firewall is still needed to protect against connections coming (or apear to come) from ISP modem. And my router needs to do masquerade on traffic targeting ISP modem, I tend to do managemnet from within one of my own VLANs and ISP modem knows nothing about them (hopefully).
BTW2, for PPPoE one doesn't need any IP address on underlying interface, PPPoE runs directly over ethernet.

Kentzo · Wed Nov 20, 2024 5:42 pm

It’s definitely not more secure, as you say. For all intents and purposes the modem needs to be treated as hostile WAN.

But for simplicity, I think it is better to use a route as a universal approach. By setting an IP address on the WAN interface you negatively affect setups where upstream uses DHCP or static assignment as the interface will end up with multiple addresses. IIRC this is not RFC and there is no default address selection standard for IPv4, but please correct me if I’m wrong.

mkx · Thu Nov 21, 2024 8:36 am

By setting an IP address on the WAN interface you negatively affect setups where upstream uses DHCP or static assignment as the interface will end up with multiple addresses.

I don't exactly understand your argument.

I guess that vast majority of devices use static IP subnet for LAN (just like ROS does by default), which means that setting static IP on LAN interface of connected (client) device is rarely a problem (and my router's interface, connected to modem, belongs to modem's LAN). In my case, I set IP address "in modem's LAN" manually and DHCP client is not running on that interface. I could go with DHCP client thingy (and modem would assign my router an address) without setting IP address manually. And also in this case setting physical interface (e.g. ether1) as member of WAN interface list would fit the purpose. In neither case it wouldn't end up with multiple addresses. This would only happen if there was statically set IP address along with enabled DHCP client. In which case router would end up having two addresses (not exactly "multiple", in my native language we have "dual" in addition to "single" and "plural") and would have opportunity to select either of them for egress connections. But since interface used is the same and it's member of WAN interface list, any of them is secured the same way.

Kentzo · Sat Nov 30, 2024 11:07 pm

This would only happen if there was statically set IP address along with enabled DHCP client.

This is exactly the argument as it's a very common setup to have a DHCP client running on the physical interface that connects to the ISP. More than one IPv4 address on an interface is not standard. So why bother with a dual IPv4 when you can just have a route that works in either setup?

mkx · Sun Dec 01, 2024 11:33 am

So why bother with a dual IPv4 when you can just have a route that works in either setup?

Adding a /32 route doesn't work with peer which uses "normal" /24 addressing ... And, again, doesn't add to security. One has to treat modem as being hostile and adding interface, connecting modem, to WAN interface list does the trick just fine ... if one sticks to concept of default config (including firewall).
If you think that using /32 route adds to security, then please explain how ... and please, include some example which will illustrate your claims. I'm not saying that your way isn't possible, I just don't see how.

anav · Sun Dec 01, 2024 4:12 pm

This topic has gotten off the rails.

1. For the OP, most of us dont worry about blocking intervlan traffic because that is just a continuation of the default safe setup MT provides for newbies.
Most of use, first thing, is turn the concept of block a few known bad things and allow everything else, TO allow known traffic and then block all else!!

SO in the forward chain we end up (modifying the default to
add action=fasttrack-connection chain=forward connection-state=established,related
add action=accept chain=forward connection-state=established,related,untracked
add action=drop chain=forward connection-state=invalid
add action=accept chain=forward comment="internet traffic" in-interface-list=LAN out-interface-list=WAN
***** add rules here *****
add action=accept chain=forward comment="port forwarding" connection-nat-state=dstnat
add action=drop chain=forward comment="Drop all else"

There is no need to setup any vlan block rules as everything not explicitly allowed, is dropped!!
Now if you need to add access from admin to vlans or all vlans to a share printer, just add those above.....

2. Once in vlan mode, the bridge as stated does nothing , no dhcp etc and should not be used for firewall rules etc either.
you have the ability to use
src or dst address --> single user
src or dst address --> entire subnet
by interface ( port/vlan ) ---> entire subnet

Interface lists are the tool of choices when describing 2 or more subnets that have a common purpose.
(exception subnet that needs to be a single interface list entry as its TRUSTED )

Address lists are required at any time you have single users, ( with or without subnets included in the same list )
++++++++++++++++\
Group where it makes sense for logic

Kentzo · Sun Dec 01, 2024 10:19 pm

If you think that using /32 route adds to security, then please explain how ... and please, include some example which will illustrate your claims. I'm not saying that your way isn't possible, I just don't see how.

It’s not about security, I fully agree that it is still WAN and don’t offer any change to that.

It’s about wider compatibility: a DHCP client on the physical interface that connects to the modem and a static route to <MODEM-IP>/32 through the said interface applies to both scenarios (ISP with DHCP and ISP with PPP). A static IP in the LAN of the modem applies “cleanly” only to the ISP with PPP case while creates a non-standard configuration in the ISP with DHCP case due to two IPv4 addresses on the same interface.

mkx · Mon Dec 02, 2024 8:38 am

It’s about wider compatibility: a DHCP client on the physical interface that connects to the modem and a static route to <MODEM-IP>/32 through the said interface applies to both scenarios (ISP with DHCP and ISP with PPP). A static IP in the LAN of the modem applies “cleanly” only to the ISP with PPP case while creates a non-standard configuration in the ISP with DHCP case due to two IPv4 addresses on the same interface.

It depends on how ISP modem behaves. In my case, even if modem is in bridge mode it still has its LAN address set and DHCP server running. So if I run DHCP client on WAN interface, then modem will offer a lease with /24 address (and I guess a /0 route via own LAN address). Adding a static IP address from same subnet with /32 mask will most probably cause router use static address when talking to ISP modem and dynamic address when talking to any other potential device in same subnet. I don't see any benefit in such arrangement compared to setting static IP address (from router's LAN address space) with /24 subnet. Compared to DHCP lease this makes sure "our" router doesn't get a /0 route via ISP router (which would be non-operational in reality as modem doesn't have internet access due to being in bridge mode). And I don't see any benefit in using /32 subnet mask instead of (normal) /24 ... in context of security ... which is discussed here.

I believe there are (minor?) benefits of using /32 instead of /24 ... but my point here is that it doesn't change anything in security department.

Having said that (and seeing @Kentzo doesn't have any good arguments about suggestion being more secure) I'm out of this thread. It's way off topic.

Difference between two Interface Lists

Difference between two Interface Lists

Re: Difference between two Interface Lists

Re: Difference between two Interface Lists

Re: Difference between two Interface Lists

Re: Difference between two Interface Lists

Re: Difference between two Interface Lists

Re: Difference between two Interface Lists

Re: Difference between two Interface Lists

Re: Difference between two Interface Lists

Re: Difference between two Interface Lists

Re: Difference between two Interface Lists

Re: Difference between two Interface Lists

Re: Difference between two Interface Lists

Re: Difference between two Interface Lists

Re: Difference between two Interface Lists

Re: Difference between two Interface Lists

Re: Difference between two Interface Lists

Re: Difference between two Interface Lists

Re: Difference between two Interface Lists

Re: Difference between two Interface Lists

Who is online