Thanks, Yes the best solution is to disable that rule.

You kinda always need a firewall in front/inline. Otherwise you would be processing malicious packets sent against your IDS or jsut processing useless packets that a firewall could have drop faster. To block ports,ip,protocol = firewall To block domains,url,user agent = proxy To block patterns, evasion/obfuscation kunfu, malware, deep packet inspection with complex regex = IDS F.

I am having this issue as well. It appeared more or less out of nowhere…

Thanks for the suggestion @khorton But unfortunately it does not seem to be my issue. Shell Output - ps -ax | grep snort 30136  -  INs    83:34.25 /usr/local/bin/snort -R 9496 -D -l /var/log/snort/sn 30421  -  SN      1:16.62 /usr/local/bin/barnyard2 -r 9496 -f snort_9496_igb1. 78985  -  S        0:00.00 sh -c ps -ax |grep snort 2>&1 79614  -  S        0:00.00 grep snort As I mentioned earlier, I'm open to any suggestions as I really would like to solve(or at least understand) my issue. Thanks

@RonpfS: https://www.freebsd.org/cgi/man.cgi?em(4) https://www.freebsd.org/cgi/man.cgi?query=man&apropos=0&sektion=0&manpath=FreeBSD+10.3-RELEASE+and+Ports&arch=default&format=html Ah, thanks! The (4) is for Chapter 4 of the manual, makes sense. Any pointers on how to solve my problem?

@genesislubrigas: re0 I had the same issue as you but for em interfaces. I have only 2 interfaces, em0 and igb0. Inline mode only worked for igb0 interfaces. Your ETH cards are Realtek, please check the chipset compatibility here, if you didn't to that already: https://www.freebsd.org/cgi/man.cgi?query=re&apropos=0&sektion=4&manpath=FreeBSD+10.3-RELEASE+and+Ports&arch=default&format=html I have Intel chipsets, so I don't know what advice to give you. Try to switch interfaces by assign a different one, although as I read on different forums, I tried to buy only ETH cards with Intel chipsets, because Realtek ones, tend to cause issues.

@dcol: Redyr, I was using only one interface, WAN. Which is on igb2. I am currently not using the em interfaces. LAN is igb3 and the email server I want to protect is on igb0 So, are you saying change the WAN to igb0? Would netmap like igb0 better? I really only need Suricata inline on the WAN interface with a few simple custom rules I am currently using in Snort. (Example shown previously) By the way, I did disable snort when running Suricata, and Suricata worked ok in legacy mode, just like Snort. Thanks Dan I have only 2 interfaces on my pfsense hardware, both with Intel chipsets, but the pfsense sees them as igb0 and em0. When I enabled Suricata Inline mode to WAN - igb0, all was fine, but when I tried to enable Inline mode for the LAN - em0 interface also, I could not access my pfsense box anymore (because the traffic was blocked). If you only use igb0 interfaces, I dont't know what advice to offer. I for one found this workaround, and I thought to share. The workaround that I speak of is only enable Inline mode for igb0, and for em0, only run Suricata in legacy mode like Snort. This is the only way it works for me. But I think you have a different problem. Sorry if I was misleading in any way Try to use suricata in Legacy mode, until the next version. On this forums I only found that Suricata Inline mode have some issues with netmap, but I did not find any resolution about it. Please share if you find any resolution. 10x

I thought increasing the stream memory had resolved it, but after rebooting pfsense box, the suricata service stopped again and cant be started even if I restart it. OMG

After reading your posts, I can say, I have the same issue as you, but for me is more speed consuming, if I disable Suricata, I get 537 Mbps. If I enable Suricata again I'll get 131 Mbps. Its possible that the root cause to be Suricata rules, that needs tweeking? I have an extra 4 Gigs of RAM free from the total 8 Gigs. So no memory issue just like you

I wouldn't say that ALL of the http_inspect rules can be ignored (though like mhertzfeld says, they're probably of greater concern if running a web server to keep an eye on attacks), but many of those rules are designed for strict adherence to specifications that have been flexed in many ways over time to accommodate the tons of applications that use HTTP today as their transport protocol. Your list there is probably the most common ones that can be suppressed without any real concerns.

Found a discussion on the subject here, http://stackoverflow.com/questions/3337020/how-to-specify-ranges-in-yaml For anyone happening upon this I gave up, because it looks unsupported,  and just lived without the alias.