The DHCP server is failing to assign IP addresses to clients because it’s not receiving their DHCPDISCOVER messages.

Cause 1: DHCP Relay Agent Misconfiguration

  • Diagnosis: On your router or L3 switch acting as a DHCP relay, check the DHCP relay configuration. You’re looking for a line similar to ip helper-address 192.168.1.10 (where 192.168.1.10 is your DHCP server’s IP). Ensure this command is present and pointing to the correct DHCP server IP address. If it’s missing or incorrect, DHCPDISCOVER packets won’t be forwarded to the server.
  • Fix: Add or correct the ip helper-address command on the L3 interface facing the client subnet. For example, ip helper-address 192.168.1.10.
  • Why it works: The ip helper-address command is a Cisco IOS feature that specifically tells the router to forward broadcast packets, including DHCPDISCOVER, to the specified unicast IP address (your DHCP server). Without it, the router drops these broadcasts.

Cause 2: DHCP Server Not Running or Unreachable

  • Diagnosis: On the DHCP server itself, check the status of the DHCP service. For Windows Server, open services.msc and look for "DHCP Server." Ensure its status is "Running." For Linux, use systemctl status isc-dhcp-server (or equivalent for your distro). Also, from a client machine, try pinging the DHCP server’s IP address (e.g., ping 192.168.1.10).
  • Fix: Start the DHCP service if it’s stopped. If it’s running but clients can’t reach it, troubleshoot network connectivity between clients and the server (firewall rules, routing issues).
  • Why it works: If the DHCP server process isn’t active, it can’t listen for or respond to any DHCP requests. Network reachability is fundamental; if the server’s IP is unreachable, clients can’t send requests to it.

Cause 3: IP Address Pool Exhaustion

  • Diagnosis: On the DHCP server, check the scope configuration for the subnet in question. Most DHCP server interfaces will show you the total number of addresses in the pool and how many are currently leased. For Windows Server, open the DHCP console, expand your server, expand IPv4, right-click the scope, and select "Properties." Look at the "Address Pool" tab. For Linux, examine your /etc/dhcp/dhcpd.conf file and compare the range directive with the number of active leases shown by dhcpstat -l or omapi commands.
  • Fix: Increase the size of the IP address pool by extending the range or adding a new, larger scope. For example, change a range from 192.168.1.100 to 192.168.1.200 to 192.168.1.100 to 192.168.1.250.
  • Why it works: DHCP works by handing out addresses from a predefined pool. If all available addresses are leased out (or reserved for static assignments), the server has no more addresses to give, and new clients will fail to obtain one.

Cause 4: Firewall Blocking DHCP Ports

  • Diagnosis: Check firewalls on the DHCP server, client machines, and any intermediate network devices. DHCP uses UDP port 67 for server requests and UDP port 68 for client replies. A common mistake is blocking inbound UDP port 67 on the server or blocking UDP port 68 on the client.
  • Fix: Ensure that UDP port 67 is allowed inbound to the DHCP server and that UDP port 68 is allowed inbound to the client. For Windows Server, add inbound rules in "Windows Defender Firewall with Advanced Security." For Linux, use iptables or firewalld commands (e.g., firewall-cmd --add-port=67/udp --permanent and firewall-cmd --reload on the server).
  • Why it works: DHCP packets are sent over UDP. If a firewall is configured to block these specific ports, the DHCPDISCOVER (client to server, UDP 67) and DHCPOFFER (server to client, UDP 68) messages will be dropped, preventing the lease process.

Cause 5: Incorrect Subnet Mask or Default Gateway Configuration

  • Diagnosis: While not directly a "lease failed" error from the DHCP server, clients failing to get an IP can be a symptom if the DHCP server is configured with incorrect subnet information for that client’s network segment. Check the subnet mask and default gateway settings on the DHCP server’s scope options. Ensure they match the actual network configuration. For example, if clients are on 192.168.1.0/24, the subnet mask should be 255.255.255.0 and the gateway 192.168.1.1.
  • Fix: Correct the subnet mask and default gateway options within the DHCP scope properties on the server.
  • Why it works: The DHCP server provides not just an IP address but also essential network configuration parameters. If these parameters are incorrect for the client’s physical network segment, the client may not be able to communicate effectively, leading to perceived lease failures or connectivity issues after an IP is assigned.

Cause 6: MAC Address Filtering on Network Devices

  • Diagnosis: Check any access points, switches, or firewalls that might be performing MAC address filtering. If a client’s MAC address is not on an allowed list or is on a blocked list, it might prevent the DHCPDISCOVER packet from reaching the DHCP server or prevent the DHCPOFFER from returning.
  • Fix: Add the client’s MAC address to the allowed list on the relevant network device’s configuration.
  • Why it works: MAC filtering is a security feature that restricts network access to only devices with pre-approved hardware addresses. If a client is filtered out at this layer, its DHCP requests will never be processed.

The next error you’ll likely encounter after fixing this is a "DHCP address conflict" if the DHCP server is handing out addresses that are already in use by statically assigned devices.

Want structured learning?

Take the full Computer Networking course →