@pfsjap said in Suricata inline mode with Netgate 6100: Wasn't a driver issue after all. MTU of this interface was 9000 and netmap buffer size (dev.netmap.buf_size) was 2048 (default). After setting buffer size to 9100, Suricata started in inline mode. Found this tunable in here. Ah! Good detective work. The error message certainly was not helpful in this instance. It could have said "out of memory" or "insufficent buffer size" you would think. This error comes from the netmap device code within FreeBSD and has nothing to do with Suricata's use of netmap. Not many folks are using MTU sizes larger than 1500, though.

@bmeeks Thank you, Mr. Meeks.

@Dobby_ Good idea. I do have two 8GB RP4B's just sitting around doing nothing. I was using those for Pi-hole before switching to pfBlockerNG.

@the-other I got pfblockerng installed... are there preloaded p2p blocklists or is this something I need to create myself?

@bmeeks I meant to update this thread before your response. Beat me to the punch. My misunderstanding is really how to work with the GUI in regards to IPS/IDS. Some of the elements aren't exactly clear so it did require poking through several threads here to understand how the pieces work.

@jpgpi250 I usually turn off rules here...see arrow in Emerging DNS... [image: 1685541192483-screenshot-2023-05-31-at-8.47.49-am-resized.png]

May 27 16:02:49 kernel pid 38637 (snort), jid 0, uid 0, was killed: failed to reclaim memory May 27 16:02:49 kernel pid 38637 (snort), jid 0, uid 0, was killed: failed to reclaim memory Can be pointed to the storage space and/or the amount of ram.

@ASGR71 Yes but to be fair 98% of them don’t have any inbound ports forwarding. Some for games or uPnP I suppose. Sine I don’t see I mentioned it above, if one runs Snort or Suricata on WAN, that runs outside the firewall so will block all sorts of things that would get blocked anyway. Running it on LAN avoids a lot of scanning plus will show internal IPs in the alerts.

@Bob-Dig said in Suricata Inline Mode with WireGuard interface?: Is it a good or a bad idea? Interesting question, indeed. One would need a dedicated NIC since one needs Netmap. I was thinking the other day wondering how to assign a NIC to Wireguard...that's how far I got.

@SteveITS I'm an idiot, was pinging from the wrong firewall! It is indeed blocking. Sorry. I'll delete my post.

@bmeeks Thanks for this precise description. OK reverted to scanning LAN ;)

@yet_learningpfsense Also if you’re running Suricata on WAN I’d recommend putting it on LAN. Otherwise it scans outside the firewall so scans all inbound to-be-blocked packets and can only see the NATted IP not LAN devices.

@steveits pfsense restart

@bmeeks said in Snort Behavior: @defenderllc said in Snort Behavior: @steveits said in Snort Behavior: @bmeeks said in Snort Behavior: the next packet through will simply trigger another block He's saying it was triggering alerts while the service/interface was showing stopped in the GUI. Hence my comment about a zombie process. It was still still blocking with the interfaces completely deleted from Snort. I had to reboot to get this to stop. You should look for Snort alerts under the ALERTS tab of the Snort GUI. You can see blocks under the BLOCKS tab. Here is what was happening. An excessive amount of SIP traffic triggered a bunch of blocks that pushed memory utilization to nearly 100% and the firewall was inaccessible for about 10 minutes. I was finally able to get in via console cable and then eventually the GUI. The Snort LAN interface was stopped which was fine with me so I could make some adjustments. The memory remained at nearly 70% and I was super busy with work, so I tried to stop the bleeding by simply stopping the service. That did not work because it would just restart within seconds even without it being configured in Service Watchdog. The next step was just to delete all of the interfaces in Snort, clear all alerts and blocks... I did this over and over and it did not matter because they just kept coming back despite a lack of any interfaces configured. Memory utilization was still high. A reboot was what it took to clear everything - include the memory utilization. #LessonLearned

@smoses Plus? There are a few recent posts about empty package lists…try re-saving your existing update branch setting (Settings/update/Settings).

@yet_learningpfsense said in Source of IP addresses blocked by Snort: may be cases where a supposedly safe website could become a dangerous one That is anysite on the planet to be honest - sites get compromised all the time, and then become hosts to malware, etc.

@bmeeks This worked perfectly thanks so much! Wish I did that before posting!

Thanks for the additional information bmeeks! I did check the documentation on Rules Update Settings and didn't see anything about altering the time if scheduled rule updates fail. It's documented here now so hopefully it will help others.