pfBlockerNG Widget Counters
-
Okay here we go -- confirmation of the issue (I think) test box has 0 traffic (there are no users going though it.) But also likely not an issue.
created some basic DNSBL - fixed a DNSBL_Socials to block a few I could hit
Step 1 we are at zero
Step 2 - hit one name I know is in the DNSBL_Socials I just created
Step 3 - Clear DNSBL - notice is leaves the 2 resolver counts behind !! even after a refresh.
Step 4 - Clear DNSBL again - now they are zero again.
The issue seems related to the time stamp of the query used when looking at the resolver. Also on a very busy system, this number might be harder to trap at a zero as any resolver queries happening would be incrementing the count, even if they are not blocked. So in effect at a point in time they could be zero, but as I said earlier it won't last long.
While typing this message - the otherwise totally ideal system has already recorded 1 resolver hit from that shown in Step 4
Is the resolver hits counter resetting? I'd say - yes
Can it immediately have a value? - yes (based on timestamps and ongoing resolver queries)Likely also why my original observation was "immediately activity on DNSBL, so it doesn't stay zero very long" - could also be the resolver flushing the latest count.
Now the resolver count is up to 2 again, but no traffic blocked, and if I clear it immediately drops to zero.
I'm not convinced it is really broken - could be improved - likely / maybe.
Would have to look at the resolver's side of the update and how those values are tabulated.
Clear -> Resolver flushes count -> Dashboard refreshes shows 1000 hits (or in the case of this idle system 2) it is an illusion that it didn't actually go to zero.
Clear again -> no resolver update -> dashboard refreshes you might actually see the 0.
timing and volume of traffic.
-
@jrey Great summary. I have very aggressive blocklists, so I get a lot of blocks by the time midnight rolls around. If I happen to up, I can tell immediately if the reset is off due to the anomalies. If I reset it manually a few times, then everything is reported to the widget as it should.
I'm not overly worried about it, but yes - it could be improved. I'm guessing the 99% of people either (1) don't really look at the widget, (2) don't have the widget clearing counters, or (3) don't care. :)
Thanks again for really digging into this.
-
@DefenderLLC said in pfBlockerNG Widget Counters:
people either (1) don't really look at the widget, (2) don't have the widget clearing counters, or (3) don't care. :)
I like the widget.
I'm looking to it if there is nothing 'yellow' in there, which indicates I have to manually Force reload.
But your 1-2-3 are somewhat valid for me ^^ -
@jrey OK, so I was watching pfSense right at midnight and the IP and DNSBL query counters clear just fine. It's the DNSBL block count number that goes to 0 initially, then returns to a number that far exceeds the lookups for the 1 o 2 seconds it's takes to clear. So not exactly what you were seeing.
Oh well! Thanks for the all the effort you put in yesterday!
-
so the time stamps for "when cleared" are the same ?
does the packets blocked count on the list add up to the packets block on the summary ?
does the "far exceeds" number match (or close) to any one particular DNSBL list? (I'm assuming like me you have more than one DNSBL list (Alias))
Unbound python mode?
screen shots of the settings always help..
I changed mine from weekly to daily - no issue. everything still adds up earlier today when I checked, still adds up now.
-
@jrey said in pfBlockerNG Widget Counters:
so the time stamps for "when cleared" are the same ?
does the packets blocked count on the list add up to the packets block on the summary ?
does the "far exceeds" number match (or close) to any one particular DNSBL list? (I'm assuming like me you have more than one DNSBL list (Alias))
Unbound python mode?
screen shots of the settings always help..
I changed mine from weekly to daily - no issue. everything still adds up earlier today when I checked, still adds up now.
The DNSBL count will reset to 0 along with the DNSBL query count. What happens is that after a few seconds, the block count will jump to a large value, but not quite as high as the previous value. That's what skews the percentages. If I rinse and repeat this manually a few times, then it works as expected. Someone that only resets once per week may not notice this as much. Again, the higher the DNSBL block count, the more likely it is that this will happen.
Using Unbound vs Unbound Python mode does make any difference.
I will try and record it tonight. I'm not that worried about it at this point. It's been doing this same behavior to me on a VM and my Netgate 6100 MAX for almost 3 years.
-
You don't need to record it, I understand what you are seeing.
I also understand you're not worried about it. But clearly there is a problem and I'm offering to help try recreate the specific case causing it so that it might lead to a solution.
Using Unbound vs Unbound Python mode does make any difference.
"does not" or are you asking if it "does make" ?
FWIW - I'm running DNSBL in Unbound python mode.
Any settings you are willing to share about your DNSBL setup would be helpful.
-
@jrey What I meant was that I have used both modes at different times and the behavior is exactly the same with the widget. I am using Unbound Python mode now.
-
@jrey We can revisit this at a later date. pfBlockerNG still works. It's just the widget.
-
@jrey For the next few weeks, I am just going to be using pfBlockerNG for IP blocks and not DNSBL. I am testing out the similar functionally with Cloudflare Zero Trust. It adds the ability to inspect SSL traffic on devices where I've added the certificate.
Here's a very small example of blocks for the last hour with Cloudlfare Zero Trust:
