Back to blog

MikroTik / RouterOS  ·  Tutorial  ·  July 2026

MikroTik
DHCP Server & NAT

The two services every edge router runs: hand addresses to the LAN, and share one public IP out to the world. RouterOS makes both quick — the default config already does them — but "quick" hides a connection-tracking model worth understanding, and a masquerade-vs-src-nat choice that matters the day you get a second WAN. This is the Cisco DHCP & NAT/PAT post in RouterOS.

MikroTik RouterOS DHCP NAT Masquerade

DHCP gives hosts an address, gateway, and DNS automatically; NAT rewrites the private source address of outbound traffic to the router's public one so many hosts share a single IP (what Cisco calls PAT / overload). RouterOS builds DHCP from three objects — a pool of addresses, a server bound to an interface, and a network declaring gateway/DNS — and does NAT with a single srcnat rule in the firewall.

The RouterOS-specific thing to internalise is that NAT is driven by connection tracking: the first packet of a flow hits the NAT rule, and every subsequent packet is handled by the conntrack entry, not re-evaluated. That's why NAT is fast, why clearing connections matters after a rule change, and why the masquerade-vs-src-nat distinction has real consequences. This is the counterpart to Cisco IOS: DHCP & NAT/PAT; inbound port-forwarding (dst-nat) has its own post in Port Forwarding.

Prerequisites

01

The DHCP Server — Pool, Server, Network

Three objects. The setup wizard builds them in one go, but doing it by hand shows you what each does and where to change it later.

Terminal — DHCP for the 10.10.0.0/24 LAN on the bridge
# 1. The range of addresses to hand out (leave .1-.9 for infrastructure):
> /ip pool add name=LAN-POOL ranges=10.10.0.20-10.10.0.254

# 2. The server, bound to the LAN interface, using that pool:
> /ip dhcp-server add name=LAN-DHCP interface=bridge address-pool=LAN-POOL lease-time=8h

# 3. The options handed to clients: gateway, netmask, DNS:
> /ip dhcp-server network add address=10.10.0.0/24 gateway=10.10.0.1 dns-server=10.10.0.1

> /ip dhcp-server lease print   # watch leases appear as clients ask
⚠ Gotcha — One DHCP Server Per Broadcast Domain

Bind the server to the bridge, not a single physical port — the bridge is the broadcast domain the clients live in. Bind it to ether2 alone and only that port gets addresses. And never run two enabled DHCP servers on the same segment: clients take whichever answers first, and you'll chase a "sometimes wrong gateway" ghost. For VLANs, one server per VLAN interface — see VLANs.

02

Static Leases — Reservations Done Right

Printers, the NVR, access points — anything you'll firewall or forward to needs a stable address. Reserve by MAC so the device still uses DHCP but always gets the same IP.

Terminal — pin a lease, from an existing dynamic one
# Fastest: find the dynamic lease and "make static", then set the address.
> /ip dhcp-server lease make-static [find address=10.10.0.51]
> /ip dhcp-server lease set [find mac-address=DC:...] address=10.10.0.10
# Or add from scratch:
> /ip dhcp-server lease add mac-address=DC:2C:6E:00:11:22 address=10.10.0.10 \
    server=LAN-DHCP comment="NVR"

03

NAT — Masquerade vs src-nat

The default config uses masquerade, which is fine until it isn't. Knowing the difference is what separates "it works on one WAN" from "it survives failover."

/ip firewall nat — the two ways to source-NAT
# MASQUERADE: use whatever address the out-interface currently has.
# Zero config, perfect for DHCP/PPPoE WANs whose IP changes.
> /ip firewall nat add chain=srcnat out-interface-list=WAN action=masquerade

# SRC-NAT: pin to a specific address. Faster (no per-packet lookup) and
# required when you have multiple public IPs and want deterministic mapping.
> /ip firewall nat add chain=srcnat out-interface=ether1 \
    src-address=10.10.0.0/24 action=src-nat to-addresses=203.0.113.10
💡 Pro Tip — Masquerade's Hidden Cost on Failover

masquerade recomputes the source address per connection and, crucially, drops tracked connections when the interface's address changes — which is actually helpful on a WAN flap. But on a router with many connections it's measurably heavier than src-nat. Rule of thumb: masquerade for dynamic-IP WANs, src-nat when the public IP is static. When you build dual-WAN failover, you'll want a masquerade rule per WAN keyed on the out-interface so translations follow the live path.

04

The Connection-Tracking Model Safe to Run

NAT and the firewall both ride on conntrack. Understanding it explains RouterOS's whole packet-flow behaviour — and why a NAT change sometimes "doesn't take" until you clear state.

Terminal — inspect and reset connection state
> /ip firewall connection print          # live flows + their NAT state
> /ip firewall connection print count-only
# Changed a NAT rule and old flows still use the old translation?
# Remove the stale connections so they re-evaluate against the new rule:
> /ip firewall connection remove [find src-address~"10.10.0"]

Takeaways

  1. DHCP is three objects: pool (addresses), server (bound to the bridge/VLAN), network (gateway + DNS). Bind to the broadcast domain, not a single port.
  2. Reserve addresses for anything you'll firewall or forward to — by MAC, so the device still uses DHCP but never moves.
  3. Masquerade for dynamic-IP WANs, src-nat for static. Masquerade is zero-config and flap-friendly; src-nat is faster and deterministic.
  4. NAT rides on connection tracking — the first packet hits the rule, the rest follow conntrack. That's why it's fast and why rule changes may need a connection flush.
  5. One masquerade rule per WAN on failover setups, keyed on out-interface, so translations follow whichever link is live.

Flat network, one overworked consumer router, and it's nearly summer?

NOCTIS designs clean addressing, DHCP, and NAT on MikroTik and Cisco for hotels and businesses in Crete — with segmentation, reservations, and failover that survive a full house.

Book a Discovery Call →