I’m setting up vlans. With working vlan segment including wireless AP when I set-up client in the access list with vlan mode=use tag and the default vlanid of the AP interface the client loses connectivity.
What is the function of these two vlan fields in the access list? Could not find it in the documentation https://wiki.mikrotik.com/wiki/Manual:Interface/Wireless#Access_List
What you mean by “default vlanid of the AP interface”? The vlan-mode and vlan-id in the /interface wireless access-list override these settings of the wireless interface itself, but do not affect the /interface bridge vlan and /interface bridge port settings. So the wireless interface must be listed in the tagged list for the VLAN ID set using the /interface wireless access-list rule, and the pvid specified for the wireless interface on its respective /interface bridge port row must differ.
Maybe better to post your actual configuration and describe which particular VLAN ID you want the specific client matched by the /interface wireless access-list rule to get.
my whole config is pretty big and there are tons of unrelated things there so I’d rather not post it. Unfortunately I don’t have clean box on which to test.
let me clarify:
This is the best guide for vlans using port and bridge vlan settings. What is germane to your questions is that the guide AVOIDS using vlan tags in wireless settings.
This approach is clean and works.
http://forum.mikrotik.com/t/using-routeros-to-vlan-your-network/126489/1
If you don’t tag the wireless interface itself, and the corresponding /interface bridge port row has pvid=10, you cannot (and need not) use vlan-id=10 in the /interface wireless access-list. But you can use e.g. vlan-mode=use-tag vlan-id=20 to move the client matching that rule into VLAN 20; in such case, the wireless interface must be listed in the tagged list on an /interface bridge vlan row whose vlan-ids list contains 20.
Imagine the wireless interface being a standalone wireless AP with an Ethernet port, connected to an Ethernet port on the bridge using a patchcord.
Currently, when the DHCP server sends the response which gets tagged with VID 10 by the /interface vlan, the vlan filtering on the bridge strips the tag with VID 10 as the frame egresses from the bridge via the bridge port to which the wireless interface is “connected”, because the pvid of this port is set to 10. And the wireless interface “connected to that port” then doesn’t forward that frame to the client matching the wireless access list rule, because only frames tagged with VID 10 are eligible to be forwarded to that client (and untagged on the way to the air).
In the client → DHCP server direction, the bridge doesn’t re-tag the frame from the client on ingress as it arrives already tagged from the wireless interface, and as the VID is permitted on that bridge port.
Thank you, but I went through this guide and it’s not matching my needs. It’s scoped to port-based vlan and I want to assign vlan based on mac address. Or, could it be it addresses my need and I have missed the respective section?
The set-up where everything is tagged the same is experiment to see what happens with matching tags and enabled/disabled access list entry. My logic was it won’t have effect, but obviously my mental model is wrong.
Do I imagine right that the access list entry creates virtual port on the AP with lan id 20 ? And that’s the real access port and everything before that needs to be trunk?
The wireless ap clients then connects to the bridge via which ports? I have vlan interface with id 20 — does the traffic go through it?
If my pvids are 10 everywhere and I want one specific AP client to be segregated into lan id 20, my understanding is I need:
How about this: wlan1 interface (let’s forget about radio for now) is principally access port for VLAN 10, configured using pvid (/interface bridge interface add interface=wlan1 bridge=bridge pvid=10). So without any special stuff clients are sending tagless packets, wireless driver passes them tagless to bridge, which tags them on ingress (and are thus tagged inside bridge). On egress bridge untags packets with VID=10, passes them to wireless driver tagless and wireless sends them to clients.
With access-list overrides, when certain client sends untagged frames, wireless driver tags them with VID=20 and passes them tagged to bridge. At this moment wlan1 interface becomes hybrid bridge port and bridge has to be configured accordingly (/interface bridge vlan add bridge=bridge tagged=wlan1 vlan-ids=20). On ingress bridge keeps vlan tag and those packets are tagged inside bridge. On egress bridge passes packets tagged with VID=20 to wireless driver, wireless driver untags them and sends them to particular client.
As @sindy already mentioned: wireless access list overrides doesn’t configure bridge interface wlan1 to become hybrid port with all necessary VIDs taged, it has to be done explicitly.
Alternative to above would be to configure wlan1 as trunk bridge port (tagged for VID 10 as well) and configure wireless driver to tag/untag all traffic by itself (vlan-id=10 vlan-mode=use-tag). In this case all traffic would ingress bridge port already tagged … perhaps a tad less confusing?
Thanks, your explanation makes it both clearer and more confusing for me. The confusing part is that you start talking about drivers tagging packets, while my impression is that ports tag/untag packets…
Adding to the confusion is the dual nature of the bridge, but I got aware of this aspect in the master thread linked above.
re bridge’s role — I don’t assign IP to it. Only to the derived vlan interfaces. Then I need to have it tagged or nothing works. I get that it’s the “backbone trunk” between the ports attached to it. It’s still not intuitive to me why it always must be explicitly tagged in the bridge/vlan record.
Next, the bridge’s vlan interfaces must be untagged because they are access ports to the other bridges & interfaces in the router. That’s clear as well (and hopefully right?)
When not using wifi client tags, the AP is access port and the bridge does tagging/untagging (as you explained) on the border between them.
When I add to this the access list overrides (this was unclear to me — is it override or yet another filter to be matched), then I create virtual port connected to the AP port, therefore the AP must act as trunk for that vlan and be hybrid.
With this mental model I got my desired set-up running 
big thanks to all who answered, you helped me. I can now finally segregate and customize the experience of my family members and worry less about someone bringing in virus or worse.
You can think about it this way, yes. As if there was a dynamically created /interface vlan vlan-id=20 on the virtual Ethernet interface of the AP facing towards the bridge port (another virtual Ethernet interface).
The whole chain looks like this: air interface virtual Ethernet interface bridge port bridgespecific client —(untagged)—vlan-id:20===(tagged:20)===( )========(tagged:20)==================|===interface vlan 20
generic client -------------(untagged)--------------------( )—(untagged)—pvid:10===(tagged)===|===interface vlan 10
Actual piece of software that does tagging/untagging is not really important, the important thing is to uderstand which entity gets configured by which configuration command and what other configuration commands should accompany it. For this exercise it’s just fine to think that driver is tagging/unragging frames.
If you configure “generic” wlan interface with vlan-id=10 vlan-mode=use-tag (or you configure access list with vid overrides), then it’s wireless subsystem as a whole that does the tagging/untagging … bridge (port) doesn’t touch VLAN headers. Wireless hardware doesn’t handle VLAN tags, hence it’s wireless driver doing it.
On the other hand if wireless port being member of bridge is configured with pvid setting, then it’s bridge (or rather software implementation of it) that does the tagging/untagging while wirekess subsystem doesn’t touch VLAN headers.
With hybrid configuration (pvid set on bridge port and vid overrides in access list) both entities (bridge port and wireless subsystem) fiddle with VLAN tags, each its own part of it.
Knowing that until ROS v6.42 bridge was not VLAN aware and it was necessary to configure VLANs directly on wireless interface … and that wireless config was not changed after 6.42, it is easier to understand that we’re talking about two distinct ways of configuring VLANs and it doesn’t seem that ROS correlates settings … So it is sometimes hard to figure out the correct setup.
Thanks once again. The different explanation methods were very helpful.
Related - if you are wanting to have 802.1q tagged vlans go through the AP, read up on WDS. With WDS, you can have a single SSID and your WDS clients then get all the Vlans , then from there you can break it down into what Vlan goes where on your WDS clients. It works and I do this on many WDS links ( both point-to-point and multi-point WDS links ).