I will just add a little more detail to the explanation to highlight the differences between inline IPS mode and the legacy IDS/IPS hybrid mode.

In legacy mode, the pcap library is used to make a copy (clone if you will) of every packet as it comes in from the NIC on its way to the pf firewall engine.  The original packet continues on to the pf firewall engine and is either passed or blocked depending on the current rules in the firewall.  Meanwhile, the cloned packet is sent over to Suricata (or Snort if using that package) for inspection against the IDS/IPS rules.  Should the cloned packet (or packets, since sometimes Suricata needs to see a group of packets before a decision can be made) be judged as “bad” by the Suricata engine, then a system call is made to insert the offending IP address from the packet into a special table in the pf firewall engine called snort2c.  IP addresses in this special table are blocked.  However, note that this decision making and subsequent insertion of the IP address into the snort2c table has happened well after the original packet (or packets if a group of packets was required to make a decision) has traversed the pf engine.  So that original packet will have already gotten past the IPS mechanism.  Packets that subsequently come through from the same IP address will now get blocked, though.  Hence I use the term “hybrid IDS/IPS” because a true IPS would never leak a packet.  A true IPS would hold up the original packet while it was being inspected, and then either pass it or drop it.  Legacy mode does not hold up the original packet.  It is allowed to continue on to the firewall while the cloned copy is used to make the decision for blocking future packets from the IP address.

With the new inline IPS mode, Suricata activates and uses the relatively new Netmap mechanism that was added to FreeBSD.  Netmap is a way for applications to create a highspeed pipe between the NIC driver layer and the rest of the system.  So packets coming and going on a given network interface must pass through the Netmap pipe.  Suricata inline-mode controls the “door” in this pipe.  Each packet stream coming from the NIC (or going to the NIC) is inspected by Suricata and a “pass” or “drop” decision is made.  If a packet is dropped, it is never forwarded on to the pfSense kernel and thus never makes it to the pf engine.  Since every single packet must traverse this Netmap pipe, there is no leakage.  No copies of the packets are made for examination.  Everything occurs with the original packet.

The downside of the new inline mode is that for now only some NIC drivers support working with the Netmap API mechanism.  So while legacy mode is pretty much NIC card and driver agnostic (meaning it works with any hardware), the inline mode is highly dependent on your firewall having a NIC driver that supports Netmap.  Another problem that currently exists is the Netmap pipe seems to break traffic shaping on the interface.  I suspect this is a fixable problem, but no solution is in place yet.

So consider these two issues before choosing to use the inline IPS mode:  (1) do I have a supported NIC and driver; and (2) can I do without traffic shaping on interfaces where I run Suricata?

Source: Suricata inline versus legacy IPS mode | Netgate Forum

Note:

Important Information About IPS Inline Mode Blocking

When using Inline IPS Mode blocking, you must manually change the rule action from ALERT to DROP for every rule which you wish to block traffic when triggered.

The default action for rules is ALERT. This will produce alerts but will not block traffic when using Inline IPS Mode for blocking.

Use the “dropsid.conf” feature on the SID MGMT tab to select rules whose action should be changed from ALERT to DROP. If you run the Snort rules and have an IPS policy selected on the CATEGORIES tab, then rules defined as DROP by the selected IPS policy will have their action automatically changed to DROP when the “IPS Policy Mode” selector is configured for “Policy”.