Firewall Rules Order
-
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.
-
Thank You for your help - I know this is an old thread but I am stuck and needing some help!
I'm using pfBlockerNB with GeoIP filtering. I have a pfSense Allow rule that needs to precede the pfB_ Block rules on the WAN interface. I have other pfSense Allow rules that should follow the pfB_ Block rules.
The solution mentioned is to create Alias' for the pfB_ rules. And then create my own WAN rules using the Alias'. I am missing something as pfB_ Firewall Aliases URLs were automatically created by pfBlockerNG (Firewall / Aliases / URLs) and my Firewall default WAN pfB_ rules are already using these Alias'.
What am I missing? My goal is to be able to sort my WAN Firewall rules to something other than one of the four Rule Order options available in pfBlockerNG.
Running
2.4.5-RELEASE-p1 (amd64)
pfBlockerNG net 2.1.4_22Thank You for Your Help,
RKGraves -
@lordofpc734 said in Firewall Rules Order:
cant find anything named Alias native anywhere in PFblockerNG-devel
(and others)
On the IPv4/IPv6 tabs select Alias Native:
Then create whatever rules you want:
(yes I know it says v4 twice in the alias, that's an artifact when upgrading from pfBlockerNG to -devel as it adds _v4 to all the aliases)
-
@rkgraves said in Firewall Rules Order:
I have a pfSense Allow rule that needs to precede the pfB_ Block rules on the WAN interface.
Make that rule a floating one if you can't find a better solution.
-
@teamits
Thank You Very Much!When you manually create WAN Firewall rules using the Aliases created this way what do you do with the default rules automatically created by pfBlocker, just disable them?
Again Thanks,
RKGraves -
Manage them in pfBlocker, disable or delete them, if you don't need them anymore.
-
@Bob-Dig
Thank You for this tip!I can see how creating an IPv6 Floating rule (Floating rules evaluated first) would work. But can an IPv4/NAT rule work as a floating rule?
Again Thanks,
RKGraves -
@rkgraves absolutely.
-
@Bob-Dig
Thank You, I'll work on this and report back.I appreciate your time and help!
RKGraves -
Thank You Everyone!
I'm now able to manually set the order of my WAN firewall rules while running pfBlockerNG-devel with GeoIP. To verify what I did is correct, and for anyone else who might come across this thread, I'll list my abbreviated steps.
- clean pfSense install
- generated a new MaxMind key
- installed pfBlockerNG-devel
- Firewall / pfBlockerNG / IP / GeoIP - for each GeoIP location I set the Action to "Alias Native"
- Firewall / Rules / WAN - manually created IPv4 and IPv6 Deny rules using the source as the GeoIP Aliases
- Firewall / NAT / Port Forward - created my IPv4 Allow Rules
- Firewall / Rules / WAN - created my IPv6 Allow rules
- Firewall / Rules / WAN - sorted my Allow and Deny rules as needed - Saved
Tested:
- Firewall / pfBlockerNT - Save (my original install would fail at this point and remove my WAN Rules sort order - defaulting instead to one of the 4 predefined rule orders)
- Rebooted pfSense & tested
For those with more experience; Please let me know if anything I did appear incorrect.
Again, Thank You for your Help!
R.K.Graves
