Firewall rules require a reboot to apply

aasimenator

Hi,

I have an SG-2440, we've had it for over 2-3 years, for the most part it has been working fine without any problems, but recently we started to see an issue where we create a firewall rule to allow certain IP address to access our network, we hit apply and then watch the filter reload process complete without any issue, but the IP address we added is still not able to access it, even if we leave it for 1 - 2 hours, It only works when we restart the entire router from "Diagnostics" > "Reboot"

We have the pfBlockerNG package installed and blocked all the countries we don't want access from, sometimes we need to allow an IP address which we know, and to be able to access our network or just a single IP address, so we create the rule to allow the access and save then apply configuration, but it doesn't work, I check the logs and it is still being blocked, also the block rule in the log doesn't list anything special just "Block/randomnumbers" also the rule order is set to "|pfSense Pass/Match | pfB_Pass/Match | pfB_Block/Reject| " so not sure why its doing that.

Restarting the entire router where we lose connection to everything is not at all ideal and we would like to know if there is a solution to this problem.

There is also another problem, if we restart the router it is stuck in boot [Not the same as BIOS password] until we enter the password for the admin account. I don't know why this is because I then have to contact our datacenter and get someone to connect a laptop and console cable to let me in and then I have to enter the admin password and then it continues to boot. I would like to remove this function, I probably implemented this somehow or at some point but i don't know how to remove it

Thanks

Aasim

stephenw10

What does it show when it asks for a password at boot?

Obviously that should not normally happen. Whenever I have seen it it's been due to either a password protected certificate being installed or an OpenVPN client where the credentials are missing.

If you do a Status > Filter Reload do you see any errors?

Steve

aasimenator

Hi,

Sorry for the delay in responding the problem automatically solved it self in a day or so. So I didn't check back here.

To respond to your question, I've already managed to solve the the password on reboot issue. that was related to OPENVPN Client config not having any password set. once I deleted that no issues in restarting anymore.

But I am still facing issues with my Firewall rules not working, the Filter Reload doesn't show any errors. see the issue below I face this with any new IP that I need to allow or bypass.

Firewall Rule:

There are no rules above these rules
1st one was manually created to allow the client to access any ip address locally within the network, 2nd one was created via the Firewall logs to allow specific access to the port 5020 of the local ip address and the 3rd one was a copy for 2nd but instead of Local IP i added the public IP address of the server.

pfBlockerNG Setting for Rule Order

But you can see below Firewall Logs the IP address is still being blocked :(

Any Help would be appreciated.

stephenw10

Ok so the destination there is a routed public subnet on an internal interface?

If you mouse over the red X in the log what firewall rule does it show is blocking that?

Steve

aasimenator

@stephenw10 Hi All it says is block/random numbers

akuma1x

@aasimenator said in SG-2440 doesn't apply firewall rules until rebooting the entire device:

@stephenw10 Hi All it says is block/random numbers

Those "random numbers" should be the tracking ID code for the firewall rule that's being used. Take a note of it, then go find the rule, is what I think @stephenw10 is getting at...

Here's what one of my firewall rules looks like, with the tracking code. It's all the way down at the bottom of the rule window.

Jeff

aasimenator

Is there a quick way to find this? as i have over 30 rules in the firewall and it would be a waste of time to go through each of them to just find the tracking id.

akuma1x

@aasimenator I don't think there's a search mechanism for finding the data you're looking for. It's been a redmine "to do" item for a little while already.

https://redmine.pfsense.org/issues/8703

Anyway, I might be wrong, since I don't know how read the data in that post very well. So, take that with a grain of salt...

On my pfsene box, I've got logging turned on for a handful of rules, and I can see what rules trigger, and then those are listed in the logs. You can find that at Status -> System Logs -> Firewall -> Normal View

(https://www.dropbox.com/s/f9xswur5fabw7gh/screenshot238976.png?dl=0)

This might be what the "bug fix" in the redmine topic actually fixed, but I'm not sure.

Hope that helps!

Jeff

aasimenator

I've checked most of the rules i have and all of them start with "15xxxxx" and none of them are with tracking id "177xxxxx"

akuma1x

@aasimenator Are you sure that's not one of your "default deny" rules, or maybe like a "block all ipv6" traffic, or the "block bogons" rules?

stephenw10

Yeah, importantly, it doesn't look like one of the default deny rules which means it's blocked by something that's been added.

Go to Diag > Command Prompt and execute: pfctl -sr -vvvv

That will show you all your rules with the tracking IDs.

Steve

aasimenator

Ok So its one of the Floating rules weird that rather than showing the description / name in the logs its showing Tracking ID which is much difficult to "track" I remember it used to show which rule is blocking the traffic before not sure why they switch to this non-intuitive way of displaying the logs, makes it difficult to troubleshoot the problem.

Anyways now that I found this, how can I allow or bypass the IP because I want my Rules to take priority not pfB's and I thought setting that in here made it so my allow rules are always first and rest will follow later.

stephenw10

It's still a floating rule which is applied before all other rules. So even if it set to be added after pfSense floating rules it will still block before the rules on the WAN interface pass it.

You can set the pfBlocker rules not to be on the floating tab. Or you could add your manual rule on the floating tab above them.

Anyway, it's blocked by pfBlocker. Mystery solved at least.

Steve