I opened a separate bug to cover this as it was getting conflated with the PHP issue whoch is a separate (and solvable) problem:
https://redmine.pfsense.org/issues/12157

Steve

@fst said in Snort will not start - PFSense 21.05 / FreeBSD 12.2:

Thanks again.

You're welcome. Sorry for not getting it working!

Regards,
fireodo

@bmeeks Thanks Bill,

I actually had a sneaking suspicion I'd seen it and had it in my to do list to check it so thanks for confirming.

@bmeeks Cool. Again, thanks for all the effort on this!

@gertjan said in ET INFO Outbound RRSIG DNS Query Observed:

@stewart said in ET INFO Outbound RRSIG DNS Query Observed:

Spectrum uses have PUMA chipsets and fall apart

Oh .... that name does ring a bell. Isn't that chipset/modem part of the top ten on badmodens.org (or something like that).

Why yes. Yes it is. I believe PUMA chipsets is the sole reason that site exists.

@gertjan said in ET INFO Outbound RRSIG DNS Query Observed:

@stewart said in ET INFO Outbound RRSIG DNS Query Observed:

You can't just say

Well .....
Right, I admit : I say so, because it, pfSense, ships in a configuration that works out of the box. They choose this build-in setup because it's probably valid for most of us.
And that's valid for me.
( so extra true ^^)

I realize that there may be a bit of a language barrier if you're primary language is French. I realize if read a certain way it could be an argumentative statement. It wasn't meant to be so, so please don't take offense.

Don't worry, I live in France, so I know that there as as many exceptions as habitants.

Still .... using a modem that goes haywire because you throw some off the mill, plain vanilla DNS requests through it makes me wonder :
You pay your ISP - or your ISP pays you ? ;)
Do you have to use this type of modem ? (I've read somewhere, sometimes that you probably do not have any choice).

Residential customers can use an approved modem. Commercial customers must use the ones provided by the ISP.

IMHO : a more basic router/firewall a pfSense doesn't exist **. I guess it's even setting that reference right now.

What I should have said above :
On the Resolver settings page : un check the DNSSEC option, as it it worthless anyway.
The "ET INFO Outbound RRSIG DNS Query Observed" log line will go away.

@stewart said in ET INFO Outbound RRSIG DNS Query Observed:

modem buckles under the weight of simple DNS traffic

This intrigues me.
Dono what the ratio of "DNS traffic"/"All traffic is".
1 or 2 %, maybe ? I should investigate.

It's not the overall amount of bandwidth that's used. It's that DNS throws out a bunch of UDP packets in quick succession when doing the resolving and the modems become unresponsive during that time.

** with probably far to many bells and whistles.

@steveits said in Snort2c Hosts being blocked:

@stewart said in Snort2c Hosts being blocked:

find the WAN IP as being blocked

Your WAN IP should appear if Snort is running on the WAN interface. If you move it to LAN, you'll see LAN IPs, and it won't see/scan traffic that was blocked by the firewall.

You misunderstand, I think. I'm not saying that I see the WAN IP in the Alerts (which I do since it's on the WAN). I'm saying I sometimes see the WAN IP in the snort2c block table. In that Suricata actually places the WAN IP on the block list and won't accept any traffic to or from the WAN IP for the duration of the block time. If he's running IDS on the WAN and the WAN IP is getting blocked then it won't accept any traffic at all on the WAN. I'm wondering if that is what he is seeing since he is talking about the snort2c block table and not the Alerts or Block lists.

I want to report that I am working offline with the Suricata developer team looking into this issue, and also the one affecting netmap operation in the Suricata 6.x binary.

@bmeeks said in Suricata-6.0.0_11 Package Update Release Notes:

It will show up in the near future.

This has been done, once again, we got your usual work... :-)
(quality above all else)
Thank you Bill, if something is missing we will shout

@bmeeks said in Snort-4.1.4 Update Package Release Notes:

Yes, it will be included in the current release (both CE and pfSense+) in the near future. I'm sure the team has been busy with the recent 2.5.2 version going RELEASE, and have not pulled over some package updates.

Good to hear!

I will drop the Netgate team an email asking them to move Snort-4.1.4 over to 2.5.2.

Thank you very much! And also THANK YOU for your work!

Nice Weekend, i wish,
fireodo

@theonemcdonald

tun_wg0: flags=80c1<UP,RUNNING,NOARP,MULTICAST> metric 0 mtu 1500 description: WREGRD options=80000<LINKSTATE> inet 10.128.128.1 netmask 0xffffffff inet6 fd1f:c547:3e98:b32f:: prefixlen 64 groups: wg WireGuard nd6 options=101<PERFORMNUD,NO_DAD>

Gave it a local link ipv6 but the issue persists.

If I delete the tun_wg0 the issue goes away.

@drewsaur There is the + icon to Suppress a rule for an IP, in the source and destination IP columns, if that helps.

The System Log Facility setting controls "where" the entries are logged. Or more accurately, what "tag" they are given in syslog. So with the default of LOG_AUTH, those alerts are going to be given that tag, so when filtering in pfSense's system log, they will show up that way. The "General" view in pfSense grabs everything (if I recall) regardless of the "tag" it was given when logged. But those other tabs do let you filter by the facility tag.

@hichem said in Snort (4.1.3_5) + SG-3100 (21.05-RELEASE (arm)) = exited on signal 10:

@steveits
Patch already done 5 days ago, but snort stop after a few minutes.

For SuricataI win reinstall it and told you the error.

Pay attention to the errors in the log. Signal 11 is a segmentation fault. That was happening from the PHP PCRE engine. The patch referenced earlier in this thread fixes that Signal 11 problem.

It does NOT fix the Signal 10 issue. That is caused by opcode choices made by the compiler for the 32-bit ARM processor used in the SG-3100 appliance. There is no easy fix for that. I've explained why in several other threads.

If running an IDS/IPS is important to you, then get off of ARM 32-bit hardware and move to either an Intel/AMD platform, or a 64-bit aarch64 platform. The Signal 10 error has been an issue with Snort (and sometimes Suricata) since the release of the 32-bit ARM hardware appliances. I've tried one patch in the past that consists of disabling compiler optimizations by essentially telling the llvm compiler to compile Snort with the debugging flags enabled. That appeared to have worked for a while, especially under FreeBSD-11 (which the 2.4.5 branch of pfSense used). It appears that as of FreeBSD-12 (which the new 2.5.x branch and higher of pfSense is using), that old debugging compiler flag may no longer be effective.

@bmeeks Awesome, thank you sir! I somehow overlooked this ridiculously obvious tab... still trying to wrap my head around this system. This solved my problem, thanks for the help!

yeah that is exactly what happens, the first suricata instance to start is the one showing the stats, unfortunately the suricata plugin does not support multiple sources so the only way is to start another telegraf instance not managed by pFsense

@bmeeks Thanks for the tip. I got the format all fixed up thanks to the docs.

RTFM works... if you know where it is. ;)

@bmeeks Stunning painless fix. Greatly appreciated.