Just to update, I have used a BPF file to bypass Snort on the media ports to the VOIP hosts. This has resolved the CPU issue, although this is a workaround rather than a fix so I would still appreciate any input. To achieve this I created /etc/snort.bpf with the following contents not (host 10.0.200.161 and udp portrange 16384-32768) and added the following line to the advanced configuration pass-through config bpf_file: /etc/snort.bpf saved the configuration and restarted snort. Now calls do not hog the CPU.

We have a somewhat similar problem. We have several external IP addresses, one for mail, one for our web server and one for everything else. We would like snort to scan and block two of the three official IP-addresses and leave the third untouched or better phrased unscanned. I have no real Idea how to do that. At first I thought I can put the IP which should not be scanned out of the home net or external net but I couldn't get snort to not scan the IP. Has someone a helping hand for me?

I have alredy tried that without success. Fortunately I solved the problem. As I suspected the problem was the vmxnet3 drivers. Netmap doesn't support it. Alerts appeared using Suricata inline with E1000 drivers on one of my bridge interfaces. I found this reference in another post: https://www.freebsd.org/cgi/man.cgi?query=netmap&apropos=0&sektion=4&manpath=FreeBSD+10.2-RELEASE&arch=default&format=html#SUPPORTED_DEVICES Lesson: DON'T use VMXNET3 with Suricata INLINE mode!

Oops, I am also facing this situation. So the reason is from Snort VRT Website :(

thanks BBcan177 After adding``` .amazonaws.com

I don't think it's possible to do it the way you are asking. One way to solve would be to use modifysid on the SID MGMT tab to exclude port 123 from the rules that are being triggered. Another option would be to suppress the internal host(s) that are triggering these rules for each specific rule.

I assumed that this warning was a false positive, since I checked IP and found that it's belong to Surfeasy which are the ones who are behind the opera VPN But still catches the eye when this warning pops up in snort alerts.I don't know what is the reason then why this alert appears?I was doing fresh  (backup/restore) install on that phone with android and it doesn't have nothing like bloatware or crapware apps on it.I was just testing Opera max & vpn from the official play store.

@jimp: That and other packages will need to be adapted for the new code on 2.4. Many things will likely be broken for a while yet until we get around to patching them up as we go. Excited to see this progress. I might consider switching to suricata over snort in pf 2.4. Thanks for all of the support, Jimp!

@mikesamo: Hello, work for me… That picture doesn't help, because in Legacy mode, it will look the same. If you are in Inline mode for both Interfaces, I believe you, I'll try to delete the configuration for suricata by hand. For me it only works for the second interface like bellow Thanks  

@ntct: https://forum.pfsense.org/index.php?topic=100256.0 Honestly, I disabled that rule yesterday to provide the service for end-users. But I still want to know this is the reason from rules or Snort. Thank you for your link.

Emerging Threats is the brand name. There are two ET main rulesets: Emerging Threats Open is free and provides (in my opinion) a decent amount of coverage Emerging Threats Pro is $750 per year per sensor and includes more rules and provides better coverage. On pfSense Snort only supports what is now referred to as legacy IPS mode. Suricata supports both legacy and inline IPS mode. With either Snort or Suricata in non-blocking mode you will only get alerts for whichever rules you are running With either Snort or Suricata in legacy IPS mode you will block the IP of the offending traffic  for whichever rules you are running. Some amount of traffic will pass before the IP is blocked and the states killed. With Suricata in inline mode you must specify which rules you want to run in drop mode. Any rules specified for drop mode will drop the traffic before it passes, and the IP address will not be blocked entirely. Any rules that are active that are not specified for drop mode will generate alerts without any dropping/blocking.

@mhertzfeld: You are not alone, I see the same thing in my setup. I had asked a similar question a few months back but never got an answer. https://forum.pfsense.org/index.php?topic=113631.0 I am thinking this has something to do with it. https://en.wikipedia.org/wiki/Promiscuous_mode Are the pfsense and snort versions the same on the system you see the vlan traffic in LAN and the system you don't? Promiscuous mode would make sense, but I thought previously Snort was putting the interfaces into promiscuous mode as well, even though it wasn't seeing all the traffic. I actually changed my configuration to adjust for this, so I was surprised to see it working as expected on the new system. I have one system available to test on, it is fully up to date (pfSense and Snort) and it is behaving as described above, running Snort on the physical interface alerts on traffic for the VLANs on that interface as well. I know that this was not the case previously, but that was probably on 2.2.6 and with a previous version of Snort.

Thanks.  I would really like to install/run Suricata, but since their main support (as I have heard) is the U.S. government, I can't bring myself to trust it.  There is too much of a chance that the government will attempt to strong arm Suricata into installing back doors.

@ntct: Hmm, I think so, How do you suspect the formatting of the YAML file is the problem? Command line or? I try the default value of profile_high, it still failed. #  - profile: {$detect_eng_profile} profile: custom custom-values:       toclient-src-groups: 15       toclient-dst-groups: 15       toclient-sp-groups: 15       toclient-dp-groups: 20       toserver-src-groups: 15       toserver-dst-groups: 15       toserver-sp-groups: 15       toserver-dp-groups: 40   - sgh-mpm-context: {$sgh_mpm_ctx}   - inspection-recursion-limit: {$inspection_recursion_limit}   - delayed-detect: {$delayed_detect} UPDATE I use command 'suricata -c suricata.yaml –dump-config' form my running interface's yaml, I don't see any toclient or toserver options. detect-engine = (null) detect-engine.0 = profile detect-engine.0.profile = high detect-engine.1 = sgh-mpm-context detect-engine.1.sgh-mpm-context = auto detect-engine.2 = inspection-recursion-limit detect-engine.2.inspection-recursion-limit = 3000 detect-engine.3 = delayed-detect detect-engine.3.delayed-detect = no As long as I add any toclient or toserver options, it can't start anymore. 21/9/2016 – 08:58:49 - <error>- [ERRCODE: SC_ERR_CONF_YAML_ERROR(242)] - Failed to parse configuration file at line 136: did not find expected key</error> toclient or toserver options is line 136. 21/9/2016 – 09:14:27 - <error>- [ERRCODE: SC_ERR_CONF_YAML_ERROR(242)] - Failed to parse configuration file at line 145: mapping values are not allowed in this context</error> inspection-recursion-limit: {$inspection_recursion_limit} is line 145  –-> ??? Thanks, ntct That error message means you either do not have all the required parameters for the option, or the syntax is incorrect, or the option you are trying to use is not recognized or supported.  I am not familiar with that particular option, so I do not know if it is still valid or not.  You might want to go over to the Suricata site and ask there how to use those options. Bill