ISP direct connect port failing to re-negotiate DHCP lease after scheduled restart
Hoping someone can shed a bit of light on this or have experienced a similar issue.
Clients are reporting external web traffic has been failing after our scheduled reboots (due to conserve mode).
ISP is a direct connect via copper or fibre to the Fortinet device through dynamic IP addressing configuration which includes a DHCP pool of one address(all configured on the ISP's side) which the Fortinet device listens for.
The port believes the information within the DHCP offer it receives has already been provided and refuses to then bind the lease. Port will receive a DHCP offer but it believes it has received the same DHCP offer information before and marks it as a conflict. A log entry of 'repeated DHCPOFFER!' is seen before the port will then set a timer e.g. 30 seconds and repeat the process again:
"timer 0x13fdb3a0(send_discover -> send_discover) will expire in 4 secs timer 0x13fdb3a0(send_discover -> send_discover) will expire in 3 secs timer 0x13fdb3a0(send_discover -> send_discover) will expire in 2 secs timer 0x13fdb3a0(send_discover -> send_discover) will expire in 1 secs timer 0x13fdb3a0 expired, take action"
Fix is to disable re-enable the Fortinet port - not really a sustainable workaround with a fair few customers on-board.
Issue exists on 61E's 100D's 300D's 500D's and 501E's running 5.4.8 1183
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.