I’m with you on this one. Let’s leave taking shortcuts to experienced and adventureous users and keep newbies straight on the right path …
Thanks for the response, and I fully 1000% support this educational reference.
(1) For the first type of item.......... Add text............
Blue VLAN
set bridge=BR1 tagged=BR1,sfp1,sfp2 [find vlan-ids=10]
Green VLAN
set bridge=BR1 tagged=BR1,sfp1,sfp2 [find vlan-ids=20]
Red VLAN
set bridge=BR1 tagged=BR1,sfp1,sfp2 [find vlan-ids=30]
T****he above rules for both Access and Trunk ports illustrates the important concept of ensuring /interface bridge vlans are correctly separated by vlanIDs.
Due to the fact that in the case above (the trunk one) there is identical (no difference) tagging and untagging of bridge/ports, the rules can be combined.
/ip interface bridge vlan
bridge=BR1 tagged=BR1,sfp1,sfp2 vlan-ids=10,20,30
(2) Point taken, and concur that after thinking about it, the default PVID shows up so its not as if the person will have to actually assign it.
However I would still add a note somewhere that states.
The PVID entry of one (1) is the default entry and normally does not need entry or modification unless one is assigning an access port.
(which will tie together both the trunk and previous access port assignments examples.
(3) (a) New points, Why do we not want pvid=xx ingressfiltering=yes
From discussions with MKX, there is nothing wrong security wise with assigning ingressfiltering=yes for access ports?
However, if using it we should state exactly what function ingress filtering has when used......... What does invoking it provide in functional terms.
(b) Why do we not want pvid=xx admit frame types=
From discussions with MKX, there is nothing wrong security wise with assigning frame types for access ports?
However, if using it we should state exactly what function frame types afffects when used......... What does invoking it provide in functional terms.
(4) New Point: Firewall rules........ I understand there is a million ways to put in rules so can we use and clearly state the premise of.......
Only allow permitted traffic
Drop all ese
OR
Permit ALL
Drop unwanted traffic.
I prefer the former and I think that is where you are headed since you do have drop all else rules.
By the way order is important needs more emphasis. Order is critical!
Finally, I like your use of VLAN list member!
As for rules
input
add chain=input action=accept in-interface-list=LAN comment="Allow Native LAN" DISAGREE
add chain=input action=accept in-interface-list=LAN source-address=IP (specific, range, subnet ) comment="Allow admin access to router"
There is no reason on gods green earth to let everyone on the LAN or (VLAN for that matter) have access to the router.
Remember the premise at the top.............
Optional: Allow LANS and/or VLANs to access router services like DNS. Naturally, you could make it more or less granular depending upon ones needs.
add chain=input action=accept in-interface-list=VLAN/LAN dst-port=xx protocol=xx comment="Allow VLAN/LAN to Particular Service"
forward
add chain=forward action=accept connection-state=established,related comment="Allow Estab & Related"
add chain=forward action=accept connection-state**=new in**-interface-list=LAN comment="Allow Native LAN"
I have no idea what your are doing with this rule and thus am very confused. In fact I cannot say I have seen new in very many configs at all.........
Optional: Disallow only the Red VLAN from Internet access:
add chain=forward action=drop in-interface=RED_VLAN out-interface-list=WAN comment="Drop Red from Internet"
NO NO NO NO...............remember the premise. ITS NOT ALLOWED BY DEFAULT..........
WE ONLY NEED TO WORRY ABOUT WHAT WE WISH TO ALLOW
\
Optional: Allow all VLANs to access each other and the Internet: I would remove the internet part and not combine too many factors, and better matches your comment line anyway.
#add chain=forward action=accept connection-state=new in-interface-list=VLAN comment="VLAN inter-VLAN routing"
out-interface-list=VLAN
YES YES YES, much better but from where to where.... missing the other half, so thats what I added in blue 
BUT WHY are you using NEW???? arggg your killing me with this new stuff.
Allow VLAN access to Internet only, not each other: Remove text, we are making rules that only are concerned with what we want to allow!!!
add chain=forward action=accept connection-state=new in-interface-list=VLAN out-interface-list=WAN comment="VLAN Internet Access only"
YES CORRECT, now you have both in and out, identified so its clear to the reader!!
BUT guess what LOL the F U G G I N G new cropped in again............... I think you get paid for injecting new into all rules. 
Just my 5 cents about firewall rules: regardless one’s personal preferences, the default firewall is “drop not wanted, implicitly allow everything else”. Personally I don’t think this approach is wrong and while teaching less knowledgeable users about VLAN config I don’t think we should mess with default firewall philosophy.
Well since I am only bringing 2 cents to the table, so perhaps you have a quark of a point 
If you will go back and review the rules he stated, as I already noted, the author has chosen a DROP ALL ELSE philosophy, and I am just ensuring that its consistently applied.
Its not a mix and match game, its one or the other, with few exceptions thrown in.
What disappoints me is you didn’t take the opportunity to educate me on why YES in his rules is viable and proper. It pains me to say, I wish sob would join this thread which involves him first impugning my capabilities and then answering my questions in his usual roundabout riddles…
A goal I have is to be verbose about VLAN concepts and brief about other concerns. I have earmarked a Security section for example to explain that necessary topic. If I try to illustrate to many things at once, all the complexity makes is hard to follow. MikroTik syntax efficiencies won’t make it into the main document, but it could very well be addressed separately. Points 3ab are security related.
#1
Firewall rules are very important to the VLAN concept, so I use some verbosity here. I’m a strong believer in drop by default, then add in rules to do otherwise. I think it reads easier too. On this, we agree.
#2
With regards to allowing access to the router, I’m torn about it, and I may have gotten this wrong. I think most people want access to the DNS instance running on it, so I allow it, but with a note that you can make it granular. Perhaps I should show that explicitly. I think that security is a massive topic on its own, so I’m trying to push it off into the Security section.
#3
I’m a fan of using interfaces whenever possible as opposed to source address and the like. Also, I like to reduce the total number of rules. So, from those two opinions, a new rule is merely the setup for the ultra simplistic Allow Estab & Related forward rule (which references nothing else), from then on. Its just easier to reason about. Visualize packet flow, and you’ll see how to catch and release them. Forget everything you’ve learned about MikroTik firewalling, and it will all make sense. : - )
A. Concur with your desire to provide a basic config, but understanding is important too.
By stating the fact that the bridge vlan line should be considered on a per VLAN basis is important, and something I didnt get until Mkx jotne et al, drilled it into my head 200 times.
So its important. But its not a blindly applied rule, if there is no difference in tagged and untagged elements (identical) then vlanIDs can be combined and rules simplified.
B. As long as your going to point the reasons for and functionality of ingress filtering, and admit frames, in the security section, it can be left out here.
BUT did you explain what pVID actually does… not sure but its important do state what effect it has on the packets.
C. So your a fan of reducing rules, just like I attempted to do in A. LOL, put that aside, I think clarity of purpose, consistency and readablity (anybody looking at your firewall rules should see the logic clearly) may call for more not less rules at times.
As I stated I dont have NEW in any of my rules, I dont see any in the default config, so where are you pulling this rectal pluck from???
Nobody needs access to the router except the admin, there is no discussion on this point.
The PCs of people may need DNS access, if they require internet access for example but it should be transparent.
Thus as per my example the router owner can decide which interfaces should have access to DNS…
When a packet enters a chain, I want to know what interface it came in on. Next, I want to know where it is going. Using connection-state=new allows you to make a decision right then to mark this packet as allowed, if it agrees with those two metrics. When you do, from then on you only need a single established,related rule for all future packets, coming in on all the random interfaces you might ever create in the future. This top rule need be the only rule that catches just about everything happening in the forward chain.
Interfaces are one way to group packets into virtual buckets (think business units like Research, Marketing, or protocols like VoIP, QUIC, etc.) from which you can do separate actions on. We want Security, Access, and Performance. That’s three things. But you can’t have three things! In life, you may only have two. So interfaces are a way to make those three goals reach a happy balance.
VLAN is for segmenting things, but not completely. In some networks, VLAN Blue gets permission to access some of VLAN Green. VLAN Red only gets access to the Internet. Thus, you’ll need to accept~drop based on those new attempted packets. Once you do, you can then toss all future packets into the established,related catch all. They’ve been given permission to flow, simply allow that to happen.
You obviously understand what you are doing and I dont. Thus I have no idea what new is for as I have never seen it or put it in any of my rules.
To me new is fundamentally dangerous as if it may allow external to internal connections I dont sanction or authorize. Also something I have to learn on my own.
I am just saying that its going to confuse many people like me… Especially because its not used whatsoever in default rules!!!
Okay I remember some nob saying this: " new connection is checked by filter rules is simple. If it’s really new, it won’t match the usual rule to accept established, so it will continue further, until it finds a rule that accepts it (or drops/rejects it). Then it stops. If none of the rules will match, it will be accepted at then end (default action) unless you have a drop all rule.
For example a new lan to wan request, is not established or connected but it will match the outgoing allow lan to wan rule and get passed and I imagine the return traffic is either classified as established or related. Thus it confirms my suspicion that using NEW breaks the premise of a firewall outlook that implicity denies all traffic and one has to clearly state what is accepted/authorized.
New is WAY to vague and general and thus get rid of it, if traffic doesnt match a rule I have (for a specific purpose), then off with its head!!
Consider this rule:
add chain=input in-interface-list=LAN protocol=udp port=53
It’s to allow LAN users use DNS caching server on RB btw.
It allows any packet, coming from LAN, and targeting RB’s DNS service. It matches all packets regardless connection state (either new or established, related not so much, we’d need another rule for reverse direction). So the state “new” is implicit here. If the connection requires a few rounds of packets (i.e. send-reply-send-reply…), then this rule will get triggered multiple times.
If you add another rule like this
add chain=input in-interface-list=LAN connection-state=established,related
add chain=input in-interface-list=LAN protocol=udp port=53
then the first rule would actually trigger on all but the initial packet of the same DNS connection. Which means that it would be just fine if we added connection-state=new to the second rule … from functionality point of view it wouldn’t change a bit, but it’d show the real reason for having this rule.
Yes I AGREE 
I for one do not fully comprehend under what circumstances I would want to use connection-state=new ::: I have never had a situation where I’ve needed to use that directive
… do I need more excitement in my tech life?
@WirelessRudy in the following link asks some good questions that helped me to get some ideas and
@fewi provided a lucid explanation that made sense.to me:
For UDP, only the first packet between a connection with two unique IP/port tupels are new, all return packets and subsequent packets are established. For TCP the first three packets are new (three way handshake: SYN, SYN/ACK, ACK), everything thereafter is established.
Packets can only belong to one connection, and each connection can only have on mark. Every packet can also have an independent packet mark, and an independent routing mark. So you can mark connections for policy routing purposes (routing marks derived from the connection mark), and use the packet mark independently for QoS purposes (but not use the connection mark for QoS decisions), or vice versa.
mkx has explained concisely how connection-state=new is really the highlight for the existence of another rule, which is processed first, and how these two relate to each other. I feel there is a benefit to using new, but I don’t want to go into all that now.
Thanks mkx, for stating it a level I can understand, and to Mozerd for delving deeper into the onion that is beyond me, only that perhaps I grasped, one doesnt need to worry about marking packets unless you want to go beyond marking connections and routes and if so probably for QoS purposes LOL.
Based on the discussion…
I still have to disagree with this combination…
add chain=forward action=accept connection-state=established,related comment=“Allow Estab & Related”
add chain=forward action=accept connection-state=new in-interface-list=LAN comment=“Allow Native LAN”
From the simpletons standpoint =(me), the above first rule states for any connections that are already established,related that the router is tracking, keep forwarding these packets as they have previously matched one of my “real” rules and are legit. My understanding is these packets do not need to be matched over and over again to my firewall list…
This is takes us to the second rule and which begs the the natural question: So what happens with new packets???
Answer: Well new packets will now meet with their adversary ME, the MARVEL ADMIN, who is going to apply a series of tests to such arrogant packets!!
If you can conquer one of my tasks then yee shall pass.
Therefore why in the heck would I then state, hey ALL NEW PACKETS your allowed to go forward if coming from the LAN.
Not being extremely knowledgeable, it would seem to me in MT vernacular that if a packet matches this rule, they are passed onwards and DO NOT HAVE TO be viewed against all subsequent rules.
For me that is NOT what I want the router to do?? I want all packets coming from wherever to be matched against the rules I have created, especially the first packets-connection (new one).
What am I missing in my logic??
The only thing I can surmize is that my understanding of the filter rules is flawed, meaning in that
a. First rule is allowing ALL direction of packets if already being tracked BUT subsequent rules will still be applied because matching a connection-state does not qualify as matching rule for exit from the filter rules path??.
b. Second rule is only allowing LAN originated new packets BUT subsequent rules will still be applied because matching a connection-state does not qualify as matching a rule for exit from the
filter rules path???.
I hope someone out there can understand my misunderstanding…
@anav First I think that the rule order should be opposite. NEW packets is the easiest way (for me) to tell the router which host can communicate with other and with Internet. For example you can tell that VLAN23 hosts can create NEW connections only when destination is VLAN56 and this hosts will have access ONLY to VLAN56. After your NEW connections rules you put general rule that allow established and related connections in forward chain - if first packed is allowed by the firewall every second, third and so on packed should be OK. At the end must be general drop rule, this is very important!
@anav, can we keep this thread talking about VLANs and (if needed) start a new thread (or three) to bitch about other things?
@ikogd: the rule order matters is important as packets get tested against rules in the order as they are defined and first rule that matches will end matching … either accepting packet or dropping it. So rule order matters for two things:
- more specific rules have to come earlier not to mis-trigger on the more general rule
- performance … the less rules packet has to test against, the less load on firewall/router
These two points are slightly contradictory … but the general rule which accepts packets of established and related connections does not interfer with checking packets that belong to new connections (connection can not be established and new at the same time!). On the other hand vast majority of passing packets usually belong to established connections and we want to stop processing those packets as soon as possible, hence this rule at the very top of rule list.
I’ve made a dedicated topic for that, please continue there.
I am a bit confused as to why you are setting up PVID on access point WLANs/vWLANs??
I have two Cap ACs and they dont seem to require this setup?
Perhaps I have been doing it wrong all this time LOL???
I thought the vlan tagging of the WLAN or vWLAN is done in the wireless settings??
/interface wireless
set [ find default-name=wlan1 ] antenna-gain=2 band=2ghz-g/n basic-rates-b=“”
country=canada disabled=no distance=indoors frequency-mode=
regulatory-domain installation=indoor mac-address= mode=
ap-bridge name=DevicesHallway rate-set=configured scan-list=2412,2437,2462
security-profile=devices_only ssid=RD2 supported-rates-b=“” vlan-id=45
vlan-mode=use-tag wireless-protocol=802.11 wmm-support=enabled wps-mode=
disabled
set [ find default-name=wlan2 ] antenna-gain=2 band=5ghz-a/n/ac channel-width=
20/40mhz-Ce country=canada disabled=no frequency-mode=regulatory-domain
mode=ap-bridge name=Hallway5G rate-set=configured scan-list=
5175-5185,5195-5205,5215-5225 security-profile=Hallway_wifi ssid=
Hallway_CellPhones wireless-protocol=802.11 wmm-support=enabled wps-mode=
disabled
add disabled=no mac-address= master-interface=Hallway5G name=
VisitorWIFI security-profile=HouseGuestsSecurity ssid=Guest_Wifi vlan-id=
200 vlan-mode=use-tag wmm-support=enabled wps-mode=disabled
and my bridge ports look so…
/interface bridge port
add bridge=bridgeHallway comment=defconf interface=ether1
add bridge=bridgeHallway comment=defconf interface=DevicesHallway (wlan1 - uses vlan45)
add bridge=bridgeHallway comment=defconf interface=Hallway5G (wlan2 - no vlan assigned uses default vlan1)
add bridge=bridgeHallway interface=VisitorWIFI trusted=yes (vWLAN - uses vlan200)
/interface bridge vlan
add bridge=bridgeHallway tagged=ether1,DevicesHallway vlan-ids=45
add bridge=bridgeHallway tagged=ether1,VisitorWIFI vlan-ids=200
I clearly did LOL, and I know what I did. I mixed that up, I read it as his way was the old way and the way I do it as the new way.
Kewl, now I get to change my config once again LOL. I do like the consistent approach he is using better!!
I was just wondering why it was different from what I was doing based on great advice from folks like yourself.
Okay so I took my perfectly working config and implemented the NEW scheme as you can see below.
(I am having issues with the checkbox for vlan filtering on the bridge)
and I no longer have access on my access wlans,
the default wlan on vlan45 and the vWLAN on vlan200. Nice signal no internet 
…..
UPDATE
I cycled the vlan filtering off and then back on. and everything works now!
UPDATE2: I spoke too soon, when I cycled my vlan filtering the AP burped and it worked because it went back to the old setup, that works LOL
So trying again
OKAY this is nuts, I cannot uncheck my vlan filtering or else the AP kicks out. WTF over???
# model = RouterBOARD cAP Gi-5acD2nD
/interface ethernet
set [ find default-name=ether1 ] speed=100Mbps
/interface bridge
add admin-mac= auto-mac=no comment=defconf name=bridgeHallway \
vlan-filtering=yes
/interface vlan
add interface=bridgeHallway name=Guests_WIFI-v200 vlan-id=200
add interface=bridgeHallway name=Wifi_SDevices_cap2 vlan-id=45
/interface list
add name=WAN
add name=LAN
/interface wireless
set [ find default-name=wlan1 ] antenna-gain=2 band=2ghz-g/n basic-rates-b="" \
country=canada disabled=no distance=indoors frequency-mode=\
regulatory-domain installation=indoor mac-address= mode=\
ap-bridge name=DevicesHallway rate-set=configured scan-list=2412,2437,2462 \
security-profile=devices_only ssid=RD2 supported-rates-b="" \
wireless-protocol=802.11 wmm-support=enabled wps-mode=disabled
set [ find default-name=wlan2 ] antenna-gain=2 band=5ghz-a/n/ac channel-width=\
20/40mhz-Ce country=canada disabled=no frequency-mode=regulatory-domain \
mode=ap-bridge name=Hallway5G rate-set=configured scan-list=\
5175-5185,5195-5205,5215-5225 security-profile=Hallway_wifi ssid=\
Hallway_CellPhones wireless-protocol=802.11 wmm-support=enabled wps-mode=\
disabled
add disabled=no mac-address=master-interface=Hallway5G name=\
VisitorWIFI security-profile=HouseGuestsSecurity ssid=Guest_Wifi \
wmm-support=enabled wps-mode=disabled
/interface bridge port
add bridge=bridgeHallway comment=defconf interface=ether1
add bridge=bridgeHallway comment=defconf interface=DevicesHallway pvid=45
add bridge=bridgeHallway comment=defconf interface=Hallway5G
add bridge=bridgeHallway interface=VisitorWIFI pvid=200 trusted=yes
/interface bridge vlan
add bridge=bridgeHallway untagged=DevicesHallway vlan-ids=45
add bridge=bridgeHallway untagged=VisitorWIFI vlan-ids=200
add bridge=bridgeHallway untagged=Hallway5G vlan-ids=1
/interface list member
add interface=ether1 list=WAN
add interface=Wifi_SDevices_cap2 list=LAN
add interface=Guests_WIFI-v200 list=LAN
add interface=bridgeHallway list=LAN
All example topics have now been posted. I recommend you use test hardware to try things out before implementing them in your main network. I’ve been using the hEX PoE lite and hAP ac lite units because they can be found cheaply and I can power them off each other easily.
The two reserved posts I have are for adding necessary editions to make the VLAN concept complete. There are details here and there that the configurations need in the real world, security being one of them. If you find any bugs, do tell.
Dear reader:
I am not here to help you with your configuration. There are others better suited for that. I have contributed by producing this documentation. I will naturally stick around to help make this document easy to read, implementable, performant, secure, and accurate.
Testing:
I would really appreciate anyone that could help out with testing. For Security we have things like: MAC Flooding, DHCP Starvation, DHCP Rogue, VLAN Hoping, ARP Poisoning, and MAC/IP Spoofing. In the Performant area we need to test wire speed switching, how much bandwidth can the router-on-a-stick process, and so on.
Thank you to everyone who helps out in the forums.