Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

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

    Scheduled Pinned Locked Moved pfBlockerNG
    4 Posts 2 Posters 419 Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • ?
      Guest
      last edited by

      #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

      1 Reply Last reply Reply Quote 0
      • NollipfSenseN
        NollipfSense
        last edited by

        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)

        pfSense+ 23.09 Lenovo Thinkcentre M93P SFF Quadcore i7 dual Raid-ZFS 128GB-SSD 32GB-RAM PCI-Intel i350-t4 NIC, -Intel QAT 8950.
        pfSense+ 23.09 VM-Proxmox, Dell Precision Xeon-W2155 Nvme 500GB-ZFS 128GB-RAM PCIe-Intel i350-t4, Intel QAT-8950, P-cloud.

        1 Reply Last reply Reply Quote 0
        • ?
          Guest
          last edited by

          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

          1 Reply Last reply Reply Quote 0
          • ?
            Guest
            last edited by

            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

            1 Reply Last reply Reply Quote 0
            • First post
              Last post
            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.