@ronpfs said in Disable action does not work ?: @chudak said in Disable action does not work ?: How does permit outbound actually works ? (Need to think about it) That may contain some answers : https://docs.netgate.com/ I am sure it does ! Is Permit Outbound default setting for white lists ?

@wolfsden3 See this thread https://forum.netgate.com/topic/162883/disable-action-does-not-work/16?_=1618355648005 Maybe helpful

Normally, I don't block TLD's as it needs 'huge' quantity of resources. But ok, let's test : I tried blocking the tld "today" : [image: 1618296304991-dfaf9bb0-5f17-4176-bdad-c7b2b0fc5fcd-image.png] A test : C:\Users\Gauche>nslookup 1618250475.site.goapp.today Serveur : pfsense.brit-hotel-fumel.net Address: 2001:470:1f13:5c0:2::1 Nom : 1618250475.site.goapp.today Address: 10.10.10.1 Which means : [image: 1618296360647-1f43da52-b94a-4dfc-a72e-ca841ad3ed91-image.png] Btw : i's very rare to see this "black screen", as no one is (should not) using http:// any more.

@ronpfs Disabling the package prior updating did the job.

@BBcan177 I had to do a clean install of pfSense to make python mode work. Not sure why. It was a two year old working configuration with multiple updates and never had an issue. Now with python mode can I let go of unbound dns now or still need to use it? I have an internal well configured BIND dns which I would like to use instead of unbound.

@bbcan177 Thank you for being so fast in fixing this and the great work you are doing with pfBlockerNG! With the modifications all is working well :).

@rtw915 said in More frequent CRON interval options: I am still stuck on this. Under the CRON jobs I tried to edit this from this: 0 * * * * root /usr/local/bin/php /usr/local/www/pfblockerng/pfblockerng.php cron >> /var/log/pfblockerng/pfblockerng.log 2>&1 to this: */15 * * * * root /usr/local/bin/php /usr/local/www/pfblockerng/pfblockerng.php cron >> /var/log/pfblockerng/pfblockerng.log 2>&1 However, the Updates tab in pfBlockerNG says that the CRON job is missing, and then deletes the job and creates a new one with the hourly update interval. So this does not work You should not change these cron entries. They are set and maintained by the pfblockerng package.

@ertnec said in pfBlockerNG-devel v3.0.0_15 not clearing down tmp files, slowly fills /tmp up.: @bbcan177 said in pfBlockerNG-devel v3.0.0_15 not clearing down tmp files, slowly fills /tmp up.: @ertnec Download an updated script for ASN processing and see how that goes. curl -o /usr/local/pkg/pfblockerng/pfblockerng.sh "https://gist.githubusercontent.com/BBcan177/3aabea5edf7b40554d93085bff380b6f/raw" Hi, I've replaced the file you suggested, however, it still seems to be leaving these files alone & /tmp is still filling up. I can confirm this. Update: Still present in v3.0.0_16 (I added a cron-job: rm /tmp/pfbt* ) Regards, fireodo

@rk0 I'd just reinstall if you think you have the 'Save Settings' checkbox marked. You could always just build fresh and restore the config, too.

@tzvia Thank you! I should have thought about adding in-addr.arpa to domain overrides. I added one for each 24-bit subnet, and that did the job.

@gertjan Downloads are instant. Filtering through 1m takes most of the time. And no, the pipes are not saturated @100Mbits And dns doesn't suffer overall. If I get the dreaded error in resolver logs, no resolution is possible. Ping with ip works great. I need to experiment a bit more, but since this is service affecting during normal hours

@derelict said in Disable NAT rule creation: @thisisme It can also render the page much less pleasant, with broken image placeholders (browser-dependent), ALT text, etc. Adaway for Android does the same. Im fine with that. Why am I not allowed to decide this myself?

@mind12 Hello, I have reviewed each of the recommended steps: 1- DNS resolver is listening for all interfaces, if I configure that it only listens for the Bridge interfaces, it presents us with the same result. 2- Modify the validation code for the virtual IP, add an IP of the example segment 192.168.1.203 and the same result still does not block domains, for verification use nslookup and it continues to show the original IP of the domain which was used as test, in few words is not blocking. 3- Well my opinion about this is that apparently there is a link between the DHCP service and the DNSBL to work with it, but as I said this is only my opinion. Previously I was looking for more information and I was with that unknown that if I wanted to make a bridge interface with DNS blocking, I would have to configure one of the interfaces that comprise the Bridge for this case the LAN will activate the DHCP service.