@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

@dcol: Possibly inline working with the new version? Where can I find the release notes? There are no release notes related to pfSense.  You can visit the Suricata Redmine site at https://redmine.openinfosecfoundation.org/projects/suricata to see what bugs were identified and fixed there related to netmap.  Netmap is the technology used to provide inline mode on pfSense. Bill

Thanks, that's great news. I'm sure that all of us know that this is free software and we can't ask for an ETA. But like you told us today, you can say from time to time, something like:"Guys, I'm very busy, have patience, it will come", just to know that the work on the package is not dead. I hope I didn't upset you with my little comment. Thanks again

@peter808: Hi Bill, did you already find the time to work on it? Hi Bill, I kindly renew my question.

Thanks.  I would love to be running in NB mode, but we're in full swing for classes and if I run in NB mode the RIAA, MPAA and anyone else with copyright grievances will be breathing down my neck… students just won't turn off their BitTorrent clients.

I see… Now it makes sense ... and I should've thought of that :( Thanks a lot