DHCP reservations and static mappings — when to use, MAC format gotchas

A DHCP reservation is a permanent lease tied to a MAC address. The client still uses DHCP, but the server always gives it the same address. This pattern is the right tool when a host needs a stable IP — for firewall rules, monitoring, or DNS — without the operator configuring the host’s network stack manually. But reservations come with their own pitfalls: MAC-format typos, virtualisation randomisation, and the documentation discipline that keeps the host inventory from drifting.

This lesson covers when reservations are the right tool, how to enter MAC addresses correctly, and the operational discipline for keeping the host inventory accurate.

Reservations vs static addresses

Two ways to give a host a fixed IP:

1. DHCP reservation: the host uses DHCP; the server always gives it the same address. The MAC is the key; the address is permanent in the DHCP database.
2. Static IP on the host: the operator configures the IP, mask, gateway, and DNS on the host itself. The DHCP server is not involved.

The tradeoffs:

The reservation pattern is the right default for production. Centralised control means the operator can see and change every fixed IP from one place. The DHCP server dependency is acceptable in any environment where DHCP is reliable (which is the entire point of running DHCP).

The static pattern is appropriate when:

• The host is the DHCP server itself (chicken-and-egg).
• The host needs to boot before DHCP is available (PXE boot environments, network boot sequences).
• The host is on a segment with no DHCP server.

Configuring a reservation in OPNsense

The configuration is under Services → DHCPv4 → [LAN] → Reservations. The fields:

• MAC address: the host’s MAC, in the format OPNsense expects (colon-separated hex).
• IP address: the address to assign.
• Hostname: optional but recommended — makes the reservation list self-documenting.
• Description: optional — additional context.

The reservation is saved; OPNsense regenerates dhcpd.conf and signals the daemon. The next time the host requests a lease, it receives the reserved address.

MAC address format gotchas

The most common production mistake with reservations: the MAC address format. OPNsense expects the colon-separated hex format (e.g. aa:bb:cc:11:22:33). The common errors:

• Hyphens instead of colons (aa-bb-cc-11-22-33). The reservation does not match. Fix: use colons.
• Dots instead of colons (Cisco format, aabb.cc11.2233). The reservation does not match. Fix: convert to colon format.
• Spaces (aa bb cc 11 22 33). The reservation does not match. Fix: remove spaces.
• Uppercase vs lowercase (AA:BB:CC:11:22:33 vs aa:bb:cc:11:22:33). OPNsense normalises case, but some operators report issues. Best practice: use lowercase consistently.
• Extra characters (a typo, a stray digit). The reservation does not match. Fix: copy the MAC from the host’s network configuration.

The verification step: every reservation should be testable. After saving the reservation, force the host to renew (dhclient -r; dhclient on Linux; reboot on most systems). Verify the host received the reserved IP.

$ arp -an | grep 192.168.1.50

? (192.168.1.50) at aa:bb:cc:11:22:33 on igb0 expires in 1198 [ethernet]

Virtualisation randomisation

Some virtualisation platforms (VMware, VirtualBox, some KVM configurations) generate a new MAC address for a virtual NIC on every boot. The “reservation” does not survive the reboot because the host’s MAC has changed.

The fix depends on the virtualisation platform:

• VMware: set the MAC manually in the VMX file. The MAC is persistent across reboots.
• VirtualBox: set the MAC manually in the network adapter settings.
• KVM/libvirt: set the MAC manually in the domain XML.
• Cloud platforms (AWS, Azure, GCP): MAC addresses are random by default; reservations cannot be tied to MAC. Use DHCP option 82 (relay agent information) or a different identity mechanism.

The operator who deploys a VM with DHCP reservation must verify the MAC is stable across reboots before relying on the reservation. If the MAC is randomised, the reservation is useless.

The host inventory

Reservations are only useful if the operator maintains the host inventory. Three things to track for every reservation:

1. MAC address (the key).
2. IP address (the value).
3. Hostname and owner (the context).

The OPNsense reservation list shows hostname and description fields; the operator should fill them in. The list becomes the inventory of every host with a fixed IP. When a host is decommissioned, the operator removes the reservation; when the host’s IP needs to change, the operator updates the reservation.

For larger estates, an external inventory system (NetBox, phpIPAM, custom spreadsheet) tracks MAC, IP, hostname, owner, location, and purpose. The OPNsense reservation list exports to CSV for import into the inventory system.

Common reservation failure modes

Five failure modes appear repeatedly:

1. Wrong MAC format. The reservation does not match. The host gets a pool address. Fix: correct the MAC format.

2. MAC changed (virtualisation). The host was rebooted and now has a different MAC. The reservation does not match. Fix: pin the MAC in the virtualisation configuration.

3. Reservation in the wrong subnet. The reservation is configured under the LAN interface but the host is on the DMZ. The reservation does not apply. Fix: move the reservation to the correct interface’s DHCP service.

4. Duplicate reservation. Two reservations for the same MAC with different IPs. The DHCP server picks one arbitrarily. Fix: delete the duplicate.

5. Reservation for a decommissioned host. The host is gone but the reservation remains. The IP is permanently wasted. Fix: regular review of the reservation list against the host inventory.

Reservation vs static for production hosts

The decision rule:

• Use a reservation when the host is on a segment with a DHCP server and the operator wants centralised control.
• Use a static IP when the host must boot before DHCP is available, or when the segment has no DHCP server.

For most production hosts (servers, printers, VoIP phones, network gear), use a reservation. The DHCP server is the source of truth for the IP; the operator can see and change every fixed IP from one place.

Summary

• A DHCP reservation ties a MAC address to a fixed IP; the host still uses DHCP.
• Reservations are the right default for production hosts with fixed IPs.
• MAC format pitfalls are the most common reservation failure: hyphens, dots, spaces, typos all break the match.
• Virtualisation platforms may randomise MACs; pin the MAC before relying on a reservation.
• Cloud VMs cannot use MAC-based reservations; use option 82 or accept dynamic addresses.
• Document the host inventory: MAC, IP, hostname, owner. Review regularly.