[SOLVED] MAXMind NAmerica IPv4 bad data deletes entire pfSense FIlter



  • #1
    Firstly pfBlockerNG is very powerful and I wish to commend the developer for his work. I don't see how one person is able to manage development and maintenance of such a package for free …

    I just had an issue where I added North America IPv4 selections from GeoIP and the update process completed successfully.  Moments later a screen notification flashed on the WEBGui indicating bad characters in the NAmerica filter set. Then I looked at the rules tables for all interfaces and they had vanished.

    Unfortunately I did not pay enough attention at the time to message, and can't find the log file it would reside in under /var/log on pfSense

    So my questions are how are we validating downloaded data sets for integrity ?  Would a form of sand boxing be beneficial ? 
    Does MaxMind provide a checksum file for downloads so a developer could easily run hashes on the downloads as an initial integrity check. 
    Is there a undiscovered bug in the update filter command ?  Is it possible to turn on verbose logging for the filter update command and log it somewhere ?

    Thanks in Advance



  • Go to Firewall >PfblockerNG, then click on log you want to view and give a few seconds to load…see pic.

    ![Screen Shot 2018-03-19 at 9.48.42 PM.png](/public/imported_attachments/1/Screen Shot 2018-03-19 at 9.48.42 PM.png)
    ![Screen Shot 2018-03-19 at 9.48.42 PM.png_thumb](/public/imported_attachments/1/Screen Shot 2018-03-19 at 9.48.42 PM.png_thumb)



  • Thanks for the suggestion, but this was the first place I looked.

    It is an error message about the filter reload - I think I may have lost the message by re-sizing the system.log, before I realized the importance of the message about the filter error bad characters. Which I am writing off as an error due to packet loss creating download file corruption. Something I saw a lot of that day, bad cable connection.

    #2
    I am still having other problems with pfBlockerNG including being totally unable to use TLD blacklist with normal TLD's such as CN, RU - etc bizarre errors such as

    /var/unbound/pfb_dnsbl.conf:5: error: unknown keyword '.cn'
    /var/unbound/pfb_dnsbl.conf:5: error: unknown keyword  '60'

    when I force an update

    I know TLD Blacklist is meant for TLD's only, but it used to work for any FQDN as well - I understand now that Custom DNSBL Lists for FQDNs are where I do that.

    I have also tried completely removing and then installing pfBlockerNG to no avail. This module has been very problematic for me recently, I don't know why. I ditched 2 years worth of config and have started from scratch, but still getting the above stated unknown keyword error is frustrating

    So now TLD Blacklist  wont work for anything. –  Going to reflash the entire device, since I do have the USB for that already made, and start all over again ..... with a restore.

    Need to re-size the swap file anyway



  • Solved the problem - it seems when I started looking at others peoples problems and offering suggestions I saw mine in a new light

    I had Alexa TLD exclusions selected - several of them
    I removed all exclusions and TLD is back working just fine

    Though I will be putting custom FQDN's I want to block into the proper category - DNSBL Feeds -  from now on

    To summarize - packet loss was the first issue + configuration error on my part the second


Log in to reply