Snort won't start, or will it.
-
I have recently noticed a problem with my Snort package. It always says that it's not running. I can hit the start button and it tells me that it was started, and I can find this in the logs. But I find no other log entries from Snort.
I know it used to work, but I have not made any changes to the Snort config or the WAN interface.
Any Ideas?
Or maybe it's working after all, I see Alert logs? Can I trust it?
-
It's not working, I cleared the logs and did a complete Snort re-install, same problem; it says it started but does not stay running, no new alerts are being generated.
I found this in another thread and executed it, but I don't know how to interpret the return.
$ ps aux | grep snort
root 92547 0.0 0.0 9068 1504 ?? S 9:03AM 0:00.00 grep snortOther than that, I have tried turning off rules down to just a bare minimum, different search methods (currently AC-BNFA), and numerous other settings that have all been returned to default.
I'm stumped.
-
Hi
If you use pfsense 2.2, snort won't start, sometime yes, do not know why but some restarts or reinstallation without saving settings can put snort "online" . If not (pfsense 2.1.x), someone more into this could help you.
-
I'm on 2.1.3-RELEASE (amd64)
I installed the service watchdog package just to see what happens. Now I can see that it detects Snort has stopped, but I still get no indication of why Snort stopped.
-
Best you try reinstall, without saving settings. In global settings you should have "Keep Snort Settings After Deinstall" uncheck this, remove package - reinstall package.
Edit: This could be related https://forum.pfsense.org/index.php?topic=78151.0.
-
I did that, de-install, reboot, fresh re-install with all blank settings. I then used sticky thread for Snort setup at the top of the packages forum, no love resulted. The only difference from the sticky was I did not have to obtain an Oinkmaster code, I pasted in the one I already had.
-
I thought that could be pfsense 2.2 but probably snort problem.
I Use suricata for now but i can't use it in my WAN (pppoe) interface, doesn't go well with pppoe interfaces. Only in Lan, better than nothing
-
Revert back to older Version of PFSense, re-install and configure Snort= No Love
complete fresh install of PFSense and complete re-configure = a lot of work for nothing.Package removed, not worth any more of my time dealing with it.
-
So I was read somewhere that IPv6 is not supported in snort, I was running IPv6 on a couple interfaces, although Snort was not monitoring them.
I changed all interfaces over to IPv4 and re-installed the Snort package. It works now.
It looks as though if I run IPv6 on ANY interface, Snort will not run, I found this odd because as I said, the interfaces that were running IPv6 were not being monitored by snort.
Is this normal? I could swear that I had been running IPv6 on these interfaces (VLAN Trunks) for some time with no trouble, Snort only looks at my WAN.
-
So I was read somewhere that IPv6 is not supported in snort, I was running IPv6 on a couple interfaces, although Snort was not monitoring them.
I changed all interfaces over to IPv4 and re-installed the Snort package. It works now.
It looks as though if I run IPv6 on ANY interface, Snort will not run, I found this odd because as I said, the interfaces that were running IPv6 were not being monitored by snort.
Is this normal? I could swear that I had been running IPv6 on these interfaces (VLAN Trunks) for some time with no trouble, Snort only looks at my WAN.
Snort works with IPv6 and can block IPv6 as well. I have it working on my home firewall just fine. It's Barnyard2 that does not support writing IPv6 to MySQL databases, so there can be issues with that.
Bill
-
So I was read somewhere that IPv6 is not supported in snort, I was running IPv6 on a couple interfaces, although Snort was not monitoring them.
I changed all interfaces over to IPv4 and re-installed the Snort package. It works now.
It looks as though if I run IPv6 on ANY interface, Snort will not run, I found this odd because as I said, the interfaces that were running IPv6 were not being monitored by snort.
Is this normal? I could swear that I had been running IPv6 on these interfaces (VLAN Trunks) for some time with no trouble, Snort only looks at my WAN.
Snort works with IPv6 and can block IPv6 as well. I have it working on my home firewall just fine. It's Barnyard2 that does not support writing IPv6 to MySQL databases, so there can be issues with that.
Bill
Well that certainly muddies thing up a bit more, I don't run Barnyard2 at all, but I did enable it and do a quick set up on it today. Whenever I setup any interface to run IPv6, Snort stops working, it then takes changing back any and all interfaces to IPv4, and a un-install and re-install of Snort to get it working again, color me confused.
-
So I was read somewhere that IPv6 is not supported in snort, I was running IPv6 on a couple interfaces, although Snort was not monitoring them.
I changed all interfaces over to IPv4 and re-installed the Snort package. It works now.
It looks as though if I run IPv6 on ANY interface, Snort will not run, I found this odd because as I said, the interfaces that were running IPv6 were not being monitored by snort.
Is this normal? I could swear that I had been running IPv6 on these interfaces (VLAN Trunks) for some time with no trouble, Snort only looks at my WAN.
Snort works with IPv6 and can block IPv6 as well. I have it working on my home firewall just fine. It's Barnyard2 that does not support writing IPv6 to MySQL databases, so there can be issues with that.
Bill
Well that certainly muddies thing up a bit more, I don't run Barnyard2 at all, but I did enable it and do a quick set up on it today. Whenever I setup any interface to run IPv6, Snort stops working, it then takes changing back any and all interfaces to IPv4, and a un-install and re-install of Snort to get it working again, color me confused.
I use a Hurricane Electric IPv6 tunnel broker account and have an IPv6 network on my LAN (and via the tunnel on my WAN). I have not seen any issues other than Barnyard2 won't log IPv6 addresses to the MySQL database (I use Snorby to accept data from Barnyard2).
Bill
-
edit missread - the above post - its not an ipv6 issue.
-
System –> Advanced --> Networking --> "allow ipv6" (uncheck this...turn it off).
Soon as I did that snort started working. Wow ... There should be prerequisite checker in pfsense (or even a warning on the package) that discloses this.
Ugh?! There is no such prerequisite like IPv6 "disabled". (All that it does is block all IPv6 traffic in packet filter anyway, as written in the GUI.) It's even discussed above (some year ago before your necropost).
-
^and turning it off didn't solve the problem. Still having issues w/ rebooting the firewall and the service not starting back up.
-
Anybody having this issue also have suricata installed and enabled on the wan interface?
-
^and turning it off didn't solve the problem. Still having issues w/ rebooting the firewall and the service not starting back up.
What do you mean exactly? How are you checking this? This is now started in backgroundl since it takes long to start, depending on HW and configuration.
-
I think I figured out how to fix the bug. Go into "snort interfaces" and then "wan categories"
Turn off all the categories, then turn any one of them on (just one)….and save it. Then if you go back into "snort interfaces" it will say the WAN is enabled. After that, go back into the "wan categories and turn on either all or whatever ones you want one, and it will stay enabled.
-
I had this issue with pfSesne 2.4.2 and had no luck fixing the issue with any of the suggestions. Though I do think I have now found out why the WAN interface went down.
As I had set up Snort previously, access to checkip.dyndns.org was noted in the Alerts tab. Enabling a suppression list for the following IP addresses seems to have corrected my connection issues.suppress gen_id 1, sig_id 2014932, track by_src, ip 91.198.22.70
suppress gen_id 1, sig_id 2014932, track by_src, ip 216.146.38.70
suppress gen_id 1, sig_id 2014932, track by_src, ip 216.146.43.70
suppress gen_id 1, sig_id 2014932, track by_src, ip 216.146.43.71
