At quick glance, it looks like @pcunite’s guide VLAN guide example… http://forum.mikrotik.com/t/using-routeros-to-vlan-your-network/126489/1
Some comments:
-
you block all inter-VLAN traffic - this may be what you want – but generally something like the main LAN may need to access the other VLANs (but perhaps not the other way around)
-
you have an IOT VLAN… this sounds like a good idea, and works fine depending on what the “IOT device”. But putting things like speakers and TVs into an “IOT” VLAN may not be ideal… since apps that control them sometimes expect them to be on same LAN as the smartphone/desktop to manage them. And since you’re blocking any VLAN from talking to any other VLAN, even unicast control from LAN be broken.
-
firewall doesn’t allow ping/icmp - this will break PMTUD from working, which, essentially, can occasionally cause slow connection and random issues with specific sites.
-
you don’t have a fasttrack rule for established, related connection that may reduce CPU load
-
the bridge vlan table does not include the bridge (BR0) as a tagged port, this is need for IP routing to work:
/interface bridge vlan
add bridge=BR0 tagged=> BR0> ,ether5 vlan-ids=20
add bridge=BR0 tagged=> BR0> ,ether5 vlan-ids=30
add bridge=BR0 tagged=> BR0> ,ether5 vlan-ids=40
add bridge=BR0 tagged=BR0,ether5 vlan-ids=10
- Re frame-types… Basically for trunks use “allow-only-vlan-tagged…”, which mean the bridge port’s pvid= is NOT untagged. While “admit-only-untagged-and-priority-tagged” is an “access port” and means the pvid= is ALWAYS untagged & it is automatically added to /interface/bridge/vlan table as an untagged= port (why the above config does NOT list any untagged= lines – since there dynamically added by used a pvid= on the /interface/bridge/port.. The only nuance here is the above – basically your bridge needs to be a tagged= port in all the /interface/bridge/vlan entries.