PfBlockerNG v2.0 w/DNSBL
-
Here are some basic instructions to get started with DNSBL.
- Open the pfBNG "DNSBL" Tab:
(Use the defaults unless you have a need to use otherwise)
Enter the DNSBL VIP as 10.10.10.1
Enter the DNSBL Listening Port as 8081
Enter the DNSBL SSL Listening port as 8443
Select the DNSBL Listening Interface as LanI have vlans configured on pfsense. Therefore there is no LAN option. The my only options are the different vlans, so what can I choose for the listening interface?
Hi maverik1,
I haven't tested that before, but I assume that it should be ok to choose any one of the VLANS…
After enabling DNSBL, run this command from the shell to see if the DNSBL VIP is assigned to the VLAN:
ifconfig
You should see a line like this in the VLAN:
inet 10.10.10.1 netmask 0xffffffff broadcast 10.10.10.1
Then try to ping the DNSBL VIP address and see if it responds…
Since you have multiple VLANs, its a good idea to enable the DNSBL Permit rule option....
-
I can confirm pfbNG works fine with VLANs.
-
OK here's a strange occurrence…
pfSense just upgraded to 2.3.2 but this behaviour happened with 2.2.1 on a physically different router.pfb version 2.1.1_4.
On our LAN when we use google chrome (latest) and go to google it can take several seconds for google to display. Doing a search can take 20 seconds to respond, but it does come back eventually.
On firefox or any other browser, internet access is instant, including identical searches on the same PC simultaneously.
pfb is working OK when enabled ie blocking incoming and outgoing ipv4 correctly.
When pfBlockerNG is disabled, searches and access on chrome become instant too, so something in pfBlocker is slowing down just chrome.
This behaviour is consistent across different PCs on different versions of windows.I don't really have much idea what this can be, and logs aren't telling me much.
tl;dr - chrome+pfblockerng = very slow. Firefox = fast. Turn off pfblocker =all browsers incl chrome fast
-
OK here's a strange occurrence…
pfSense just upgraded to 2.3.2 but this behaviour happened with 2.2.1 on a physically different router.pfb version 2.1.1_4.
On our LAN when we use google chrome (latest) and go to google it can take several seconds for google to display. Doing a search can take 20 seconds to respond, but it does come back eventually.
On firefox or any other browser, internet access is instant, including identical searches on the same PC simultaneously.
pfb is working OK when enabled ie blocking incoming and outgoing ipv4 correctly.
When pfBlockerNG is disabled, searches and access on chrome become instant too, so something in pfBlocker is slowing down just chrome.
This behaviour is consistent across different PCs on different versions of windows.I don't really have much idea what this can be, and logs aren't telling me much.
tl;dr - chrome+pfblockerng = very slow. Firefox = fast. Turn off pfblocker =all browsers incl chrome fast
What block lists are you running? Also, ctrl-shift-I to get into dev mode for both look at performance in FF and timeline in chrome, run them both and compare.
-
What block lists are you running? Also, ctrl-shift-I to get into dev mode for both look at performance in FF and timeline in chrome, run them both and compare.
Currently running top_v4 and top_v6 by selecting various countries in the Top 20.
Also 5 lists in IPv4 to block some social networking sites by AS number.
And DNSBL is enabled although I was testing the speed prior to this and I don't think it made any difference. TLD isn't ticked. All other options are default. -
On our LAN when we use google chrome (latest) and go to google it can take several seconds for google to display. Doing a search can take 20 seconds to respond, but it does come back eventually.
You can open the Chrome cache viewer with this URL (Clear that and see if it helps):
chrome://net-internals/#dns
Also ensure that the LAN devices only have pfSense as its DNS server.
-
On our LAN when we use google chrome (latest) and go to google it can take several seconds for google to display. Doing a search can take 20 seconds to respond, but it does come back eventually.
You can open the Chrome cache viewer with this URL (Clear that and see if it helps):
chrome://net-internals/#dns
Also ensure that the LAN devices only have pfSense as its DNS server.
Will try the cache clear, thanks.
However the LAN devices are all set with our domain servers as DNS servers. The DNS on the AD servers are all set to just have the pfsense as the only forwarder. pfSense has DNS Resolver only. I did just watch the last hangout about DNS and believe that I am setup OK with just resolver even though we are multi-WAN. If you think I'd be better off with DNS forwarder instead please let me know.
Thanks for your help :)
-
So to be clear, ensure that the LAN devices have only your AD DNS servers defined. Then set the AD DNS server DNS Forwarder settings to pfSense only… This way DNSBL will filter the traffic.
The resolver can be in Resolver mode or in Forwarder mode.... I recommend Resolver mode....
If you are referring to the DNS Forwarder (dnsmasq), then DNSBL will not function, as its not configured for that.
-
So to be clear, ensure that the LAN devices have only your AD DNS servers defined. Then set the AD DNS server DNS Forwarder settings to pfSense only… This way DNSBL will filter the traffic.
The resolver can be in Resolver mode or in Forwarder mode.... I recommend Resolver mode....
That is exactly how we are configured (in Resolver mode). Testing continues….
-
Hi all,
Yesterday I added 4 new lists to DNSBL, see attachment 1.
Right after I added these new lists, my DNSBL Alerts/Log stopped working, and all blocks are now shown in the "DENY" log section. See attachment 2.
Can anyone shed light as to what I have done wrong?
Thanks
BR Jim
-
Hi jim82,
In the DNSBL tab, only add DNSBL based feeds, the RW_IPBL is an IP based list that should be added to the IPv4 Tab.
Goto the General Tab, and enable Suppression and follow that with a Force Reload - All… This will remove any RFC1918 or loopback addresses that might be in a list. I am going to make this standard in the next release to avoid this issue... The Deny alerts that you see are from the DNSBL_IP firewall rule. In DNSBL, you enabled the "DNSBL_IP" option which will collect and block any IP addresses that are found in a Domain based feed.
-
Thanks a lot for your swift reply! Should I remove the RW_IPBL list from DNSBL?
BR Jim
EDIT: I've now removed the list from DNSBL and added it to IPv4, is this the correct way of doing it?Hi jim82,
In the DNSBL tab, only add DNSBL based feeds, the RW_IPBL is an IP based list that should be added to the IPv4 Tab.
Goto the General Tab, and enable Suppression and follow that with a Force Reload - All… This will remove any RFC1918 or loopback addresses that might be in a list. I am going to make this standard in the next release to avoid this issue... The Deny alerts that you see are from the DNSBL_IP firewall rule. In DNSBL, you enabled the "DNSBL_IP" option which will collect and block any IP addresses that are found in a Domain based feed.
-
The tables are built from MaxMind GeoIPLite2 database, pfblockerNG just take the db and create the files for it's usage. MaxMind support has been contacted about the size being 3x larger than before.
Just out of curiosity, is there any progress on this? I saw that MaxMind: Last-Modified: Tue, 02 Aug 2016 is still on August. Of course I could do a "php /usr/local/www/pfblockerng/pfblockerng.php dc", but everything is working fine (pfBlockerNG v2.1.1_4) so no need for it, as in ….if it ain't broke, than don't try to fix it ;)
Cheers Qinn
-
Hello I keep getting this in the update log
Could not open ISO
UPDATE PROCESS START [ 10/09/16 10:30:37 ] ===[ DNSBL Process ]================================================ [ hphost_partial ] exists. [ mvps_hosts ] exists. [ SomeoneWhoCares ] exists. [ BBcan177 ] exists. [ DNSBL_IP ] Updating aliastable... no changes. Total IP count = 1 ===[ Continent Process ]============================================ Could not open ISO [ SH_v4 ] [ pfB_Africa_v4 ] exists. Could not open ISO [ AP_v4 ] Could not open ISO [ CX_v4 ] Could not open ISO [ CC_v4 ] [ pfB_Asia_v4 ] exists. [ 10/09/16 10:30:38 ] Could not open ISO [ PN_v4 ] [ pfB_Oceania_v4 ] exists. [ pfB_SAmerica_v4 ] exists. [ pfB_Top_v4 ] exists. [ pfB_Top_v6 ] exists. [ 10/09/16 10:30:42 ] [ pfB_PS_v4 ] exists. ===[ IPv4 Process ]================================================= ===[ IPv6 Process ]================================================= ===[ Aliastables / Rules ]========================================== No changes to Firewall rules, skipping Filter Reload No Changes to Aliases, Skipping pfctl Update UPDATE PROCESS ENDED [ 10/09/16 10:30:43 ]
-
Could not open ISO [ SH_v4 ]
Could not open ISO [ AP_v4 ]
Could not open ISO [ CX_v4 ]
Could not open ISO [ CC_v4 ]
Could not open ISO [ PN_v4 ]Yes this is an issue with the MaxMind monthly database changes not reporting on some GeoIPs… I have a fix for this which will be in the next release which will add a "placeholder" for all GeoIPs regardless if they are not defined by MaxMind... Just ignore for the time being...
-
Thanks a lot for your swift reply! Should I remove the RW_IPBL list from DNSBL?
EDIT: I've now removed the list from DNSBL and added it to IPv4, is this the correct way of doing it?Yes… remove from DNSBL and Add the RW_IPBL to the IPv4 tab...
-
Just out of curiosity, is there any progress on this? I saw that MaxMind: Last-Modified: Tue, 02 Aug 2016 is still on August. Of course I could do a "php /usr/local/www/pfblockerng/pfblockerng.php dc", but everything is working fine (pfBlockerNG v2.1.1_4) so no need for it, as in ….if it ain't broke, than don't try to fix it ;)
Do you have any MaxMind update errors in /var/log/pfblockerng/geoip.log?
I would manually run the update and see if it reports any errors…
php /usr/local/www/pfblockerng/pfblockerng.php dc
-
Hi.
I keep watching in the general system log entries like this:
*nginx: 2016/10/10 19:04:39 [error] 23499#100098: 737 open() "/usr/local/www/utsync.ashx" failed (2: No such file or directory),client: 10.10.10.1, server: , request: "GET /utsync.ashx?eid=50052&et=0&fp=2X9bJ6tnRz5B2L0llgZVTWayaMg4TcNYwOj-CDyEPl1k&return=http%3A%2F%2Fps.eyeota.net%2Fmatch%3Fbid%3Dr8hrb20%26uid%3Dnil HTTP/1.1", host: "ml314.com", referrer: "http://viraliq.com/15-musicians-didnt-know-passed?utm_source=revcontent&utm_medium=referral&utm_campaign=desktop&utm_content_id=996712&utm_boost_id=116872&utm_targeting=editorial%20news&utm_widget_id=31653"I understand that DNSBL has successfully diverted the DNS petition to server 10.10.10.1 and the requested file is not there but is, logging these messages, the right behavior?
Is there a way to disable them?. They are populating the system logs and hiding important stuff.
-
just wanted to give a personal thank you to bbcan for his committed FREE support on this amazing addon.
you sir are a legend :)
-
Just out of curiosity, is there any progress on this? I saw that MaxMind: Last-Modified: Tue, 02 Aug 2016 is still on August. Of course I could do a "php /usr/local/www/pfblockerng/pfblockerng.php dc", but everything is working fine (pfBlockerNG v2.1.1_4) so no need for it, as in ….if it ain't broke, than don't try to fix it ;)
Do you have any MaxMind update errors in /var/log/pfblockerng/geoip.log?
I would manually run the update and see if it reports any errors…
php /usr/local/www/pfblockerng/pfblockerng.php dc
I encoutered no errors, so no log file. Btw I am on a APU2C4, 2.3.2-RELEASE-p1 (amd64) and pfBlockerNG 2.1.1_4