DHCP client false positive for IP address conflict

[Randall_Farr]

I have an FGT60D running DHCP on the Internal interface serving IP addresses to about 120 clients. Every few weeks someone using Windows will report to me that they are seeing a pop-up message that they have an IP address conflict. This happened this morning to a Windows 7 client. Running ipconfig shows the client has an address of 192.168.1.136 and does not change, however, the Fortigate system log shows that they are requesting a new IP address about every 10 seconds. The log shows the following events:

[ol]

DHCP client sends a DHCPDISCOVER

DHCP server sends a DHCPOFFER and offers a lease

DHCP client sends a DHCPREQUEST and requests for the given lease

DHCP client accepts the given lease and sends a DHCPACK

DHCP client detects an IP conflict with the given lease and sends a DHCPDECLINE[/ol]

On the client system I've tried a release/renew, as well as deleting the network adapter from the device manager and rebooting, allowing the network adapter to be auto-installed on system boot. Neither of these resolved the issue.

Has anyone run into this scenario before?

thanks

[mgrell · Accepted solution]

Not sure if this is the same issues I saw after an upgrade to v.5.2, but I had a Microsoft Server as the DHCP server and was getting the DHCP server filled up with badaddress. What solved the problem for me was to disable broadcast suppression on the wifi on the router. I did open a case with fortinet and they confirmed this was a bug.

Here is the command to disable the broadcast suppression

config wireless-controller vap   edit wifi unset broadcast-suppression   next end 

[echo · Accepted solution]

Thank you for this. I was suggested doing that first (unset broadcast-suppression) and if it won't help, then also this:

config system interface edit <interface> set vlanforward disable next end

I understood that this should be done in all interfaces, but it looks strange, why all. Anyway, by the cli reference, there are many suppression types available to set and the defaults are dhcp-up and arp-unknown.

I wasn't told this was a bug. But this really looks like one and has caused us so much trouble. If something so elementary as DHCP is faulty, then how can we consider these devices suitable for business?

mgrell wrote:

Not sure if this is the same issues I saw after an upgrade to v.5.2, but I had a Microsoft Server as the DHCP server and was getting the DHCP server filled up with badaddress. What solved the problem for me was to disable broadcast suppression on the wifi on the router. I did open a case with fortinet and they confirmed this was a bug.

Here is the command to disable the broadcast suppression

config wireless-controller vap edit wifi unset broadcast-suppression next end 

[qxu_FTNT · Accepted solution]

This was an known issue that needs fix in both FOS and FAP sides. It had been fixed in FOS 5.2.3 B0670 or later and FAP 5.2.3 B0234 or later.

[ewhiteway]

I've had this now at 5 different sites, and different models / firmware.    I'm glad I searched "Badaddress fotinet".

I will try the fixes mentioned - the most recient unit is newest firmware, so still a bug (with 2013r2 HDCP server, on wire with a bridged wireless)

[ewhiteway]

It was the Vlan suppression that I needed to change.

Looking back, we added a phone Vlan, and by default we just set the switch to egress phone vlan on all ports.  The Fortinet must be receiving those on the phone vlan and doing something with them causing the problem.

As soon as I did the vlan suppression on the port connected to our main internal switch, the problem went away.