Issue with SNORT
-
Greetings,
I have two CARP'ed firewalls. The backup was upgraded to 2.3.4. Somehow the SNORT package on the BACKUP firewall was upgraded before the primary. Apparently, their was a database incompatibility and now the boot up of the device hangs on the following.
Enter an option: Jun 5 09:21:02 snort[736]: Non ip() parameter passed with white list, skipping…
Jun 5 09:21:02 snort[736]: FATAL ERROR: pf.conf => Table snort2c does not exist in packet filter: Bad file descriptorThis repeats for at least 10 mins without interfaces loading so NO access to GUI.
When I boot to safe mode the interface IP's don't load then after a number of minutes there is some more activity (sorry don't have that post-execution) and it goes into a loop attempting to load CARP VIPs.
At this point, I power cycle the unit.
Thoughts please and thank you.
Dino
-
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
-
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
-
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
-
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.
-
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
-
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
-
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
-
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
-
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
-
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
