I replied to your other post too early (btw please don't do separate posts for the same issue like this, it makes everything far more confusing when people come across your post with the search functionality).
So what you're showing is that your policy is getting hit, but I think you're getting the different policy types mixed up. Your classified profile accounts for one IP hitting the alarm activate or max values. It appears per your previous comments and your expectation of how you expect this to function would dictate that you actually wish to setup an aggregate policy instead of a classified. The section that you've highlited saying there is 610 sessions is the total session count for this policy. As you've configured it unless one of the sole source IPs hit above 180/s. The highlited rate of 15 that you've pointed out also doesn't come close to actually triggering your policy as configured.
The difference here is that you're currently limiting a sole source ip from hitting the target destination at the specified rates. That means that 172.16.1.1 gets 180/s and then 172.16.1.2 gets 180/s but collectively the firewall as you currently have the policies set don't care how many sessions collectively occur. If you switched this to an aggregate then it would be all traffic is only allowed to get to a specified rate.
Once you've actually triggered the policy limit you can find the information in the threat logs when using the query ( subtype eq flood ), where you will see either 'Session Limit Event' if you've hit a resource limit or a variation of 'TCP/ICMP/UDP Flood' to indicate if you've hit a connection rate limit.
Again I would expect with your specified rate limits what you're actually looking for is an aggregate policy. If you aren't looking at an aggregate ppolicy and you actually want a classified policy, there is currently no provided results that your hitting the values you've set in the profile.
Sorry for duplicate threads. You can delete the another one.
The point is that we can see that the policy DoS is getting hits. But we dont see any threat events type "flood" when we launch j-meter.
So it could be that flood threat event is only generated with "zone protection" limit, and not with DoS policy?????
Should DoS limit SYN obverloaded generate an event in threat logs??
Right... again 'hits' against the profile are not the same as actually triggering the DoS protection. You keep talking about jmeter, but you haven't actually shown that you know that jmeter is actually launching enough traffic to trigger your DoS profile. Simply lowering your connection 'alarm' rate would allow you to verify/see that the DoS policies are working as expected and see exactly the alerts that I'm mentioning in the threat logs. I'm not confident that jmeter running on one host would be able to actually generate enough sessions to trigger the policy as you have it configured, your values are simply too high for a classified policy.
Both Zone and DoS policies will trigger a log whenever either is actually activated; that's not a configurable piece, they trigger they log.
We changed the limits values lowe and it still not generating a threat food event.
We can see in counter DoS rule the number of packets matched in DoS policy that why we think the alarm should be generated.
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the Live Community as a whole!
The Live Community thanks you for your participation!