Skip to content
Go back

Mikrotik RouterOS for Home Lab

By SumGuy 16 min read
Mikrotik RouterOS for Home Lab

Your $300 Router Is Embarrassingly Underpowered

Take a breath. Close those tabs where you’re researching gaming routers. That shiny ASUS with the RGB accents and the “WiFi 6” marketing? It’s running more bloatware than actual routing logic. Meanwhile, Mikrotik dropped a $59 hAP ax2 that will humiliate it in every way that matters.

Here’s the thing: prosumer routers are built for the person who wants to click buttons in a web UI and feel like they’re doing networking. RouterOS is built for people who actually do networking. And the best part? Once you realize what you’ve been missing, you can’t unsee it.

This isn’t a “buy Mikrotik” rant (okay, maybe it is a little). This is a “here’s what RouterOS actually is, why it matters, and how to get started without your head exploding” guide. Because if you’re running any kind of homelab—VLANs, VPNs, complex routing, or just tired of your ISP’s router—you’ve been playing on hard mode with training wheels on.

What Is RouterOS, Actually?

Mikrotik RouterOS is a locked-down Linux distribution optimized for networking appliances. That’s the elevator pitch. Let’s unpack it.

RouterOS isn’t an off-the-shelf Linux distro with iptables and a prayer. It’s Mikrotik’s own OS built on Linux kernel, but everything above the kernel is proprietary, purpose-built for routing, switching, and network management. It runs on Mikrotik’s hardware (hAP, RB, CCR series), on x86 servers (the CHR—Cloud Hosted Router—for VMs), and historically on other ARM-based boards (though that support is being phased out).

The operating system gives you:

The key difference from a typical Linux router (like pfSense or OPNsense): RouterOS is single-purpose from the OS up. It’s not a general-purpose OS bolted with networking tools. Everything is optimized for the routing task. No bloat. No package manager temptation to install random services. Just networking.

The Gear Lineup: Which Mikrotik Box Do You Need?

Mikrotik makes routers for every market. Here’s the reality of the homelab-relevant hardware:

hAP ax2 and hAP ax3 ($50–$80)

These are the entry point. The hAP ax2 (hex, not eight-core) is a dual-core ARM with 256 MB RAM, gigabit ports, and WiFi 6. The hAP ax3 adds another 2.4 GHz radio for mesh. Both run RouterOS just fine for a homelab. If you’re replacing your ISP-provided garbage, start here. The WiFi actually works. The routing actually works. There’s no “5 GHz band disappears after 12 hours” nonsense.

Reality check: These are genuinely good. Not “good for the price.” Good, period.

RB5009 ($150–$200)

The RB5009 is where you go when you have actual expectations. Dual-core ARM, 1 GB RAM, 10 gigabit SFP+ port, PoE out, optional 4G modem. This is the prosumer box. If you’re running multiple VLANs, WireGuard tunnels, and VMs, this is your weapon. It’s not fancy. It’s pure capability. Build quality is industrial. It will run for five years without you thinking about it.

CCR (Core Cloud Router) Series ($300–$3000+)

For people who’ve drunk the Kool-Aid and decided routing is their personality. These are purpose-built throughput beasts. Quad-core to 16-core processors, up to 64 GB RAM, multiple 10 Gbps interfaces. Overkill for any homelab. Totally worth researching if you’re running infrastructure that needs 100+ VLANs and can’t handle packet loss.

CHR (Cloud Hosted Router) ($0–$99/year)

RouterOS as a VM image for ESXi, Proxmox, AWS, Azure, etc. Free licensing for 1 Gbps throughput. If you’re running virtualized infrastructure, spin up CHR instead of dealing with Linux routing. It’s the same RouterOS you’d get on hardware, just in software.

The Recommendation

For a homelab: Start with hAP ax2 or hAP ax3 ($60–$80). You’re replacing your ISP router or creating a secondary routing appliance. Spend the money you saved on a managed switch (because VLANs on a consumer switch are theater; you need a real switch to tag frames). If you’re serious: RB5009 ($150–$200) is the inflection point where the upgrade justifies itself in features and peace of mind.

What RouterOS Gives You That Consumer Gear Doesn’t

Let me list what you lose if you use a consumer router:

  1. Real Firewall Chains: Consumer routers have a firewall, sure. But it’s usually a blacklist router (default allow, block specific traffic) with basic NAT. RouterOS gives you forward, input, output, and prerouting chains with full packet inspection, custom rules, and connection tracking. You can write actual firewall logic, not just “block port 23.”

  2. VLANs With Teeth: Consumer routers say “we support VLANs” and then you spend six hours figuring out they mean “we let you name ports” while the hardware doesn’t actually isolate traffic. RouterOS VLANs work. Bridge interfaces with tagged ports, isolated security zones, guest networks that are actually isolated. Done.

  3. Scriptable Everything: RouterOS has its own scripting language (weird syntax, but powerful). You can automate firewall rules, DHCP pools, DNS entries, backups, monitoring—everything. Need to add a firewall rule when a specific IP is detected? Write a script. Need to auto-update a DDNS entry? Script. Need to reset a VLAN pool every morning? Scheduler + script.

  4. Real QoS (Quality of Service): Consumer routers have a QoS toggle that does basically nothing. RouterOS lets you shape traffic by port, protocol, IP, DSCP marking, and about five other dimensions. Bandwidth limits per user, priority queues, burst rates—the infrastructure ISPs use is available to you.

  5. VPN Infrastructure: WireGuard support since RouterOS 7. IPsec, L2TP, OpenVPN too. You’re not limited to the VPN client app your router came with (or didn’t). Set up a site-to-site tunnel, remote access mesh, or interconnect home labs across continents.

  6. API and Automation: REST API + Ansible support. Integrate RouterOS with your infrastructure-as-code stack. Terraform providers exist. This is how you scale a homelab from “manual config in WebFig” to “reproducible infrastructure.”

  7. Actual Logging: NetFlow export, packet capture, detailed flow logs. You can send logs to a Syslog server, Splunk, ELK—whatever you’re already using. No “router logs show nothing” nonsense.

The Learning Curve Reality

Okay, so RouterOS is powerful. But it’s also intimidating if you’ve only ever used consumer gear. Let’s be honest about the learning curve.

The Interfaces

RouterOS ships with three frontends:

Winbox (Windows and Wine on Linux): A GUI tool that’s clunky but functional. It exposes almost everything in the OS, which is both powerful and overwhelming. If you’re used to web UIs, Winbox feels like navigating a decades-old enterprise tool. Because, well, it kind of is.

WebFig (the web UI): RouterOS 7+ ships with a modern web interface. It’s cleaner than Winbox. It covers maybe 70% of what you need for a basic setup. Missing advanced features? Time to switch tools.

SSH/CLI (the command line): This is where RouterOS flex happens, and where the learning curve gets steep. The syntax is unique (not Cisco, not Linux), but once you get it, it’s powerful. You’re not running iptables. You’re running ip firewall filter add chains with actual logic.

Reality: You’ll use all three. Web UI for the quick stuff, Winbox for deeper dives, CLI for scripting and bulk operations. Expect a weekend or two of head-scratching if you’ve never done this before. After that, it clicks.

The Documentation

Mikrotik’s wiki is thorough but scattered. Google “RouterOS VLAN” and you’ll find three different approaches, all valid, all slightly different. The official docs assume you know what you’re doing. YouTube is your friend here—the community has filled in the gaps.

Basic Setup: From Box to Functioning Router

Let’s walk through a realistic homelab setup: a RB5009 replacing your ISP router, with VLANs, firewalling, and WireGuard for remote access.

Step 1: Reset and Identity

Out of the box, RouterOS ships with a default user (admin, no password) and an IP pool (192.168.88.0/24). First thing: reset it to known state.

Reset and Identity
/system reset-configuration no-defaults=yes skip-backup=yes
# Your router will restart. Wait 30 seconds.
# Over SSH or Winbox, set the identity (useful for Syslog and backups)
/system identity set name=homelab-router
# Set up an admin user with a real password
/user add name=admin group=full password=YourStrongPasswordHere
# Disable the default admin user (it'll log you out, reconnect with your new user)
/user disable admin
# Now you're running a router with no default credentials. Good.

Step 2: Network Interfaces and IP Pools

Set up the WAN port and LAN bridge, plus an IP pool for DHCP.

Terminal window
# View current interfaces
/interface ethernet print
# Create a bridge for LAN (if you're adding VLANs)
/interface bridge add name=bridge-local
# Add ports to the bridge (e.g., ether2 through ether9 for a 10-port RB5009)
/interface bridge port add interface=ether2 bridge=bridge-local
/interface bridge port add interface=ether3 bridge=bridge-local
/interface bridge port add interface=ether4 bridge=bridge-local
# ... repeat for all LAN ports ...
# Configure WAN (ether1) as a DHCP client
/ip dhcp-client add interface=ether1 disabled=no
# Add an IP to the bridge (your router's LAN IP)
/ip address add address=192.168.1.1/24 interface=bridge-local
# Create a DHCP pool
/ip pool add name=dhcp-pool ranges=192.168.1.100-192.168.1.254
# Set up DHCP server on the bridge
/ip dhcp-server add interface=bridge-local address-pool=dhcp-pool disabled=no
# Configure DHCP lease options (gateway, DNS)
/ip dhcp-server network add address=192.168.1.0/24 gateway=192.168.1.1 dns-server=192.168.1.1

At this point, plug in a device to a LAN port and it should get an IP. If it does, congratulations—you’ve done more than 90% of consumer router users ever will.

Step 3: Firewall NAT (Allow Outbound, Block Inbound)

Now the defensive stuff. Default: allow LAN clients out, block the WAN from initiating inbound connections.

Terminal window
# NAT: Masquerade outbound traffic from LAN
/ip firewall nat add chain=srcnat action=masquerade out-interface=ether1
# Filter: Default chains
# Input (packets destined for the router itself)
/ip firewall filter add chain=input action=accept connection-state=established,related,untracked
/ip firewall filter add chain=input action=accept in-interface=bridge-local
/ip firewall filter add chain=input action=drop in-interface=ether1
# Forward (packets routed through the router)
/ip firewall filter add chain=forward action=accept connection-state=established,related,untracked
/ip firewall filter add chain=forward action=accept in-interface=bridge-local
/ip firewall filter add chain=forward action=drop in-interface=ether1
# Drop invalid packets (security hardening)
/ip firewall filter add chain=input action=drop protocol=tcp tcp-flags=none
/ip firewall filter add chain=input action=drop protocol=tcp tcp-flags=fin,!ack,!syn,!rst

Step 4: VLANs for Isolation

Now the magic. Create a guest VLAN and a servers VLAN, isolated from each other.

vlan-setup.rsc
# Create VLAN interfaces
/interface vlan add name=vlan-guests vlan-id=10 interface=bridge-local
/interface vlan add name=vlan-servers vlan-id=20 interface=bridge-local
/interface vlan add name=vlan-trusted vlan-id=1 interface=bridge-local
# Add IPs to each VLAN
/ip address add address=10.0.1.1/24 interface=vlan-trusted
/ip address add address=10.0.2.1/24 interface=vlan-guests
/ip address add address=10.0.3.1/24 interface=vlan-servers
# Create DHCP pools per VLAN
/ip pool add name=pool-trusted ranges=10.0.1.100-10.0.1.254
/ip pool add name=pool-guests ranges=10.0.2.100-10.0.2.254
/ip pool add name=pool-servers ranges=10.0.3.100-10.0.3.254
# DHCP servers per VLAN
/ip dhcp-server add interface=vlan-trusted address-pool=pool-trusted
/ip dhcp-server add interface=vlan-guests address-pool=pool-guests
/ip dhcp-server add interface=vlan-servers address-pool=pool-servers
# DHCP networks
/ip dhcp-server network add address=10.0.1.0/24 gateway=10.0.1.1 dns-server=10.0.1.1
/ip dhcp-server network add address=10.0.2.0/24 gateway=10.0.2.1 dns-server=10.0.2.1
/ip dhcp-server network add address=10.0.3.0/24 gateway=10.0.3.1 dns-server=10.0.3.1
# Tag ports on the bridge
# Ports 2-4: trusted, ports 5-7: guests, ports 8-9: servers
/interface bridge port set [find interface=ether2] pvid=1 tagged=vlan-trusted,vlan-guests,vlan-servers
/interface bridge port set [find interface=ether3] pvid=1 tagged=vlan-trusted,vlan-guests,vlan-servers
/interface bridge port set [find interface=ether4] pvid=1 tagged=vlan-trusted,vlan-guests,vlan-servers
/interface bridge port set [find interface=ether5] pvid=10 tagged=vlan-trusted,vlan-guests,vlan-servers
/interface bridge port set [find interface=ether6] pvid=10 tagged=vlan-trusted,vlan-guests,vlan-servers
/interface bridge port set [find interface=ether7] pvid=10 tagged=vlan-trusted,vlan-guests,vlan-servers
/interface bridge port set [find interface=ether8] pvid=20 tagged=vlan-trusted,vlan-guests,vlan-servers
/interface bridge port set [find interface=ether9] pvid=20 tagged=vlan-trusted,vlan-guests,vlan-servers
# Firewall: Deny guests↔servers, allow everything else
/ip firewall filter add chain=forward action=drop in-interface=vlan-guests out-interface=vlan-servers
/ip firewall filter add chain=forward action=drop in-interface=vlan-servers out-interface=vlan-guests

Now plug a managed switch into, say, ether2 (now a trunk port). Configure the switch ports with VLAN 10 and VLAN 20, plug in clients, and they’ll be isolated from each other automatically.

Step 5: WireGuard VPN

RouterOS 7+ has native WireGuard. Set it up for remote access to your homelab.

Terminal window
# Generate a keypair for the router
/interface wireguard add name=wireguard-tunnel mtu=1420 listen-port=51820
# Get the public key
/interface wireguard print where name=wireguard-tunnel
# Copy the public-key field
# Add a WireGuard peer (your laptop, phone, whatever)
/interface wireguard peers add interface=wireguard-tunnel public-key=<laptop-public-key> allowed-address=10.0.10.2/32
# Add an IP to the WireGuard interface (router side)
/ip address add address=10.0.10.1/24 interface=wireguard-tunnel
# Firewall: Allow WireGuard traffic inbound and forward from WG to LAN
/ip firewall filter add chain=input action=accept in-interface=wireguard-tunnel
/ip firewall filter add chain=forward action=accept in-interface=wireguard-tunnel out-interface=bridge-local
/ip firewall filter add chain=forward action=accept in-interface=bridge-local out-interface=wireguard-tunnel
# NAT: Masquerade from WG to LAN (so LAN doesn't know packets came over WG)
/ip firewall nat add chain=srcnat action=masquerade out-interface=bridge-local in-interface=wireguard-tunnel

Your laptop now connects to <your-public-ip>:51820 and gets 10.0.10.2, with full access to 192.168.1.0/24 (or your VLANs, whatever you opened in the firewall).

Gotchas and Speed Bumps

After spinning up half a dozen RouterOS setups, here are the things that will trip you up:

The Input Chain

The input chain filters packets destined for the router itself (SSH, WebFig, DHCP responses). The forward chain filters traffic through the router. Everyone messes this up. You’ll block SSH by accident. You’ll wonder why Winbox stops responding. It’s because you added a drop rule to input before you added an accept established,related rule. Protip: always add connection-state rules first, default-deny rules last.

Bridge and Firewall Bridge Flag

By default, bridge interfaces bypass the firewall. If you create a bridge and wonder why your firewall rules don’t apply to bridged traffic, set the bridge-firewall flag:

Terminal window
/interface bridge set [find name=bridge-local] use-ip-firewall=yes

Now the firewall filters bridged traffic. This matters when you’re using VLANs, because VLANs are part of the bridge.

DHCP Renew and Lease Time

DHCP leases default to 10 minutes. In a lab environment where you’re rebooting stuff constantly, bump it up:

Terminal window
/ip dhcp-server set [find name=<your-server>] lease-time=7d

RouterBOOT and Default Config

If something goes catastrophically wrong, RouterBOOT (the bootloader) has a reset sequence: hold the reset button for 3+ seconds. The router will start with an IP of 192.168.88.1. Winbox can find it automatically. Just know this exists so you can recover without a serial console.

Mikrotik vs. UniFi: The Uncomfortable Comparison

UniFi is Ubiquiti’s ecosystem: managed switches, APs, and a cloud controller. It’s beautiful, cloud-friendly, and relatively affordable. Mikrotik is… not that.

Where Mikrotik wins:

Where UniFi wins:

The real talk: If you’re mixing Mikrotik and UniFi, use Mikrotik for routing/firewalling and UniFi for wireless APs. That’s the unstoppable combo. Mikrotik router, UniFi switches, UniFi APs. Routing intelligence where it matters, AP polish where you notice it. Total cost of ownership is lower than an all-UniFi stack, and you get actual networking depth.

Why Your Homelab Needs This

A Mikrotik router is not about bragging rights (okay, it’s partly that). It’s about:

  1. Learning real networking: VLANs, firewall chains, routing protocols, VPNs—you learn the stuff that matters when you move to infrastructure careers. Your homelab is a laboratory. Use it as one.

  2. Scaling without friction: When you add a second home lab site (office, guest house, wherever), you spin up WireGuard tunnels, bridge networks, automate firewall rules. A consumer router makes you do this manually via the web UI, every time.

  3. Stability: RouterOS routers don’t crash. They don’t leak memory. You reboot them when you update RouterOS (4–6 times a year). That’s it. A consumer router? Odds are it reboots itself spontaneously every six months.

  4. Peace of mind: You own your network. No cloud dependency, no phone-home telemetry, no forced auto-updates that break things. You decide when and how to update.

Getting Started: The Action Items

  1. Buy a hAP ax2 ($60–$80 on Amazon). It’s risk-free. If you hate it, you’ve spent less than a nice dinner.
  2. Grab Winbox from mikrotik.com. Boot it up, reset the router to defaults, and follow the four-step setup above.
  3. Accept the awkwardness for a weekend. The learning curve is real, but it’s worth it.
  4. Join the Mikrotik forums (mikrotik.com/forum) and the r/mikrotik subreddit. The community is helpful and weird in the best way.
  5. If you get stuck: the wiki is thorough. Google “RouterOS [your problem]” and you’ll find a script or an explanation. It might be in a forum post from 2015, but it’ll work.

Your homelab is about learning. A prosumer router teaches you what buttons to click. RouterOS teaches you why networks work. That’s worth the $60, the weekend of confusion, and the weird syntax you’ll have to remember.

You’ve been doing networking with training wheels. Time to take them off.


Share this post on:

Send a Webmention

Written about this post on your own site? Send a webmention and it'll show up above once verified.


Next Post
Boundary vs Teleport

Discussion

Powered by Garrul . Sign in with GitHub or Google, or post anonymously.

Related Posts