@jwnazz said in Netgate 1100: @bmeeks Snort started without issue with just the "Connectivity" IPS Policy selected. Thanks for the suggestion. Thank you for the feedback

@bmeeks said in Recommended Snort rules to change from "Alert" to "Block"?: @Enso_ said in Recommended Snort rules to change from "Alert" to "Block"?: Looks like you are right once again. It was set to 'remove blocked host after 1 hour'. So I just never caught it in time. I recommend leaving that setting alone, too. You generally don't want blocks hanging around forever. Not only do they consume resources, but if the block was due to a false positive you would like it to automatically clear in a reasonable time without requiring admin action. If Snort blocked the traffic the first time, it will block it a subsequent time later on (if the blocked host is automatically periodically cleared). One issue with Legacy Blocking Mode is that it is a big hammer. It blocks ALL traffic to a blocked IP for ALL internal hosts. Inline IPS Mode, if you can use it (your NICs must support netmap natively), drops individual packets instead of blocking everything to/from the IP. That's much more granular. But with Inline IPS Mode, you must explicitly change rules you want to block traffic from ALERT to DROP using the features on the SID MGMT tab. I'm leaving the setting to remove the blocked host after 1h. As for inline mode; that is something I want to circle back to in the future. However, currently there are no resources that could configure inline mode in a timely fashion. Plus, I'm quite sure I'd have to upgrade the NICs to support netmap.

Snort will log a message to the pfSense system log as it starts. If it fails, generally the reason for the failure is also logged. The only exception to that is if a shared library is the wrong version or not present. That would only happen if you installed or updated some other package that shared a library with the Snort binary. That is very unlikely -- but not impossible. The most common reason for Snort failing to start would be an error with a rule. It is not unheard of for the Snort VRT to release a rules update package with a syntax error in it. Snort will abort startup when it detects a syntax error. Rule syntax errors will be logged to the pfSense system log. So, <TLDR;> check the pfSense system log immediately after trying to start Snort and see what is logged there. That will clue you in to the problem.

@Enso_ said in SNORT stopped generating alerts: @bmeeks Thank you for all your help. One last question, which I have edited in above. Can I use the free Oinkcode for multiple instances? I'm reading different information about this. I'm running a few pfsense boxes running Snort and have the same free Oinkcode on all three of them, which I will remove if this is not allowed. Here are the actual Terms and Conditions from Snort: https://www.snort.org/snort_license. They state your license is "per sensor" if using the paid license. The license for Registered Users appears a bit more permissive. Here is the direct wording: If You are a Registered User, then subject to the terms and conditions of this Agreement, Cisco grants You a world-wide and non-exclusive license to: (a) download, install and use the Rules on Sensors that You manage (or over which You have administrative control); So, it appears from the above that Registered Users can use their Oinkcode on all sensors that they manage and have administrative control over. But Paid Subscribers can only use the Oinkcode on a single device (sensor). If you need to manage multiple devices on a Paid Subscriber plan you must purchase a license for each sensor. And there are different rules (and a much higer cost) for commercial use of the Paid Subcriber rules.

Ok I don't know why but when testing it this weekend it was working. I did not change anything neither did I reinstall and fresh setup. Would this have to do with the static routing that was setup previously but the device it was pointing to was removed the same day it was setup till recently when the client went over to the new system and was installed again. I mean it makes sens that the pbx server was speaking to the firewall and the firewall was pointing to a device on the network that was not available. NAT is now disabled and siproxd is kinda setup. I'll arrange to test the DNS rebinding check to disable and the preferred work around and the same for Browser HTTP_REFERER enforcement and get back if it works now. Though the client registration check for the App was an issue even before static routing was setup. Please let me know if there is clarity needed.

Problème réglé en ajustant le firewall, le LAN serveur accède bien au LAN client. Il me reste un souci, j'avait une règle NAT pour rediriger un port spécifique depuis le WAN serveur vers une IP client. Cette règle fonctionnait en Site to Site Shared Key mais je ne parviens pas à la faire fonctionner sur le VPN TLS/SSL. [image: 1710152632512-capture-d-x27-%C3%A9cran-2024-03-11-112308.png] Qu'est ce que le passage en TLS/SSL peut avoir à voir avec cela? Des Idées?