Ctrlk
Page cover

Evolution of my home network with Mikrotik RouterOS v7

I have been using MikroTik as my home Wi-Fi router platform for a long time, ever since I discovered there was a better and more affordable way to build a capable home network. Before that, I relied on the generic routers provided by my ISP, followed by the usual off-the-shelf consumer devices from TP-Link, D-Link, and Netgear. They were fine for basic home use, but the features were fairly limited when it came to building a more advanced network setup. At the time, my network was just a simple flat topology with a few awkward port-forwarding rules for services like OpenVPN and Plex Media Server.

When I first started using the tiny hAP ac router from MikroTik running RouterOS, I was genuinely surprised by how many enterprise-like features were packed into such a small and affordable device. It quickly became the perfect platform for my home lab and all the networking projects I liked experimenting with in my spare time.

That said, getting started was not easy. Even basic tasks, such as setting up a DHCP server in RouterOS, felt overwhelming at first. Most consumer routers come with these essentials pre-configured, so average home users rarely need to think about the underlying details. Although RouterOS includes a Quick Set wizard, I only used it occasionally during my early days with MikroTik while experimenting and learning how everything worked under the hood.

As I became more familiar with the RouterOS syntax and configuration style, managing network segmentation for different device groups such as IoT devices, security cameras, and printers became much easier and more straightforward. To keep the network design clean and simple, I initially used separate bridges for each network segment, each with its own dedicated DHCP server configuration, as shown below. I also implemented firewall filtering rules between the networks to control traffic flow and improve security, ensuring that untrusted devices could not freely communicate with trusted systems while still allowing access to essential services where required.

/interface bridge
add comment="Security Camera Bridge" name=cam port-cost-mode=short
add comment="IoT Bridge" name=iot port-cost-mode=short
add comment="LAN Bridge" name=lan port-cost-mode=short

/ip pool
add comment="Secure LAN IP Pool" name=lan ranges=10.0.0.100-10.0.0.200
add comment="All unsecure and IoT devices IP Pool" name=iot ranges=10.10.0.100-10.10.0.200
add comment="Security cameras IP Pool" name=cam ranges=10.20.0.100-10.20.0.200

/ip dhcp-server
add address-pool=lan interface=lan lease-time=1d name=lan
add address-pool=iot interface=iot lease-time=1d name=iot
add address-pool=cam interface=cam lease-time=1d name=cam

/ip dhcp-server network
add address=10.0.0.0/24 dns-server=1.1.1.1,1.0.0.1 gateway=10.0.0.1
add address=10.10.0.0/24 dns-server=1.1.1.1,1.0.0.1 gateway=10.10.0.1
add address=10.20.0.0/24 dns-server=1.1.1.1,1.0.0.1 gateway=10.20.0.1

/ip firewall address-list
add address=10.0.0.0/24 list=trusted
add address=10.10.0.0/24 list=trusted
add address=10.20.0.0/24 list=untrusted

/ip firewall filter
add action=accept chain=forward connection-state=established,related
add action=drop chain=forward dst-address-list=trusted src-address-list=untrusted
add action=drop chain=forward dst-address-list=untrusted src-address-list=untrusted

That setup had been working well for my homelab requirements, but I eventually ran into a limitation with using bridges for network segmentation between trusted and untrusted environments. The bridge-based design was straightforward - simply map physical interfaces to their respective bridges and assign dedicated DHCP services. However, as the homelab grew, the physical port capacity on my MikroTik router started becoming a bottleneck.

Over time, every available port ended up being consumed by a mix of homelab gear, servers, wireless access points, and various IoT devices around the house.

Recently, I wanted to introduce additional isolated networks to create sandbox environments for virtual machines and build a safer space for learning penetration testing within my Proxmox virtualisation setup. While my hypervisor still had spare network interfaces available, my MikroTik router had already reached its physical port limit.

That was the point where I started reconsidering the network design. Instead of continuing with a bridge-per-network model, it made more sense to move toward a VLAN-based approach - allowing multiple isolated networks to share the same physical infrastructure while providing far greater scalability and flexibility for future expansion.

In addition, there were several objectives I wanted to achieve by moving to a VLAN-based design within my Proxmox environment:

  • The existing management network would remain unchanged and continue using the current setup. Since no VLAN tagging is required for management traffic, it would remain untagged on the default VLAN.

  • The network interface connected to my Proxmox VE (PVE) node would be configured as a trunk port, allowing multiple VLANs to be carried over a single physical connection and enabling VLAN tagging directly at the virtual machine network interface level.

  • Some VM networks would need to operate as fully isolated environments. These VLANs should have no access to the rest of the homelab infrastructure and only be allowed outbound internet access for operating system updates, package installation, and similar requirements.

  • With the trunk configuration in place, I also wanted the flexibility to extend selected VLANs from my home network into the virtual environment, allowing certain VMs to connect and communicate with services already running across the homelab ecosystem.

This approach would provide a more scalable network design while maintaining proper segmentation and control between isolated and shared environments. Here is how I have configured my Mikrotik router to achieve those objectives.

If you prefer using Winbox instead of SSH to manage the MikroTik router, the configuration can be viewed as shown below.

With this configuration in place, the required VLAN can then be assigned and tagged directly at the virtual machine network interface level in PVE, as shown below.

PreviousMikrotik RouterOS Hardening for your home internet connectionNextSupercharge your networking lab with Containerlab

Last updated