Technical Tip: Local-in policies do not block DHCP requests on FortiGate

[amalsky]

Description	This article describes why a local-in policy does not block Dynamic Host Configuration Protocol (DHCP) requests on a FortiGate firewall. This is not a FortiGate product limitation, but rather a result of how the FortiOS kernel processes broadcast and system traffic. It also clarifies the supported methods for properly disabling or restricting the DHCP service on FortiGate interfaces.
Scope	FortiGate.
Solution	Purpose of Local-in Policy: Local-in policies are designed to control traffic explicitly destined to a FortiGate interface IP. Typical use cases include: Restricting management access (HTTPS, SSH, SNMP). Controlling routing protocol sessions (BGP, OSPF). Filtering ICMP or other unicast services directed to the FortiGate. Mostly unicast traffic addressed to the FortiGate’s own IP is evaluated by the local-in policy engine. Why DHCP Requests Bypass Local-in Policy: Broadcast nature of DHCP:  DHCP Discover and Request packets are broadcast at both Layer 2 (MAC ff:ff:ff:ff:ff:ff) and Layer 3 (destination IP 255.255.255.255). Kernel-level processing: The FortiGate DHCP daemon, dhcps, listens for these broadcasts at a low-level kernel hook. The daemon consumes packets before they reach the local-in policy chain. Result: Local-in policies never evaluate DHCP client requests. Clients continue to receive addresses even when a local-in rule is configured to block DHCP. This design ensures DHCP service remains available and avoids accidental disruption of critical system functions, such as: Built-in DHCP server or relay High Availability (HA) heartbeats Routing protocol hellos and keepalives. Verification steps: Configure a local-in policy to deny all traffic to an internal interface: config firewall local-in-policy     edit 1         set intf "port2"         set srcaddr "all"         set dstaddr "all"         set service "ALL"         set action deny     next end From a client, test unicast traffic (e.g., ping the FortiGate). The ping fails, confirming the local-in policy is active. From the same client, request a new DHCP lease. The client still receives an IP address.   Verify no hits appear against the DHCP-blocking policy: diagnose firewall iprope show 100001 <policy id> Correct methods to disable DHCP on FortiGate: If the DHCP service is not desired, use one of the following supported options: Disable the DHCP server: config system dhcp server     edit <ID>         set status disable     next Delete the DHCP server configuration: config system dhcp server     delete <ID> end The following shows the command and output to identify the DHCP server ID. Prevent accidental re-enablement: Ensure that templates, automation scripts, or FortiManager do not unintentionally reapply DHCP settings. Note: Disabling 'dhcp-relay-service' under an interface affects only relay, not the built-in DHCP server. Packet flow diagram: Unicast traffic like SSH/HTTPS/ICMP reaches here. However, DHCP broadcasts never reach this stage. Conclusion: A local-in policy cannot block DHCP requests because DHCP traffic is broadcast-based and consumed by the DHCP daemon at the kernel layer before reaching the local-in policy engine. This behaviour is inherited from Linux kernel design and ensures the reliability of core services. To stop FortiGate from assigning IP addresses, administrators must disable or delete the DHCP server configuration directly. Local-in policies are not a supported mechanism for controlling DHCP traffic.