Firewall rules require a reboot to apply

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