Vlan-filtering=yes breaks DHCP for new WiFi clients on a hybrid tagged/untagged port

RouterOS General
1

RouterOS 7.24.1, RB5009UPr+S+.

I have a WiFi AP connected to one bridge port, carrying two SSIDs: the main/native network (untagged, VLAN1) and an isolated IoT network (tagged, VLAN20).

With vlan-filtering=no everything works fine. As soon as I set vlan-filtering=yes, any device doing a fresh DHCP negotiation over the untagged VLAN1 side of that port fails to get a lease and self-assigns a 169.254.x.x address. Devices that already had a lease keep renewing fine through the same port — it's specifically new devices (or a forget/rejoin on WiFi) that fail. The client associates to the AP fine and its frames do arrive at the bridge, correctly tagged VID 1 (confirmed via /interface bridge host print). Wired devices on plain single-VLAN ports are unaffected, and the tagged VLAN20 side of the same port works fine for new clients too — it's specifically the untagged VLAN1 side that breaks.

One more thing I'm not sure is related or not: at one point during troubleshooting, my main PC — plugged into a completely different, plain, single-VLAN (non-hybrid) port, nothing tagged on it at all — also ended up with a self-assigned address after the router rebooted, at a point where vlan-filtering may still have been active (hard to say for certain, other things were going on at the same time). If that is actually connected, this might not be limited to the hybrid tagged+untagged port specifically, but could affect any fresh DHCP negotiation while filtering is on, on any port. Not confident about that one, but wanted to mention it in case it's relevant.

/interface vlan
add interface=bridge name=vlan20-iot vlan-id=20

/ip pool
add name=iot-dhcp ranges=192.168.20.10-192.168.20.254

/ip address
add address=192.168.20.1/24 interface=vlan20-iot network=192.168.20.0

/ip dhcp-server
add address-pool=iot-dhcp interface=vlan20-iot name=iot-dhcp-server disabled=no

/ip dhcp-server network
add address=192.168.20.0/24 dns-server=192.168.20.1 gateway=192.168.20.1

/interface bridge vlan
add bridge=bridge vlan-ids=1 tagged=bridge untagged=ether2,ether3,ether7,ether8,ether4
add bridge=bridge vlan-ids=20 tagged=bridge,ether4 untagged=ether5,ether6

/interface bridge port
set \[find interface=ether5\] pvid=20
set \[find interface=ether6\] pvid=20

/interface bridge port print detail where interface=ether4
(pvid=1 frame-types=admit-all ingress-filtering=yes hw=yes)

/interface bridge
set bridge vlan-filtering=yes

(Main/VLAN1 DHCP is the default "defconf" server bound to interface=bridge, 192.168.88.0/24, unmodified from RouterOS's default configuration script.)

Does anyone know what could be wrong here?

2

Take care with vlan 1 it is special see rule 1 and 2 of:
The twelve Rules of Mikrotik Club - RouterOS / Beginner Basics - MikroTik community forum
Make the bridge use it untagged like:

/interface bridge vlan
add bridge=bridge vlan-ids=1 untagged=bridge,ether2,ether3,ether7,ether8,ether4

This should be sufficient.

With recent versions of routerOS, it can automatically figure out untagged ports from the port pvid setting it also can add vlan interfaces you create as tagged to the bridge.

3

This works fine, and it's my normal config on the same router.

What I don't see in your posted config is a dhcp server on the bridge/VLAN1 . . . such as:

add address-pool="TPC default (untagged)" comment="TPC (untagged)" interface=bridge name="TPC (untagged)" use-reconfigure=yes
add address-pool="TPC Lab (VLAN12)" comment="Lab 101" interface=Lab_101 name="Lab 101" use-reconfigure=yes
4

Thanks again rplant, marking your reply as the solution - you nailed it straight away and saved me lots of time

@tadawson thanks for chiming in too - I did actually have a DHCP server bound to the bridge/VLAN1 the whole time, so that wasn't the missing piece in my case. Turned out the real cause was VLAN1's CPU-port membership being tagged instead of untagged (see rplant's post above) - leaving it here in case anyone else searching this symptom checks DHCP first like I did.

Appreciate you both taking the time :slight_smile:

New setup below, seems good. However, if anybody chooses to skim through it and notice something alarming/wrong, please let me know

RB5009UPr+S+ — final config, RouterOS 7.24.1

/interface bridge vlan
set [find vlan-ids=1] tagged="" untagged=bridge
set [find vlan-ids=10] tagged=bridge untagged=ether4
set [find vlan-ids=20] tagged=bridge,ether4 untagged=ether2,ether5,ether6
set [find vlan-ids=30] tagged=bridge,ether4 untagged=ether7
set [find vlan-ids=40] tagged=bridge untagged=ether8
set [find vlan-ids=50] tagged=bridge untagged=ether3

/interface vlan
add interface=bridge name=vlan10-trusted vlan-id=10
add interface=bridge name=vlan20-iot vlan-id=20
add interface=bridge name=vlan30-sandbox vlan-id=30
add interface=bridge name=vlan40-homelab vlan-id=40
add interface=bridge name=vlan50-mgmt vlan-id=50

/interface bridge port
set [find interface=ether2] pvid=20
set [find interface=ether3] pvid=50
set [find interface=ether4] pvid=10
set [find interface=ether5] pvid=20
set [find interface=ether6] pvid=20
set [find interface=ether7] pvid=30
set [find interface=ether8] pvid=40

/ip pool
add name=trusted-dhcp ranges=192.168.10.10-192.168.10.254
add name=iot-dhcp ranges=192.168.20.10-192.168.20.254
add name=sandbox-dhcp ranges=192.168.30.10-192.168.30.254
add name=homelab-dhcp ranges=192.168.40.10-192.168.40.254
add name=mgmt-dhcp ranges=192.168.50.10-192.168.50.20

/ip address
add address=192.168.10.1/24 interface=vlan10-trusted network=192.168.10.0
add address=192.168.20.1/24 interface=vlan20-iot network=192.168.20.0
add address=192.168.30.1/24 interface=vlan30-sandbox network=192.168.30.0
add address=192.168.40.1/24 interface=vlan40-homelab network=192.168.40.0
add address=192.168.50.1/24 interface=vlan50-mgmt network=192.168.50.0

/ip dhcp-server
add address-pool=trusted-dhcp interface=vlan10-trusted name=trusted-dhcp-server disabled=no
add address-pool=iot-dhcp interface=vlan20-iot name=iot-dhcp-server disabled=no
add address-pool=sandbox-dhcp interface=vlan30-sandbox name=sandbox-dhcp-server disabled=no
add address-pool=homelab-dhcp interface=vlan40-homelab name=homelab-dhcp-server disabled=no
add address-pool=mgmt-dhcp interface=vlan50-mgmt name=mgmt-dhcp-server disabled=no

/ip dhcp-server network
add address=192.168.10.0/24 dns-server=192.168.10.1 gateway=192.168.10.1
add address=192.168.20.0/24 dns-server=192.168.20.1 gateway=192.168.20.1
add address=192.168.30.0/24 dns-server=192.168.30.1 gateway=192.168.30.1
add address=192.168.40.0/24 dns-server=192.168.40.1 gateway=192.168.40.1
add address=192.168.50.0/24 dns-server=192.168.50.1 gateway=192.168.50.1

/ip dhcp-server lease
add address=192.168.40.251 mac-address=AA:BB:CC:DD:EE:FF server=homelab-dhcp-server comment=Tower

/interface list member
add interface=vlan10-trusted list=LAN
add interface=vlan20-iot list=LAN
add interface=vlan30-sandbox list=LAN
add interface=vlan40-homelab list=LAN
add interface=vlan50-mgmt list=LAN

/ip firewall address-list
add address=192.168.10.0/24 list=Trusted
add address=192.168.20.0/24 list=IoT
add address=192.168.30.0/24 list=Sandbox
add address=192.168.40.0/24 list=Homelab
add address=192.168.50.0/24 list=Management

/ip firewall filter
add chain=forward action=drop src-address-list=IoT dst-address-list=Trusted comment="Block IoT -> Trusted"
add chain=forward action=accept src-address-list=Trusted dst-address-list=IoT comment="Allow Trusted -> IoT"
add chain=forward action=drop src-address-list=Homelab dst-address-list=Trusted comment="Block Homelab -> Trusted"
add chain=forward action=drop src-address-list=Sandbox dst-address-list=Trusted comment="Block Sandbox -> Trusted"
add chain=forward action=drop src-address-list=Sandbox dst-address-list=IoT comment="Block Sandbox -> IoT"
add chain=forward action=drop src-address-list=Sandbox dst-address-list=Homelab comment="Block Sandbox -> Homelab"
add chain=forward action=drop src-address-list=Trusted dst-address-list=Sandbox comment="Block Trusted -> Sandbox"
add chain=forward action=drop src-address-list=IoT dst-address-list=Sandbox comment="Block IoT -> Sandbox"
add chain=forward action=drop src-address-list=Homelab dst-address-list=Sandbox comment="Block Homelab -> Sandbox"

5

Lousy approach, do not use vlan id=1 as that is the glue that MT uses behind the scenes for bridging.

You have two viable options, if you simply have two different subnets then apply one subnet to the bridge for all the ports EXCEPT the port for the AP, simply assign this port the subnet for the wifi.

However, once you have multiple VLANS, then the correct approach is to assign a vlan for the network that is for the 'OTHER bridge traffic'
Call it vlan 11 for example. aka treat this traffic like you would any other vlan.
Tagged to smart devices, untagged to dumb devices.

Remember you CANNOT have bridge traffic and vlan traffic going over the same port. You can pass many vlans over a single port. If you have two subnets that need to reach a port for hybrid reasons, typically a device such as a VOIP device which has a separate output to a computer, it captures the vlan for the voip and sends the non-VLAN traffic onto the computer................ then we setup a hybrid port on the router
/bridge port
add bridge=bridge frame-types=admit all interface=ether1 vlan-id=YY ( YY being the untagged data)

6

This statement confuses me, in that if I read it correctly, I do it without issue. Ports are on the bridge (so bridge traffic, untagged PVID=1) and 4 VLANs also on the ports (10,11,12,13). (VLANs are configured on the bridge as well), so not exactly certain what config you are referring to as impossible.

7

Its a matter of being accurate and secure.
Why would one want to send untagged and tagged data over a port to a dumb device that cannot read tagged data.
Why would one want to send untagged and tagged data over to a smart device (another switch) that is expecting only tagged data.

In MT jargon if I need to send data to a hybrid device, aka expecting both untagged and tagged data, such as VOIP phone, then one is still using data vlans to do so untagged on lets say 11, and tagged on 22.
The bridge in MT is only using vlan-id=1 in the background for its own bridging housekeeping.

ANother example of smart but stupid devices are ubiquiti which expect the management vlan (where it gets its IP from) untagged and all the vlans for the AP, tagged. So its kinda default setup to be hybrid in approach, however, one can modify so that all data flowing in and out of the port to the router are all tagged vlans, which is always preferable.

Finally, even though we may have untagged ports or hybrid ports on the router, or switch, we ensure that the bridge itself has vlan filtering enabled. This prevents any leakage or infiltration by way of vlan1 past security of the vlan process and firewall rules.

Follow jaclans rules of 12, as they are setup for good reasons.

The MT is very forgiving in that if often lets users do things and it all seems to work, but its not necessarily optimal/efficient or the safest way to proceed.

8

Any device in my world getting just one network is untagged, period.

Switches do *NOT* only expect tagged data! Not sure where you got that from, but I can't recall that being true for any brand.

VLAN1 (the default ID for untagged) is the primary network for my clients. Leaving it untagged across routers and switches means less screwing around connecting clients. It's everywhere by default. Tagged VLANs are for other more isolated stuff, and are either passed to clients tagged along with VLAN1 untagged on trunks, or the switch just presents the VLAN via PVID, so not having to deal with the myriad of complexities on clients and tagging. K.I.S.S.

For my deployment, taggjng is primarily inter-switch, period . . .

9

I have non MT smart devices from switches to access points and dont use vlan1 on any of them.
If it works for you no need to change. There is no point in buying a managed switch unless you are going to use vlans. If you are going to use vlans, then all data should travel in vlans UNLESS NECESSARY. Given the option I always go vlans tagged, if absolutely necessary I will use untagged ( to dumb device ) or hybrid to ( a device requireing both ).

10

I use VLANs! WITH untagged VLAN 1 simultaneously! Thus, make complete use of managed switches.

I just don't take it all the way to the end device (which I may or may not control). Minimizes issues (as well as dealing with idiot users).

All the training I have had over the years from the "majors" seemed to have no issue with the hybrid config (often recimmending it) so (nothing personal Mikrotik) the small player (or perhaps just the user base) I don't tend to take terribly seriously on this one. Kind of like "urban legend" vs "fact".

I do NOT, however, route or firewall on switches . . . . despite Mikrotik offering those abilities.