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]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
Solved! Go to Solution.
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
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
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
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.
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.
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...
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.
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.
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
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
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.
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
mgrell wrote:Thanks for this! We were able to disable the broadcast and our issue was resolved. Appreciate this forum.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
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1688 | |
1087 | |
752 | |
446 | |
227 |
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.
Copyright 2024 Fortinet, Inc. All Rights Reserved.