How to Create VLANs with MikroTik — The Proper Way (Bridge VLAN Filtering)

In a previous post I covered the easy way to create VLANs on MikroTik — one bridge per VLAN. It works, it’s great for learning, but it doesn’t scale well and it’s heavier on the CPU than it needs to be. If you haven’t read it, you can find it here.

This post covers the proper way: bridge VLAN filtering. One bridge, one VLAN table, everything in one place. Understanding the easy way first makes this much easier to appreciate — but you don’t need it to follow along.

The topology is the same as in the previous post: a MikroTik router connected to a Cisco switch via a trunk port, three VLANs, devices on each VLAN getting DHCP and internet access.


How Bridge VLAN Filtering Works

Instead of creating a separate bridge for each VLAN, we create a single bridge and enable VLAN filtering on it. The bridge then maintains a VLAN table that controls which ports carry which VLANs — tagged (trunk) or untagged (access).

The key concepts:

  • Tagged ports carry traffic for multiple VLANs with 802.1Q tags. Your uplink to a switch or another router is typically tagged.
  • Untagged ports carry traffic for a single VLAN with no tag. Your end devices (PCs, printers, APs) connect to untagged ports.
  • PVID (Port VLAN ID) is the default VLAN assigned to untagged traffic arriving on a port. When a frame arrives without a tag, the bridge stamps it with the PVID before processing it.

This model maps closely to how Cisco switches think about VLANs — trunk ports and access ports — which may feel more familiar.


Step 1 — Create the Bridge

/interface bridge
add name=bridge-vlans

We create the bridge first without enabling VLAN filtering yet. We’ll turn that on after the VLAN table is fully configured — enabling it on an empty table drops all traffic immediately.


Step 2 — Add Ports to the Bridge

Add your trunk port (uplink to the switch) and your access ports (connected to end devices).

/interface bridge port
add bridge=bridge-vlans interface=ether5 pvid=1
add bridge=bridge-vlans interface=ether2 pvid=2
add bridge=bridge-vlans interface=ether3 pvid=3
add bridge=bridge-vlans interface=ether4 pvid=4
  • ether5 is the trunk port to the Cisco switch — PVID 1 is fine here since tagged traffic will override it
  • ether2, ether3, ether4 are access ports — PVID tells the bridge which VLAN to assign untagged frames arriving on each port

Step 3 — Configure the VLAN Table

This is where you define which VLANs are allowed on which ports, and whether each port carries them tagged or untagged.

/interface bridge vlan
add bridge=bridge-vlans vlan-ids=2 tagged=ether5,bridge-vlans untagged=ether2
add bridge=bridge-vlans vlan-ids=3 tagged=ether5,bridge-vlans untagged=ether3
add bridge=bridge-vlans vlan-ids=4 tagged=ether5,bridge-vlans untagged=ether4

Breaking this down:

  • VLAN 2 is carried tagged on ether5 (the trunk to the switch) and on bridge-vlans itself (so the router can route it), and untagged on ether2 (the access port for VLAN 2 devices)
  • Same pattern for VLANs 3 and 4

Step 4 — Enable VLAN Filtering

Now that the VLAN table is in place, it’s safe to enable filtering. The bridge will start enforcing the table immediately.

/interface bridge
set bridge-vlans vlan-filtering=yes

Step 5 — Create VLAN Interfaces for Routing

To route between VLANs and assign IP addresses, we need VLAN interfaces attached to the bridge.

/interface vlan
add interface=bridge-vlans name=vlan2 vlan-id=2
add interface=bridge-vlans name=vlan3 vlan-id=3
add interface=bridge-vlans name=vlan4 vlan-id=4

Step 6 — Assign IPs, DHCP, and NAT

This part is identical to the easy way — the IP addressing, DHCP, and NAT configuration doesn’t change, only the interfaces you assign them to.

/ip address
add address=10.0.2.1/24 interface=vlan2 network=10.0.2.0
add address=10.0.3.1/24 interface=vlan3 network=10.0.3.0
add address=10.0.4.1/24 interface=vlan4 network=10.0.4.0

/ip pool
add name=dhcp_pool0 ranges=10.0.2.2-10.0.2.254
add name=dhcp_pool1 ranges=10.0.3.2-10.0.3.254
add name=dhcp_pool2 ranges=10.0.4.2-10.0.4.254

/ip dhcp-server
add address-pool=dhcp_pool0 disabled=no interface=vlan2 name=dhcp1
add address-pool=dhcp_pool1 disabled=no interface=vlan3 name=dhcp2
add address-pool=dhcp_pool2 disabled=no interface=vlan4 name=dhcp3

/ip dhcp-client
add disabled=no interface=ether1

/ip dhcp-server network
add address=10.0.2.0/24 dns-server=10.0.2.1 gateway=10.0.2.1
add address=10.0.3.0/24 dns-server=10.0.3.1 gateway=10.0.3.1
add address=10.0.4.0/24 dns-server=10.0.4.1 gateway=10.0.4.1

/ip dns
set allow-remote-requests=yes

/ip firewall nat
add action=masquerade chain=srcnat

Easy Way vs. Proper Way — At a Glance

Easy WayBridge VLAN Filtering
Bridges neededOne per VLAN + one trunkOne total
Interface list sizeGrows fastClean and minimal
Adding a new VLAN3+ commands, new bridge2 commands
CPU usageHigher (software per bridge)Lower (single bridge path)
Switch chip offloadNoYes (on supported hardware)
TroubleshootingMultiple bridges to checkOne VLAN table to check
Good for learningAfter you know the basics
Good for production

A Few Things Worth Knowing

PVID must match the VLAN table. If a port’s PVID doesn’t have a corresponding untagged entry in the VLAN table, untagged frames arriving on that port will be dropped. Double-check both match — it’s the most common source of “why isn’t this device getting an IP” confusion.

The bridge itself must be tagged in the VLAN table for routing to work. That’s what the bridge-vlans entries in Step 3 are for. If you forget this, inter-VLAN routing fails silently — devices get DHCP but can’t reach other VLANs or the internet.

This configuration assumes a clean slate. If you’re adapting this to an existing bridge that already has ports and traffic, take care — enabling VLAN filtering mid-session will drop everything that isn’t covered by the VLAN table. Test in a lab or during a maintenance window.


Final Thoughts

Once you’ve done it a few times, bridge VLAN filtering is actually simpler to manage than the easy way — there’s just less of everything. The learning curve is the VLAN table concept, which takes a bit of getting used to if you’re new to it.

If Part 1 got your VLANs working and you understand why each piece is there, you’re ready for this. The configuration is a bit more deliberate, but the payoff in cleanliness and efficiency is worth it.

Mikrotik DNS failover script, for Pi-Hole

MikroTik DNS Failover Script for Pi-Hole

If you have a Pi-hole configured on your home lab and you’re anything like me, there’ll be occasions in which you’ll be tinkering with your Pi-hole and affecting your home network.

But this shouldn’t be the case. You can configure your MikroTik so it automatically takes over DNS resolution upon Pi-hole failure — seamlessly, with zero manual intervention, and with a Telegram notification so you know exactly what happened and when.


How It Works

The setup relies on a MikroTik Netwatch rule that monitors a secondary IP on the Pi-hole VM. When that IP stops responding, MikroTik assumes the DNS service is down and activates a fallback — by enabling a dormant IP address directly on the router that answers DNS queries itself. When the Pi-hole comes back, the process reverses.

Here’s the full flow:

Normal state (Pi-hole up):

  • Pi-hole VM has two interfaces: one serving DNS (10.1.1.10) and one dedicated to monitoring (10.1.100.2) with no gateway, on a separate VLAN only the MikroTik can reach
  • MikroTik’s Netwatch pings the monitoring IP (10.1.100.2) at regular intervals
  • Two IP addresses are configured on the MikroTik but kept disabled: 10.1.1.10/24 and 10.1.100.2/24
  • MikroTik forwards DNS to the Pi-hole at 10.1.1.10

Failover state (Pi-hole down):

  • Netwatch detects the monitoring IP is unreachable
  • MikroTik enables its own 10.1.1.10 and 10.1.100.2 addresses, effectively impersonating the Pi-hole on the network
  • MikroTik clears the ARP entries for both IPs so clients pick up the new owner immediately
  • MikroTik switches its DNS server to AdGuard’s public DNS (94.140.14.14, 94.140.15.15) — which still blocks ads and trackers, keeping the experience close to normal even during failover
  • A Telegram notification fires

Recovery (Pi-hole back up):

  • Netwatch detects the monitoring IP is reachable again
  • MikroTik disables its own 10.1.1.10 and 10.1.100.2 addresses
  • ARP entries are cleared again so clients reconnect to the real Pi-hole
  • MikroTik switches DNS back to 10.1.1.10
  • Another Telegram notification fires

The reason for the separate monitoring interface is important: you don’t want Netwatch pinging the DNS IP itself (10.1.1.10), because MikroTik would be impersonating that IP during failover — which would make Netwatch think the Pi-hole is back up when it isn’t. The monitoring IP on its own isolated VLAN can only be answered by the real VM, never by the MikroTik fallback.


Prerequisites

  • MikroTik router with RouterOS
  • Pi-hole running on a VM with two network interfaces
  • A Telegram bot token and chat ID for notifications
  • The monitoring VLAN must be routable from the MikroTik but not from other devices

MikroTik Configuration

Step 1 — Add the fallback IP addresses (disabled by default)

These are the addresses MikroTik will enable during failover. Replace the interface name with your actual LAN bridge or interface.

/ip address
add address=10.1.1.10/24 interface=bridge-home disabled=yes
add address=10.1.100.2/24 interface=bridge-mgmt disabled=yes

Step 2 — Configure Netwatch

Netwatch monitors the Pi-hole’s dedicated monitoring IP. Adjust the interval and timeout to your preference.

/tool netwatch
add host=10.1.100.2 interval=30s timeout=5s \
    up-script=dns-up \
    down-script=dns-down \
    comment="Pi-hole DNS monitor"

Step 3 — The down script (Pi-hole unreachable)

/system script
add name=dns-down source={
:global telegramMessage "DNS Server not detected, backup DNS enabled"
:log error "$telegramMessage"
/ip dns set servers=94.140.14.14,94.140.15.15
/ip address enable [find address="10.1.1.10/24"]
/ip address enable [find address="10.1.100.2/24"]
/ip arp remove [find address=10.1.1.10]
/ip arp remove [find address=10.1.100.2]
/tool fetch url="https://api.telegram.org/bot<YOUR_TOKEN>/sendMessage?chat_id=<YOUR_CHAT_ID>&text=$telegramMessage" keep-result=no
}

Step 4 — The up script (Pi-hole restored)

/system script
add name=dns-up source={
:global telegramMessage "DNS Server detected, DNS Service Restored"
:log warning "$telegramMessage"
/ip dns set servers=10.1.1.10
/ip address disable [find address="10.1.1.10/24"]
/ip address disable [find address="10.1.100.2/24"]
/ip arp remove [find address=10.1.1.10]
/ip arp remove [find address=10.1.100.2]
/tool fetch url="https://api.telegram.org/bot<YOUR_TOKEN>/sendMessage?chat_id=<YOUR_CHAT_ID>&text=$telegramMessage" keep-result=no
}

Replace <YOUR_TOKEN> with your Telegram bot token and <YOUR_CHAT_ID> with your chat ID.


Why Clear the ARP Table?

This is the detail that makes the whole thing work cleanly. When MikroTik enables a new IP address, clients on the network may still have the old ARP entry cached — pointing to the Pi-hole’s MAC address. By clearing the ARP entries for both IPs immediately after the switch, you force clients to re-resolve, and they’ll get the MikroTik’s MAC address instead. Without this step, clients could experience a gap in DNS resolution even after the failover has technically completed.

The same logic applies on recovery — you clear the ARP entries so clients stop pointing at the MikroTik and pick up the Pi-hole again.


Result

With this in place, a Pi-hole restart, a VM crash, or any maintenance you do on the DNS server will cause a seamless failover in under 30 seconds (or whatever interval you set). Your network keeps resolving DNS, your devices never notice, and you get a Telegram message telling you exactly what happened.

When you bring the Pi-hole back up, everything switches back automatically — including your ad-blocking and local DNS records — again without touching anything manually.


Tested on RouterOS 7.x. The Netwatch tool and script engine behave consistently across recent RouterOS versions, but always test in your own environment before relying on it in production.

Simple & Basic Home Firewall with Mikrotik

One of the most common mistakes I’ve seen from technicians setting up MikroTik routers is leaving the firewall completely empty. The assumption seems to be that a strong password is enough protection. It isn’t. A password protects your router’s management interface — it does nothing to stop malicious traffic from flowing through it, scanning your network, or exploiting services running behind it. A firewall is not optional. It’s the foundation.

This post walks you through a simple but solid home firewall ruleset for MikroTik. It’s designed to be approachable — you don’t need to be a network engineer to follow it — but it covers the right bases and explains the reasoning behind each decision.

A few things to keep in mind before we start:

  • This assumes your firewall is currently empty. If it isn’t, read through the rules carefully and apply what makes sense for your setup.
  • I group rules by purpose rather than by chain. I find this easier to reason about, especially when troubleshooting.
  • MikroTik processes firewall rules in sequential order — the position of each rule matters.
  • I’m using ether1-wan as the WAN interface and bridge.home as the LAN bridge throughout. Adjust these to match your actual interface names.
  • This post does not cover NAT configuration — that deserves its own post.

The Ruleset

1. Accept established and related traffic

/ip firewall filter
add action=accept chain=input comment="Accept established & related inputs" \
    connection-state=established,related
add action=accept chain=forward connection-state=established,related

These go first and they’re critical for performance. Once a connection is established, there’s no need to re-evaluate every subsequent packet against the full ruleset. Accepting established and related traffic early means the router only does the heavy lifting once per connection, not once per packet. Skip these and your CPU will suffer for it.


2. Drop invalid packets

add action=drop chain=input comment="Drop invalid inputs & forwards" \
    connection-state=invalid
add action=drop chain=forward connection-state=invalid

Invalid packets are those that don’t belong to any known connection and don’t make sense as the start of a new one — malformed headers, out-of-sequence packets, and similar garbage. There’s no legitimate reason to accept them. Drop them early.


3. Reject blacklisted sources

add action=reject chain=input comment="Reject blacklisted" in-interface=\
    ether1-wan reject-with=icmp-network-unreachable src-address-list=\
    Blacklist

This rule rejects any traffic from IPs that have been added to a Blacklist address list. The list itself gets populated later by the blacklisting rules — this rule just enforces it. The order matters: this needs to come before any accept rules so blacklisted IPs get stopped regardless of what they’re trying to do.


4. Drop unsolicited inbound forwards

add action=drop chain=forward comment="Drop all from WAN not DSTNATed" \
    connection-nat-state=!dstnat connection-state=new in-interface=ether1-wan

This rule blocks any new inbound connection from the WAN that hasn’t been explicitly port-forwarded via DNAT. Without this, your router would happily forward unsolicited traffic from the internet toward your internal devices. Unless you’ve set up a DNAT rule for a specific service, nothing from the outside should be initiating connections to your network.


5. Accept traffic from a whitelist (optional)

add action=accept chain=input comment="Accept inputs from the whitelist" \
    in-interface=ether1-wan src-address-list=Whitelist

This is optional. It allows specific trusted external IPs to reach the router directly — useful if you manage the router remotely from a known static IP. Use it carefully. If you don’t have a stable public IP or aren’t sure you need it, skip it. A WireGuard VPN is a much better way to manage your router remotely.


6. Log and track access attempts on the Winbox port

add action=add-src-to-address-list address-list="Unknown Admin" \
    address-list-timeout=1w chain=input comment="Log unknown admins" \
    dst-port=8291 in-interface=ether1-wan log=yes log-prefix="Unknown Admin" \
    protocol=tcp src-address=0.0.0.0/0
add action=accept chain=input comment="Accept unknown admins" dst-port=8291 \
    in-interface=ether1-wan protocol=tcp src-address=0.0.0.0/0

Port 8291 is the default Winbox port. If you’re keeping it accessible from the WAN — and I’d strongly recommend against it — these rules at least log who’s trying to connect so you can see it happening.

More importantly: change this port. Leaving it at 8291 means every automated scanner on the internet knows exactly where to knock. Moving it to a non-standard port won’t make you invisible, but it will dramatically reduce the noise. You can change it in WinBox under IP → Services → Winbox.

Better yet, block it from the WAN entirely and only access your router from your local network or over a VPN.


7. Accept traffic from your LAN

add action=accept chain=input comment="Accept inputs from home" in-interface=\
    bridge.home src-address=192.168.88.0/24
add action=accept chain=forward comment=\
    "Accept internet access for home devices" in-interface=home-bridge \
    out-interface=ether1-wan src-address=192.168.88.0/24

These rules allow your local devices to reach the router and access the internet. Adjust the subnet and interface names to match your LAN configuration.


8. Blacklist port scanners

add action=add-src-to-address-list address-list=Blacklist \
    address-list-timeout=1w chain=input comment=\
    "Add forbidden attempts to the blacklist" dst-port=\
    21-23,25,53,80,110,135,139,443,445,587,1025,1352 in-interface=ether1-wan \
    protocol=tcp src-address=0.0.0.0/0 src-address-list=!Whitelist
add action=add-src-to-address-list address-list=Blacklist \
    address-list-timeout=1w chain=input dst-port=\
    1433,1521,3306,3389,5060,5900,6001,8000-8080 in-interface=\
    ether1-wan protocol=tcp src-address=0.0.0.0/0 src-address-list=!Whitelist
add action=add-src-to-address-list address-list=Blacklist \
    address-list-timeout=1w chain=input dst-port=\
    53,69,161,135-139,445,593,1433-1434,1900 in-interface=ether1-wan \
    protocol=udp src-address=0.0.0.0/0 src-address-list=!Whitelist

Any external IP that probes these ports gets added to the Blacklist for one week. These ports cover the most commonly abused attack vectors: FTP, SSH, Telnet, SMTP, DNS, NetBIOS, SMB, RDP, SIP, VNC, SQL Server, MySQL, SNMP, and UPnP among others.

The logic is simple: if you’re not deliberately exposing any of these services to the internet, there is no legitimate reason for an outside IP to be probing them. Anyone who does is either scanning opportunistically or targeting you specifically — either way, they go on the list. Rule 3 then blocks them from that point forward for the entire week.


9. Drop everything else

add action=reject chain=input comment="Drop all from WAN" in-interface=\
    ether1-wan reject-with=icmp-network-unreachable
add action=reject chain=forward comment="Drop everything else" reject-with=\
    icmp-network-unreachable

These are your catch-all rules. Anything from the WAN that hasn’t been explicitly accepted by a previous rule gets dropped here. Never skip these — without them, unmatched traffic falls through to RouterOS defaults, which is not a firewall policy you want to rely on.


Complete Rule Order at a Glance

#ChainActionPurpose
1input / forwardAcceptEstablished & related traffic
2input / forwardDropInvalid packets
3inputRejectBlacklisted sources
4forwardDropUnsolicited WAN inbound
5inputAcceptWhitelisted sources (optional)
6inputLog + AcceptWinbox port tracking
7input / forwardAcceptLAN traffic
8inputAdd to listBlacklist port scanners
9input / forwardRejectEverything else

Final Thoughts

This ruleset won’t make your router impenetrable, but it will make it vastly more resilient than an empty firewall with just a password on it — which, again, is a setup I see far more often than I should.

Start with these rules, watch your logs, and watch your blacklist populate. You’ll quickly get a sense of what’s being thrown at your network from the outside every single day. It’s eye-opening, and it makes a strong case for never leaving a MikroTik without a proper firewall again.

How to Create VLANs with MikroTik — The Easy Way

When you start working with MikroTik, VLANs can feel intimidating — especially if you’re coming from a Cisco background where the mental model is different. I’ve been there.

This post covers what I call the easy way: one bridge per VLAN. It’s not the most efficient method, and I wouldn’t recommend it for a production environment with many VLANs, but for a home lab or a small home network it works perfectly well and it’s straightforward to understand and troubleshoot. If you just want VLANs working without diving deep into MikroTik’s bridge VLAN filtering engine, this is your starting point.

A few things to keep in mind before we begin:

  • I’m demonstrating this in GNS3 with a MikroTik router connected to a Cisco switch, but the commands work the same on real hardware.
  • There’s no firewall or security configured in this lab — don’t apply this blindly to a production device without adding those first.
  • I’m assuming you have a basic familiarity with the MikroTik CLI and can relate the commands to the Winbox GUI.
  • We start from a clean slate with only a DHCP client on ether1.

The Lab Topology

In this scenario we have a MikroTik router connected to a Cisco switch via a trunk port. Three VLANs are configured, and devices on each VLAN can reach the internet and talk to each other through the router.


Why one bridge per VLAN?

MikroTik’s more advanced VLAN method uses a single bridge with VLAN filtering enabled — cleaner, more scalable, and better for CPU. The method in this post creates a separate bridge for each VLAN instead, which is simpler to visualize and configure but doesn’t scale well beyond a handful of VLANs. For a home lab with 3-4 VLANs, the difference is negligible.


Step 1 — Create the Trunk Bridge

Instead of attaching VLANs directly to a physical interface, I prefer to create a bridge for the trunk port. This gives you flexibility to add more trunk ports later without restructuring everything.

/interface bridge
add name=bridge-trunk

/interface bridge port
add bridge=bridge-trunk interface=ether5

Here ether5 is the interface connected to the Cisco switch trunk port. After running this you should see the bridge and its port in Winbox: <img


Step 2 — Create the VLANs on the Trunk Bridge

Now we create the VLAN interfaces and attach them to bridge-trunk. This tells MikroTik to expect tagged traffic for these VLAN IDs on that bridge.

/interface vlan
add interface=bridge-trunk name="vlan-2" vlan-id=2
add interface=bridge-trunk name="vlan-3" vlan-id=3
add interface=bridge-trunk name="vlan-4" vlan-id=4


Step 3 — Create a Bridge for Each VLAN

This is the “clunky” part. Each VLAN gets its own bridge. This bridge is what you’ll later attach access ports and IP addresses to.

/interface bridge
add name=br-vlan2
add name=br-vlan3
add name=br-vlan4


Step 4 — Attach VLAN Interfaces and Access Ports to Each Bridge

Now we tie everything together. Each VLAN interface goes into its corresponding bridge, and the access ports (the physical interfaces your end devices connect to) go into their respective bridges as well.

/interface bridge port
add bridge=br-vlan2 interface="vlan-2"
add bridge=br-vlan3 interface="vlan-3"
add bridge=br-vlan4 interface="vlan-4"
add bridge=br-vlan4 interface=ether4
add bridge=br-vlan3 interface=ether3
add bridge=br-vlan2 interface=ether2

At this point the trunk and access ports are working at Layer 2. Devices on the same VLAN can reach each other. To get IP addressing, DHCP, and internet access working we need a few more steps.


Step 5 — Assign IPs, Configure DHCP, and Set Up NAT

Each VLAN bridge gets an IP address (this becomes the default gateway for devices on that VLAN), a DHCP pool, and a DHCP server. We also configure NAT so all VLANs can reach the internet.

/ip address
add address=10.0.2.1/24 interface=br-vlan2 network=10.0.2.0
add address=10.0.3.1/24 interface=br-vlan3 network=10.0.3.0
add address=10.0.4.1/24 interface=br-vlan4 network=10.0.4.0

/ip pool
add name=dhcp_pool0 ranges=10.0.2.2-10.0.2.254
add name=dhcp_pool1 ranges=10.0.3.2-10.0.3.254
add name=dhcp_pool2 ranges=10.0.4.2-10.0.4.254

/ip dhcp-server
add address-pool=dhcp_pool0 disabled=no interface=br-vlan2 name=dhcp1
add address-pool=dhcp_pool1 disabled=no interface=br-vlan3 name=dhcp2
add address-pool=dhcp_pool2 disabled=no interface=br-vlan4 name=dhcp3

/ip dhcp-client
add disabled=no interface=ether1

/ip dhcp-server network
add address=10.0.2.0/24 dns-server=10.0.2.1 gateway=10.0.2.1
add address=10.0.3.0/24 dns-server=10.0.3.1 gateway=10.0.3.1
add address=10.0.4.0/24 dns-server=10.0.4.1 gateway=10.0.4.1

/ip dns
set allow-remote-requests=yes

/ip firewall nat
add action=masquerade chain=srcnat

Result

With everything in place, devices on different VLANs can communicate through the router and reach the internet — as shown here with PC1 and PC8 on opposite ends of the topology on different VLANs:


Config Files

If you want to study the full configuration or follow along in your own lab, here are the config files used in this post:

If you’d like the GNS3 lab file, send me an email and I’ll share it.


When to Use This Method — And When to Move On

If you’ve never configured VLANs before, or you’ve never done it on MikroTik specifically, this is a great way to get your feet wet. The structure is visible and tangible — you can see every bridge, every VLAN interface, every port assignment in Winbox. That transparency makes it easier to understand what’s actually happening at each layer, which is valuable when you’re learning.

That said, you should make an effort to learn the proper way once this clicks. Here’s why:

Performance. The easy way does all VLAN tagging and untagging in software on the CPU. Every packet that crosses a VLAN boundary goes through RouterOS’s bridge code. On a busy network or a router handling many VLANs, this adds up. The proper method — bridge VLAN filtering — is more efficient because there’s only one bridge in the kernel’s forwarding path instead of one per VLAN. On hardware with a built-in switch chip it can offload VLAN handling entirely to hardware, barely touching the CPU at all.

Management. The easy way grows linearly and messily. Five VLANs means five extra bridges, five VLAN interfaces, and five sets of bridge port assignments on top of your trunk bridge. Your interface list becomes a wall of entries and finding things in Winbox gets tedious. With bridge VLAN filtering, everything lives in one bridge. The VLAN table is a single clean list, and adding a new VLAN is a one-liner instead of three commands and a new bridge.

Troubleshooting. When something breaks with the easy way, you’re tracing traffic across multiple bridges. With a single bridge there’s one place to look — the bridge VLAN table and its port assignments.

The honest caveat: for a home lab with three or four VLANs and normal traffic levels, the performance difference is genuinely invisible. The management argument is the stronger one — this approach just gets unwieldy as you grow. Start here if you need to, but treat it as a stepping stone rather than a destination.