M370 struggled to keep up with packets per second
edited September 2020 in Firebox - Networking, Multi-Wan, VLAN, NAT, SD-WAN
Yesterday we had a large attack that hit our M370 Active Passive Firecluster.
The traffic was not huge in bandwidth but there was a lot of packets per second. This caused our M370’s to have kernel exceptions and a lot of packet loss as (I think) the CPU was going crazy on the units. I managed to get them both upgraded to 12.5.4 which stopped the Kernel Exceptions but the CPU was still crazy high.
The traffic was all “egp”, “pim” & “gre” packet types and got handled by our “Unhandled External Packet” policy.
This surely should not have floored our Watchguards? Support weren’t amazing as once they got on they said the CPU looked normal (which it was as the attack had subsided).
Am I missing something?
Sign In to comment.
All of the DDOS/flooding type protection is in Setup -> Default Threat Protection -> Default Packet Handling in policy manager, or Firewall -> Default packet handling in the WebUI.
(About Default Packet Handling Options)
Our defaults are at 100 connections a second, but those can be lowered as needed.
The issue for attacks like these isn't that the firewall can or can't handle the traffic, it's that they generally will consume your available throughput. The firewall won't be able to reply to traffic because it doesn't get any or all of the request to begin with.
WatchGuard Customer Support
Thanks James, so are you suggesting that the issue might be upstream of the firewall?
The CPU on the firewall was going crazy and the WebUI was pretty unresponsive at the time until I pulled the cable.
The goal of DDoS attacks is to fill up your incoming ISP link with so many packets that whatever Internet services that you host or whatever your users try to do out on the internet can't really happen.
And, depending on the type of DDoS attack, it can also overwhelm firewalls and or internal servers.
The packet types shown as denied in your post here do not look like they should overwhelm your firewall. But packets not logged may have contributed to the CPU usage that you observed.
Logging of tons of denied packets also puts a load on the firewall. So perhaps that is part of the cause of what you saw.
That makes sense actually that it could be the logging indeed. They were caught with the unhandled external packet as you can see in the screenshot above which from memory has to log and you can't turn that off.
I have created a rule now to deny that traffic at the top of the my policies. No logging and just denied with no reset. Like you say with that traffic it should be able to handle it.
You can unselect the Log setting on Default Packet Handling options, including for Unhandled External & Internal packets.
In Policy Manager: Default Packet Handling -> Logging