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 

[MikeRigsby]

We ran into this same exact issue with a FortiWifi 40C that we're using. If you're running 5.2.2 firmware then I recommend reverting to 5.0 and resetting your device.

This looks to me like a firmware bug that is inconsistent, so it's not getting widely noticed.

[michal1]

I've recently had the same problem on multiple 60D and 60C devices when I was upgrading to 5.2.3.

For some time, after clearing leases and resetting client interfaces problem disappears, but it is annoying...

[vsvangen]

I have the same problem on 100D Firmware 5.2.2, 2 ssid bridged to local network.

*solved when I upgraded to firmware 5.2.3.  I believe this bug id caused the problem:

253652 MAC Address learning on interfaces out of the Virtual Switch may not be disabled.

[echo]

I have opened a ticket with Fortinet because this happened in many FWF30D devices that we installed recently. Perhaps few months were OK, and then it started happening in different places: IP conflicts for no apparent reason, then (as it seemed to me), FWF30D started owning the IP-address that was reserved in DHCP, using a MAC-address beginning with 88:dc:96. Just in case: has anybody seen this in connection with IP conflict problems? Has such MAC appeared in ARP table? Currently there are no conflicts, but I feel that it's a matter of time when it will happen again and cause nasty problems.

[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 

[jason_wisniewski]

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 <VAP name> unset broadcast-suppression next end 

I experienced this same issue starting yesterday and this was the solution.

[Seeeebz]

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

Hi,

We experienced the same issue today and this was the solution for us.

FortiGate 60C 5.2.3 Build670

FortiAP 210B 5.2 Build 212

[Terry]

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 

Thanks for this! We were able to disable the broadcast and our issue was resolved. Appreciate this forum.