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

    Issue with SNORT

    Scheduled Pinned Locked Moved IDS/IPS
    11 Posts 2 Posters 1.9k Views
    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.
    • bmeeksB
      bmeeks
      last edited by

      I think you have a configuration problem with that firewall.  Looks like something got corrupted.  That error about the snort2c table is from pfSense and not Snort.  That table is a built-in automatically created pf table that pfSense creates during boot up.  It will exist whether you install Snort or not.  That fact it is missing means something is really hosed with the firewall setup.  Maybe try restoring the config.xml file from earlier if you have automatic backups enabled or have a manual backup.

      Bill

      1 Reply Last reply Reply Quote 0
      • D
        dbennett
        last edited by

        Thanks for replying bmeeks!!

        Update to this:  Each boot seemed to produce a different result.  when I was FINALLY able to get to the menu and reset defaults it would sit there for a long time.  After it finally rebooted, the configuration didn't reset and my interface IP's came back.  At this point, I didn't trust it and I factory reset it again and it booted right away and reset.
        Changed the LAN ip so I could access the GUI, imported the configuration and rebooted.  Booted up fine.

        What type of configuration issues could I have that would cause this?

        Thanks again for your insight.

        Dino

        1 Reply Last reply Reply Quote 0
        • bmeeksB
          bmeeks
          last edited by

          I'm not sure what the original issue was, but I sort of think Snort was not the root cause but rather a "victim" of the configuration corruption.  What pfSense version were you coming from?  Was it a much older one where the config files would be different?  The symptoms you describe of bootup failure are not likely to be caused by the Snort package (I never say "impossible", but it is extremely remote that Snort would cause a failure to properly boot).

          Bill

          1 Reply Last reply Reply Quote 0
          • D
            dbennett
            last edited by

            The update was a simple 'patch'.  Moving up from 2.3.3_1  to 2.3.4.  I've upgraded 5 other firewalls, two of which were almost identical in role and settings but at a different location.

            If the file was deemed to be missing, how would doing a factory reset of the configuration suddenly find that file?

            Again, I realize I am giving little in way of substance to review to help answer my question but do appreciate your attempt.

            1 Reply Last reply Reply Quote 0
            • bmeeksB
              bmeeks
              last edited by

              When you say "factory reset of the configuration", if you mean what I think you do, then the firewall starts with an out-of-the-box default configuration file.  So it would have created a new config.xml file, but only with default settings in it.  When you restore your own config.xml via the backup/restore menu option, then that overwrites the factory-default file.

              Bill

              1 Reply Last reply Reply Quote 0
              • D
                dbennett
                last edited by

                Yes and that was exactly what I wanted to do.  Though the question remains how did snort2a get rebuilt if it has nothing to do with SNORT?

                I'm trying to understand pfSense better thus the reason for all the questions.  Thanks again for your time.

                Dino

                1 Reply Last reply Reply Quote 0
                • bmeeksB
                  bmeeks
                  last edited by

                  @dbennett:

                  Yes and that was exactly what I wanted to do.  Though the question remains how did snort2a get rebuilt if it has nothing to do with SNORT?

                  I'm trying to understand pfSense better thus the reason for all the questions.  Thanks again for your time.

                  Dino

                  The snort2c table is simply a table name created in the packet filter firewall by the pfSense code during startup.  pfSense creates a number of initial tables in pf for bogons and other reasons.  These are all generally hidden from users (but you can see them under DIAGNOSTICS > TABLES).  Do a Google search of FreeBSD packet filter tables for a general explanation of what tables are and how they work in pf.

                  That error message about the snort2c table was simply a symptom of a larger problem and was not the problem itself.

                  Bill

                  1 Reply Last reply Reply Quote 0
                  • D
                    dbennett
                    last edited by

                    Well said!

                    Soo…  Resetting the unit to factory defaults then uploading the config again didn't really fix that problem??  I pretty much feel I know the answer to this already but I'm going to ask it anyway....

                    How do I go about finding the root cause to a problem like this?  O even simpler yet, how do you troubleshoot and hunt down a problem like this?

                    Dino

                    1 Reply Last reply Reply Quote 0
                    • bmeeksB
                      bmeeks
                      last edited by

                      @dbennett:

                      Well said!

                      Soo…  Resetting the unit to factory defaults then uploading the config again didn't really fix that problem??  I pretty much feel I know the answer to this already but I'm going to ask it anyway....

                      How do I go about finding the root cause to a problem like this?  O even simpler yet, how do you troubleshoot and hunt down a problem like this?

                      Dino

                      Unless it can be reliably reproduced, finding the cause is going to be hard.  My best guess is that somehow for some reason during the upgrade of the backup firewall the config.xml file that holds the entire firewall configuration got corrupted.  That file contains pretty much all of the settings for the firewall itself along with any installed packages.  If it gets corrupted, then anything can happen to the firewall at the next boot.

                      Bill

                      1 Reply Last reply Reply Quote 0
                      • D
                        dbennett
                        last edited by

                        I guess I didn't mention that pretty much the same thing happened on the primary as well…

                        Ok.  I'll put it on a test bed and do the upgrade again to see if I can replicate it and this time check the config.xml.

                        Thanks again

                        Dino

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