Pfblockerng suddenly starts associating lists to rules incorrectly

  • Below is a screenshot that shows the problem. You'll see that the denied traffic is because of rule BadIP which has the countryUS list. When looking at the alias badIP, there isn't a countryUS listed. The firewall has been working fine for months up until today people noticed it was blocking random stuff. After digging deeper, it appears pfblockerNG got its wires crossed somehow and I can't figure out how to rectify it.

    I've tried:

    • rm -rf evernything under /var/db/pfblockerng
    • disabling : De-Duplication , Aggregation of CIDRs, and Restore previous download on failure
    • rebooting
    • Force reload of all types
    • and probably lots more

  • Moderator

    Hi bbrendon,

    To clear out pfBNG its best to "Disable pfBlockerNG" and Uncheck the "Keep Settings" and Save. This will clear out the files properly, including Rules and Aliases.

    Once you do that, re-enable and see how that goes. I would also suggest not using Sigma Lists as they seem to be unreliable. There is a post here to add approx 50 Lists:

    In your screenshot, you show "CountryUS". Is this from another pfBlockerNG alias? All of the alerts that you show are being blocked by that list, and its not shown in your "BadIP" alias.

  • I tried clearing using your method. Then forcing everything. Same results. Its still blocking traffic and the countryIP is showing up under BadIPs in the alerts tab.

    Yes, countryUS is an alias for a different rule. I'm confused because badIP doesn't have countryUS listed. I'm not sure why badIP is absorbing an alias from a different rule. Seems very strange to me.

  • Moderator

    The pfBNG Alerts tab takes its info from the pfSense Firewall Logs. Clear the pfSense Firewall log and start fresh.

    Does the alias that has the "CountryUS" have logging enabled? Is that alias set to "Deny" or "Permit"?

  • Summary: no change.

    I cleared the firewall log.

    goodCountries has logging enabled. Its list action is "Alias Native". I recall I have a manually configured FW rule that uses this alias. I haven't touched this part of the setup.

    If I set the badIPs list alias to "list action disable", things work okay. But then I don't get the added security.

  • Moderator

    The Alerts Tab will search the Deny folder for a blocked IP and report that List as a match. If it doesn't find a match in the Deny folder, it moves to the "Native" folder and tries to find a match there. Since the "CountryUS" is a safe list, I would suggest using "Alias Permit" instead of "Alias Native".

    You can run these command to see which IPs might be blocking    199.67.217.x :

    grep "^199.67." /var/db/pfblockerng/deny/*


    grep "^199." /var/db/pfblockerng/deny/*

    note - I already mentioned that Sigma lists are problematic….

  • Okay, so I'm guessing that the rule has to be enabled for these commands to work…

    I set badIPs alias to deny both.
    Then clicked force update
    then clicked force cron
    the click force reload

    The 199.67 grep yields no results.
    The 199 grep yields lots of results

    Using the command below, I don't see any subnets that would cause the deny, though I just looked manually. I don't know of a program to do it.

     grep "^199\." /var/db/pfblockerng/deny/* | grep '/[0-9]' | awk -F":" '{print $2}'|sort

    and the output…

  • Moderator

    I don't see anything either that would trigger an alert to that IP… Try to run the same commands in this folder?


    These are the aliastable files that pfSense uses to block with.


    Force Update: will download any Lists that have not been downloaded.
    Force Cron: will download any list that is within the "Frequency" setting to be downloaded or any list that has not been previously downloaded.
    Force Reload: Reloads the originally downloaded file and if not found downloads a new copy of the list.

    So you don't need to hit all of those buttons :)

    If you browse to  or    or    do you get any new blocked alerts?

  • : grep "^199.67." /var/db/aliastables/*

    : grep "^199." /var/db/aliastables/* | sort

    Okay, now if I goto the website that I couldn't before its coming up as IP
    That shows its blocked by badIP-sigma_1.  is blocked by badIP-countryUS is blocked by badIP-countryUS  is blocked by badIP-countryUS (you asked the same one twice)

    I wonder if the problem is that the IP is in the sigma list but there is a bug in the log reporting?

  • @bbrendon:

    I wonder if the problem is that the IP is in the sigma list but there is a bug in the log reporting?

    Guess not. I could only find: pfB_goodCountries.txt
    …which references to the

    I wonder if there is an auto-update that was installed that broke something. This is super bizzare.

    I also rummaged through the syslog server for anything reported from the FW recently... I didn't find anything interesting.

  • Moderator

    Did you change the "goodCountries" alias to "Alias Permit"? Are you sure that you set the firewall rules for this to "Permit"? Re-check your firewall rules including the Floating tab? I don't expect there to be any issue with how pfSense or pfBNG is handling the reporting. If you are still having issues, post more screenshots of what your doing? Its only going to block on the rules that you have enabled as "Block/Reject" and only on the IPs that are listed in those aliastables.

    I also suggest to disable all Sigma lists and follow that with a "Force Reload".

  • It appears removing sigma is fixing it (or a workaround, depending on the interpretation. heh)

    If I disable BadIP auto-rule in the firewall rules area (WAN/LAN), then things work correctly. There must be a bug somewhere in the reporting though (or elsewhere), because it says a different alias (goodCountries) is the cause of the block. If I enable/disable that one, there is no change in the blocking, so its obviously mistaken.

    The only other thing I can think of is the rule goodCountries rule… it says "if NOT goodCountries", then block. Maybe the "if not" is somehow  exposing a bug?  goodCountries is an "alias native" type in pfblockerng.

  • I'm still baffled. I searched for in the sigma lists very thoroughly and I guarantee you its not in there. Maybe the alias has too many lists and its too big causing some kind of problem?

    Please tell me I'm crazy or there is a bug somewhere. I need closure :)

    These are this lists, and Sigma isn't at fault here.




  • I don't know why you remove the blocklist's URL in the picture…
    But looking at, it seems these lists are generated by, so why not use the iblocklist directly?

    I downloaded the atma list, and I got a CRC error in 7-zip when I extracted it.
    As you mention you use "Alias Native", this maybe be part of your problem.

    Take a look at the files in /var/db/pfblockerng/* to debug what is happening with these tables.

  • Is the crc error maybe causing the problem? I couldn't uncompres  one of the files on Linux and winrar didn't report a problem. Seemed odd but I was hunting for IPs.

    What am I looking for in the alias native list? That one appears to be working fine.

  • Moderator


    Just like Ronpfs has said, it makes no sense to use Sigma Lists. I even stated that several times in this thread… See the following thread from February 10, 2015:

    Not to mention that their website code hasn't been updated in over 2 years:

    From this link you posted earlier:,drop,spyware,pedophiles

    With a gunzip command it fails with the following error:  gunzip: invalid compressed data–length error

    There seems to be some issue with how Sigma Lists is compiling the four selected lists. If you drop any one of those lists from the URL, it doesn't seem to corrupt the file.

    pfBlockerNG uses PHP gzopen/gzgets commands to extract this file and doesn't seem to show any errors when extracting this file and continues to processes the file. I assume that when Sigma Lists is compiling the four lists that you selected (webexploit,drop,spyware,pedophiles) that Sigma is stripping some data from a line between one of those sigma lists.

    I went thru the file and found this line:      (Start IP: End IP:

    So i would assume that it should be a /32 mask instead of a /3. So with this address in the blocklist, you will now understand that it would block and as its within the blocked range above. Its actually going to block anything from to

    I will look for a better solution to check gz files, probably just a (gunzip -t) command before attempting to extract the file so that it just reports a download failure instead of extracting a bad file.

    The other issue that you have is that you put the Country file in the "Alias Native" format instead of "Alias Permit" format.

    Hope this resolves this once any for all…. :)  So please change the Alias format and Remove all reference to Sigma lists....

  • In this case I wasn't concerned about the sigma list because I thought you meant by being unreliable it generated false positives, not corruption. We proved it wasn't the IPs in the list that were the problem, so I dismissed sigmalist as the problem. I didn't expect corruption to join the party. I guess it's good you discovered it because this could potentially happen with any other list, not just sigma.

    That was very good sleuthing! When I extracted the file on windows the smallest network in the list was a /10.

    Can I add a bug/feature report somewhere to add corruption checking on compressed lists?

    The country file is in the alias native so I can customize the order. see image i sent you. I''m assuming this is okay.

    EDIT: What about the sigma block showing up as a goodCountries alias in the log? Is this resolved because of the corruption or is this caused because of the way I'm using aliases? (or is there a 3rd option?)

    EDIT2: I couldn't stand that /3 got by me so I re-added them to pfSense and you're right. (should I be surprised I got a different result on windows?) . Wish I sorted by network size to begin with!

    EDIT3: Dug in some more to see whats up with the Alerts tab. I'm not sure how this works but based on how slow the page loads, I'm guessing that the block list information isn't stored in a logfile but instead the blocked IP is matched to a list dynamically so depending on how that works, I'm guessing a corrupt list could cause the log to malfunction. It seems to be working fine as of now. I looked through a few pages and looks like I would expect.

Log in to reply