pfSense - pfBlockerNG GUI integration issue
-
Just posting to describe an integration (or usability) issue I noticed while repeatedly trying to delete a firewall rule. I'm fairly sure it's hiding perniciously under various requests and cries for help on this forum. So hopefully this note can feed an adjustment to the GUI in some future release. I'll describe the unsuspecting, overly trusting noob use case that's brought me here.
I inadvertantly added a list of Internic DNS root servers as a pfBlockerNG feed. (Stop laughing.) The result showed up as firewall rules for each interface under /firewall_rules.php, and these presented as if they were subject to the various knobs and switches on the page for managing the firewall rules. Trouble is, the knobs and switches do NOT actually function. I was able to delete the rule, invert it to a "pass," move it in the order, etc. Save, apply, whatever all appeared to function. More precisely, they only TEMPORARILY changed the ruleset as intended. Inverting the rule to "pass" and moving it in the order actually did work for a few hours or so. However, after the passage of time or a reboot, the original blocking rules automagically reappeared.
OK, so what's the issue? Basically, it's a UI/UX fustercluck. /firewall_rules.php should NOT offer the various methods for changing pfBlockerNG-controlled rules. Far better would be an indication the knobs and switches are disabled, or at least offer guidance sending the user to the pfBlockerNG pages to just delete the "feed" item altogether.
-
@Lost-and-Confused said in pfSense - pfBlockerNG GUI integration issue:
Just posting to describe an integration (or usability) issue I noticed while repeatedly trying to delete a firewall rule. I'm fairly sure it's hiding perniciously under various requests and cries for help on this forum. So hopefully this note can feed an adjustment to the GUI in some future release. I'll describe the unsuspecting, overly trusting noob use case that's brought me here.
I inadvertantly added a list of Internic DNS root servers as a pfBlockerNG feed. (Stop laughing.) The result showed up as firewall rules for each interface under /firewall_rules.php, and these presented as if they were subject to the various knobs and switches on the page for managing the firewall rules. Trouble is, the knobs and switches do NOT actually function. I was able to delete the rule, invert it to a "pass," move it in the order, etc. Save, apply, whatever all appeared to function. More precisely, they only TEMPORARILY changed the ruleset as intended. Inverting the rule to "pass" and moving it in the order actually did work for a few hours or so. However, after the passage of time or a reboot, the original blocking rules automagically reappeared.
OK, so what's the issue? Basically, it's a UI/UX fustercluck. /firewall_rules.php should NOT offer the various methods for changing pfBlockerNG-controlled rules. Far better would be an indication the knobs and switches are disabled, or at least offer guidance sending the user to the pfBlockerNG pages to just delete the "feed" item altogether.
Every time pfBlockerNG runs any kind of automatic update, it will rearrange and re-establish all of the automatic firewall rules it created as a result of your IP list managment configuration.
The way to stop this is to have pfBlocker create and populate aliases that you then use in your own firewall rules. Tell pfBlockerNG to NOT auto-manage its own rules.
I'm not a pfBlockerNG user, so I can't tell you the exact key clicks required to accomplish this. You can visit the pfBlocker sub-forum in the PACKAGES section of the Netgate forums site for more details or to find an experienced pfBlockerNG user.
-
@Lost-and-Confused said in pfSense - pfBlockerNG GUI integration issue:
(Stop laughing.)
Sorry. To late.
As @bmeeks : rules, aliases, and 'things' added by pfBlocker are maintained by pfBlocker.
True, if pfSense was "pfBlocker" aware, prohibiting rule editing could help those who can't see the obvious ;)
-
@bmeeks -- Awesome, good to know.
-
@Gertjan -- I have no complaints about there being a learning curve for the tool. I'm simply noting the UI/UX has some flaws. Non-functioning knobs and switches should be bothersome to any engineering team. It's particularly bothersome for end users with jobs that don't center on futzing around with pfSense-based firewalls on a daily basis.
<snark>You've got a funny sense of "obvious." So you'd be ok having a fake fire hydrant in your front yard, huh? That'll be "obvious" when it doesn't work. Wrong pattern on your gear shift knob -- that'd be obvious. Put a "reboot" label on a "factory reset" function. Maybe re-arrange black, white, red, and green in your service panel! That'll also give you "obvious" when you least need it. </snark>
-
An important thing to remember and learn about the pfSense environment is that packages (the vast majority of them, anyway) are contributed and maintained by volunteer programmers in the true spirit of open-source. Therefore the amount of "integration" between a given package and the core pfSense firewall system is pretty much totally up to the package author/maintainer. The folks who create the pfSense firewall itself pretty much have zero to do with how individual packages operate.
So the issue you see with pfBlockerNG is not something the core pfSense developers have any control over unless they were to take over the package from its creator/maintainer.
The proper place to direct your input about the behavior of the pfBlockerNG package would be to the developer and maintainer of that package. He can generally be found in the pfBlockerNG sub-forum under the Packages forum here. I believe he also maintains a Reddit feed for that package.