Thank you very much. I change all to Alias type and make own rules manualy and all is working.

Iblocklist lists are not very up to date, check http://iplists.firehol.org/ to see when they were last updated, only 6 lists were updated lately as of today. You should probably take your lists from the source and not third party like iblocklist.com

Well, I put this issue aside to think about, and was out of the office for a few days.  When I returned this morning I saw in the DNSBL log files that another Win7 box on the network is now listed as blocking sites.  It is a box that last week was tested and was not working.  So I tested my own Win7 box, and now DNSBL is now working on it.  My box had not been shutdown or rebooted between the time it was tested as not working, and today when it is working. So I don't know what to say other than there is something fishy in the Windows network stack.  All of our LAN boxes get their network, dns, dhcp, and gateway information from our dnsmasq server, so they are all configured the same.  We are running the Avast Antivirus clients here, but I do not see any option to re-route the incorrect dns queries to the proper address.  And we are not using a proxy here. Anyway, I will now consider this fixed/solved.  Even though the true issue is still not identified.  I give up and will move on to something else. Thanks for the input. Jeff

It's not pfBlockerNG that generate the error, it's the reload process. Default settings in pfSense can not handle huge alias table like GeoIP IPv6 tables.

Ok, I am getting close on this, but am still puzzled about what is happening.  The Windows boxes on my lan have their DNS reference pointing to the dnsmasq box (192.168.112.51), and the dnsmasq box only has the pfSense gateway/firewall box (192.168.112.11) listed in its /etc/resolve.conf file, and therefore is fowarding all DNS queries to the pfSense box.  The pfSense box has DNS resolver enabled.  In the System/General Setup there are two upstream DNS servers from my provider, and one public DNS server from Google.  The Disable DNS Forwarder box on the General Setup page is not checked.  Therefore 127.0.0.1 shows as the first DNS server on the dashboard page. The EasyList sites are blocked when queried from the pfSense box. nslookup ad.doubleclick.net Server: 127.0.0.1 Address: 127.0.0.1#53 Name: ad.doubleclick.net Address: 10.10.10.1 If I query the same site from a test Linux box on the local network I get the same results. [root@disect ~]# nslookup ad.doubleclick.net Server:        192.168.112.51 Address:        192.168.112.51#53 Name:  ad.doubleclick.net Address: 10.10.10.1 If I query the same site from a Windows box on the local network I get a different result.  I even made sure to flush the Windows dns cache before doing the query. C:\Users\jeffb> nslookup ad.doubleclick.net Server:  taxa.mei.lan Address:  192.168.112.51 Name:    dart.l.doubleclick.net Address:  216.58.216.134 Aliases:  ad.doubleclick.net So I started a Wireshark trace on the Windows box to see what was happening.  Below is the summary of the final two sets of packets from the query and response exchange. 1267 6.512617000 192.168.112.101 192.168.112.51 DNS 78 Standard query 0x0004  A ad.doubleclick.net 1269 6.513636000 192.168.112.51 192.168.112.101 DNS 94 Standard query response 0x0004  A 10.10.10.1 1271 6.524775000 192.168.112.101 192.168.112.51 DNS 78 Standard query 0x0005  AAAA ad.doubleclick.net 1273 6.525384000 192.168.112.51 192.168.112.101 DNS 78 Standard query response 0x0005 A traceroute to ad.doubleclick.net from the Windows box shows that it initially goes to the pfSense box, then goes out to an IP of my upstream provider, then on to obtain the correct DNS number. From the Wireshark data it appears that DNS is returning the virtual IP of 10.10.10.1 for the DNS block list.  Searching the Wireshark data I can not see the address that the Windows box is showing at the command line response to the nslookup (216.58.216.134) anywhere.  So I don't understand why the Windows box is getting the correct DNS address for this site, while a Linux box on the lan, and the pfSense box are both returning the virtual IP for the block list.  What else should I be looking for, or looking at?  Thanks. Jeff

Use the "Adv. Inbound Firewall Rule" settings to restrict those ports to the smallest subset of IPs that you can….

See the following link about your first question: https://forum.pfsense.org/index.php?topic=99929.msg556801#msg556801 MaxMind updates once a month, so there is no reason to run cron updates hourly for GeoIP. However. If you add other IP feeds, you should update at an increased frequency.

@rajl: Thanks for the advice.  I'm running the latest version, so I'll bump the max table entries up to 10m (currently set at 4m) and Force Reload like you suggested.  I'll see what happens and report back in a few days. I've done this as well and it still hasn't resolved my issue. Are you getting these dpinger errors when this happens in your logs? send_interval 500ms loss_interval 2000ms time_period 60000ms report_interval 0ms data_len 0 alert_interval 1000ms latency_alarm 500ms loss_alarm 20% dest_addr xx.xx.xx.xx bind_add xx.xxx.xx.xx identifier "TPWANGW " I get these errors but only on my CARP Backup device, not the main. For me all of my gateways go down every 6 hours and that's when this error occurs and I have to run a CRON in pfBlocker to fix it. The only CRON that runs every 6 hours is Snort, but I've set it to run :05 minutes after the hour and I still see errors. This happens as well, I'm not sure if it's directly related Oct 17 00:01:03 kernel ovpns2: link state changed to DOWN Oct 17 00:01:03 php-fpm 32369 /xmlrpc.php: Resyncing OpenVPN instances. Oct 17 00:01:02 php-fpm 32369 /xmlrpc.php: ROUTING: setting default route to xx.xx.xx.xx Oct 17 00:01:02 check_reload_status Reloading filter Oct 17 00:01:02 check_reload_status Syncing firewall When that ROUTING entry happens all my OpenVPN interfaces reset. I don't mean to hijack and I need to start my own thread but I was just curious if you had the same issues. I have Snort and Squid running as well, but this only happens every 6 hours which leads me to think it's related to Snort in some way.

@BBcan177: If you see an AD in a web page, right click on it, and click "Inspect"… This will show what the domain of the AD is... There are other DNSBL Feeds that can be added (Check the DNSBL thread), and you can also manually add Domains to the Custom Lists... actually i see Ads on youtube app on my android and iOS devices, is there any solution?

Hey BBcan177! Thank you SO much for taking the time to explain this to me. I was scratching my head trying to figure out exactly why my PrivacyGuard alerts weren't showing, but my general pfBlocker alerts were. This makes perfect sense, now. Thank you again for the clear, concise explanation. You rock!  ;D

This is not a bug with the package… If you use the GeoIP rules and depending on what Countries you add, you can block access to the Root DNS Servers. So its up to how you configure the rules and the blocklists... Anything being blocked will show in the Alerts Tab. Here is an IP list of the Root DNS Servers, which should not be blocked... https://www.internic.net/domain/named.root btw - I am not actively maintaining pfBlockerNG in pfSense 2.2.x... Best to move to pfSense 2.3.x asap...

php /usr/local/www/pfblockerng/pfblockerng.php dc seems to have fixed the issue thanks for your help

https://forum.pfsense.org/index.php?topic=99929.msg556801#msg556801

@centurioapertus: I solved my problems by installing Linux, but I digress.  Since I still have a few Windows 10 machines, my plan is to block all traffic to microsuck except from one VM which will be running as a WSUS server.  All my Windows 10 machines will be pointed to the WSUS server for updates. I just thought I would drop the idea of a WSUS server into the mix. Noob question from me:  I've used a little SCCM 2012 but never WSUS to push out Windows Updates.  Does WSUS require a Windows Server OS?  I'm curious if a home user can spin up a WSUS VM for free (legally).

The package allows for different options to define the firewall rules… There isn't one better than the other.... Its wants better for you network environment.... Your observations about the differences between those rule options is sound tho.. I will say that its best not to overload the widget statistics/Alerts Tab with useless information with packets that are already being dropped by the stateful implicit deny firewall rule and then concentrate on those Alerts that are important to review.

Just pfBlockerNG.  Deleted all lists manually, did a force update to clear everything, uninstalled the package, rebooted the machine and installed pfBlocker from scratch and re configured from a blank slate. Not sure what preciusely that fixed, other then to know that it is now working as expected, again.

If Avast uses a CDN, it might be hit or miss with a TLD domain in the whitelist… Try your google FU and see if you can find the whole list of IPs that are used for the update process, or send Avast Support a request for those IP ranges.... Then add those IPs to the Whitelist....

To bypass DNSBL, you can configure the LAN devices to use a different DNS server and that should solve this issue for you. Could also run the DNS Forwarder (dnsmasq) on a different port….