DHCP MAC Address Filtering

Overview

By default, a RouterOS DHCP server assigns IP addresses to any client that requests one. To restrict your network so that only pre-registered (known) MAC addresses receive a lease, you configure the DHCP server with address-pool=static-only and create a static lease for each allowed device.

This approach is useful for:

Small offices or home networks where only known devices should connect
Networks where rogue or guest devices must be denied automatic IP assignment
Environments where IP address management (IPAM) requires every host to be explicitly registered

For stronger enforcement (blocking unknown MACs at Layer 2 before any IP is assigned), RouterOS bridge filters can drop frames from unregistered MAC addresses entirely.

Security note: MAC addresses can be spoofed by any device. An attacker who knows an allowed MAC can impersonate it. For environments requiring stronger assurance, consider 802.1X port-based authentication (RADIUS) in addition to or instead of MAC filtering.

Prerequisites

RouterOS 6.x or 7.x
A DHCP server already configured on the target interface (e.g., created via Quick Set or /ip dhcp-server setup)
Administrator access (full or write permissions to /ip dhcp-server and /ip dhcp-server lease)
MAC addresses of all devices that should be allowed on the network

Configuration

1. Create Static Leases for Known Devices

For each device that should receive a DHCP lease, add a static lease binding its MAC address to a fixed IP:

/ip dhcp-server lease
add server=dhcp1 mac-address=AA:BB:CC:DD:EE:01 address=192.168.88.10 comment="workstation-01"
add server=dhcp1 mac-address=AA:BB:CC:DD:EE:02 address=192.168.88.11 comment="printer-01"
add server=dhcp1 mac-address=AA:BB:CC:DD:EE:03 address=192.168.88.12 comment="nas-01"

Replace dhcp1 with the name of your DHCP server, and assign IP addresses from within your DHCP pool range.

To convert an existing dynamic lease (a device already connected) to static without re-entering its details:

/ip dhcp-server lease make-static [find where active-mac-address="AA:BB:CC:DD:EE:01"]

2. Restrict the Server to Static Leases Only

Set address-pool=static-only on the DHCP server. After this change, any client whose MAC address does not have a static lease entry will be silently ignored — it will not receive a lease or a DHCPNAK response.

/ip dhcp-server
set [find name="dhcp1"] address-pool=static-only

RouterOS version note: The authoritative property existed in RouterOS 6 (values: yes, no, after-2sec-delay, after-10sec-delay) and controlled whether the server sent a DHCPNAK to clients with addresses outside its scope. This property does not exist in RouterOS 7. The command is accepted without error but has no effect. In RouterOS 7, with address-pool=static-only, unknown clients are silently ignored — no DHCPNAK is sent and no additional configuration is needed.

3. (Optional) Populate ARP Table Automatically

Enable add-arp=yes to have the router automatically add a static ARP entry for each DHCP lease. This prevents ARP spoofing: only the registered MAC can use the assigned IP.

/ip dhcp-server
set [find name="dhcp1"] add-arp=yes

4. (Optional) Harden ARP to Prevent IP Spoofing

A device can bypass DHCP by self-assigning a static IP. Setting arp=reply-only on the bridge interface causes the router to answer ARP only for addresses it has a static ARP entry for — effectively blocking traffic from any IP not registered via DHCP:

/interface bridge
set bridge-lan arp=reply-only

When combined with add-arp=yes on the DHCP server (step 3), only IPs assigned through DHCP leases will have working ARP entries. A client using a self-assigned static IP gets no ARP reply and cannot communicate.

Note: After setting arp=reply-only, ensure the router itself has a static ARP entry if needed, or that its own interface IP is already in the ARP table.

5. (Optional) Block Unknown Hosts at the Firewall

A device with a manually-configured static IP (bypassing DHCP entirely) would still be able to forward traffic. To block such hosts, add firewall rules that only permit traffic from the registered IP addresses:

# Add known hosts to an address list
/ip firewall address-list
add list=lan-known address=192.168.88.10 comment="workstation-01"
add list=lan-known address=192.168.88.11 comment="printer-01"
add list=lan-known address=192.168.88.12 comment="nas-01"

# Accept traffic from known hosts; drop everything else from LAN
/ip firewall filter
add chain=forward in-interface=bridge-lan src-address-list=lan-known action=accept \
    comment="Allow known LAN hosts"
add chain=forward in-interface=bridge-lan action=drop \
    comment="Drop unknown LAN hosts"

Replace bridge-lan with the name of your LAN bridge or interface. Run the two add commands in the order shown — accept first, drop second. RouterOS appends each rule to the end of the chain, so the accept rule ends up above the drop rule.

Existing rules: If you already have permissive rules in the forward chain, insert these new rules above them using place-before=<number>, where <number> is the position of the first rule to supersede. Do not use place-before=0 when the chain is empty — RouterOS returns no such item because there is no rule at position 0 yet.

6. (Optional) Suppress Unknown MAC Flooding on Access Ports

Rather than full bridge filtering, you can disable unknown unicast flooding on individual access ports. This prevents frames destined for unknown MACs from being flooded out those ports:

/interface bridge port set [find where interface="ether5"] unknown-unicast-flood=no

Important: Only disable unknown-unicast-flood on edge/access ports facing client devices. Leave it enabled on trunk and uplink ports — disabling it there will blackhole traffic to any MAC not yet in the bridge’s FDB.

This alone does not prevent devices from sending traffic, but combined with address-pool=static-only it reduces broadcast noise from unknown devices.

7. (Optional) Block Unknown MACs at Layer 2 (Bridge Filter)

For the strictest enforcement — blocking unknown devices before they can even send an IP packet — use bridge filters. This requires bridge firewall to be enabled:

# Enable bridge firewall processing
/interface bridge settings
set use-ip-firewall=yes

# Allow known source MACs; drop all others on the LAN bridge
/interface bridge filter
add chain=forward in-bridge=bridge-lan \
    src-mac-address=AA:BB:CC:DD:EE:01/FF:FF:FF:FF:FF:FF \
    action=accept comment="workstation-01"
add chain=forward in-bridge=bridge-lan \
    src-mac-address=AA:BB:CC:DD:EE:02/FF:FF:FF:FF:FF:FF \
    action=accept comment="printer-01"
add chain=forward in-bridge=bridge-lan \
    src-mac-address=AA:BB:CC:DD:EE:03/FF:FF:FF:FF:FF:FF \
    action=accept comment="nas-01"
add chain=forward in-bridge=bridge-lan action=drop \
    comment="Drop unknown MAC addresses"

Important: Bridge filtering with use-ip-firewall=yes can reduce switching performance on hardware-offloaded bridges. On switches that support hardware offload (e.g., CRS series), verify whether bridge filters are processed in software or hardware before deploying in high-throughput environments.

Verification

Check DHCP Server Configuration

/ip dhcp-server print detail where name="dhcp1"

Confirm address-pool: static-only appears in the output.

Check Static Leases

/ip dhcp-server lease print

Each registered (static) device should appear without the D (dynamic) flag. When a known device connects, its status changes to bound. (RouterOS 7 does not show a type field in lease print output — static vs dynamic is distinguished by the D flag.)

Watch DHCP Activity in the Log

/log print where message~"dhcp"

A known MAC receives a lease: dhcp1 assigned 192.168.88.10 to AA:BB:CC:DD:EE:01
An unknown MAC is rejected: no lease assignment log entry (RouterOS 7 silently ignores unknown clients when address-pool=static-only)

Test with a Known and an Unknown Device

Connect a device with a registered MAC — it should receive the configured static IP.
Connect a device with an unregistered MAC — it should receive no IP (or show “Limited connectivity” / “169.254.x.x” self-assigned address on the client).

Check Firewall Counters (if using address-list rules)

/ip firewall filter print stats

The drop rule for unknown LAN hosts should increment when an unregistered device attempts to forward traffic.

Check Bridge Filter Counters (if using L2 MAC filtering)

/interface bridge filter print stats

Troubleshooting

Known device is not receiving a lease

Verify the MAC address in the static lease exactly matches the client’s MAC (case-insensitive, but check for typos): /ip dhcp-server lease print
Confirm the lease server field matches your DHCP server name.
Check that the DHCP server is active on the correct interface: /ip dhcp-server print
Ensure the assigned IP address is within the subnet served by the DHCP server.

Unknown device still receives an IP

Confirm address-pool=static-only is set: /ip dhcp-server print detail
Check whether there is a second DHCP server on the same interface (perhaps from a previous configuration): /ip dhcp-server print
If running RouterOS 7.x with a DHCP server created via the new wizard, verify the server name used in set [find name=...] is correct.
Existing dynamic leases issued before you set static-only remain valid until they expire. To revoke them immediately: /ip dhcp-server lease remove [find where dynamic=yes]

add-arp=yes not blocking spoofed IPs

ARP entries added by DHCP are set to dynamic. Manually added static ARP entries (with reply-only=yes) provide stricter enforcement: /ip arp add address=192.168.88.10 mac-address=AA:BB:CC:DD:EE:01 interface=bridge-lan
Enable ARP reply-only on the interface to prevent unanswered ARP requests from spoofed sources: /interface bridge set bridge-lan arp=reply-only

Bridge filter drops legitimate traffic

Print bridge filter rules and their hit counters to find which rule is matching: /interface bridge filter print stats
Ensure the accept rules for known MACs appear before the drop rule.
Remember to add MAC entries for the router’s own interfaces if they forward traffic through the bridge.

Performance impact on hardware-offloaded bridges

On CRS switches with hw-offload=yes, enabling use-ip-firewall=yes moves bridge traffic to the CPU for filter processing. Monitor CPU usage after enabling.
Consider whether DHCP static-only + firewall address-list rules (Layer 3) are sufficient, avoiding the need for bridge filters entirely.