Hi,

Coming from a PfSense/Cisco world I thought I had an okay understanding of VLANs, L2 and L3. However, after hours of digging through manuals and forum posts regarding Mikrotik and VLANs, I am left with more questions than I had initially. Most guides explain advanced setups and focuses on trunks and HW offloading. While this is great, it doesn´t cover my basic questions.

Can someone explain the steps involved in a simple VLAN setup, as well as the bridge´s role in VLANs for ROS?

After setting up VLAN interfaces, IP addresses, firewall rules, DHCP pools and servers I have access to WAN from the different VLANs, but not other LANs/VLANs.

Setup:
RB760iGS
Untagged LAN for trusted devices with multicast for Chromecast, AirPlay and Spotify Connect
Trusted devices on VLAN 120
IoT on VLAN 13
Unifi Management on VLAN 99

HW offloading not required, as very little traffic will pass between the VLANs. I do, however, want to restrict traffic to my firewall rules. This exercise is for educational, home lab purposes, and not to be used in production.

viewtopic.php?t=143620
https://help.mikrotik.com/docs/display/ROS/VLAN

Different bridge personalities: viewtopic.php?t=173692

viewtopic.php?t=143620
https://help.mikrotik.com/docs/display/ROS/VLAN

Thanks for the reply. I have read these posts, none of them explain the basics or the bridges’ role, nor routing for VLANs.

Is a bridge required for VLAN routing?
Do I need to add routes manually for VLAN subnet A to find VLAN subnet B?

I don’t want to add additional complexity or potential security holes to my setup unless required for routing. For pfSense, I’m used to simply add firewall rules to allow routing between VLANs, and I do not fully understand ROS’ routing table.

Basically to setup vlans, you have good references.
For managing vlan traffic, the basic default firewall rules are not quite sufficient or more accurately efficient.

Best to change the following default ruleset from:
add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid
add action=drop chain=forward comment="defconf: drop all from WAN not DSTNATed" \
connection-nat-state=!dstnat connection-state=new in-interface-list=WAN

TO:
add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid
add action=accept chain=forward comment="allow internet traffic" in-interface-list=LAN out-interface-list=WAN
add action=accept chain=forward comment="allow port forwarding" connection-nat-state=dstnat ( remove or disable if port forwarding not required )
******
add action=drop chain=forward comment="drop all else"

Basically we took a one line rule that tried to accomplish two things, one - drop all inbound wan to lan traffic not dst-natted ( aka port not defined in dst nat rules inbound ) and
two - allow inbound traffic for port forwarding and made it better with some modifications.

First we allow LAN to WAN traffic ( yes it was implicitly allowed by the old rule, and this fact was not plainly clear, much better for control to be clear )
Second we allow port forwarding action to occur through the firewall
Third we block everything else. So we block not only WAN to LAN, but LAN to LAN type traffic, meaning all your vlans will not be routed via L3 and thus cannot reach other.

Now you see the ******* characters and that is to denote the location of any additional ALLOW rules you need to have on your network.
This is where you can allow connectivity between vlans or users/devices to each other as required. Typical uses are creating access for all vlans to a common printer, or to allow the admin to all vlans etc.......

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

If you stick with the default forward chain filter rules, then you would have to block every vlan from each other and that approach is tedious....... Much easier to block all and only allow authorized traffic.

Bla bla bla

@llamajaja … aka @anav …. Did they ban you AGAIN ??? goodness gracious great

Bla bla bla

@llamajaja … aka @anav …. Did they ban you AGAIN ??? goodness gracious great

No, I have been a good boy lately, even quiet on the "must have zerotrust cloudflare in an options package" mantra LOL.
--> simply travelling..........

Basically to setup vlans, you have good references.
For managing vlan traffic, the basic default firewall rules are not quite sufficient or more accurately efficient.

Best to change the following default ruleset from:
add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid
add action=drop chain=forward comment="defconf: drop all from WAN not DSTNATed" \
connection-nat-state=!dstnat connection-state=new in-interface-list=WAN

TO:
add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid
add action=accept chain=forward comment="allow internet traffic" in-interface-list=LAN out-interface-list=WAN
add action=accept chain=forward comment="allow port forwarding" connection-nat-state=dstnat ( remove or disable if port forwarding not required )
******
add action=drop chain=forward comment="drop all else"

Basically we took a one line rule that tried to accomplish two things, one - drop all inbound wan to lan traffic not dst-natted ( aka port not defined in dst nat rules inbound ) and
two - allow inbound traffic for port forwarding and made it better with some modifications.

First we allow LAN to WAN traffic ( yes it was implicitly allowed by the old rule, and this fact was not plainly clear, much better for control to be clear )
Second we allow port forwarding action to occur through the firewall
Third we block everything else. So we block not only WAN to LAN, but LAN to LAN type traffic, meaning all your vlans will not be routed via L3 and thus cannot reach other.

Now you see the ******* characters and that is to denote the location of any additional ALLOW rules you need to have on your network.
This is where you can allow connectivity between vlans or users/devices to each other as required. Typical uses are creating access for all vlans to a common printer, or to allow the admin to all vlans etc.......

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

If you stick with the default forward chain filter rules, then you would have to block every vlan from each other and that approach is tedious....... Much easier to block all and only allow authorized traffic.

Thanks, I appreciate your awesome input on firewall rules, will definitely implement those, as it makes more sense to me as well to do it that way.

However, my question regarding VLAN bridges and bridges remain unanswered:

Do I need a VLAN bridge or bridge for routing (not switching) to occur using the CPU of my RB? HW offloading is not necessary, as only management traffic will be routed between these VLANs.

Are routes required for inter-VLAN routing created automatically?

You do not need VLAN bridge if the VLAN are only routed.
Create VLAN interfaces for every VLAN (they may exist on one (ethernet) interface without a bridge). The same VLANid on different interfaces are separate/independent VLANs
(If the ethernet interface is a port on a bridge, the VLAN must be defined on the bridge (just like a DHCP must be defined on the bridge, not on a port of the bridge))

For every interface with an IP address an automatic router rule is added for that subnet, with distance 0 (connected subnet, highest priority)

The MT router is very flexible, you can do almost anything that is within the networking spectrum of allowable setups, however with later RoS and products the vlan filitering approach on one bridge works very well and is why its often cited. As soon as one goes to using one vlan for lan traffic one sort or another its easy to add more vlans etc....

Yes it is very flexible , because it is a combination of many things (switch, router, NATing gateway, Firewall, VPN, etc etc) And RouterOS lets one just combine things to create some complex setup. For younger network people this can be very confusing to still see the things as independent OSI layers in this RouterOS.

Therefore the answer on the 2 questions can be difficult to formulate. They did not go from HDSL (slip, ppp),and ethernet, with repeater, hub, bridge, switch, router

Is a bridge required for VLAN routing?
Do I need to add routes manually for VLAN subnet A to find VLAN subnet B?

Both answers are NO. "IP routing" is a layer 3 operation, as done by a dedicated router. An IP router will route between the available interfaces (serial line, ethernet, (token ring, FDDI, ATM ... you name it) , VLAN, wireless, LTE, ISDN, xDSL, bluetooth, etc etc , and in the case of RouterOS at least will create the necessary dynamic routes for all the connected interfaces.

VLAN's are layer 2 handled by VLAN capable devices like bridges, switches, servers, PC, laptop, router, ... in software or firmware or even hardware.
It is not required to use the bridge/switch handling of VLAN in RouterOS, if there is no L2 level connectivity required.
I have many MT (and Fortigate) routers and firewalls where every ethernet interface is an independent L3 domain (some of these L3 networks have their own set of VLAN as needed). The routers route between those VLAN of different or same L3 domains

This has helped me get a much better understanding of the reason of the complex setup.

I am still, however, not able to route between L3 on my HexS. I am looking for a way to combine VLAN 13 and untagged traffic on a bridged physical interface where I have my AP connected. I thought this was easy to setup, but have ended up deep down the rabbit hole of multi-site, trunked, redundant VLAN config routes.

Is it possible to switch the untagged traffic on L2 and route all VLAN13 traffic while these are on the same interface? Can someone explain this straight-forward setup to me?

a way to combine VLAN 13 and untagged traffic on a bridged physical interface where I have my AP connected.

Is it possible to switch the untagged traffic on L2 and route all VLAN13 traffic while these are on the same interface? Can someone explain this straight-forward setup to me?

Well trying to catch what you want to understand.
There is L2 connectivity needed, so indeed a bridge is required.
Now your requirements:
- combine untagged and VLAN13 on a physical interface, points to a bridge with a "hybrid" port connected. Hybrid being a combination of tagged and untagged.
- There can only be one untagged data stream, and multiple VLAN.
- The untagged data in handled as a VLAN internally in the bridge. This tag/untag operation is set with the PVID of the bridge port for that interface.
Read only recent posts and documents on VLAN , as RouterOS capabilities have changed over time, and the Bridge VLAN Table capability is larger than most Switch based VLAN tables. So check if Switch or Bridge capabilities are discussed. (Switch based is discussed in cases where hardware offloading to the switch chip is wanted)

In your case some good documents on PVID are:
viewtopic.php?t=143620
https://help.mikrotik.com/docs/display/ ... VLAN+Table

You probably will need at least one hybrid port (combining untagged and VLAN 13).
To route VLAN13, a "/interface VLAN" is needed , and VLAN13 should then NOT be forwarded to that bridge port (see: Bridge VLAN Table) where you want it routed instead https://help.mikrotik.com/docs/display/ROS/VLAN

Thanks for the great references and help, much appreciated.

Should the VLAN interface be on the ether interface or bridge? The ether interface (with its untagged traffic) is already a bridge member and L2 switching is taking place, as intended.

Simple rule: an ethernet interface that is a port on a bridge is reduced to a "slave interface" only.
E.G. : It can not have DHCP server defined on it.
DHCP client, IP address, and other things should be defined on the bridge. Those are not forbidden on the ethernet interface but not recommended.
VLAN must be on the bridge, not on the slave interface.
See : https://wiki.mikrotik.com/wiki/Manual:L ... figuration , https://wiki.mikrotik.com/wiki/Manual:L ... _interface

That makes sense, thanks.

Deeper down the rabbit hole, I still have a hard time finding simple documentation explaining why you have seperate "Interface VLAN" and "Bridge VLANs" tabs. Why do we have two different VLAN setup pages?

From my understanding you define VLANs under the "Interface VLAN" tab and you control tagging/untagging on the bridge in the "Bridge VLANs" tab.

Bonus question: in the latter, "Bridge VLANs" menu you can set the following:

• Bridge

• VLAN IDs

• Tagged

• Untagged

What does the field "VLAN IDs" set?

Here is an illustration of my setup:

For the trunk:

• Untagged and VLAN 120 should be bridged, L2 switched and HW offloaded with the other interfaces in bridge1

• VLAN 13 should be firewalled and routed, not HW offloaded

All the other ether interfaces are access ports for clients in one subnet, switched on L2. Access ports/untagged traffic only.

Would the setup be cleaner if the ether5 interface was removed from the bridge? Would a hybrid port setup still be possible?

Not sure if this is 100% correct, but the way I see this ....

1. VLAN interface, is an interface in RouterOS , traffic can be handled (eg. routed) at RouterOS L3. The VLAN interface does tag VLAN ingress and untag VLAN egress traffic. A VLAN interface can be defined on the bridge or other master interface.

2. VLAN id's in Bridge menu, are all the VLAN's known and handled by that bridge. A bridge can filter (limit) and L2 forward VLAN traffic, and do the necessary ingress and egress tagging/untagging for bridge-port interfaces
VLAN's handled by the bridge may have, or not have a VLAN interface defined in that RouterOS device. It will not need a VLAN interface if that RouterOS itself has no own traffic for that VLAN.

3. For some MT hardware switch chips, this bridge VLAN handling can be offloaded to the switch chip (which is not the RouterOS cpu). Not all MT hardware switch chips can handle VLAN as bridge-HW-offloading. If not, all handling must be done by the CPU.

4. Some interface drivers can handle VLAN tagging/untagging on their own. Typical are the WLAN and wifiwave2 wireless drivers. Wifi interfaces are not connected to the switch chip.

There are cases where only VLAN interfaces are used (and the bridge may have VLAN filtering disabled). E.g. RouterOS as DHCP server for some VLAN, and forwarding VLAN as a dump (VLAN unaware) bridge or switch.

There are cases where there are no VLAN interfaces defined, and for the forwarded traffic the VLAN filtering/tag/untag is done by the bridge/switch.

And then there are the combinations of both cases.

Even combinations with a 3th case where "VLAN interfaces" are ports on some (VLAN specific) bridge, together with the VLAN untagged interfaces also ports of that bridge. Here everything is always done by the cpu for the VLAN interfaces, and no VLAN are defined on that (VLAN specific) bridge, because all traffic is always untagged when it comes to that (VLAN specific) bridge. This is the old, rather unefficient, method of handling VLAN in RouterOS. (Known as "one bridge per VLAN")

Aaargh bridge and switch. Yet another complex thing. Bridge HW offloading uses the switch chip if it can. But quite some functionality HW offloading is limited to some switch models. There is a way to still use the switch chip hardware if the switch is configured in its own menu. Configuring bridge with HW offloading, and also configuring the switch will lead to undocumented configuration conflicts . The switch config is not seen in the bridge config, and I did not see any bridge HW offloaded config in the switch config.

Mikrotik HELP has been updated, and now with access, trunk and hybrid interface exemples

https://help.mikrotik.com/docs/display/ ... NFiltering