Repeating ARP requests from Fortigate every 1 second

[FortigateUser1]

I am seeing some strange ARP requests from our Fortigate using Wireshark. I'm not sure the best way to describe it. It's as if the Fortigate has a cooldown of 1 second in between ARP requests. So when a device doesn't respond, it keeps sending requests exactly every 1 second. The IPs that it's trying to contact appear to be random DHCP devices that joined the network and then left. The IPs that it's trying to contact do change some over time. It's like it has a list of the last 10 devices that it can't find and just keeps repeating those until other devices leave the network. I've checked the ARP table on the Fortigate while it's sending these ARP requests and the IPs it's sending the requests to are not in the ARP table. It's not a network loop. No other devices are showing this kind of behavior.

The amount of traffic generated by this isn't causing network disruptions, but I don't want the Fortigate to be this noisy. Any thoughts?

[abarushka]

Hello,

There could be another device in the network which is trying to reach DHCP client device which has already left the network. You may consider to sniff the traffic using DHCP client device IP address as a filter.

[AEK]

As Abarushka said, probably someone from another network trying these disconnected hosts, and probably caused by continuous ping requests (1 second interval).

[FortigateUser1]

I tried testing this by pinging other clients and was not able to replicate the issue. But the theory of pings makes a lot of sense due to the 1 second interval between the ARP requests. I'll maybe have to look into if there are any features on the firewall that would result in it trying to ping clients. Thank you for your thoughts!

[FortigateUser1 · Accepted solution]

I ended up opening a support ticket about this as I was curious as to what was going on. Support was able to narrow down the issue. Occasionally a few devices will disconnect from the network before closing their open TCP sessions. The Fortigate will continue to probe these devices until the session time-to-live runs out. Since the device isn't on the network, the device is removed from the Fortigate ARP table. This results in every probe from the Fortigate sending an ARP request because it's no longer in the ARP table. The default session TTL is 60 minutes and the default ARP reachable time is 30 seconds. This means you can end up getting ARP spam for about an hour for each device that has sessions open but is unreachable.

Unfortunately, support said this was the expected behavior. I don't remember having this issue with our Sonicwall. The only "solution" I've found is to lower the default session TTL and/or increase the ARP reachable time on the Fortigate. Doing so will prevent the client from being dropped from the ARP table before the session TTL runs out, thus no ARP spam. I'm not sure what consequences there could be from changing these values, so be mindful of that before you start messing with them.

[AEK]

Thanks for sharing.. Indeed I'd change TTL with caution.

[DPadula]

Hi there,
Can you share with us the screen shot of the wireshark capture?

[FortigateUser1]

There really isn't much to show. All I see is that the Fortigate sends ARP requests to about 10 to 20 different IPs once every second for long durations of time. When you sort the packet capture by the "info," you'll quickly see 99% of the ARP requests are repeating. There is some normal ARP traffic, but not much.

Fortigate support and I confirmed that this is from devices that have open TCP sessions but have left the network. As soon as support cleared the TCP sessions, the ARP requests stop for that device. I never noticed any patterns to which devices this occurs with. Perhaps it's phones or laptops roaming from the wifi or going into sleep mode before properly closing the TCP sessions.

The amount of ARP spam depends on the amount of devices that have the problem. Each devices equal 1 packet per second ARP requests. This isn't a huge amount, but it depends on how many devices it happens to and how often.

I've confirmed that setting the session TTL lower and the ARP reachable time higher than the session TTL eliminates the repeating ARP traffic.