I know this thread is a bit old but having just stumbled on it, I figured it might help to post the following. I raised a case with TAC a while ago with this very same question and here is the response:-
###########################################################
Regarding this, there are some likely causes for this behaviour:
Cause 1
When snort receives a new stream of traffic it will put packets from that stream into a queue (buffer). The packets in this queue will not be flushed to detection until one of a few things happens. The most common occurrences (but not all) of these things are:
- Snort sees enough data in the stream to determine the protocol(s) (or service(s)) in that stream. This is called protocol aware flushing (PAF).
- Snort sees the end of the stream (snort must see both the client and the server end the connection).
- Snort does not see any additional packets from that stream for 180 seconds (this is the default timeout and can be configured in the stream 5 preprocessor settings).
Before the stream is flushed to detection (while the queue is being built), snort will send the packets in the stream on the wire (so it does not delay the traffic and inject latency). Once the stream has been flushed to detection it will go through the rule evaluation. All of the packets that have already been passed on the wire (packets in the queue) for the stream are evaluated at this time. If any of the packets match a rule that is set to drop, snort will not be able to drop these packets as they have already been sent on the wire.
Cause 2
If a device is under heavy load, or the latency packet handling preprocessor is kicking in often, it can also cause this behavior. If inline normalization is enabled and you are still seeing this behavior, the next likely cause is the latency handling packet preprocessor.
In certain cases, if a packet matches a rule that is set to drop, but that packet crossed the latency packet threshold, it's possible that the packet was fast-pathed before it could be dropped. Why this happens depends on when the check is done for the packet time, and when the rule triggered.
Cause 3
Traffic passing through the sensor twice.(two different inline sets)
There are chances that when traffic is passing through sensor twice, it trigger rule with "Would have dropped". For example, a 5 packet HTTP GET request whose first packet triggers a rule is blocked the first time through the sensor, only last packet will be dropped.
The second time through the sensor, it will see only 4 packets. The connection got dropped, but when it finally flushes the partial get request because it is pruning the session, it will trigger the same rule with "Would have dropped" as the inline result.
###########################################################
Hope this helps,
Matt.
