• Only after scanning the packets and a match is done with the rules will the host be blocked.
• There is a chance that the packet could make it past because of the time it takes to scan the packet, i.e. there will be small packet leakage, but eventually the host will be blocked if there is a matching block rule on it.

• 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.

• This could be referred to as a “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.

• The packets are scanned and blocked if matched to a rule before passing to network.
• Currently breaks traffic shaping.

• 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?