No state tables!?!?!?
-
Let me put it another way: assuming I did have the System>Advanced>Firewall/NAT the "disable all packet filtering" is checked (which I do not), what actual system configuration file would that setting end up in? What processes would or wouldn't be running? etc.
I want to check if despite what the GUI shows me, the system is in a state consistent with that having been checked or not.-
Look around for the 'disablefilter' variable in /etc/inc/filter.inc.
-
The PHP code for that page in the gui is /usr/local/www/system_advanced_firewall.php
-
Look through the saved config xml code in /cf/conf/config.xml
-
PHP code for displaying states detail in the gui is /usr/local/www/diag_dump_states.php
Be careful.
-
-
That was over-simplified to some extent. The other two options are you've created a slew of rules that don't keep state at all, including outbound floating rules, or you had exactly 0 active connections going to or through the system (which is impossible unless you're viewing the states at the console).
-
This will show you the state table from the console (states doesn't appear to work):
pfctl -s info
Steve
Edit: Ah 'states' in in 10, 'state' is in 8.3. 'info' is probably more useful here.
-
and "pfctl -ss" to dump the contents of the state table.
-
So here's some good news and some more questions:
The good news is, I have states again.What's questionable from my POV is what fixed the issue:
I had previously played around with the traffic shaper, but never got it to work properly.
So all rules referring to any of the queues were either disabled or deleted (actually in the process of troubleshooting this, I deleted all of the disabled rules, and any other rule that still had a reference to traffic shaping.) This did NOT fix the issue.What did fix the issue, was deleting the queues that weren't referenced by anything.
Does that make sense, and why?
Also, the queues were set up by the traffic shaper wizard way back when.I would expect that queues not referenced are not used and shouldn't interfere with anything, guess I'm wrong, either because I don't the workings well enough, or because there is/was a bug or messed up configuration somewhere.
Anyone have a comment regarding the issue if this is a matter of my stupidity or some sort of bug/corrupted config file?
-
It would be easy to miss a floating rule.
Check /tmp/rules.debug.
Steve
-
Also try:
pfctl -f /tmp/rules.debug
It may print an error, and if so, correct that and try again. Could be that the bogons list is corrupt or something similar. Usually that would produce an alert, but you can check it that way also.
-
Thanks all for the various suggestions, I'll keep these handy for future reference.
However, right now, things are working again. As I said, the strange thing was, that even after trimming down the rules to next to nothing I still had no states, but the moment when I deleted the various queues that were originally set up by the traffic shaper wizard (but which I didn't use because all the relevant rules were first disabled, and then deleted), then things worked again.
So either the queues configuration was corrupt, or there's another bug that lets queues that are set up but not used in rules, affect things. I should have saved a before and after set of configuration settings, but I forgot. That would have made it easy to diff and try to figure out the issue. For the time being, as far as I'm concerned, the case is closed, but in case this point to a bug in the traffic shaper wizard or elsewhere, it's something to keep in mind that it seems that queues that according to the web GUI are unused can affect things.
-
I know this post is old, but for my particular problem (which I'll post as a separate topic) this is the top result from google and thought I would add what fixed it for me for the next person that googles lost state table functionality.
So, In 2.3.2 I had the same exact problem, 0/200k states. After someone above mentioned that you should look for errors in /tmp/rules.debug, it hit me.
pfBlockerNG on my little Intel atom 2gb RAM firewall was throwing errors in that file (but never caused a problem) because of memory allocation limits. I finally rebooted it after making a change to the memory allocation for x86 installs (it was mentioned in a thread about x64 memory allocation problems) and lost the ability to have any states in my state table.
I uninstalled pfBlockerNG and the states came back right away, so, long story short, if you suddenly lose your state tables, look at the package or sub-system causing errors in /tmp/rules.debug (in at least 2.3+ it shows in the top right as a notification) and either see if you can correct the error or uninstall the package and do without.
-
If you run the manual ruleset reload command at the CLI (or from Diag > Command Prompt) it will report the error that is causing that. Almost certainly an unpopulated alias that pfBlocker created in that case.
pfctl -f /tmp/rules.debug
https://doc.pfsense.org/index.php/Firewall_Rule_Troubleshooting#Ruleset_Loading
Steve