Build the MikroTik foundation once — so the next VLAN does not require a firewall rewrite

Scope

For new RouterOS 7 routers used as small-business or lab gateways. The examples assume an authorised administrator, IPv4 routing and a managed Layer-2 environment. Adapt interface names, addresses and WAN configuration to the actual device.

Start with the architecture, not ether1

The easiest MikroTik configuration to build is often the hardest one to maintain.

A new router arrives.

ether1 becomes WAN.

Everything else goes into one bridge.

The network receives 192.168.88.0/24.

A masquerade rule is added.

Several firewall rules refer directly to ether1 and bridge.

Everything works.

Six months later the business needs a guest VLAN.

Then a server VLAN.

Then WireGuard.

Then a second ISP.

Then a separate management network.

At that point rules such as:

in-interface=ether1
out-interface=bridge
src-address=192.168.88.0/24

stop representing security policy.

They represent the topology that happened to exist on installation day.

That is the design mistake this guide avoids.

The firewall should answer questions such as:

Can USERS reach SERVERS?

Can GUEST reach the Internet?

Can MGMT administer the router?

Can WAN initiate connections to anything?

Those questions remain meaningful even when the physical interfaces change.

The central rule is therefore:

Use physical interfaces to build the topology. Use logical zones to build the security policy.

RouterOS interface lists exist specifically to group interfaces for features including firewall and neighbour discovery, making them useful as the abstraction between topology and policy.

Decide the network roles before configuring the router

Even if the organisation currently needs only one client network, decide what the eventual trust boundaries are likely to look like.

This example reserves four zones:

VLAN 10    USERS      10.42.10.0/24
VLAN 20    SERVERS    10.42.20.0/24
VLAN 30    GUEST      10.42.30.0/24
VLAN 99    MGMT       10.42.99.0/24

The exact numbers are not important.

Consistency is.

A larger organisation might reserve an entire /16 per site and use the third octet to reflect the VLAN or function.

The important decision is to avoid building the organisation around common default ranges such as 192.168.0.0/24, 192.168.1.0/24 or 192.168.88.0/24 unless there is a reason to use them.

Those networks are common in homes, hotels and remote locations and therefore become unnecessarily inconvenient when site-to-site or remote-access VPNs appear later.

Do not allocate addresses randomly.

Leave room for networks that do not exist yet.

The target architecture

Our example begins with:

ether1     Internet
ether2     802.1Q trunk to the LAN switch
ether3     local MGMT access port
ether4     local USERS access port

br-core
 ├── VLAN 10 USERS
 ├── VLAN 20 SERVERS
 ├── VLAN 30 GUEST
 └── VLAN 99 MGMT

The physical ports describe transport.

The VLAN interfaces describe Layer-3 networks.

Interface lists describe security zones.

That distinction is what makes the design expandable.

Before touching VLAN filtering, protect your way back in

Bridge VLAN filtering is one of the easiest RouterOS changes with which to disconnect yourself.

MikroTik explicitly recommends configuring the VLAN membership before enabling vlan-filtering, because an incomplete management path can immediately remove access to the device.

Use console access, a temporary interface that is not part of the bridge, or another known recovery method while building the initial configuration.

And use Safe Mode.

In RouterOS CLI:

Ctrl+X

or:

F4

enters Safe Mode.

If the management session terminates abnormally, RouterOS rolls the changes made in that Safe Mode session back. MikroTik recommends making changes in small groups because Safe Mode history is finite.

Safe Mode is not a substitute for understanding the change.

It is insurance against an incorrect assumption.

Build one VLAN-aware bridge

For a conventional modern RouterOS design, do not create one bridge for USERS, another for SERVERS and another for GUEST simply because the networks are separate.

Create one VLAN-aware bridge and separate the Layer-2 domains with VLAN filtering.

Begin with filtering disabled:

/interface bridge
add name=br-core protocol-mode=rstp vlan-filtering=no \
    comment="Core VLAN-aware bridge"

Now define the physical port behaviour:

/interface bridge port
add bridge=br-core interface=ether2 \
    frame-types=admit-only-vlan-tagged \
    ingress-filtering=yes \
    comment="TRUNK: LAN switch"

add bridge=br-core interface=ether3 pvid=99 \
    frame-types=admit-only-untagged-and-priority-tagged \
    ingress-filtering=yes \
    comment="ACCESS: MGMT"

add bridge=br-core interface=ether4 pvid=10 \
    frame-types=admit-only-untagged-and-priority-tagged \
    ingress-filtering=yes \
    comment="ACCESS: USERS"

A trunk accepts tagged frames.

An access port accepts untagged client traffic and assigns it to its PVID.

Explicit frame-types and ingress filtering make that intent enforceable rather than merely documented. MikroTik recommends ingress filtering where possible, and RouterOS 7 enables it by default; defining it explicitly also makes the configuration easier for the next administrator to read.

Now define the VLAN membership:

/interface bridge vlan
add bridge=br-core tagged=br-core,ether2 vlan-ids=10 \
    comment="USERS"

add bridge=br-core tagged=br-core,ether2 vlan-ids=20 \
    comment="SERVERS"

add bridge=br-core tagged=br-core,ether2 vlan-ids=30 \
    comment="GUEST"

add bridge=br-core tagged=br-core,ether2 vlan-ids=99 \
    comment="MGMT"

Notice that br-core itself is tagged.

The bridge represents the CPU port. Because the router will terminate Layer-3 interfaces for these VLANs, the CPU must be able to receive them.

Create the Layer-3 VLAN interfaces on the bridge:

/interface vlan
add interface=br-core name=vlan10-users vlan-id=10
add interface=br-core name=vlan20-servers vlan-id=20
add interface=br-core name=vlan30-guest vlan-id=30
add interface=br-core name=vlan99-mgmt vlan-id=99

Do not casually create routed VLAN interfaces directly on a trunk Ethernet interface when the design uses a VLAN-filtering bridge.

MikroTik documents VLAN interfaces on the hardware-offloaded bridge as the correct model for devices using Layer-3 hardware offloading; placing them on physical switch ports or bonds can also produce unexpected forwarding behaviour on affected hardware.

Assign the gateway addresses:

/ip address
add address=10.42.10.1/24 interface=vlan10-users comment="USERS gateway"
add address=10.42.20.1/24 interface=vlan20-servers comment="SERVERS gateway"
add address=10.42.30.1/24 interface=vlan30-guest comment="GUEST gateway"
add address=10.42.99.1/24 interface=vlan99-mgmt comment="MGMT gateway"

Only after the management path has been verified should VLAN filtering be enabled:

/interface bridge
set br-core frame-types=admit-only-vlan-tagged vlan-filtering=yes

MikroTik specifically documents admit-only-vlan-tagged on the bridge interface as a way to prevent the CPU port from unintentionally participating in the default untagged VLAN 1.

VLAN 1 is not forbidden by IEEE 802.1Q.

It is simply unnecessary as an implicit management network in this design.

Check what RouterOS actually built

Do not assume the VLAN table matches the diagram.

Check it:

/interface bridge port print
/interface bridge vlan print detail
/interface vlan print
/ip address print

On hardware capable of bridge hardware offloading, verify the expected H flags and consult the hardware-specific documentation.

Not every MikroTik switch chip supports every bridge feature in hardware. A design that is logically correct can still cause traffic to be processed by the CPU on hardware that cannot offload it. MikroTik documents missing H flags, unexpectedly high CPU usage and poor throughput as typical symptoms of an incorrect hardware-offload design.

Configuration correctness includes performance behaviour.

Now create security zones

This is the part that prevents the future firewall rewrite.

Create lists based on roles, not cables:

/interface list
add name=WAN comment="Internet-facing interfaces"
add name=ZONE-MGMT comment="Administrative networks and VPNs"
add name=ZONE-USERS comment="Normal corporate users"
add name=ZONE-SERVERS comment="Server networks"
add name=ZONE-GUEST comment="Untrusted guest networks"
add name=INSIDE include=ZONE-MGMT,ZONE-USERS,ZONE-SERVERS,ZONE-GUEST \
    comment="All internal routed zones"

Assign the current interfaces:

/interface list member
add list=WAN interface=ether1

add list=ZONE-MGMT interface=vlan99-mgmt
add list=ZONE-USERS interface=vlan10-users
add list=ZONE-SERVERS interface=vlan20-servers
add list=ZONE-GUEST interface=vlan30-guest

Suppose an administrative WireGuard tunnel is added six months later.

Do not rewrite every WinBox and SSH firewall rule.

Add the WireGuard interface to ZONE-MGMT.

Suppose the company buys a second ISP.

Do not rewrite every Internet-facing firewall rule.

Add the new logical WAN interface to WAN.

That is the abstraction we wanted.

A useful warning from MikroTik documentation: adding a bridge to an interface list does not mean that all bridge ports automatically become members of that list. Bridge interfaces and bridge ports are different objects.

Treat the firewall as a policy matrix

A maintainable firewall should not gradually become 140 unrelated rules in one forward chain.

Keep the main chain boring.

Use it to classify traffic into zone-specific chains.

RouterOS processes firewall rules from top to bottom, and packets that reach the end of a built-in chain without matching a rule are accepted. A deliberate default-deny rule is therefore essential in this model.

Start with state:

/ip firewall filter
add chain=forward action=accept \
    connection-state=established,related,untracked \
    comment="FWD 10: established, related, untracked"

add chain=forward action=drop \
    connection-state=invalid \
    comment="FWD 20: drop invalid"

Now classify new traffic by source zone:

add chain=forward in-interface-list=ZONE-MGMT \
    action=jump jump-target=FWD-MGMT \
    comment="FWD 30: policy MGMT"

add chain=forward in-interface-list=ZONE-USERS \
    action=jump jump-target=FWD-USERS \
    comment="FWD 31: policy USERS"

add chain=forward in-interface-list=ZONE-SERVERS \
    action=jump jump-target=FWD-SERVERS \
    comment="FWD 32: policy SERVERS"

add chain=forward in-interface-list=ZONE-GUEST \
    action=jump jump-target=FWD-GUEST \
    comment="FWD 33: policy GUEST"

add chain=forward in-interface-list=WAN \
    action=jump jump-target=FWD-WAN \
    comment="FWD 34: policy WAN"

add chain=forward action=drop \
    comment="FWD 99: default deny"

The main forwarding chain may now remain almost unchanged for years.

The policy lives below it.

Give every zone an explicit policy

Guest traffic should normally have a very boring life:

/ip firewall filter
add chain=FWD-GUEST out-interface-list=WAN \
    action=accept \
    comment="GUEST: Internet"

add chain=FWD-GUEST action=drop \
    comment="GUEST: deny everything else"

Users can reach the Internet:

add chain=FWD-USERS out-interface-list=WAN \
    action=accept \
    comment="USERS: Internet"

Suppose users need HTTPS access to one internal application server.

Instead of embedding the server IP throughout the firewall, create an object:

/ip firewall address-list
add list=APP-INTERNAL-WEB address=10.42.20.10 \
    comment="Internal web application"

Then express the policy:

/ip firewall filter
add chain=FWD-USERS dst-address-list=APP-INTERNAL-WEB \
    protocol=tcp dst-port=443 \
    action=accept \
    comment="USERS -> internal web application HTTPS"

add chain=FWD-USERS action=drop \
    comment="USERS: deny everything else"

If the application moves from .10 to .25, the security policy has not changed.

Update the address list.

Do not edit five firewall rules.

This separation between policy and objects becomes increasingly valuable as the environment grows.

Management may be broad internally without exposing the router itself

For a small environment, administrators may intentionally need access from MGMT to all internal networks:

/ip firewall filter
add chain=FWD-MGMT out-interface-list=INSIDE \
    action=accept \
    comment="MGMT: administer internal networks"

add chain=FWD-MGMT out-interface-list=WAN \
    action=accept \
    comment="MGMT: Internet"

add chain=FWD-MGMT action=drop \
    comment="MGMT: default deny"

That governs traffic through the router.

Access to the MikroTik itself belongs in the input chain.

Do not mix those concepts.

RouterOS defines input for packets destined for the router and forward for packets passing through it.

A simple router-management baseline is:

/ip firewall filter
add chain=input action=accept \
    connection-state=established,related,untracked \
    comment="INPUT 10: established, related, untracked"

add chain=input action=drop \
    connection-state=invalid \
    comment="INPUT 20: drop invalid"

add chain=input action=accept protocol=icmp \
    comment="INPUT 30: ICMP"

add chain=input action=accept in-interface-list=ZONE-MGMT \
    comment="INPUT 40: management zone"

add chain=input action=drop \
    comment="INPUT 99: default deny"

This example assumes client-facing services such as DNS and DHCP are either handled appropriately elsewhere or have explicit input rules where required.

Do not blindly paste the rule set onto a production router before identifying which services the router itself provides.

A firewall rule should not know that WinBox happens to live on ether3

This distinction is worth repeating.

Bad long-term policy:

add chain=input in-interface=ether3 protocol=tcp dst-port=8291 action=accept

Better:

add chain=input in-interface-list=ZONE-MGMT action=accept

Today ZONE-MGMT may contain VLAN 99.

Tomorrow it may contain:

VLAN 99
WireGuard-admin
IPsec-admin
an out-of-band management interface

The policy remains:

management sources may administer the router.

That is stable architecture.

NAT is translation, not security policy

Keep NAT rules simple and separate from access policy.

For a dynamic WAN address:

/ip firewall nat
add chain=srcnat out-interface-list=WAN \
    action=masquerade \
    comment="Dynamic WAN source NAT"

MikroTik documents masquerade as the form of source NAT designed specifically for interfaces whose public address may change, such as DHCP and PPPoE links. For a stable public address, explicit src-nat is normally the more deterministic choice.

Notice again the use of:

out-interface-list=WAN

rather than:

out-interface=ether1

A second dynamic WAN can later join the same role without requiring the basic NAT policy to be rewritten.

Routing and failover still need to be designed separately.

The firewall should not be the component that prevents adding the link.

Do not make destination NAT silently equal permission

A common small-router pattern is effectively:

if it has been dst-natted, allow it.

That is convenient.

It also means that creating a NAT rule can unintentionally become a firewall change.

For an environment intended to grow, prefer two explicit decisions:

1. Translate this public address/port.
2. Permit this translated connection.

For example, if a public HTTPS service is eventually required, create the destination NAT and then permit the corresponding service in FWD-WAN.

Do not open the whole WAN chain merely because one service exists.

A future administrator should be able to read the firewall and understand exactly what the Internet may initiate.

Do not enable FastTrack just because the default configuration had it

FastTrack is useful.

It is not free abstraction.

RouterOS documents that FastTracked traffic bypasses several processing facilities, including firewall processing for subsequent packets, simple queues, some queue trees, IP accounting, IPsec processing paths, VRF assignment and other facilities.

That matters if the network later gains:

QoS
policy routing
traffic accounting
IPsec
complex mangle rules
VRFs
flow visibility

Therefore a foundation configuration does not need FastTrack on day one.

First make the network correct.

Measure performance.

Then add FastTrack deliberately if the hardware and policy require it.

Performance optimisation should not become an invisible architecture dependency.

The same applies to RAW

RouterOS can perform highly effective early filtering in the RAW table before normal connection tracking, and MikroTik publishes an advanced firewall example that uses it extensively.

That does not mean the first configuration requires dozens of RAW rules copied from the Internet.

Build the trust model first.

Add RAW filtering when there is a defined reason: unwanted bogons, obvious invalid traffic, connection-tracking pressure or another understood threat.

A sophisticated rule whose purpose nobody remembers is technical debt with an action button.

Secure the management plane from the beginning

Disable services that will not be used:

/ip service
disable telnet,ftp,www,api

If SSH and WinBox are required, restrict them to management networks as another layer of protection.

Use named administrator identities.

Verify the new administrator works before removing the default account.

RouterOS supports SSH public keys including RSA, Ed25519 and Ed25519-sk keys.

For production networks where Layer-2 emergency access is not required, MikroTik recommends disabling MAC Telnet, MAC WinBox and MAC Ping:

/tool mac-server set allowed-interface-list=none
/tool mac-server mac-winbox set allowed-interface-list=none
/tool mac-server ping set enabled=no

Neighbour discovery can likewise be disabled or restricted to interfaces where it has an operational purpose:

/ip neighbor discovery-settings
set discover-interface-list=none

MikroTik documents both controls as part of router hardening.

Do not disable recovery mechanisms merely to score another point on a checklist.

If MAC WinBox is the documented local recovery method, restrict it to a dedicated physically controlled port instead.

Decide what the router does with DNS

Do not accidentally create a DNS resolver available to untrusted networks.

RouterOS has allow-remote-requests=no by default. If the router is intentionally used as a DNS cache for clients, MikroTik explicitly recommends restricting TCP and UDP port 53 access to known hosts.

Either make RouterOS an intentional internal DNS service and firewall it accordingly, or point clients at the organisation's real DNS service.

“DNS seems to work” is not a design decision.

IPv6 is not a problem for Future You

One particularly dangerous architecture is:

carefully designed IPv4 firewall
+
working IPv6 connectivity
+
no equivalent IPv6 policy

IPv4 and IPv6 have separate RouterOS firewall configuration.

If IPv6 will be used, design its trust boundaries and firewall alongside IPv4.

If the organisation intentionally does not use IPv6 yet, make that a documented decision and verify the actual router state.

Do not assume IPv4 NAT somehow protects IPv6.

It does not.

MikroTik's own advanced firewall documentation provides separate IPv4 and IPv6 rule sets for exactly this reason.

Leave unused ports boring

Unused interfaces do not need to sit in the USERS network waiting for somebody to plug something into them.

MikroTik recommends disabling unused interfaces as part of router hardening.

Alternatively, in environments where ports need to stay electrically active, assign them deliberately to an unused or quarantine VLAN.

What matters is that:

unused port != trusted LAN by default

Logging belongs in the first configuration, not the incident

Correct time and remote logs are much easier to configure before an incident than during one.

Configure NTP.

Use the correct time zone.

Send useful RouterOS events to central logging.

RouterOS supports remote syslog and, since RouterOS 7.18, CEF output with millisecond timestamp support.

Useful early telemetry includes administrative logins, configuration changes, interface state, VPN events, serious firewall events and system warnings.

Do not enable logging on every dropped Internet packet simply because you can.

A public router can turn that into a log-generation benchmark.

Log events that somebody can use.

Do not let configuration backups live only on the router

After completing each major configuration stage, preserve both a readable export and an appropriate binary backup.

A RouterOS export is useful for review, version control and rebuilding.

A binary backup is useful for restoring the same device or a very similar recovery situation.

They are not equivalent.

MikroTik notes that binary backups contain sensitive configuration data and are preferably restored on the same RouterOS version. Plain-text exports, meanwhile, do not include items such as user passwords, certificates and SSH keys.

A basic export is:

/export terse file=router-baseline

Sensitive values are hidden by default unless explicitly requested.

Download the result from the router.

Do not call a file stored on the same device a backup strategy.

Update before declaring the baseline finished

Record:

/system resource print
/system routerboard print
/system package print
/system package update print

Review the supported release channel and changelog before upgrading.

MikroTik currently maintains Stable, Long-term, Testing and Development release channels and explicitly describes Testing and Development as unsuitable for normal production use. MikroTik also recommends upgrading RouterBOOT after the RouterOS upgrade where applicable.

At the time this article was reviewed, 21 September 2026, RouterOS 7.24.4 was the current Stable release and 7.23.7 the current Long-term release.

That sentence will age.

The architecture should not.

What happens when the network grows?

This is the actual test of the design.

A second ISP arrives

Create or configure the second WAN interface.

Add it to:

WAN

Build the routing or failover policy.

The fundamental firewall does not change.

WireGuard is deployed for administrators

Create the tunnel and its addresses.

Add the WireGuard interface to:

ZONE-MGMT

Add its source network to any management address list used for additional restrictions.

The router-management model does not change.

A new IoT VLAN is required

Create:

VLAN 40
ZONE-IOT
FWD-IOT

Add one classification jump in the stable forward chain.

Define exactly what IoT may reach.

Nothing else needs to be redesigned.

A second server VLAN is required

If both server networks have the same trust policy, add the new VLAN interface to:

ZONE-SERVERS

The firewall can remain untouched.

A public application appears

Create the required destination NAT.

Add one explicit WAN policy for that application.

Do not convert WAN into a trusted zone.

That is what scalable configuration looks like.

Run it, read it, decide what changes

After the initial build, collect evidence rather than relying on a successful ping.

/interface bridge port print
/interface bridge vlan print
/interface list print
/interface list member print
/ip address print
/ip route print
/ip firewall filter print stats
/ip firewall nat print stats
/ip service print
/log print

Then test from different trust boundaries.

A GUEST client should reach what the GUEST policy allows and fail against internal resources.

A USERS client should reach the Internet and only explicitly allowed server applications.

An MGMT workstation should reach the management plane.

An untrusted WAN host should not reach WinBox, SSH or arbitrary internal systems.

The counters should increment on the rules you expected to make those decisions.

A successful ping from one laptop proves surprisingly little.

What not to bake into the foundation

Do not make physical port names part of security policy unless the physical port itself is the intended boundary.

Do not make one giant LAN interface list containing networks with different trust levels.

Do not use the management network as the normal user network.

Do not create a port forward and assume NAT is sufficient access control.

Do not enable FastTrack before understanding the features it bypasses.

Do not add complex RAW filtering merely because somebody else's configuration contains it.

Do not expose WinBox or SSH to the Internet because the password is strong.

Do not leave IPv6 outside the security design.

Do not assume a configuration export stored in RouterOS Files is a backup.

And do not build a rule whose only explanation is:

“It stopped working without it.”

That is not documentation.

That is an archaeological layer.

Operational judgement

A future-proof MikroTik configuration is not one that predicts every feature the business will ever need.

That would be impossible.

It is one that puts the boundaries in the correct places.

Physical interfaces transport frames.

Bridges switch them.

VLANs define Layer-2 domains.

VLAN interfaces provide Layer-3 gateways.

Interface lists define security roles.

Address lists define groups of objects.

Firewall chains express policy.

NAT translates addresses.

Routing selects paths.

Keep those responsibilities separate and ordinary expansion becomes additive rather than destructive.

When a new VLAN appears, add it.

When a new ISP appears, add it.

When a VPN appears, classify it.

When an application needs a path, describe that path.

You should not have to rewrite the firewall merely because the network learned a new trick.

That is the difference between configuring a router and designing a network.

Handover

The final documentation should record the IP and VLAN plan, interface roles, security-zone membership, permitted traffic matrix, WAN design, management path, recovery path, backup location, RouterOS release policy and any deliberate exceptions.

A replacement administrator should be able to understand why a rule exists without reconstructing the company's history from packet counters.

Before handover, verify at least one allowed and one denied path for every trust zone.

Preserve the baseline export outside the router.

Then treat future changes as changes to the model rather than exceptions to it.

Primary references

MikroTik RouterOS Documentation — First Time Configuration
MikroTik RouterOS Documentation — Interface Lists
MikroTik RouterOS Documentation — Bridge VLAN Table
MikroTik RouterOS Documentation — Bridging and Switching
MikroTik RouterOS Documentation — Firewall
MikroTik RouterOS Documentation — Building Advanced Firewall
MikroTik RouterOS Documentation — Connection Tracking and FastTrack
MikroTik RouterOS Documentation — NAT
MikroTik RouterOS Documentation — Securing Your Router
MikroTik RouterOS Documentation — Configuration Management
MikroTik RouterOS Documentation — Logging
MikroTik RouterOS Documentation — Upgrading and Installation

Editorial status: first edition. Commands were reviewed against RouterOS 7 documentation and the current release state on 21 September 2026. Hardware-offload behaviour differs between RouterBOARD families; verify the device-specific switching documentation before deploying the VLAN design to production.