UDP flood attacks & false positives

GePo

A long time, in our Firebox's Default Packet Handling, I enabled the defaults without thinking much of it — including 1,000 packets/second for UDP.

Our organization relies on UDP for lots of SRT-based remote desktop access (not RDP), 4K video streaming, and IBM FASP UDP-based file transfers.

Last week, we had an internet outage, caused by losing DNS. After analyzing our Firebox logs with Watchguard's help, it turned out that a video streaming test we ran, triggered the UDP flood protection.

This has me looking at this feature, of course. What actually confuses me is… For file transfers alone, we routinely upload/download 350Mb/s, if not multiples of that. At 1500 MTU, that's 30,000 packets per second. And we've been running those smoothly for years, on the Firebox, with Default Packet Handling at 1K packets/sec enabled.

Similarly, while troubleshooting the DNS drop I rebooted our Firebox, and now the same video streaming test went fine. We upped it to 8x30Mbps UDP streams (20K packets/sec) while the CDN provider monitored the data streams, and all was well.

The math doesn't add up: How come this flood protection doesn't trigger all the time??

james.carson

Hi @GePo
I can't really answer that question fully without having a look at your actual network traffic. You probably aren't tripping the thresholds.

The default threat protection numbers are a best guess at what would be normal, and is used across the product line (you'll see the same settings on a NV5 to a M5800.)
What generally happens when UDP flooding is triggered, is that the subsequent reconnection attempts will trigger it again on the next tick (one second in this case.) Without seeing the traffic that was being triggered, that would be my best guess at what happened.