PfBlockerNG v2.0 w/DNSBL
-
Thanks,
Not sure it belongs in this thread but I should elaborate.
Currently pfS is not in active use except for learning/testing things out.
Attached image shows current setup where the NAS is OVPN server and adblocking DNS server, HOME1-net is with family in another country and HOME2-net is my home, it does not provide DNS for HOME2-net. The Synology DNS server uses bind and provides adblocking DNS for OVPN clients and the HOME1 LAN/WiFi only.you may be opening yourself to cache poisioning and other potential issues.
Curious if that is the case in the current situation, see image, thank you.
You should be able to utilize the pfSense Resolver for your OpenVPN connections (Which will use DNSBL).
Yes, in the new setup pfS will be OVPN/DNS server for HOME2-net, the NAS will become OVPN client for my backup and I thinking about leaving the NAS adblock DNS server for the HOME1-net active, nice for the family.
-
-Update- Logging worked for about 20 minutes, then stopped. It would actively update on what seemed to be about 30 second intervals. Is there a logging setting that needs to change?
The IP Alerts are taken from the pfSense Firewall Logs. So you can clear the firewall log to start fresh.
For DNSBL the log is taken from /var/log/pfblockerng/dnsbl.log
If you are getting sporatic DNSBL logging, ensure that your LAN device(s) only have pfSense as its DNS server, as any other DNS server settings could be round-robin to other DNS servers and will bypass DNSBL.
Ensure that you can ping the DNSBL VIP, and browse to the DNSBL VIP and get the 1x1 pix.
DNS is set correctly as suggested already. Looking at the log from the shell is the same.
-
-Update- Logging worked for about 20 minutes, then stopped. It would actively update on what seemed to be about 30 second intervals. Is there a logging setting that needs to change?
The IP Alerts are taken from the pfSense Firewall Logs. So you can clear the firewall log to start fresh.
Clearing the log only clears everything BUT DNSBL
-
-Update- Logging worked for about 20 minutes, then stopped. It would actively update on what seemed to be about 30 second intervals. Is there a logging setting that needs to change?
Ensure that you can ping the DNSBL VIP, and browse to the DNSBL VIP and get the 1x1 pix.
I can ping the VIP but cannot get the 1x1 pixel
-
The Synology DNS server uses bind
Well atleast its using a decent DNS Server, just ensure that DNSSEC is enabled… I'm always uneasy about these types of devices running the DNS role... Once you put pfSense into the mix, you could then utilize the pfBlockerNG package to get all the additional features it offers.
-
-Update- Logging worked for about 20 minutes, then stopped. It would actively update on what seemed to be about 30 second intervals. Is there a logging setting that needs to change?
Ensure that you can ping the DNSBL VIP, and browse to the DNSBL VIP and get the 1x1 pix.
I can ping the VIP but cannot get the 1x1 pixel
To clear the DNSBL log:
rm /var/log/pfblockerng/dnsbl.log
BY any chance do you have an Anti-virus/Firewall pkg on your desktop that might be causing issues… Seen someone who had Avast doing some 'DNS tunneling' and causing issues with DNSBL. Also check your browser Addons... If your not getting the 1x1, then DNSBL won't work as expected...
-
The only thing I have for AV is MS Security Essentials. Tried turning it off and no changes. The list has cleared and is now staying that way.
-
To clear the DNSBL log:
rm /var/log/pfblockerng/dnsbl.log
BY any chance do you have an Anti-virus/Firewall pkg on your desktop that might be causing issues… Seen someone who had Avast doing some 'DNS tunneling' and causing issues with DNSBL. Also check your browser Addons... If your not getting the 1x1, then DNSBL won't work as expected...
What could possibly be blocking me to the DNSBL VIP?
-
If you are in a multi-segmented Lan network, there is a in the DNSBL tab to auto create a Floating allow rule for the selected Lan networks.
-
If you are in a multi-segmented Lan network, there is a in the DNSBL tab to auto create a Floating allow rule for the selected Lan networks.
That is already checked and created
-
I have added all lists on my apu.
Now my unbound is very slow. It takes more than 800ms to resolve a hostname.
The flicker.conf list is about 60mb.
I have increased some values like Message Cache Size and Number of Hosts to Cache. 50mb and 100000. But it is still so sloooow.
Any ideas?
Thank you -
I have added all lists on my apu.
Now my unbound is very slow. It takes more than 800ms to resolve a hostname.
The flicker.conf list is about 60mb.
I have increased some values like Message Cache Size and Number of Hosts to Cache. 50mb and 100000. But it is still so sloooow.Ensure that your LAN devices can ping the DNSBL VIP, and also that they can browse to the DNSBL VIP and get the 1x1 pix. If any of those two tests fail, you will see slowness as the browser is timing out waiting for the DNS resolution to the blocked Domains.
-
Thats works fine.
I tested the dns resolution time in the Diagnostic menu.
With top I can see that unbound takes a lot of cpu for some time. -
Is the Resolver in "Forwarder" or "Resolver" mode?
What DNS settings are defined in the pfSense General Tab? As these settings are used by the pfSense box itself…
When testing the ping/browse to the DNSBL VIP, do that from the LAN clients and not from pfSense itself.
If you're in a multi-segmented LAN, ensure to use the 'DNSBL Permit Rule' option in the DNSBL Tab. Also clear your Browser/OS cache.
-
Resolver Mode.
No multi segmented LAN.
VIP is tested from remote.
I tested a dns resolution like www.IBM.com on pfsense box.
The slow network is reproducible on many devices.
Maybe there is a mistake in my config which unbound makes that slow.
-
Is the Resolver in "Forwarder" or "Resolver" mode?
What DNS settings are defined in the pfSense General Tab? As these settings are used by the pfSense box itself…
When testing the ping/browse to the DNSBL VIP, do that from the LAN clients and not from pfSense itself.
If you're in a multi-segmented LAN, ensure to use the 'DNSBL Permit Rule' option in the DNSBL Tab. Also clear your Browser/OS cache.
Unfortunately not 100% sure of what fixed it, but the DNSBL alerts are current. On to the next…
-
Ive just noticed an annoying bug when pressing save on the Firewall/pfBlockerNG/Edit/IPv4 page if there are any errors all your data gets wiped out :-(
Can you please leave the data so if can be corrected?
FYI, this bug was fixed by the following pfSense commit for pkg_edit.php:
https://github.com/pfsense/pfsense/commit/a654d899cd5d288501fea1ec52dba2e3f0e479baIts in the pfSense Dev version and will be in the next pfSense 2.3.2 release.
-
pfBlockerNG v2.0 …When a DNS request is made for a domain that is listed in DNSBL, the request is redirected to a Virtual IP address where an instance of Lighttpd Web Server will collect the packet statistics and push a '1x1' GIF image to the Browser…
Just curious why you chose to use lighttpd vs. the nginx webserver that is already built in. Was this for backwards compatibility with older versions?
-
I think i found out, why my network is so slow and unresponseful sometimes.
The Unbound seems to restart pretty often :(Jul 17 13:57:29 unbound 64290:0 notice: Restart of unbound 1.5.9. Jul 17 13:57:29 unbound 64290:0 info: 1.000000 2.000000 4 Jul 17 13:57:29 unbound 64290:0 info: 0.524288 1.000000 3 Jul 17 13:57:29 unbound 64290:0 info: 0.262144 0.524288 2 Jul 17 13:57:29 unbound 64290:0 info: 0.131072 0.262144 14 Jul 17 13:57:29 unbound 64290:0 info: 0.065536 0.131072 10 Jul 17 13:57:29 unbound 64290:0 info: 0.032768 0.065536 13 Jul 17 13:57:29 unbound 64290:0 info: 0.016384 0.032768 1 Jul 17 13:57:29 unbound 64290:0 info: lower(secs) upper(secs) recursions Jul 17 13:57:29 unbound 64290:0 info: [25%]=0.0598646 median[50%]=0.127795 [75%]=0.236398 Jul 17 13:57:29 unbound 64290:0 info: histogram of recursion processing times Jul 17 13:57:29 unbound 64290:0 info: average recursion processing time 0.298118 sec Jul 17 13:57:29 unbound 64290:0 info: server stats for thread 1: requestlist max 14 avg 7.29787 exceeded 0 jostled 0 Jul 17 13:57:29 unbound 64290:0 info: server stats for thread 1: 73 queries, 26 answers from cache, 47 recursions, 0 prefetch Jul 17 13:57:29 unbound 64290:0 info: 0.262144 0.524288 1 Jul 17 13:57:29 unbound 64290:0 info: 0.131072 0.262144 2 Jul 17 13:57:29 unbound 64290:0 info: 0.065536 0.131072 2 Jul 17 13:57:29 unbound 64290:0 info: 0.032768 0.065536 1 Jul 17 13:57:29 unbound 64290:0 info: 0.016384 0.032768 1 Jul 17 13:57:29 unbound 64290:0 info: lower(secs) upper(secs) recursions Jul 17 13:57:29 unbound 64290:0 info: [25%]=0.057344 median[50%]=0.114688 [75%]=0.212992 Jul 17 13:57:29 unbound 64290:0 info: histogram of recursion processing times Jul 17 13:57:29 unbound 64290:0 info: average recursion processing time 0.156474 sec Jul 17 13:57:29 unbound 64290:0 info: server stats for thread 0: requestlist max 0 avg 0 exceeded 0 jostled 0 Jul 17 13:57:29 unbound 64290:0 info: server stats for thread 0: 18 queries, 11 answers from cache, 7 recursions, 0 prefetch Jul 17 13:57:29 unbound 64290:0 info: service stopped (unbound 1.5.9). Jul 17 13:55:09 unbound 64290:0 info: start of service (unbound 1.5.9). Jul 17 13:55:08 unbound 64290:0 notice: init module 0: iterator Jul 17 13:54:33 unbound 64290:0 notice: Restart of unbound 1.5.9. Jul 17 13:54:33 unbound 64290:0 info: server stats for thread 1: requestlist max 31 avg 16.4314 exceeded 0 jostled 0 Jul 17 13:54:33 unbound 64290:0 info: server stats for thread 1: 53 queries, 2 answers from cache, 51 recursions, 0 prefetch Jul 17 13:54:33 unbound 64290:0 info: server stats for thread 0: requestlist max 1 avg 0.5 exceeded 0 jostled 0 Jul 17 13:54:33 unbound 64290:0 info: server stats for thread 0: 2 queries, 0 answers from cache, 2 recursions, 0 prefetch Jul 17 13:54:33 unbound 64290:0 info: service stopped (unbound 1.5.9). Jul 17 13:54:33 unbound 64290:0 info: start of service (unbound 1.5.9). Jul 17 13:54:33 unbound 64290:0 notice: init module 0: iterator Jul 17 13:54:15 filterdns clearing entry 192.30.253.113 from table debian_updates on host github.com Jul 17 13:54:15 filterdns adding entry 192.30.253.112 to table debian_updates on host github.com Jul 17 13:53:58 unbound 64290:0 notice: Restart of unbound 1.5.9. Jul 17 13:53:58 unbound 64290:0 info: 0.262144 0.524288 14 Jul 17 13:53:58 unbound 64290:0 info: 0.131072 0.262144 26 Jul 17 13:53:58 unbound 64290:0 info: 0.065536 0.131072 18 Jul 17 13:53:58 unbound 64290:0 info: 0.032768 0.065536 9 Jul 17 13:53:58 unbound 64290:0 info: 0.016384 0.032768 4 Jul 17 13:53:58 unbound 64290:0 info: lower(secs) upper(secs) recursions Jul 17 13:53:58 unbound 64290:0 info: [25%]=0.0828302 median[50%]=0.153758 [75%]=0.243239 Jul 17 13:53:58 unbound 64290:0 info: histogram of recursion processing times Jul 17 13:53:58 unbound 64290:0 info: average recursion processing time 0.165017 sec Jul 17 13:53:58 unbound 64290:0 info: server stats for thread 1: requestlist max 12 avg 4.98592 exceeded 0 jostled 0 Jul 17 13:53:58 unbound 64290:0 info: server stats for thread 1: 82 queries, 11 answers from cache, 71 recursions, 0 prefetch
-
pfBlockerNG v2.0 …When a DNS request is made for a domain that is listed in DNSBL, the request is redirected to a Virtual IP address where an instance of Lighttpd Web Server will collect the packet statistics and push a '1x1' GIF image to the Browser…
Just curious why you chose to use lighttpd vs. the nginx webserver that is already built in. Was this for backwards compatibility with older versions?
Hi Luke,
When 2.3 was in testing, I attempted to switch to NGINX; however, ran into issues on DNSBL logging for HTTPS alerts. Lighttpd has an error-conditional-log that contains some details that the pkg uses to provide some Alert details for HTTPS alerts. With NGINX, when the browser drops the connection to the DNSBL webserver due the incorrect Certificate provided, no other logging is completed by NGINX. I managed to get the Devs to add LUA support to NGINX, but there were issues with OpenSSL at the time that prevented further testing. I may revisit this as time permits, but so far, there hasn't been any issues with both NGINX and Lighttpd running at the same time.