i am trying to get more knowledge about bridge vlan filtering and admittedly, i am at the very beginning of learning how to implement it.
That being said there is one thing i have noticed in my first attempts in playing around with it, that i need some clarification on.
So lets say i create a bridge for vlan filtering, create a bunch of vlan interfaces (interfaces → vlan) and assign ipv4 addresses to them afterwards.
Now, lets assume my parent interface for all these vlans is ether5, which is already carrying untagged traffic and should continue to do so.
Additionally it should carry a bunch of tagged vlans,(for a few wifi ssids) which would basically make it a hybrid port, if i am not mistaken.
The thing now is, as soon as i assign vlans under bridge → ports to eth5 i am not allowed to use eth5 as an in-/out matcher in my already existing filter rules anymore. There is a warning message that says:
in-/out interface matcher not possible when interface (ether5) is slave - use master instead (vlan-bridge)
So if i follow that advice, i am supposed to replace any pre-existing firewall rules i have created that had ether5 as an “in” matcher with vlan-bridge instead and the bridge filtering will basically do the rest or is this considered bad practice?
The same issue occurs when i review my dhcp setup and with vlan-bridging i cannot dhcp on a port that has become part of a bridge.
Coming from a pfsense background that is weird to me, because i can always create firewall rules or dhcp on a vlan parent interface, even if it carries multiple vlan tags but is also carrying untagged traffic in addition to that, as its native vlan.
thank you for your reply.
I might be overlooking things and i apologize if thats the case, but i cannot find a clear answer in Paragraph C of the link you provided.
You need to stop getting bogged down in config speak…
Detail the traffic flow requirements and provide a network diagram.
From that a rational design/config can be reached.
No one sends all their vlans on a single port, they assign vlans to the bridge and via bridge ports and bridge vlan interfaces sends the vlans down the ports as needed.
Trunk or access or hybrid.
Allright, let me try that again because i feel like i didn’t explain properly what confuses me in configuring vlans.
Its not so much a misunderstanding i guess but rather a question of what is considered “best/common practice” in general, when it comes to vlan bridging and how that affects firewall rules.
So lets start with my configuration right now:
I have a RB4011iGS+RM. Ether6 of said router is connected to Port 24 of my PoE Switch. Port 25 and P26 of that switch are connected to WiFi access points. Port 24, 25, 26 on the switch build a separate vlan. (id 30, all ports untagged with pvid30) Simple stuff, right?
I’ve setup a bunch of firewall rules on the RB4011. I won’t bother you with all the firewall rules that are related to ether6 but just for the purpose
of my question and to give you an example:
So lets say, i wanna create a few extra SSIDs and vlan them on top of the already existing traffic that was flowing through ether6 in the first place.
(eg. Guests vlan id 100, Private vlan id 200) So basically, i would have the standard traffic that was already flowing through ether6 (my default vlan if you will) and in addition to that vlan100 for the SSID Guests and vlan id 200 for SSID Private.
I ve setup everything in RouterOS according to various guides and howtos found here or in the official wiki. As soon as i add ether6 under bridge → ports to my vlan bridge, my pre-existing firewall rules with ether6 look like that:
If i follow the advice and change the “in match” from ether6 to vlan_bridge, the red message disappears and my vlan seems to work.
Whats the problem then you might ask? Well, as you can do pretty much whatever you want with RouterOS, that doesn’t mean that the way i did it is sane or even recommended, right? Should i instead put all the traffic that was initially flowing through ether 6 in a “base vlan” and therefor avoid being required to set vlan_bridge as in matcher for my rules (because i can just set it to vlan_base) or is it perfectly fine to do it the way i described above?
I sincerely hope it came across what i am trying to ask here. Its just a bit of confusion i need clarification on, before i am able to take the next step i guess. Hope you kinda see where i am coming from with this.
Getting better…
So basically ensure you have a separate vlan per SSID ( with different users ).
All the vlans will be trunked out on ether6 on the MT firewall.
All firewall rules regarding these vlans are exercised on the mikrotik input chain/forward chain etc…
The input port on the POE switch that has to be also trunk and NO pvid is assigned to port 24.
UNLESS its a stupid ubiquiti switch that needs the managed vlan untagged and this cannot be changed by you.
in this case its a hybrid port coming out of the MT device on ether 6 untagged for the management vlan and tagged for all others.
So I dont understand your terminology surrounding vlan30. Its created on the RB4011 and gets connected to the switch on port24,
either as part of a trunk of vlans, or as a hybrid port 30 with the rest of the vlans tagged. This would presume that vlan 30 is your managed vlan.
Thank you anav, i really appreciate your answers here but we are circling around my actual question a bit.
We are talking about VLANs and how to set them up properly, but that isn’t really my problem.
I am coming from a background where mostly pfsense was used so i hope that explains a bit why it is confusing to me, that i cannot assign physical interfaces to firewall rules anymore, after i ve created vlans on top of an interface.
As i described in my previous post, every physical interface i add to a vlan_bridge in the process of creating an actual vlan setup, cannot be adressed with --in-/out matchers anymore. Using the vlan_bridge interface instead, seems to work fine but i don`t know if that can be considered good practice or is even recommended. Do you know what i mean?
Its bascially firewall rule semantics i am trying to figure out here.
Just a basic example:
1.) Let say i started with a simple subnet of 192.168.180.0/24 on ether6, created a bunch of firewall rules, so that traffic is forwarded to the WAN interface properly or is rejected from being forwarded to other local subnets. All of it is working fine and traffic flows properly.
2.) Now i wanna add two vlans on top of that, so i create a vlan_bridge interface, add some vlans to it, create additional subnets for said vlans and assign the physical port(s) afterwards (in this case ether6 tagged for vlan id 200 and 300)
3.) Now i can create firewall rules for vlan200 and vlan300. I could for example say:
accept all traffic on the FORWARD chain, coming in on interface vlan200 to interface wan. So far so good.
But for the traffic regarding 192.168.180.0/24 on ether6 i can’t do that anymore, because the firewall rules won`t let me assign physical interfaces for -in/out when those interfaces are part of a vlan bridge. So for that particular traffic i would have to use the vlan_bridge instead. That is what my whole question revolves around. Is using vlan_bridge the “correct” way or is it better to vlan the initial subnet i started with too and make it vlan400 for example.
Everything is possible on MT.
You could assign a subnet to ether6.
You could assign ether6 to a bridge
you could add several vlans to the bridge
you could have all the vlans and the subnet going out ether6
Correct you would need separate firewall rules dealing with the vlans.
You could manage firewall rules for the subnet using the subnet itself.
I am not sure what effects would transpire if you tried to apply rules to the interface in hopes of hitting only the subnet.
In any case, to me mixing apples and oranges is too confusing and not useful in most case.
If you have five subnets with a mix of subnets going over various ports why on earth would you not simply make your single subnet into a vlan attached to the bridge and going out as an access port on ether6… OR a hybrid port, where the subnet is untagged and any other vlans going over ether6 are tagged…
In other words anything is possible, but how to optimally configure things is a different question.