Sounds fair.
Though, my conclusion is, like @DN3092 and @ecs-solutions, that it is or may be still slipping through and is not working as intended. Perhaps more guidance in how to prove that it actually works as intended is needed.
I did some further testing running
curl http://testmyids.com/
from a downstream S8 Switch. If it would be working as intended, I assume the response would be blocked but it came out as OK/200.
I also modified the suricata.yaml to output the alerts to log file to get better insight into timing. The alert is timely issued. But, the connections doesn’t seem to be deleted in time. Or, at least that is my interpretation.
grep conntrack /var/log/messages and
grep ips /var/log/messages
typically says
1_Route10 daemon.alert ips: too many events (2) when i force multiple and frequent calls to testmyids.com, like if some que is saturated and it can’t handle it anymore?!
I have also seen
ips: ctfail: conntrack v1.4.6 (conntrack-tools): 0 flow entries have been deleted.
in the very near vicinity of these repeated IDS triggers. Either the reactive deletion attempt is too slow or is misdirected?!