IPS blocked, then allowed

[dcol]

I have IPS enabled with a custom rule which seems to trigger a block properly.
My issue is, The custom rule triggered a block, then another ET rule that also matched after that blocked the same packet.
Isn't the engine suppose to quit the packet after it matches and not continue through the rules? Is this a setting?
Here is an example of the same packet that triggered two IDS rules. Why? Should't the first one have ended the search? What if one rule is set to block and the other to allow. Which one does it follow?
The second example shows another double hit. The common element here is the User Defined GeoIP block. There must be something wrong with the GeoIP block. I think at this point I will submit a bug report to github.

[dcol]

I submitted a bug report to OPNsense git-hub and Suricata. Neither has responded, so far.

According to the Suricata manual, a drop is definitely suppose to end the chain, but in my case it does not. This has happened with many other matching rules as well. Looks like the rules engine processes all packets against every rule in its algorithm. This has to impede performance and stress to netmap.

At this point I am not sure if it is an adjustable setting in the Suricata configuration or a bug.

[dcol]

This issue is not an OPNsense issue since the same thing happens in other firewalls using Suricata.

[franco]

Hi there,

Do you have a link for future reference where the same behaviour happens on e.g. Linux?


Thanks,
Franco

[dcol]

Just tried it on a pfs box with the same results.

[franco]

Ah ok, I was hoping for a non-FreeBSD confirmation, but no worries as that is ok too.


Cheers,
Franco