DHCP for the firewall operator

Most firewall operators have configured DHCP at some point. Few have thought carefully about what happens when DHCP is broken. This lesson covers DHCP at the depth the operator needs to debug the production failures.

The DORA exchange

DHCPv4 uses a four-step exchange: Discover, Offer, Request, Acknowledge.

Client                                          Server (OPNsense)
  | --- DHCP Discover (broadcast) ----------->       |
  | <-- DHCP Offer 192.0.2.50, lease 1h, GW .1 ---   |
  | --- DHCP Request 192.0.2.50 --------------->     |
  | <-- DHCP Acknowledge, lease confirmed -----      |

The Discover is a broadcast — every DHCP server on the segment hears it. The Offer comes back unicast from the server that wins. The client Request is a broadcast to tell every server who offered “I picked this one”. The Acknowledge completes the lease.

For DHCP to work across a router (which does not forward broadcasts by default), you need a DHCP relay. The relay agent on the router side receives the broadcast, unicasts it to the configured DHCP server, and unicasts the response back to the client. OPNsense can be either the DHCP server or the relay agent (under Services → DHCPv4 → Relay).

Lease lifecycle

A DHCP lease has three timings:

• Default lease time — how long a fresh lease is given (typically one hour).
• Maximum lease time — the longest lease the server will give (typically one day or one week).
• Renewal (T1) — when the client first attempts to renew (default: 50% of the lease time).
• Rebinding (T2) — when the client broadcasts to any server (default: 87.5% of the lease time).

The firewall operator’s choice of lease time matters. Short leases (15 minutes, 1 hour) are good for transient clients (guests, DHCP-by-MAC rollouts) but generate more traffic and stress the server. Long leases (1 week, 30 days) reduce load but mean new DNS or routing changes take longer to reach clients.

Reservations and static mappings

A reservation (also called “static mapping” in OPNsense) is a permanent DHCP lease tied to a MAC address. The client still uses DHCP, but the server always gives it the same IP.

Reservations are the right tool when:

• A server needs a fixed IP for documentation, firewall rules, monitoring, or external DNS.
• The network manager wants central control of IP assignments rather than configuring every host’s network stack.

Reservations are not the right tool when:

• The host moves between networks (laptops) — use a regular lease.
• The MAC address is unpredictable (some virtualisation environments generate new MACs on every boot) — the reservation will not match.

DHCPv6 — a different protocol

DHCPv6 is not an extension of DHCPv4; it is a different protocol. The same OPNsense service handles both, but the message exchange, ports, and lease semantics are different.

The relevant differences:

DHCPv6 uses DUID, not MAC, as the stable identifier. A DUID is built from a timestamp + MAC (DUID-LL) or from an opaque identifier chosen by the host at install time. The operator who copies a host’s MAC and uses it for a DHCPv6 reservation will be disappointed — the host identifies itself by DUID, not MAC.

Common DHCP failure modes