DHCP scope and pool design — address range, gateway, DNS, lease time

A DHCP scope is the configuration the operator writes for a subnet. The pool boundaries decide which addresses can be assigned automatically; the gateway and DNS advertised via DHCP decide where clients send their traffic; the lease time decides how long a client can hold an address without renewing. A well-designed scope is invisible. A poorly-designed scope is the source of half the connectivity incidents in the production runbook.

This lesson covers the four things the operator must decide for each scope — pool, gateway, DNS, lease time — and the reserved ranges inside the subnet that keep static addressing working.

Scope boundaries

The pool boundaries are the start and end of the range the DHCP server hands out. Two principles:

1. The pool must fit inside the subnet. A pool that spans two subnets (e.g. 192.168.1.100 to 192.168.2.200) is wrong; clients on either subnet get addresses that may not be reachable.
2. The pool must leave room for static addresses. Printers, network gear, servers, and any other device with a manually-assigned address need IPs that are not in the pool.

For a typical /24 subnet (192.168.1.0/24):

The convention varies; the discipline is to write it down, apply it, and never change it casually. The reserved range for static addressing is the part most often violated — an operator adds a new printer at 192.168.1.100 (in the pool) and a future lease hands that address to a laptop. The result is the laptop failing to communicate and the operator debugging a phantom IP conflict.

$ grep -A1 'range' /var/dhcpd/etc/dhcpd.conf | head -10

subnet 192.168.1.0 netmask 255.255.255.0 {
  range 192.168.1.100 192.168.1.250;
  option routers 192.168.1.1;
  option domain-name-servers 192.168.1.1;
  option domain-name "lan.example.com";
  default-lease-time 3600;
  max-lease-time 86400;
}

The gateway option

The DHCP option routers (option 3) carries the default gateway the client should use. For an OPNsense firewall on the LAN at 192.168.1.1, the gateway option is 192.168.1.1.

Three things can go wrong:

1. Wrong gateway. The operator configures 192.168.1.254 (the old firewall’s address) and clients cannot reach the Internet. Always verify the gateway option matches the firewall’s actual LAN address.
2. Gateway outside the subnet. The gateway must be on the same subnet as the clients. A client on 192.168.1.0/24 with a gateway of 192.168.2.1 cannot ARP the gateway and cannot send default-routed packets.
3. Multiple gateways advertised. Some operators try to advertise two gateways for redundancy. DHCP only supports one; for failover, the operator needs HA (CARP) or gateway groups.

The right answer for HA: CARP. The two firewalls share a virtual IP; DHCP advertises the CARP VIP as the gateway. Clients see one gateway; the active firewall responds.

The DNS option

The DHCP option domain-name-servers (option 6) carries the DNS servers clients should use. For an OPNsense firewall running Unbound, the typical configuration is:

• Primary DNS: the firewall’s LAN address (e.g. 192.168.1.1). Clients query Unbound, which resolves recursively.
• Secondary DNS: a public resolver (e.g. 1.1.1.1 or 8.8.8.8) for redundancy if Unbound fails.

The two-DNS pattern is widely deployed. The discipline: the primary must respond; the secondary is a fallback that adds an external dependency. Many operators use only the firewall’s address and rely on Unbound’s reliability.

For an estate with internal DNS (Windows AD, internal-only zones), the operator points DHCP at the internal DNS server, not at the firewall. The firewall’s Unbound is configured to forward to the internal DNS for internal zones.

The domain name option

The DHCP option domain-name (option 15) carries the DNS search domain. For a LAN named lan.example.com, the option is lan.example.com. Clients append this to unqualified hostnames before querying DNS.

The option must match the actual DNS configuration. If the operator sets domain-name "lan.example.com" but the DNS server serves a different zone, clients append the wrong suffix and resolve internal hostnames incorrectly.

Lease time

Three lease-time knobs:

• default-lease-time: the lease time given to a new client with no preference.
• max-lease-time: the longest lease the server will give, regardless of client request.
• min-lease-time: the shortest lease the server will give, regardless of client request.

The tradeoffs:

The right default for most production LANs: 1 hour default, 24 hours maximum. This is short enough that DNS changes propagate within an hour, long enough that the DHCP server is not overloaded.

Reserved ranges

Three ranges should be reserved inside the subnet, outside the DHCP pool:

1. Static infrastructure. Firewall, switches, routers, access points, printers, servers. These have manually-assigned addresses.
2. DHCP reservations. Hosts that need a fixed address (servers, monitoring agents, voice-over-IP phones). The reservation ties the address to a MAC.
3. HA / future use. CARP VIPs, gateway group addresses, future subnets, monitoring tools. Keep some space free.

The reserved ranges are documented in the runbook. When the operator adds a new static device, they pick from the reserved range, not from the pool. When the operator adds a new DHCP reservation, they pick from the reserved-for-reservations range.

The discipline: the reserved ranges never overlap the pool. The pool is exactly what DHCP can hand out. Static and reservation ranges are exactly what DHCP cannot hand out.

Scope sizing

For a /24 subnet with 254 usable addresses, typical scope sizing:

The pool is sized larger than the expected device count to leave headroom for guests, BYOD, and forgotten devices. A pool of 50 in a /24 is reasonable for a small office; a pool of 200 in a /24 is reasonable for a large office. The reserved ranges shrink as the pool grows; the discipline is that the reserved ranges exist and are documented.

Common scope failure modes

Five failure modes appear repeatedly:

1. Pool exhaustion. More devices than the pool can serve. Symptom: clients get APIPA addresses (169.254.x.x). Fix: expand the pool or add a second subnet.

2. Pool overlaps static addresses. The printer is at 192.168.1.100; the pool is 192.168.1.50 - 192.168.1.200. Symptom: printer intermittently unreachable; clients sometimes get 192.168.1.100. Fix: move the printer out of the pool range.

3. Wrong subnet mask. The scope is configured with a /16 mask on a /24 subnet. Symptom: clients get addresses that are not on the right segment. Fix: align the subnet mask with the actual subnet.

4. Gateway typo. The gateway is set to 192.168.1.10 instead of 192.168.1.1. Symptom: clients can reach local hosts but not the Internet. Fix: correct the gateway.

5. Lease time too long for the workload. A 7-day lease in a guest network means guests who leave keep their addresses. Symptom: pool exhaustion from stale leases. Fix: reduce the lease time for guest networks.

Summary

• A DHCP scope has four critical parameters: pool boundaries, gateway, DNS, lease time.
• The pool must fit inside the subnet and leave room for static and reserved ranges.
• The gateway must be the firewall’s LAN address; for HA, use the CARP VIP.
• Lease time tradeoffs: short leases propagate changes faster; long leases reduce server load. 1 hour default, 24 hour maximum is a sensible production default.
• Reserved ranges for static and reservations are documented and never overlap the pool.
• Verify the scope by reading /var/dhcpd/etc/dhcpd.conf after each GUI change.