pfBlockerNG-devel | Resolver settings | pfSense crashing / Not resolvable



  • Hi there,

    I see threads covering the issue I have run into with DHCP leases specifically restarting unbound but none along the lines of where pfsense crashes and/or isn't resolvable after settings are changed under the DNS resolver (once pfsense has been enabled and configured with lists etc.).

    The only way I can manage to make changes to the DNS Resolver settings is by rebooting my pfsense and disabling pfblocker momentarily to make the changes and then re-enabling/downloading the lists.

    Has this bug been reported before or is this something that I am unaware of and should be doing differently? I've tested this somewhat a reasonable amount from clean installs and I feel it's in relation to the unbound conf file and pfblocker interrupting those changes .

    Regards



  • Seen this behaviour a few times.

    After saving the Resolver settings, it run unbound-checkconf for about a minute.
    Then when you click on Apply change, it try to stop unbound but it does exit nicely, it's stuck with the HardDrive LED on until I kill -9 unbound from a shell.

    It looks like unbound-checkconf grabbed all the memory and unbound is kinda swapping trying to exit. I tried to wait 2-3 minutes before Apply change, same hanging of unbound.

    Maybe one workaround would be to stop unbound from the Services tab, before applying the changes in Resolver tab. If unbound doesn't exit nicely, then kill -9 unbound, then save Resolver settings.

    Remember to open the WebGUI with the IP of the firewall so the browser doesn't try to resolve the firewall FQDN.



  • I don't know if the issue you are speaking of is the same to what I am experiencing currently.

    I don't even get the chance to apply any changes after I hit Save as the GUI becomes unresponsive until I reboot pfsense (changes not saved upon reboot).

    The only way I can work around making changes is by disabling pfblocker (unticking --> pfBlockerNG/Keep Settings), making the DNS resolver changes, then reenabling pfblocker and downloading the lists etc.



  • @stylenz said in pfBlockerNG-devel | Resolver settings | pfSense crashing / Not resolvable:

    I hit Save as the GUI becomes unresponsive until I reboot pfsense

    Maybe you are using to many table in DNSBL for the memory in your system. Try removing the big tables then see if you it survive a Save.



  • I have 16GB of RAM. I believe I had played around with the state tables before this with no luck, but I can try again. I recall the issue may only arise when I use forwarding too but I'll try confirm that by troubleshooting some more. Below are the settings I currently have enabled where changing anything now under the resolver causes it to become unresponsive.

    0_1546930805631_pfsense.PNG 0_1546930810898_pfsense2.PNG



  • @stylenz said in pfBlockerNG-devel | Resolver settings | pfSense crashing / Not resolvable:

    . Below

    I am talking about DNSBL feeds that created the unbound pfb_dnsbl.conf db for unbound.

    I have 1116415 entries on a 8GB system without squid or memory intensive pkg.

    From pfblockerng.log : [DNSBL update [ 1116415 | PASSED ]
    you can see the size of each table after the [ DNSBL Domain/IP Counts ] section



  • Well, I don't use any other packages besides pfblocker. I do have TLD ticked but imagine that only is memory intensive while it scans the lists.

    This is mine currently
    DNSBL update [ 1511416 | PASSED ]... completed [ 01/07/19 21:21:11 ]

    When trying to load pfb_dnsbl.conf from the GUI I get the below error. I imagine that is just a limitation of the GUI PHP due to the size of the file?

    PHP errors
    PHP ERROR: Type: 1, File: /usr/local/www/pfblockerng/pfblockerng_log.php, Line: 192, Message: Allowed memory size of 536870912 bytes exhausted (tried to allocate 4096 bytes) @ 2019-01-08 21:52:02


  • Moderator

    The issue is with the DHCP Registrations/Static DHCP Mapping options in Unbound when DNSBL is enabled.
    When you have a large DNSBL database it takes some time to load. So when one or both of those options are enabled, it will reload unbound and also cause DNS resolution interruption until it has fully reloaded.
    So try to ensure that the DHCP for LAN is set to a higher value than 1hour, or use static mappings if you can, or just disable that option in Unbound.
    pfBlockerNG-devel has a live-sync options that does not require a reload of Unbound, but on the pfSense side, it doesn't take advantage of "unbound-control" feature of Unbound where changes could be made on-the-fly without needing a reload.



  • BBcan177, I really believe this is a separate issue to the one you describe. I had looked at a few other posts and had already seen your solution regarding DHCP and unbound reloads but through troubleshooting for about a week now, don't believe this problem I am coming across is due to the same reason. When unbound is loading and working correctly, the reloads you speak of can be forced with DHCP renewals which I witness about a 5-10 second outage tops.

    I have tried a number of settings back and forward now and have come to the conclusion that regardless of the settings being forwarding with TLS enabled or not, that something is causing pfsense to lockup when DNS resolver settings are changed with pfblocker enabled and running. I have repeated this many many times now and have come to the work around that stopping both pfBlockerNG DNSBL service and pfBlockerNG firewall filter service before making the resolver changes works. It's a matter of those 2 not executing together or unloading what ever needs to be unloaded for the resolver changes to take place.

    Hope that clears things up.


  • Moderator

    @stylenz said in pfBlockerNG-devel | Resolver settings | pfSense crashing / Not resolvable:

    I have repeated this many many times now and have come to the work around that stopping both pfBlockerNG DNSBL service and pfBlockerNG firewall filter service before making the resolver changes works. It's a matter of those 2 not executing together or unloading what ever needs to be unloaded for the resolver changes to take place.

    The "pfb_filter" service has nothing to do with DNBSL, that is used to parse the pfSense filter.log (IP events). So you shouldn't need to touch that service for DNSBL/Unbound.

    When you hit "Save" in pfSense DNS Resolver (Unbound), it will do a full reload of Unbound, so with DNSBL enabled, you have to wait for it to fully load before DNS resolution will return to normal.



  • @stylenz said in pfBlockerNG-devel | Resolver settings | pfSense crashing / Not resolvable:

    When trying to load pfb_dnsbl.conf from the GUI I get the below error. I imagine that is just a limitation of the GUI PHP due to the size of the file?
    PHP errors
    PHP ERROR: Type: 1, File: /usr/local/www/pfblockerng/pfblockerng_log.php, Line: 192, Message: Allowed memory size of 536870912 bytes exhausted (tried to allocate 4096 bytes) @ 2019-01-08 21:52:02

    pfb_dnsbl.conf file is big and it's not the size of file that the GUI can handle.

    There is some memory_limit defined in /etc/inc/config.inc

    // Set memory limit to 512M on amd64.
    if ($ARCH == "amd64") {
    	ini_set("memory_limit", "512M");
    } else {
    	ini_set("memory_limit", "128M");
    }
    

    Increase 512M to 640M or bigger, maybe this will "resolve" this issue.
    Remember that any pfsense upgrade will overwrite /etc/inc/config.inc

    However, it's better to use the shell to read those big files, or copy them to your desktop.



  • Sorry, after further testing, unbound is needing to be manually stopped if pfblocker is enabled in order to make setting changes to DNS resolver. Not the pfblocker services.

    Do DNS resolver config changes work fine for you both without needing to manually interfere with stopping unbound? I just find it odd cause ive done 3-4 reinstalls lately and it’s presented this problem to me in all instances.

    The only thing that I guess has changed as of recently is using the devel release. I don’t recall having to manually stop unbound previously.

    Anyway, this can be marked as resolved as I don’t know if this is how it’s intended to be but I’ve managed a workaround.

    Cheers for the awesome package BBcan! It’s some great stuff. I’ll flick you a donation to show my appreciation.