@bmeeks: Great advice, thanks again.

I really appreciate your response. Thank you.

@elmnts shouldnt I see the initial connect in the Snort log Depends on the rule. E.g. packets from a listed IP.

It's very simple to test the functionality of Snort. Install nmap on any laptop or PC on your network. Run a simple SYN scan against the firewall's interface IP for a network that has a Snort instance running on it with the Emerging Threats SCAN rule set enabled. nmap -sS <target_ip_address> If the above command generates connection attempt alerts, then Snort on that interface is working. If you see nothing, then Snort is either not actually running or the needed rules are not installed/enabled. Note that you won't get blocks from this test because the firewall interface IPs should all be in the automatic Pass List, but you will see ALERTS from the attempts.

@NRgia No problem. Would be great if Netgate clarifies the support of suricata going forward but they seem to work on both suricata and pfblockerng now.

@Patch said in So why is Netflix hitting me with Dradis?: The information they are after on your device is screen fingerprinting (to identify content played not from them). And any thing else they can see on your network. The overall effect is a rather high price for a country. Clearly an individual can’t change this on their own but neither must an individual accept or support it. Interested in a source for the claims. I thought targeted advertising was frighteningly cheap?

@bmeeks There community edition as well, when I'm asked about pfSense package, I mean community edtition. Plus Suricata 8.0 a huge step forward from previous releases.BTW any plan to integrate Suricata 8.0 in pfSense? https://www.stamus-networks.com/clear-ndr-community.

Here. I think. Referenced as "github.com: vendor-provided URL vendor-advisory" in your link.

@bmeeks Understood. Thank for kindly for your help. I will likely be ordering a new unit soon.

@Greyhat I think it's useful to work with what we've got and figure something out for the (i hope) edge cases later. So for the JSON I figured you can actually use an existing suricata integration by co-opting their pipelines.

@smsigroupit said in Throughput drop on Netgate 8200 MAX LAN/VLAN (ix1) with Suricata inline mode: @bmeeks Thank you for the reply. Switching Suricata’s Run Mode to Workers resolved the throughput drop. Really appreciate the help! Ah --- yes. I forgot to mention trying Workers Run Mode in my previous post. Workers mode allows the netmap packet handling module to avoid the need to lock the netmap rings during critical functions.

@rlrobs Update: I can't resist the urge to try and optimize things and tinker with them, to tweak it into a better state. I don't like default settings, I like exact settings, configured for your use case (if this provides benefit ofc). So I thought if I organize all the traffic flows like highest priority to lowest, my most important network applications will always run flawlessly and what is less important might have a little hiccup or delay, but some things you always want to prioritize right. Such as Voice over IP, I don't use that, but I was thinking about that concept. So I was fiddling with the settings of limiters and implementing QoS. It was all going well, until I wasn't able to connect to my VLAN AP anymore. I researched this and apparently (though not 100% sure) this has to do with the use of dummynet of the QoS / Limiters section. This seems to interfere with VLANs. I heard dummynet also strips VLAN tags or something along these lines. Now what's relevant to your question is - this also broke Suricata Inline IPS mode for the VLAN subnets again for me, sadly. I tried reverting everything to previous state (I keep many many back-ups of each change manually, I prefer that over configuration back-ups in PfSense itself). Bottomline my experience was: Suricata Inline IPS mode for VLANs worked directly after my upgrade to PfSense 2.8.0 Suricata Inline IPS mode for VLANs stopped working after I started to configure Limiters for the VLANs and QoS for the WAN side. After reverting to Legacy, I did notice a huge jump in performance. I think because running Inline IPS on both WAN, LAN and VLANs is a bit compute intensive. Just so you guys know as well, it's worked, but it stopped working again after like many months because of my tweaking. And when I re-enable I couldn't join the VLAN Wi-Fi SSID's anymore (Yes I did check if the DHCP allowed new clients and the rules etc.). Conclusion: now not 100% sure if Suricata + VLANs definitively works in PfSense 2.8.0. Apparently, if you start using QoS and Limiters and then try to restore everything back to previous state, the settings it created regarding dummynet are not always fully removed 'cleanly'.

@SteveITS Pass lists are completely blank. there are some blocks that have occured so it seems to be blocking some things.

@SteveITS Thank you for the reply. I understand. Hopefully its picked back up.

It was all CVE fixes in the PHP GUI part of the package. See the Redmine ticket here: https://redmine.pfsense.org/issues/16414.

I have struggled with the log sizes getting too big and then the web pages refusing to list things on them (alerts/blocks pages show empty in UI). Clearing the logs manually instantly fixes the UI issue. I think the problem is the fact that logs can grow quite quickly and that relying on the log rotation can lead to a (very minimal) denial of service type event. I've thought about mucking with how often it rotates but as long as I'm not being legit DDOS'd it is just a nuisance. Suricata still clearly works. The firewall itself clearly works. The only real problem is UI issues when attempting to do a real investigation or troubleshoot. One can work around that manually. Of course somebody will simply say turn suricata off on the external interface. No. Occasionally good research happens there.

@icoso said in Snort Alert list explanation: If I only run it on the LAN ports wouldn't that only prevent my users from going outbound to certain IP's? I think you're misunderstanding how it works. In legacy mode it will check for "bad" packets going past the router, and add the "bad" IP to a table/alias, and the firewall will block packets to/from that table. It is not directional in the sense of "it's on LAN so only watches outbound." Running it on LAN also identifies which internal device triggered the rule because otherwise on WAN it is after NAT, since it's outside the firewall. You can run it on WAN, sure. Some do if they have a lot of internal interfaces and don't want that many Snort/Suricata processes running. It's a tradeoff of "scanning packets that will never actually arrive" vs convenience/RAM usage. Here is the setting I mentioned in Suricata; the packages are similar to maybe Snort has it also: [image: 1757427238489-8223c7ca-ba6c-4503-8668-2b7c03e597ef-image.png] However, on the Snort interface settings click the View List button by "IP Pass List" and you'll see which IPs are ignored by default.

@Gradius said in Feodo Tracker Botnet C2 IP Rules down for almost 48h: Any mirror or alternative ? No - AFAIK ... Edit (08.09.2025): Its UP again!