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

Thanks a lot

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