PfBlockerNG rules is going downwards in the firewall rule everyday
-
Ah sorry we misunderstood that. Here is the attachment.Thanks.
![firewall rules.jpg](/public/imported_attachments/1/firewall rules.jpg)
![firewall rules.jpg_thumb](/public/imported_attachments/1/firewall rules.jpg_thumb) -
Wonderful. And - the problem is? I cannot see any problem there. It exactly matches pfBNG settings.
-
@souradip:
We have a pfBlockerNG rules , that is ordered as normal in the settings . The rule is automatically ordered downwards and we need to move it upwards in the firewall stack manually everyday at 12:00AM hours. Please help in this regards.
Which rule(s) are you moving each day?
-
We are moving the underlying rule in a daily basis at the top of firewall stack.
-
Yes. That is by design and as configured. Sigh.
-
What Souradip is saying is that he has to manually move the Block rule to the top after the automatic ordering routine fires. The ordering routine actually does not move the Block rule to the top. It moves it down. The screenshot he is presenting is to highlight the rule that has to be manually moved to the top ever night.
-
souradip roy,
Goto the IPv4 tab, and Click-Hold-Drag the Block rules to the Top so that they are first. Save.
Repeat that for the IPv6 Tab.
Then execute a "Force update"
-
souradip roy,
Goto the IPv4 tab, and Click-Hold-Drag the Block rules to the Top so that they are first. Save.
Repeat that for the IPv6 Tab.
Then execute a "Force update"
The issue was that a rule was created at Floating rule tab, and moved to the top, but once pfBlockerNG updates the rules. all the non-pfBlockerNG rules should be on the top were moved to the bottom, while all the pfBlockerNG rules were on the top, which shouldn't be. Thats the major issue using pfBlockerNG.
-
The issue was that a rule was created at Floating rule tab, and moved to the top, but once pfBlockerNG updates the rules. all the non-pfBlockerNG rules should be on the top were moved to the bottom, while all the pfBlockerNG rules were on the top, which shouldn't be. Thats the major issue using pfBlockerNG.
Dude. That is NOT how it works with what the OP configured. OMG… Select the proper option there. Not the one that puts pfBNG rules on the top by design. Really.
-
Hi ,
We are still in the same state of problem after following your advise. It would be very kind of yours if you can suggest any thing else to fix this.
Thank you in advance.
-
Yeah, you are in state of problem because you have selected the WRONG ORDER. Looks at the OTHER options there. Pick one that fits your needs. The one shown on your screenshots is NOT the one you want. Possibly you want this one instead:
-
Yeah, you are in state of problem because you have selected the WRONG ORDER. Looks at the OTHER options there. Pick one that fits your needs. The one shown on your screenshots is NOT the one you want. Possibly you want this one instead:
Don't know whether you have tested it or not before helping others. I had exactly the same rule order setting as you mentioned, BUT after pfBlockerNG updates its rules. the rules order at Floating rule tab were not right. All the non-pfBlockerNG rules supposedly on the top were moved to the bottom, all the pfBlockerNG rules were placed on the top.
-
The current setting is the default. Doesn't that option mean to keep the BLOCK/REJECT rules at the TOP? It is not doing that. It is MOVING THEM DOWN AUTOMATICALLY.
-
The current setting is the default. Doesn't that option mean to keep the BLOCK/REJECT rules at the TOP? It is not doing that. It is MOVING THEM DOWN AUTOMATICALLY.
Hopeless. Explained ~10 times by now.
@pfcode: Need a translator, perhaps? Getting absolutely ridiculous. With what the OP configured, yes, it will ALWAYS get moved. Because he configured that this way. PEBKAC. OSI Layer 8 error. ::)
-
Hi, BB
Got your file. It worked like a charm. Thanks much for the fix, well done.
-
The current setting is the default. Doesn't that option mean to keep the BLOCK/REJECT rules at the TOP? It is not doing that. It is MOVING THEM DOWN AUTOMATICALLY.
Hopeless. Explained ~10 times by now.
@pfcode: Need a translator, perhaps? Getting absolutely ridiculous. With what the OP configured, yes, it will ALWAYS get moved. Because he configured that this way. PEBKAC. OSI Layer 8 error. ::)
I don't think you've explained anything at all here. The option selected is supposed to ensure that BLOCK/REJECT rules are at the TOP. It does not do that. The BLOCK/REJCET RULE IS BEING MOVED DOWN!!!! What exactly do you think you have explained?
-
OMG. No, the option will put whatever pfBNG rules to the top. There clearly is a whole lot of people who should never use this package, because it's way over they head and they have no clue what they are doing. Those "I've blocked the entire world minus my country" guys are another example.
P.S. Need a replacement keyboard? Seems like you have a key stuck.
-
The block/reject rule to which I am referring is a pfBNG rule, is it not? It is named pFB_Block_IPs. According to your statement and to the wording of the actual automatic ordering option, it should be placed at the top of the firewall rule stack. The ordering rule looks like this:
pfB_Block/Reject | All other rules | Original format
Does that not mean that the pfB_Block rule would be first?
-
I made a few changes to the rule ordering code… When using the first order format, it will put the pfB Block/Reject before the pfB Permit rules... also a couple other improvements...
You can fetch the changed files from my gist:
First copy the existing file as backup:
cp /usr/local/pkg/pfblockerng/pfblockerng.inc /usr/local/pkg/pfblockerng/pfblockerng.inc.bk
Fetch the new file and execute a 'Force Update' cmd:
fetch -o /usr/local/pkg/pfblockerng/pfblockerng.inc "https://gist.githubusercontent.com/BBcan177/cf6af30af46fedd37d07/raw"
-
that seems to be working on our server that had the issue
did you do any other changes to the package, other then the ordering issue ?
should i be aware of any other issues ?
finally, id love if you can add support for FQDN in a list, and have a "resolver" resolve the FQDN every x amount of time, and the resolved IP should be whitelisted or blacklisted, based on the rules of the list
?