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

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.

DHCP bypasses a local-in-policy on FortiGate because it is processed by the system control plane (DHCP daemon) before traffic reaches the firewall or local-in-policy engines, since DHCP must function without IP addressing or routing.

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 behavior 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.