Priority of Local In Policy and IPv4 DoS Policy

[wotik]

Hello
Which rules: "Local In Policy" or "IPv4 DoS Policy" have higher priority in filtering traffic and should be activated first?
It makes sense to me that the "Local In Policy" rules should work first. If some network traffic is detected and stopped in "Local In Policy", it should not reach the "IPv4 DoS Policy" module anymore...
However, that's probably not the case...
I have a rule in "Local In Policy" that blocks network traffic by geolocation (Russia, China, etc). In "IPv4 DoS Policy" I tested only one rule with very small values (e.g. 1, 5) of anomaly thresholds and a "Monitor" action (does not block) to see if any network traffic comes here.
In Fortianalyzer, however, I observe that the rule in "IPv4 DoS Policy" captures network traffic that should not be allowed by the "Local In Policy" module, i.e. network traffic from countries such as Russia, China, etc.
I gave here an example of blocking after geolocation, but the same behavior is also in the case of attempts to block specific IP addresses.
Have I configured something incorrectly?

[pminarik · Accepted solution]

The "Parallel Path Processing" (or "Life of a Packet") document will give you the answer.

https://docs.fortinet.com/document/fortigate/6.4.0/parallel-path-processing-life-of-a-packet/86811/p...

Specifically:

[wotik]

Hi

Thanks for providing the source of information.
So it's exactly the opposite of what I thought... ;)
I understand that for version 7.2.3 it is analogous (I can't find a reference for this version)?

P.S. You may know the solution to the problem described here?

[pminarik]

Yes, the 6.4 version is the latest, but there hasn't been any change since then, so it applies to 7.2 as well.

Regarding the P.S.: threat-feeds are not automatically applicable everywhere, only where they've been allowed to be used (by development, and ultimately by project management). You can reach out to your Fortinet sales contact to let them know that you are interested in this being implemented in the future. (there's an existing feature-request for it, but it has not been actioned yet)