Technical Tip: DHCP service intermittently fails after ADVPN configuration

The issue has been identified as involving an interaction between the ADVPN and DHCP daemons. This article provides a description of the issue, the affected versions, a permanent solution, and a verified workaround.

Verify the issue by executing the following command and checking if the dhcpd daemon is repeatedly being killed with status 0x0:

diagnose debug crashlog read | grep dhcpd

2563: 2026-01-11 06:59:27 the killed daemon is /bin/dhcpd: status=0x0
2564: 2026-01-11 07:33:27 the killed daemon is /bin/dhcpd: status=0x0
2565: 2026-01-11 07:50:45 the killed daemon is /bin/dhcpd: status=0x0
2566: 2026-01-11 08:10:49 the killed daemon is /bin/dhcpd: status=0x0
2567: 2026-01-11 08:30:20 the killed daemon is /bin/dhcpd: status=0x0

Symptoms:
Intermittent failure of the FortiGate DHCP server to assign IP addresses to clients (both wired and wireless).

Clients fail to obtain an IP address and may default to an Automatic Private IP Addressing (APIPA) address (169.254.x.x).

On the FortiGate can see the IP address assigned to the client's MAC. 

The DHCP server logs may show requests from clients, but no corresponding offers are being sent, or the process is holding up.

Root cause analysis:
When ADVPN shortcuts are being negotiated or established, the process can intermittently hold up the DHCP daemon, preventing it from processing client requests. This results in DHCP timeouts for end-users. The problem is not related to network capacity but rather a process handling within the FortiGate's operating system.

Fix:
The issue is fixed in v7.6.6 and later. 
The reported issue observed is verified internally, and it is not observed from 7.6.6 versions or later.

Workaround:
If an immediate upgrade is not possible, a configuration workaround is available. This workaround involves disabling the auto-discovery-receiver setting on the ADVPN spoke configuration.

FortiGate CLI:

config vpn ipsec phase1-interface
    edit <your_phase1_interface_name>
        unset auto-discovery-receiver
    next
end

Note:
When auto-discovery-receiver is disabled on the spoke, the spoke will no longer learn the hub’s tunnel interface IP address (or the hub BGP loopback IP in a loopback-based design). As a result, the BGP neighborship between the spoke and hub will go down and will not re-establish automatically.

To restore BGP adjacency, the spoke must be manually configured to exchange interface IP information with the hub. This can be achieved by enabling exchange-interface-ip under the Phase1 interface configuration on the spoke.

Configuration (Spoke):

config vpn ipsec phase1-interface
    edit <your_phase1_interface_name>
        set exchange-interface-ip enable
        set exchange-ip-addr4 <Spoke_BGP_Loopback_IP>  --> Required only for BGP loopback design.
    next
end