When you’re standing up network infrastructure for a remote office that needs to talk back to a head office, one router can do a surprising amount of heavy lifting — if you lean on VLANs, address lists, and a tight firewall ruleset instead of throwing extra hardware at the problem.
This post walks through a real-world branch office configuration built on a MikroTik router running RouterOS 7, connecting a remote site back to a central head office (HQ) over a routed WAN link. All site-identifying names, domains, and serial numbers have been replaced with placeholders — swap in your own values before using any of this.
The goal
The site has three distinct traffic types that need to stay apart from each other:
- LAN — staff workstations, which need full access back to HQ resources
- Cameras — an isolated network for site surveillance devices, with no need to reach anywhere except each other
- WiFi — guest/general wireless, which should reach the internet but never touch LAN, Cameras, or HQ
Everything rides on one physical uplink and one trunk to the office switches, separated entirely by VLAN tagging and firewall address lists.
Step 1: A VLAN-aware bridge
Everything starts with a single bridge interface with VLAN filtering turned on. This is what lets one router push out multiple isolated broadcast domains over one trunk port.
/interface bridge
add name=bridge1 vlan-filtering=yes comment="Main bridge for all site traffic"
/interface ethernet
set [ find default-name=ether1 ] name=WAN comment="WAN uplink to HQ / internet via <firewall-appliance>"
/interface vlan
add interface=bridge1 name=Camera vlan-id=40 comment="Camera interface"
add interface=bridge1 name=LAN vlan-id=1 comment="LAN interface"
add interface=bridge1 name=WiFi vlan-id=41 comment="WiFi interface"The WAN port here doesn’t go straight to the internet — it uplinks to a firewall appliance at head office, which is why the default route later points at an internal IP rather than an ISP gateway.
Step 2: Trunking to the office switch
A single bridge port carries all three VLANs down to the site’s access switches, with VLAN 1 (LAN) untagged and the other two tagged:
/interface bridge port
add bridge=bridge1 interface=ether2 comment="Trunk to office switches"
/interface bridge vlan
add bridge=bridge1 vlan-ids=1 untagged=ether2 tagged=bridge1 comment="LAN untagged"
add bridge=bridge1 vlan-ids=40 tagged=bridge1,ether2 comment="Camera tagged"
add bridge=bridge1 vlan-ids=41 tagged=bridge1,ether2 comment="WiFi tagged"Step 3: Addressing and DHCP per VLAN
Each VLAN gets its own /24, its own DHCP pool, and its own gateway on the router:
/ip pool
add name=pool-cameras ranges=192.168.40.1-192.168.40.200 comment="Camera DHCP pool"
add name=pool-lan ranges=192.168.41.1-192.168.41.200 comment="LAN DHCP pool"
add name=pool-wifi ranges=192.168.42.1-192.168.42.200 comment="WiFi DHCP pool"
/ip dhcp-server
add name=dhcp-cameras interface=Camera address-pool=pool-cameras comment="DHCP for cameras (site only)"
add name=dhcp-lan interface=LAN address-pool=pool-lan comment="DHCP for LAN (HQ routed)"
add name=dhcp-wifi interface=WiFi address-pool=pool-wifi comment="DHCP for WiFi (isolated)"
/ip address
add address=192.168.40.254/24 interface=Camera comment="Camera gateway (local only)"
add address=192.168.41.254/24 interface=LAN comment="LAN gateway"
add address=192.168.42.254/24 interface=WiFi comment="WiFi gateway (local only)"
add address=<router-wan-ip>/24 interface=WAN comment="HQ fibre uplink"Fixed leases keep known devices — cameras especially — pinned to predictable addresses:
/ip dhcp-server lease
add address=192.168.41.198 mac-address=<mac-address> server=dhcp-lan
add address=192.168.40.1 mac-address=<mac-address> server=dhcp-camerasStep 4: DNS that follows the domain back to HQ
Rather than running a local resolver for internal names, DNS queries for the internal domains are forwarded straight to the head office DNS servers, with everything else falling back to public resolvers:
/ip dns forwarders
add name=hq-dns-pool dns-servers=<hq-dns-server-1>,<hq-dns-server-2>
/ip dns
set allow-remote-requests=yes servers=1.1.1.1,8.8.8.8 cache-max-ttl=1d
/ip dns static
add name=<internal-domain-1> type=FWD forward-to=hq-dns-pool match-subdomain=yes
add name=<internal-domain-2> type=FWD forward-to=hq-dns-pool match-subdomain=yesThis means any device on LAN resolving an internal hostname gets routed to the real head-office DNS servers, while general internet lookups go to public resolvers — no split-DNS server needed on site.
Step 5: Locking it down with address lists
This is where the segmentation actually gets enforced. Every VLAN’s subnet and gateway gets its own address list, and the firewall rules reference those lists instead of raw IPs — much easier to read and maintain:
/ip firewall address-list
add list="Camera Network" address=192.168.40.0/24
add list="LAN Network" address=192.168.41.0/24
add list="WiFi Network" address=192.168.42.0/24
add list="HQ Network" address=<hq-network-range>The forward chain then enforces the actual policy:
| Traffic | Result |
|---|---|
| LAN ↔ HQ | Allowed both ways |
| LAN → internet | Allowed |
| WiFi → internet | Allowed |
| WiFi → LAN / Camera / HQ | Blocked |
| Camera → anywhere (outbound) | Blocked entirely |
| HQ → Camera / WiFi | Blocked |
/ip firewall filter
add chain=forward action=accept src-address-list="LAN Network" dst-address-list="HQ Network" comment="LAN to HQ"
add chain=forward action=accept src-address-list="HQ Network" dst-address-list="LAN Network" comment="HQ to LAN"
add chain=forward action=accept src-address-list="LAN Network" comment="LAN to internet"
add chain=forward action=drop src-address-list="Camera Network" comment="Block camera outbound"
add chain=forward action=drop src-address-list="WiFi Network" dst-address-list="LAN Network" comment="Block WiFi to LAN"
add chain=forward action=drop src-address-list="WiFi Network" dst-address-list="Camera Network" comment="Block WiFi to Camera"
add chain=forward action=drop src-address-list="WiFi Network" dst-address-list="HQ Network" comment="Block WiFi to HQ"
add chain=forward action=accept src-address-list="WiFi Network" comment="Allow WiFi to internet"
add chain=forward action=drop dst-address-list="Camera Network" src-address-list="HQ Network" comment="Block HQ to Camera"
add chain=forward action=drop dst-address-list="WiFi Network" src-address-list="HQ Network" comment="Block HQ to WiFi"A catch-all drop rule with rate-limited logging closes things out, so anything not explicitly permitted gets dropped and logged without flooding the log file:
/ip firewall filter
add chain=forward action=passthrough log=yes log-prefix=DROP limit=1/1h,1:packet comment="Drop logging"
add chain=forward action=drop limit=1/1m,5 log-prefix=DROPPED comment="Drop all other traffic"Cameras get the strictest treatment of all — a flat outbound block. They can talk to each other and to a local NVR on their own VLAN, but they have zero path out to the internet or anywhere else, which limits their blast radius if one is ever compromised.
Step 6: NAT and routing
Only LAN and WiFi are masqueraded out to the internet — Cameras don’t need it and don’t get it:
/ip firewall nat
add chain=srcnat action=masquerade out-interface=WAN src-address-list="LAN Network"
add chain=srcnat action=masquerade out-interface=WAN src-address-list="WiFi Network"
/ip route
add dst-address=0.0.0.0/0 gateway=<hq-firewall-gateway-ip> comment="Default route to HQ firewall for LAN traffic"Step 7: Locking down router management
Finally, SSH and the web interface are restricted to the internal management range only — never exposed to WAN:
/ip service
set ssh address=<management-subnet>
set www address=<management-subnet>If you’re setting router or user passwords as part of this build, RouterOS strips them from configuration exports automatically — but always double-check that any scripts, templates, or backups you keep around use placeholders like <router-admin-password> rather than real credentials, and store the real ones in a password manager.
The takeaway
Three VLANs, one bridge, and a handful of address-list-driven firewall rules gets you a branch office network where guest WiFi can’t see the cameras, the cameras can’t phone home to anyone, and only staff LAN traffic gets a path back to head office — all on a single router. It’s a pattern that scales cleanly to more VLANs (extra departments, a voice VLAN, an IoT VLAN) just by repeating the same pool/DHCP/address-list/firewall pattern for each one.
