Rule order bug?
-
@johnpoz In theory there could be a routed network behind this network. Although as "guest" that is probably less likely than the normal amount of unlikely.
@fero1233 If you look at your saved config file for these rules, before and after the reordering, do you see anything of note? Normally rule ordering complaints are tied to automatically created rules from pfBlockerNG but you don't seem to have those in your screen cap.
-
@SteveITS said in Rule order bug?:
In theory there could be a routed network behind this network.
Which why I stated if the network was a transit/connector network ;)
-
@johnpoz said in Rule order bug?:
if I use the lan subnet or optx subnet in all of my rules, why would you use an any in blocks?
Basically, why not? It would enhance security in my opinion.
@SteveITS answered already.
A device within the subnet could act as a VPN client connecting to a remote site and would forward incoming traffic.
Sure, without additional configuration faults (not happening to you ;) ), pfSense won't route responses ever back.
However, assumed, the machine running the VPN is stated as gateway on the concerned interface, pfSense would route back any response packet to it, which has created a state before by the pass any source rule on this interface. -
@viragomann said in Rule order bug?:
Basically, why not? It would enhance security in my opinion.
How? If you do not allow the traffic, then the default deny will block it. What is the point of using any in block, when they are blocked anyway.. The habit should be to always use the source network in your rules. explicit rules are best, even just just the admin looking at the rules. Any or cidrs should be limited to where they are actually needed, ie a transit network where there would be downstream networks to be allowed.. If you were putting rules on a transit, I would create an alias or use a cider that covered my downstream networks that would be using this transit network.. So again if your allows are only allowing your networks be it directly attached or your downstream.. using any as source for deny don't really do anything, other than make your rules inconsistent when looking at them.
if you wanted to log specific traffic, ok - if you were not logging the default deny and you wanted to use the rule to catch stuff in your logs for misconfiguration of devices on the network, maybe..
I see no point in created block rules with any as source, when it makes no sense to do so. I just makes the rules inconsistent.. Sure it works and all, I just don't see the point. And it doesn't make it any more secure..
If you would provide an example scenario where it would make it "more" secure - I am all ears..
So for example here is example set of locked down network rules.
How would changing my rejects there to an any for source in any way enhance security?
if some source other than test subnets was inbound into this network, it would be denied by the default deny anyway. What would be the point in using any in my reject?
-
@johnpoz
Of course, there is all correct with your rule set. :-)How? If you do not allow the traffic, then the default deny will block it.
The point is, the TO has an allow any-to-any rule, but has the block rules restricted to the subnet.
-
@viragomann yeah the OP rules lack clarity that is for sure.. if your going to use any on your source for your allow, makes no sense to use a specific source in your deny.
Unless you had no control over what the downstream networks were using your transit. And you wanted to block a specific source network, etc. But then again all of those blocks after an any any allow are never going to be evaluated anyway.
There are many different ways to create rules that "work" but my question was to your statement to always use any in blocks.
It's recommended to enhance security to limit the source in pass rules to the respective subnet, but use any in block rules.
I am not understanding the point to that statement.
Good habits are to always be as explicit as possible in your rules.. I would never suggest an any any anything on even on a transit allow.. You should create an alias or use a cider that allows just your downstream networks using the transit.
-
Please keep replys on-topic, and discuss other issues in pm, or make a new topic. Thanks.
-
I updated the firewall to the latest version
From 23.05.1-RELEASE (amd64)
To 23.09.1-RELEASE (amd64)After i did that, and rebooted. The rules ware re-aranged wrong once again.
But then i aranged them correctly, saved and applyed. And then it seems to work now. As well in the config (thanks for that suggestion @SteveITS )
-
@fero1233 said in Rule order bug?:
From 23.05.1-RELEASE (amd64)
To 23.09.1-RELEASE (amd64)Possibly:
https://docs.netgate.com/pfsense/en/latest/releases/23-09.html#rules-nat
"Fixed: Changes in Ethernet ruleset can lead to incorrect rule and separator order #14705"
-> https://redmine.pfsense.org/issues/14705 -
@SteveITS said in Rule order bug?:
Changes in Ethernet ruleset
@fero1233 were you using "ethernet" rules - do you even have it enabled?
-
I checked the rules today, and now the rules are ordered wrong again. All the "block" are pushed to the buttom, and the allow is on top again.
I created the RFC yesterday as well, as recommended. And added it above the "Any any" rule, and it seems after a while yesterday (and if i looked in the config) that it saved the order. But this morning, it was all re-arranged again.
Are there any other/better way to achive this setup?
-
@fero1233 said in Rule order bug?:
But this morning, it was all re-arranged again.
have a look at the "config.xml" file.
There is a section that start with :
From then on, for every interface (WAN is called WAN, LAN is called LAN, the second LAN is called opt1, etc), in order ( ! ), you rules are listed as they should list in the GUI, and way more important, in the order the firewall rules are listed in 'pf'.
Having a last "pass all" rule, and then it gets listed at the top, that's a security issue (for me).
So : question : is the order in the config.xml also changed ?
If so, that would explain the miss ordering.
The question now becomes : who/what is saving the config, and what impacts the the firewall rules to be ordered differently ?What pfSense packages do you have installed ?
-
In config, it is also wrong order today. It was correct yesterday just after update/reboot/edit/save/apply
But i found this in config:
<revision>
<time>1707220801</time>
<description><![CDATA[(system): pfBlockerNG: saving DNSBL changes]]></description>
<username><![CDATA[(system)]]></username>And i am using pfblocker. So wondering if it is pfblocker, that changes the firewall(?) I might wanna try disable it.
Other plugins
-
@fero1233 said in Rule order bug?:
And i am using pfblocker. So wondering if it is pfblocker, that changes the firewall(?) I might wanna try disable it.
pfBlockerNG creates rules and rearrange the order on each update according due its settings. That's why I asked, if your have manually created the rules in my second question.
-
@viragomann said in Rule order bug?:
That's why I asked, if your have manually created the rules
Yes, on this interface all rules are created manually. There are no pfblocker rules at all, on this interface.
-
@fero1233 IIRC pfBlocker logs a config change at every cron interval. Is that when the reordering happens? Disable/reschedule its update to double check.
-
@SteveITS said in Rule order bug?:
Disable/reschedule its update to double check
I have completely disabled pfblocker for now, to test.
Will let it run like this, for a day or so. And if it works, i will try to look in to, if it is posible to disable update on that specific interface. -
@fero1233 said in Rule order bug?:
I have completely disabled pfblocker for now, to test.
Will let it run like this, for a day or so. And if it works, i will try to look in to, if it is posible to disable update on that specific interface.One thing we cannot see as you cropped the image that way is if that allow any rule is the default allow any from the LAN interface or if it's one you created yourself.
So another thing you can try would be to actually create another "pass any any" rule with a custom description so you know which one is which. Then move that below the Blocks and check if only the default/old allow is getting pushed up or if the blocks are actually pushed down to the bottom.Rule order switching is a thing I've only ever seen with pfBlocker moving rules to the top/bottom when creating automatic rules, but normally it only touches rules with "pfB_xy" aliases in them. So that would be weird. Also one thing you could check is the "Backup & Restore" / Config History Tab in case something is rolling back your configuration because of an error or something (or if someone/-thing commits a new config) - that should show who/what changes the config and why.
Cheers
-
@JeGr said in Rule order bug?:
One thing we cannot see as you cropped the image that way
There is nothing else.
This is the full image, after using RFC rule instead
So i re-enabled pfblocker again, and then removed "Guest" interface from "outbound Firewall Rules" in pfblocker
,as i really only need pfblocker on wan interface - and then it seems to be staying in order.
So for future refrence: pfblocker is the problem, and the solution is to remove that specific interface from "outbound firewall rules" in pfblocker :)
-
@fero1233 Did you change pfB off the default option? see:
Edit: if I ever don't want the default "block on top" I create lists as Alias Native which then allows me to create my own rules however I want.
There's not a default allow any rule on networks aside from LAN.
