Technical Tip: Caution regarding udp_flood Anomaly for DoS Policies on FortiGate

[pjang]

Description	This article describes the udp_flood anomaly, its method of operation, and why it is the most likely anomaly present within Denial of Service (DoS) Policies that will cause false positives and impacts to end-users. This article will also aggregate the many articles available that touch upon the udp_flood Anomaly, and it will also offer guidance for how to use this Anomaly responsibly. Note that this article assumes that users are generally familiar with DoS Policies. Refer to the following documentation for a primer on DoS Policies on the FortiGate: DoS policy.
Scope	FortiGate, DoS Policy
Solution	First and foremost: do not enable the Block action for the udp_flood Anomaly until the Monitor action has been used to sufficiently tune the Threshold. Enabling udp_flood blocking on the WAN interface without adjusting the default thresholds will almost-certainly result in impacts to user traffic, particularly UDP-based traffic like DNS and any VoIP traffic (SIP, Microsoft Teams, Zoom, etc.) What is udp_flood, and how does it work? The udp_flood Anomaly tracks the number of incoming UDP packets per second that are going to a given Destination IP address, and it triggers if that traffic exceeds the threshold configured within the DoS Policy. This means that the udp_flood anomaly is useful for identifying and blocking attackers that use one or more sources to send a high volume of UDP traffic towards the FortiGate (for example, a DNS amplification attack). Notably, there are a few critical points to consider for this specific Anomaly: The udp_flood Anomaly does not take into account stateful session information on the FortiGate (i.e., it will not exempt traffic even if it belongs to a session matching an allow Firewall Policy). Refer to Technical Tip: Identifying packet drops caused by DOS Policy for an explanation of why this behavior exists. By extension, it also does not take into account any NAT'ing that is occurring for a given stream of traffic. The DoS Policy will only look at the raw Source and Destination IP addresses as they appear in the packet when arriving on the FortiGate network interface. Finally, the default threshold setting for udp_flood is only 2000 packets-per-second (pps). Why can udp_flood result in false-positives? At the time of this writing, the vast majority of enterprise networks today are still predominantly using IPv4, which means that Source NAT is almost always being applied for traffic flowing from the corporate LAN out to the Internet. This also means that for any given session (e.g., a client device connecting to an Internet server), two sets of traffic are incoming from the FortiGate's perspective: Incoming on the LAN interface is traffic sourced from the client's private IPv4 address and destined for the server's public IPv4 address. Incoming on the WAN interface is traffic sourced from the server's public IPv4 address and destined for the FortiGate's public IP (either the interface IP, IP Pool, or Virtual IP address). In the latter case (incoming to WAN interface), the first part of the problem can be seen: many unique sessions from different clients going out to the Internet will inevitably result in reply traffic being destined for a singular (or relatively small set) of public IP addresses assigned to the FortiGate. The second part of the problem occurs when users are frequently utilizing UDP-based services on the Internet. While TCP is utilized for applications that trade latency for reliable packet delivery, UDP is utilized by applications that can tolerate minor packet loss but are much more sensitive to latency and overhead. This is why the udp_flood Anomaly disproportionately affects VoIP applications (e.g., Microsoft Teams, Google Meet, Zoom, etc.,) when it comes to false-positives, as these applications prefer to utilize high volumes of small-sized UDP datagrams when handling audio and video traffic (since UDP is much more performant in these use-cases compared to TCP). This problem can also be observed with DNS traffic sent out to the Internet, as well as with HTTP/3 (aka QUIC) based web traffic. For example, consider the following log sample. Note how the Source IP is 1.1.1.1 (Cloudflare) and Source Port is 53 (DNS), which is counter to typical expectations given that this was triggered by a client making a DNS request out to Cloudflare (the threshold was set to only 5 pps for demonstration purposes): date=2025-09-09 time=12:23:36 eventtime=1757445816755223619 tz="-0700" logid="0720018432" type="utm" subtype="anomaly" eventtype="anomaly" level="alert" vd="root" severity="critical" srcip=1.1.1.1 srccountry="Australia" dstip=100.64.0.1 dstcountry="Reserved" srcintf="wan1" srcintfrole="wan" sessionid=0 action="clear_session" proto=17 service="udp/50736" count=17 attack="udp_flood" srcport=53 dstport=50736 attackid=285212772 policyid=1 policytype="DoS-policy" ref="http://www.fortinet.com/ids/VID285212772" msg="anomaly: udp_flood, 6 > threshold 5, repeats 17 times since last log, pps 6 of prior second" crscore=50 craction=4096 crlevel="critical" What can be done to prevent false-positives with udp_flood? Generally speaking, there are a few different approaches that can be taken when addressing udp_flood in DoS Policies, though these approaches are useful across the many different Anomalies: Option 1: Measure the udp_flood thresholds and increase them to above typical network usage. Start by setting the udp_flood Anomaly to Monitor and toggle-on Logging. The FortiGate will now start generating logs whenever the udp_flood Anomaly threshold is exceeded (viewable under Log & Report -> Security Events -> Anomaly), though it will not block any traffic. Whenever a log entry is generated, increase the threshold by coarse amounts (e.g., increase by 10000 or 100000) and then monitor for further log entries. When the log entries are no longer being produced during typical busy hours for the site, decrease the threshold by fine amounts (e.g. decrease by 1000) until the log entries start to be produced again. Once the border threshold has been determined, increase the udp_flood threshold beyond this point by a healthy margin. This should generally ensure that regular UDP traffic will not trigger the threshold, but at the same time, anything significantly beyond this point (such as an attack) can be caught and dropped. Option 2: Disable blocking of udp_flood. In some cases, the typical usage of UDP traffic on the network may be too variable to set a particular threshold value. In those cases, it may be easier to simply set the udp_flood Action to either Disable or Monitor so that it does not block traffic at all.  Option 3: Modify the DoS Policies to handle known traffic differently. If an application uses a specific set of UDP ports or server IP addresses, then it is possible to define a separate DoS Policy that matches this traffic. This would allow different settings for the Anomalies compared to traffic hitting the main DoS Policy (e.g., disable udp_flood for Microsoft Teams traffic, but enable udp_flood for all other cases). For more specific guidance for certain applications, as well as more information on DoS Policies in-general, consult the Related Articles section below. Related articles: Technical Tip: Using Microsoft Teams with DOS Policy Technical Tip: Using Zoom with IPv4 DoS Policy Technical Tip: DoS policy on WAN interface can cause slowness in IPsec throughput or block IPsec tr... Troubleshooting Tip: User DNS communication fails randomly Technical Tip: DoS attack log according to action set on DoS policy Troubleshooting Tip: How to set DoS policy exceptions Technical Tip: Identifying packet drops caused by DOS Policy Technical Tip: FortiGate - UDP Flooding Attack is blocked but amount of traffic does not decrease