I've been running pfSense CE 2.7.2 for several months in a small office environment (about 25 users). My setup is straightforward: a Protectli appliance with an Intel i3-7100U and 8GB RAM, acting as firewall, router, and running Suricata in IPS mode on the WAN interface.
After extensive tuning, I've concluded that enabling Suricata, even with a very conservative ruleset, is causing significant WAN throughput degradation. My baseline throughput (no Suricata) is ~940 Mbps down/40 Mbps up. With Suricata active, I see the following:
* With the ET Open ruleset (only the "Policy" and "Current Events" categories enabled, ~1700 rules): throughput drops to ~620 Mbps down.
* With only the "Policy" category enabled (~1200 rules): throughput drops to ~700 Mbps down.
* With a manually created, minimal ruleset of 15 rules (blocking only known-bad IPs and specific exploits relevant to our public services): throughput still drops to ~820 Mbps.
This seems excessive. The CPU usage rarely exceeds 30% total across both cores, and RAM usage is stable. I've already implemented the common performance recommendations:
* Set `pattern-matcher` to `hyperscan`.
* Disabled all logging to disk for Suricata, sending alerts to syslog only.
* Tuned the `default-rule-path` memory settings.
* Confirmed that hardware checksum offloading is disabled (as required).
My primary question is whether this level of performance loss—nearly a 25% hit with a bare-bones ruleset—is expected on this hardware, or if there's a fundamental configuration bottleneck I'm missing. For comparison, in my home lab with an OPNsense box on similar hardware, Snort in IPS mode seems less impactful, but I haven't done a controlled, side-by-side spreadsheet comparison yet.
Specifically, I'm looking for insight on:
* The relationship between rule count and throughput in Suricata on pfSense, and whether it's linear or has a baseline overhead.
* Any `suricata.yaml` advanced tuning parameters under the `pfSense` GUI that are known to help in gigabit scenarios.
* Whether the choice of `IPS` mode vs `IDS` mode inherently carries this cost on the WAN interface, even if the rule actions are primarily `pass`.
Measure twice, buy once.