Technical Tip: Investigation of missing DHCPREQUEST in Firewall DHCP Flow

[nkapse]

Description	This article describes how to troubleshoot a device that is not receiving an IP address intermittently, due to the DHCPREQUEST not received on the Firewall.
Scope	FortiGate as the DHCP server.
Solution	The flow for the DHCP process will be: DHCPDISCOVER -> DHCPOFFER -> DHCPREQUEST, and finally DHCPACK. DHCPDISCOVER: The client sends a broadcast searching for DHCP servers. DHCPOFFER: A DHCP server notifies the client that it has an IP address the client can use. DHCPREQUEST: The client responds with a request for the IP address. DHCPACK: The server returns the IP address. As a first troubleshooting step, verify the following: DHCP server settings on the firewall: Ensure the DHCP service is enabled, the correct interface is selected, and the IP pool has available addresses. Client configuration: Confirm the user's device is set to obtain its IP address dynamically via DHCP (not using a static IP). Additionally, collect the following packet capture output on the Firewall: diagnose sniffer packet any 'port 67 or port 68' 6 0 l  Or: diagnose sniffer packet <interface> '' 6 0 l <----- Enter the interface that is handing the DHCP IP lease. Debug the traffic to understand the message exchange between FortiGate and the client: diagnose debug reset diagnose debug console timestamp enable diagnose debug app dhcps -1 diagnose debug enable To stop the debug: diagnose debug reset diagnose debug disable Running the debug displays DHCP daemon output, including communication details and any errors during the process. Note: The Transaction ID will be the same for one entire DHCP flow. Thus, it can be used to filter and follow all related packets. Now, in this scenario, the DHCPDISCOVER and DHCPOFFER were visible on the packet captures collected on the Firewall. However, the DHCPREQUEST was not. Refer to the screenshot below: In this case, the issue is not with the Firewall. The Firewall successfully sent the DHCPOFFER, but did not receive the DHCPREQUEST, which it is supposed to send next. One possible reason is that another DHCP server on the network may also be responding to the client. If the client receives an offer from a different DHCP server first, it will send the DHCPREQUEST to that server instead. The user should check their network to ensure there is no unauthorised or additional DHCP server present.