Firewall Rules Order
-
Right. If one of those options works for you on all interfaces.
-
You can adjust the FW Rules ordering in Firewall / pfBlockerNG / IP ; IP Interface/Rules Configuration ; Firewall 'Auto' Rule Order
Thanks. I'll give it a shot. Why isn't the default to allow the Pass above Block? Does it just choose the first alphabetically from the list?
-
Because if you Pass access from any to your web servers then block with pfBlocker, the block rules will not be hit.
Everyone's requirements are different.
I personally don't like the thought of a package manipulating my firewall rules.
-
Because if you Pass access from any to your web servers then block with pfBlocker, the block rules will not be hit.
Everyone's requirements are different.
I personally don't like the thought of a package manipulating my firewall rules.
Yes It's not a fit for all users. But most users tend to have simpler rules and the ordering options listed may work for them. Other options include adding the Permit rules to pfBNG so that some scenarios can work.
Otherwise, users can opt for "Alias type" rules, which will just create the Aliastable of IPs, and the user can make all of the rules as required… There is also a trick to use Auto Type rules which will create the Rules on all of the required interfaces. Then the user can manually edit each one and only change the Description to start with "pfb_" (Lowercase). Then edit each Alias to use "Alias type" ... So it saves the user from having to manually create all the rules the first time...
Other options include using the Adv. In/Out rule settings to further customize the rules....
YMMV...
-
Excellent. Thank you.
I was hoping for a way to get them all set up automatically then convert them to manual.
-
Because if you Pass access from any to your web servers then block with pfBlocker, the block rules will not be hit.
Everyone's requirements are different.
I can see that everyone's requirements are different. It just seems odd that by default the package can create whitelists but doesn't apply them in a way that works. Once you know it's an easy change but it seems inconsistent.
I personally don't like the thought of a package manipulating my firewall rules.
If you don't like packages manipulating your firewall rules then I would assume you don't use pfBlocker since that is how it functions? Is there anything that you do instead that would mimic the features?
-
The package does do something meaningful for users. Just because it is not right for YOU doesn't mean it is broken.
Use type Alias Native, let pfBlocker manage the aliases and use them in rules as you see fit.
Read all of the above again, particularly the part about changing the rule description so pfBlocker stops messing about with them.
-
The package does do something meaningful for users. Just because it is not right for YOU doesn't mean it is broken.
Use type Alias Native, let pfBlocker manage the aliases and use them in rules as you see fit.
Read all of the above again, particularly the part about changing the rule description so pfBlocker stops messing about with them.
You misunderstand. It's working after changing the rule order. I'm just wondering why the default rule order is the one chosen as default. I realize it isn't broken. It just seems odd to me that the default order makes the white listing ineffective. It seems to me that a different rule order would be better suited to be default. I was just asking what the reason was for this particular order to be default. I wasn't stating it was broken. I was merely speculating a question.
-
The package does do something meaningful for users. Just because it is not right for YOU doesn't mean it is broken.
Use type Alias Native, let pfBlocker manage the aliases and use them in rules as you see fit.
Read all of the above again, particularly the part about changing the rule description so pfBlocker stops messing about with them.
You misunderstand. It's working after changing the rule order. I'm just wondering why the default rule order is the one chosen as default. I realize it isn't broken. It just seems odd to me that the default order makes the white listing ineffective. It seems to me that a different rule order would be better suited to be default. I was just asking what the reason was for this particular order to be default. I wasn't stating it was broken. I was merely speculating a question.
YMMV… The default is what was the original setting from v1 of pfBlocker... so its never been changed... I'll consider some changes to the code to possibly a notice message when a Permit rule is added to check the rule order settings.... No matter what is selected it will work if your case, but possibly affect other scenarios.... There are too many options to make an "easy button"....
-
The package does do something meaningful for users. Just because it is not right for YOU doesn't mean it is broken.
Use type Alias Native, let pfBlocker manage the aliases and use them in rules as you see fit.
Read all of the above again, particularly the part about changing the rule description so pfBlocker stops messing about with them.
Also keep in mind that users can use other "Alias type" options, like "Alias Deny" which will do the same thing, but utilize deduplication/suppression etc…
-
You can adjust the FW Rules ordering in Firewall / pfBlockerNG / IP ; IP Interface/Rules Configuration ; Firewall 'Auto' Rule Order
The only problem is that there is no order option which would place pfSense pass and block rules above pfBlockerNG rules
pfBlockerNG rules always pushes "block" rules on the bottom and this seems like a problem. -
You can always add the pfSense Blocked IPs to a pfBlockerNG customlist instead…. Then no need for a different Rule order option.... Plus these IPs will be deduplicated with the other IP Feeds in use...
-
You can always add the pfSense Blocked IPs to a pfBlockerNG customlist instead…. Then no need for a different Rule order option.... Plus these IPs will be deduplicated with the other IP Feeds in use...
I guess I don't know how to make it happn and you can elaborate a bit.
I have rules like this => https://snag.gy/HceE21.jpg
(One rule allow DNS to pfSense only and other block all non pfSense DNS quires)When pfBlockerNG updates or reloads and resorts rules it actually inserts pfBlockerNG rules before pfSense block DNS rule.
I tried all options, including using Floating Rules in pfBlockerNG and so far found no remedy (logged a feature request that I believe would help https://redmine.pfsense.org/issues/8279).
So @BBcan177 pls elaborate.
-
You can create a new alias in pfBlockerNG and add "0.0.0.0" which is equivalent to "any" IP, into the custom list…
Then edit either the Advanced Inbound or Outbound Firewall rule settings to configure the balance of the rules options...
You can then define this Alias Action setting to Permit or Block...
You can drag the Aliases from the IP tab to re-order as you wish.
Also as stated above, you can use "Alias Type" rules and create all the rules manually.
-
You can create a new alias in pfBlockerNG and add "0.0.0.0" which is equivalent to "any" IP, into the custom list…
Then edit either the Advanced Inbound or Outbound Firewall rule settings to configure the balance of the rules options...
You can then define this Alias Action setting to Permit or Block...
You can drag the Aliases from the IP tab to re-order as you wish.
Also as stated above, you can use "Alias Type" rules and create all the rules manually.
Thank you! But I have more questions then answers to those steps, need more info.
It seems overall the rules order in combination with pfB has room for improvement :D
-
You can create a new alias in pfBlockerNG and add "0.0.0.0" which is equivalent to "any" IP, into the custom list…
Then edit either the Advanced Inbound or Outbound Firewall rule settings to configure the balance of the rules options...
You can then define this Alias Action setting to Permit or Block...
You can drag the Aliases from the IP tab to re-order as you wish.
Also as stated above, you can use "Alias Type" rules and create all the rules manually.
I don't know but all those changes seem too much and too complicated.
Here is my example, I want to keep untouched rules order to make all network clients to use pfSense router as DNS server like:
pass - Allow DNS to pfSense only
block - Block all DNS not to pfSenseAnd every time pfBlockerNG updates, my "block" rule get pushed to the end of the list.
It seems wrong to me regardless of workarounds. As I described in this https://redmine.pfsense.org/issues/8279
Why won't we either
1 - in pfBlockerNG, Rule Order add option - "Do not change (preserve) existing order"
or
2 - in Firewall Rules <if>add say a check box "Preserve existing order", which will not allow the order to be changed.
???</if>
-
Floating rules are evaluated first - or at least they were a few years ago.
I had to solve this problem a few years ago. Make the rules that get moved downward into floating rules. Then change the evaluation order of the others as needed using built in tools.
I don't have this problem today but I'm sure the answer is still correct.
-
Maybe im being stupid but, i cant find anything named Alias native anywhere in PFblockerNG-devel
-
Firewall rules are shown as a list on the Rules tab. The rules are applied from top to bottom, and the first rule that matches the traffic overrides all the other rules below. The main principle is to allow only the needed traffic and block the rest. Therefore, the last rule of a firewall profile is the Deny rest rule dgcustomerfirst
-
Would it be possible to add a "rule order" option "manual order" where pfBlocker would not reorder the rules automatically? Insertion of any new rule might be to the "original format" but if the user reorders the rules manually in the Firewall Rules interface, those changes would persist.
