@bmeeks Thanks for the tips, I disabled the Wan Snort interface and added a suppress by src for that preprocessor rule. I appreciate your help.

@bmeeks I think that worked. Thanks much

@bmeeks Hey, thanks for responding! As far as the rules go, both interfaces are the exact opposite. On the LAN side, I only have the "Snort OPENAPPID Rules" enabled with no blocking. The WAN side has pretty much all of the other rulesets enabled for IPS. So no common rules between them. I will start looking on the log you suggested. I will probably switch back to Suricata with all of the other discussions you've had on Snort's short lifespan on 2.9, but I really do like seeing the L7 traffic coming out of my UDM-SE. Thanks again. EDIT: It's strange that the LAN rules in question haven't even been updated since this started happening. Also, it starts right back up when I start it again manually. I will dig though the system log when I get back in town. Thanks. [image: 1691448241714-96d3c7be-c9cb-4ac1-8048-5326c1bc0be5-image.png]

I got it all sorted out. Had to restart the interface three times but no inter-vlan traffic will be blocked. I tested this running a nmap scan between networks not in the PassList. Setting to 'none' is the best option per the maintainer's notes but i just need a bit of flexibility.

@giyahban said in Netmap (Suricata) cause crash: didnt know its not recommended to have vlan with inline mode. Inline IPS Mode has some limitations. The biggest is that VLANs and other virtual interfaces are not currently well supported. Things like a Bridge or LAGG setup will not work well. VLANs are especially problematic. There is some work happening within FreeBSD's netmap code to make things better, but none of those experimental updates are present in the pfSense kernel yet. If you want to use Inline IPS Mode, you should only deploy it on plain-vanilla Ethernet interfaces (meaning no VLANs defined and not a member of a LAGG or Bridge). You may get by with running Suricata on the physical parent interface only and NOT on each defined VLAN interface.

Thank you everyone

The community rules are back: https://www.snort.org/downloads#rules [image: 1690924093721-8605de56-d4d6-4bcf-96c9-7f5c69e34db9-image.png] [image: 1690923819777-69f04bea-f17a-43e5-806d-659d0ca1d198-image.png]

@bmeeks Thank you. Yes, I did actually try attaching Suricata to the parent, but it still caused problems. I'll have a play with legacy mode and see how that works. Thank you.

So it does work. [image: 1689777284892-capturexx.png]

@bmeeks It looks like they might have put this into v7. https://forum.suricata.io/t/how-to-log-alert-into-a-pcap/2127/4

@TAC57 said in 2.6.0 --> 2.7.0 Upgrade Crash Report: Something must be screwed up because if I reboot a number of packages don't automatically start, Yes, this would be a red flag that your upgrade did not complete properly.

@SteveITS Thank you very much. I heard that even current antivirus software can be bypassed by creating viruses that can evade detection through pre-testing by attackers. However, if they are using AI for checking, it might be possible to detect them. I would like to consider using it.

@bmeeks I believe I know why suricata would crash when geolite2 was updated and I believe suricata was using lots of data and holding ip address's well over 5000 them in snort2c tables, that, coupled with using too large a RAM Disk for /var & /tmp, I was simply out of ram. I have changed the ram disk size and adjusted suricata to NOT keep ip's longer than 7 days and this helped as I've had no more 6am suricata crash nor core dumps have occurred. I really appreciate all of you guys help here on the forum :) Thank you again!

@InstanceExtension Greetings - and apologies all for the disruption this caused last week. As identified within this thread, two rules (SIDs 2046273 and 2046274) were released to the live ruleset with syntax errors. The rules had the "flow: stateless" option set with "to_server" also set which causes a Fatal Error within Snort. Upon investigation it was found that due to a text parsing issue in our QA infrastructure these errors were missed and the rules were released into production. Going forward, we have made adjustments to our QA process to ensure this will not recur and errors of this sort will be caught within our QA process and mended. The next morning we released an out-of-band update to address. Feel free to reach out here via DM, on twitter (@et_labs) or on our Discourse.

@EmergingThreats said in ET Rules or Snort Subscriber rule: @DefenderLLC Greetings - unfortunately, there is currently no alternative pricing at that tier. I will let the sales team know of the interest, though. Thanks for the reply. I would be gladly pay a modest fee for both licenses. Perhaps you can offer a home lab license kind of like what Netgate does for pfSense+ licenses for home users.