Rules not working unless restart
-
Hello,
I've been experiencing this issue for the past 1-2 weeks now.
What happens exactly is : if I add a new rule, change a rule, create NAT, open port.. no matter what, I have to reboot the firewall or do /etc/rc.reload_all otherwise the rules are not working.
This happened first at 2.5.x, I've reinstalled, restored from backup all was good for 1-2 days, then the issue started again.
I replaced the ssd with another one and installed 2.6.0 - clear install, no restoration from backup. I did the rules from 0. All was working fine. Couple of days later - same behavior.
Any ideas? This is driving me insane. -
@lcs This isn't certainly the case in general.
And replacing the ssd is irrelevant too.
If it boots, and works, then ssd is ok.What kind of rules?
Have you tried clearing states after applying rules? -
@netblues When I reinstalled and did backup-restore, I thought maybe the backup file was corrupted, so I changed the entire sdd and rebuild the config from 0. The point of swapping the ssd was to have a semi-working state system with the entire rule set, if I should need those later.
I did try to clear the states, no luck.
This is happening with all rules, WAN/LAN.
Even if I change the Description of any rule, I can still see the pass/block event (if logging is enabled) with the old description.
When I reboot or reload_all the issue is fixed and I can see the updated description. -
@lcs said in Rules not working unless restart:
Even if I change the Description of any rule,
Open the content of /tmp/rules.debug in a text editor.
Now, change a LAN rules, only the description will do.
Open again the /tmp/rules.debug file in another editor - compare with the first editor.
You should find :
...... "USER_RULE: xxxxxx "where xxxxxx is your modified comment.
Btw : /tmp/rules.debug are the rules loaded into the firewall 'pf'.
-
@gertjan as of this moment it's working.
I can see the change in the file and in the UI.
I'll test later again and upload the results. -
example :
As you can see from the screenshot, the rule is disabled.
And it's still allowing traffic to pass.
No change after states reset.
Another example.
I have a NAT forwarding port 80 from public internet for acme challenge.
Traffic is blocked by a rule which was disabled.
On top of that, for some reason, I cannot open port 80 in any way anymore.
Example
I have a NAT allowing port 80
This is the firewall rule
and yet while testing from external network, the port is listed as closed.This is a capture during my tests. I can see the incomming traffic on port 80 but the rule allowing that is never triggered.
The ports are open when tested from internal network.
-
Some more details
As you can see, this alias contains ports 80 and 443
Extract from rules.debug
And after this I can see ports 80 and 443 open
-
So basically you say that any change you make isn't applied unless you reboot/update rules by hand, and you have tried clearing states too.
Clearly if this was the general case there would be numerous posts here.
Any other software used? eg squid/pfblockerng
Anything else from packages?Floating rules have a tendency to create difficult to comprehend corner cases, however behaviour is constant, and not after a couple of days.
-
@netblues I have pfblocker ng for geoblock on one of my services, which is not related to this. Even with pfblocker disabled it's the same. I tried disabling suricata - same behavior.
Yesterday the new rulleset wouldn't apply even after restart. I had to manually reload all a couple of times.This is what I got
The weird thing is, sometimes it's working just fine for days and days, and sometimes it just stops without any prior changes done.
-
@lcs FWIW, I appear to have a similar issue (using v2.6.0). This is caused for me, when I use aliases.
So, for example, I had a simple inverted block rule against a single hosts IP address, which worked just as expected. I then needed to extend this rule by adding an additional host, so a created an alias to capture both hosts IP's, then edited the original rule to use the alias rather than the original IP. I actually made a typo in the alias IP, but once it was updated to be correct, the rule was not applied as expected until pfsense is rebooted.
Just to test this, I set up a continual ping to a host in another subnet that should match the rule and be allowed to pass. Of course, this did not work, then I rebooted pfsense, as as it came up, so the ICMP message started getting through.
I was looking for a way to reload the rule set without rebooting and came across this post.
