Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Snort stops by itself

    IDS/IPS
    8
    22
    8.3k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • I
      Ip Man
      last edited by

      Ok, from the responses here I understand that this is a well known and very serious problem with Snort and pfSense. A IDS that turns off randomly is obviously a very serious problem. This bug has to be corrected before pfSense can be trusted and used with confidence.

      1 Reply Last reply Reply Quote 0
      • F
        fearnothing
        last edited by

        I had a similar issue, but it was solved by using the AC-BNFA or AC-BNFA-NQ memory setting. It was a result of snort rules updates causing the process to attempt to allocate more memory than was available.

        1 Reply Last reply Reply Quote 0
        • panzP
          panz
          last edited by

          Sometimes Snort stops on the LAN interface. Never on the WAN.

          pfSense 2.3.2-RELEASE-p1 (amd64)
          motherboard: MSI C847MS-E33 Micro ATX (with Intel Celeron CPU 847 @ 1.10 GHz) ~ PSU: Corsair VS350 ~ RAM: Kingston KVR1333D3E9S 4096 MB 240-pin DIMM DDR3 SDRAM 1.5 volt ~ NIC: Intel EXPI9301CTBLK (LAN) ~ NIC: D-Link DFE-528TX (CAM) ~ Hard Disk: Western Digital WD10JFCX Red ~ Case: Cooler Master HAF XB ~ power consumption: 21 Watts.

          1 Reply Last reply Reply Quote 0
          • F
            Fmstrat
            last edited by

            I have had this happen quite regularly. I've narrowed it down to the fact that I have a constant connection on a VPN. When the VPN connection goes down and reconnects, snort is restarted, even though it is not tied to the VPN interface. I'm guessing it's because of the check_reload_status process.

            Edit
            To be more specific, an OpenVPN client is on PFSense, connected to an external OpenVPN server.

            Edit 2
            It could also be due to the reloading of rules depending on how you have updates set. Here's some log snippets showing what I believe to be the above issue, though:

            Jun 17 17:18:47	kernel: ue0: promiscuous mode enabled
Jun 17 17:16:11	SnortStartup[96556]: Snort START for WAN(34137_ue0)...
Jun 17 17:16:07	SnortStartup[94480]: Snort STOP for WAN(34137_ue0)...
Jun 17 17:16:05	check_reload_status: Syncing firewall
Jun 17 17:16:04	check_reload_status: Syncing firewall
Jun 17 17:16:02	check_reload_status: Reloading filter
Jun 17 17:16:02	check_reload_status: Restarting OpenVPN tunnels/interfaces
Jun 17 17:16:02	check_reload_status: Restarting ipsec tunnels
Jun 17 17:16:02	check_reload_status: updating dyndns VPNI
Jun 17 17:16:00	kernel: ue0: promiscuous mode disabled
Jun 17 17:16:00	kernel: pid 18641 (snort), uid 0: exited on signal 11
Jun 17 17:15:57	php: rc.start_packages: No pfBlocker action during boot process.
Jun 17 17:15:57	php: rc.start_packages: No pfBlocker action during boot process.
Jun 17 17:15:57	php: rc.start_packages: No pfBlocker action during boot process.
Jun 17 17:15:57	php: rc.start_packages: No pfBlocker action during boot process.
Jun 17 17:15:55	php: rc.start_packages: The command '/usr/local/etc/rc.d/cron.sh stop' returned exit code '1', the output was ''
Jun 17 17:15:51	php: rc.start_packages: Restarting/Starting all packages.
Jun 17 17:15:49	check_reload_status: Reloading filter
Jun 17 17:15:49	check_reload_status: Starting packages
Jun 17 17:15:49	php: rc.newwanip: pfSense package system has detected an ip change 0.0.0.0 -> 10.159.1.10 ... Restarting packages.
Jun 17 17:15:47	php: rc.newwanip: Creating rrd update script
Jun 17 17:15:42	php: rc.newwanip: rc.newwanip: on (IP address: 10.15.4.10) (interface: VPNI[opt1]) (real interface: ovpnc2).
Jun 17 17:15:42	php: rc.newwanip: rc.newwanip: Informational is starting ovpnc2.
Jun 17 17:15:40	check_reload_status: rc.newwanip starting ovpnc2
Jun 17 17:15:40	kernel: ovpnc2: link state changed to UP
Jun 17 17:15:39	check_reload_status: Reloading filter
Jun 17 17:15:39	kernel: ovpnc2: link state changed to DOWN
Jun 17 17:11:19	kernel: ue0: promiscuous mode enabled
Jun 17 17:08:44	SnortStartup[12975]: Snort START for WAN(34137_ue0)...
            1 Reply Last reply Reply Quote 0
            • I
              Ip Man
              last edited by

              @fearnothing:

              I had a similar issue, but it was solved by using the AC-BNFA or AC-BNFA-NQ memory setting. It was a result of snort rules updates causing the process to attempt to allocate more memory than was available.

              Now I use AC-BNFA-NQ on all interfaces and Snort has not stopped yet.

              1 Reply Last reply Reply Quote 0
              • BBcan177B
                BBcan177 Moderator
                last edited by

                @Ip:

                @fearnothing:

                I had a similar issue, but it was solved by using the AC-BNFA or AC-BNFA-NQ memory setting. It was a result of snort rules updates causing the process to attempt to allocate more memory than was available.

                Now I use AC-BNFA-NQ on all interfaces and Snort has not stopped yet.

                Dont tell  jflsakfja ,that he was right! Please.  :) Glad that its solved now.

                "Experience is something you don't get until just after you need it."

                Website: http://pfBlockerNG.com
                Twitter: @BBcan177  #pfBlockerNG
                Reddit: https://www.reddit.com/r/pfBlockerNG/new/

                1 Reply Last reply Reply Quote 0
                • I
                  Ip Man
                  last edited by

                  @Fmstrat:

                  I have had this happen quite regularly. I've narrowed it down to the fact that I have a constant connection on a VPN. When the VPN connection goes down and reconnects, snort is restarted, even though it is not tied to the VPN interface. I'm guessing it's because of the check_reload_status process.

                  Edit
                  To be more specific, an OpenVPN client is on PFSense, connected to an external OpenVPN server.

                  Edit 2
                  It could also be due to the reloading of rules depending on how you have updates set. Here's some log snippets showing what I believe to be the above issue, though:

                  Jun 17 17:18:47	kernel: ue0: promiscuous mode enabled
Jun 17 17:16:11	SnortStartup[96556]: Snort START for WAN(34137_ue0)...
Jun 17 17:16:07	SnortStartup[94480]: Snort STOP for WAN(34137_ue0)...
Jun 17 17:16:05	check_reload_status: Syncing firewall
Jun 17 17:16:04	check_reload_status: Syncing firewall
Jun 17 17:16:02	check_reload_status: Reloading filter
Jun 17 17:16:02	check_reload_status: Restarting OpenVPN tunnels/interfaces
Jun 17 17:16:02	check_reload_status: Restarting ipsec tunnels
Jun 17 17:16:02	check_reload_status: updating dyndns VPNI
Jun 17 17:16:00	kernel: ue0: promiscuous mode disabled
Jun 17 17:16:00	kernel: pid 18641 (snort), uid 0: exited on signal 11
Jun 17 17:15:57	php: rc.start_packages: No pfBlocker action during boot process.
Jun 17 17:15:57	php: rc.start_packages: No pfBlocker action during boot process.
Jun 17 17:15:57	php: rc.start_packages: No pfBlocker action during boot process.
Jun 17 17:15:57	php: rc.start_packages: No pfBlocker action during boot process.
Jun 17 17:15:55	php: rc.start_packages: The command '/usr/local/etc/rc.d/cron.sh stop' returned exit code '1', the output was ''
Jun 17 17:15:51	php: rc.start_packages: Restarting/Starting all packages.
Jun 17 17:15:49	check_reload_status: Reloading filter
Jun 17 17:15:49	check_reload_status: Starting packages
Jun 17 17:15:49	php: rc.newwanip: pfSense package system has detected an ip change 0.0.0.0 -> 10.159.1.10 ... Restarting packages.
Jun 17 17:15:47	php: rc.newwanip: Creating rrd update script
Jun 17 17:15:42	php: rc.newwanip: rc.newwanip: on (IP address: 10.15.4.10) (interface: VPNI[opt1]) (real interface: ovpnc2).
Jun 17 17:15:42	php: rc.newwanip: rc.newwanip: Informational is starting ovpnc2.
Jun 17 17:15:40	check_reload_status: rc.newwanip starting ovpnc2
Jun 17 17:15:40	kernel: ovpnc2: link state changed to UP
Jun 17 17:15:39	check_reload_status: Reloading filter
Jun 17 17:15:39	kernel: ovpnc2: link state changed to DOWN
Jun 17 17:11:19	kernel: ue0: promiscuous mode enabled
Jun 17 17:08:44	SnortStartup[12975]: Snort START for WAN(34137_ue0)...

                  Thank you for the information. I don't have a VPN but Snort will stop anyway. I will try AC-BNFA-NQ from now on. So far no problem.

                  1 Reply Last reply Reply Quote 0
                  • I
                    Ip Man
                    last edited by

                    @BBcan177:

                    @Ip:

                    @fearnothing:

                    I had a similar issue, but it was solved by using the AC-BNFA or AC-BNFA-NQ memory setting. It was a result of snort rules updates causing the process to attempt to allocate more memory than was available.

                    Now I use AC-BNFA-NQ on all interfaces and Snort has not stopped yet.

                    Dont tell  jflsakfja ,that he was right! Please.  :) Glad that its solved now.

                    It will be our little secret :-X I really hope that it works in the long run ;)

                    1 Reply Last reply Reply Quote 0
                    • F
                      Fmstrat
                      last edited by

                      @fearnothing:

                      I had a similar issue, but it was solved by using the AC-BNFA or AC-BNFA-NQ memory setting. It was a result of snort rules updates causing the process to attempt to allocate more memory than was available.

                      Interesting that this seems to be working for people. I will try switching as well, but even with AC I still have gigs of RAM free, so can't imagine its a memory allocation issue unless it's related to a bug.

                      Thanks,
                      Ben

                      1 Reply Last reply Reply Quote 0
                      • M
                        manhattanboy
                        last edited by

                        @Ip:

                        @fearnothing:

                        I had a similar issue, but it was solved by using the AC-BNFA or AC-BNFA-NQ memory setting. It was a result of snort rules updates causing the process to attempt to allocate more memory than was available.

                        Now I use AC-BNFA-NQ on all interfaces and Snort has not stopped yet.

                        I was having this problem as well, so thank you for the fix.  :D
                        Plenty of memory and CPU power in the pf box (8 gigs and 8 cores), nonetheless SNORT does seem happier with this setting change, but it is strange that random stops are occurring with other settings.

                        1 Reply Last reply Reply Quote 0
                        • I
                          ischilling
                          last edited by

                          Thanks for the AC-BNFA-NQ this seems to help us here as well.

                          I want to contribute something I observed and can reproduce:

                          Situation

                          • HW (old PC) based pfSense in a branch office

                          • Win 2012 R2 U1 based pfSense in our DC

                          Snort

                          • HW based is running stable with AC-NQ even though it has only 2 Cores and 8GB memory at all

                          • Hyper-V based is running on 12 Cores and 16GB memory, but Snort failed with AC-NQ, the AC-BNFA-NQ does the trick, now it can be not only activated (about 2minutes) faster on all interfaces, instead of one only, it now can be activated on all interfaces and it is running stable now for 3d, usually it turned itself off every 2h to 6h.

                            A strange side effect on IPSec stability?  :o

                            We reported https://redmine.pfsense.org/issues/4790 (Titel: Established IPSec Tunnel refused transporting further traffic out of sudden.. it than refuses any rule based traffic to anywhere!).

                            Even though it should be impossible from my point of view, we observed that since the only configuration change on both tunnel ends is the Snort thing it seems to be an obvious side effect.

                            This seems to be fixed now as well - and I find this is 'a bit' disturbing..

                          –-
                          doing something right means no-one takes notice.

                          1 Reply Last reply Reply Quote 0
                          • First post
                            Last post
                          Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.