Skip to main content
Randall_Farr
Randall_Farr
New Member
January 22, 2015
Solved

DHCP client false positive for IP address conflict

  • January 22, 2015
  • 6 replies
  • 48268 views

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

      • Best answer by mgrell

      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 

       

      6 replies

      MikeRigsby
      MikeRigsby
      New Member
      February 4, 2015

      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
      michal1
      New Member
      May 9, 2015

      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
      vsvangen
      New Member
      May 27, 2015

      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
      echo
      Explorer II
      June 9, 2015

      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
      mgrellAnswer
      New Member
      July 8, 2015

      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
      echo
      Explorer II
      July 21, 2015

      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 

       

      ewhiteway
      ewhiteway
      New Member
      July 30, 2015

      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
      ewhiteway
      New Member
      July 30, 2015

      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.

      Terms & ConditionsAccessibility statement