No state tables!?!?!?

rcfa

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.

If the system acts as if that setting were set, even though it's not, then we have found some sort of GUI bug (and need to figure out what triggers it). e.g. maybe a setting is duplicated in some config file, and the UI always only acts on the first instance, and thus the second instance which is never changed permanently overrides whatever line the UI keeps changing.

If the system is set up the way it should be, and there are still no states, then the question is, what else is going on.

charliem

@rcfa:

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.

cmb

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).

stephenw10

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.

cmb

and "pfctl -ss" to dump the contents of the state table.

rcfa

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?

stephenw10

It would be easy to miss a floating rule.

Check /tmp/rules.debug.

Steve

jimp

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.

rcfa

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.

rudger_wolvram

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.

stephenw10

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