PfBlockerNG v2.0 w/DNSBL
-
I had a list in pfBlockerNG and I removed it. Its gone from the pfBlocker GUI, but it is still on my dashboard widget and I get these warnings all the time. Unresolvable destination alias 'pfB_iBlockYoyoAdServers' for rule 'pfB_iBlockYoyoAdServers auto rule' @ 2016-04-14 16:00:03
I tried update, cron and refresh all in pfBlockerNG
Ran:
pfctl -t pfB_iBlockYoyoAdServers -T killOutput: 0 table removed
Ran: pfctl -s all
Did not see a table with that nameI have tried to uninstall pfBlocker w/keep setting uncheck. The list is still there when I reinstall.
pfSense 2.3
-
I had a list in pfBlockerNG and I removed it. Its gone from the pfBlocker GUI, but it is still on my dashboard widget and I get these warnings all the time. Unresolvable destination alias 'pfB_iBlockYoyoAdServers' for rule 'pfB_iBlockYoyoAdServers auto rule' @ 2016-04-14 16:00:03
I tried update, cron and refresh all in pfBlockerNG
Ran:
pfctl -t pfB_iBlockYoyoAdServers -T killOutput: 0 table removed
Ran: pfctl -s all
Did not see a table with that nameI have tried to uninstall pfBlocker w/keep setting uncheck. The list is still there when I reinstall.
pfSense 2.3
I fixed my issue. I deleted the entries in Firewall >> Rules for LAN and WAN that reference the list I wanted to remove. The list is gone from the dashboard and I am not getting the error anymore.
-
Hello,
I have just built a clean install of 2.3 and install pfBlockerNG and added a bunch of lists from i-BlockList
However, I am getting these lists blocking DNS traffic to the router itself
I've worked around this with a permit rule at higher priority … but it doesn't seem to be the right solution. Does this imply one of the lists has the LAN's non-routable addresses in it?
-
Hi robwalker5561,
Run these commands and it will show if there is a loopback address (Won't be the first time that IBlock does this :) ):
grep "127\.0\.0\." /var/db/pfblockerng/deny/* grep "127\.0\.0\." /var/db/pfblockerng/dnsbl/* grep "127\.0\.0\." /var/db/aliastables/*If it finds a loopback, then enable "Suppression" in the General Tab, and run a "Force Reload" to clear it out…
-
Thank you for the reply.
Those commands don't match any entries (nor does a regex for 192.168. or my WAN IP address)
The help for 'Suppression' says:
This will prevent Selected IPs from being blocked. Only for IPv4 lists (/32 and /24).
Which sound great … the correct approach is to then modify the pfBlockerNGSuppress alias manually with the local IP?
Hi robwalker5561,
Run these commands and it will show if there is a loopback address (Won't be the first time that IBlock does this :) ):
grep "127\.0\.0\." /var/db/pfblockerng/deny/* grep "127\.0\.0\." /var/db/pfblockerng/dnsbl/* grep "127\.0\.0\." /var/db/aliastables/*If it finds a loopback, then enable "Suppression" in the General Tab, and run a "Force Reload" to clear it out…
-
From your original screenshot: How can you have both src and dst with a 192.168.1.x address range? Are you double Natting? WAN/LAN should be in separate IP ranges…
-
Shouldn't be anything too complicated going on … at least not by design, I probably misconfigured something:
192.168.1.6 is a box on the LAN
192.168.1.1 is the gateway's LAN interface (a /24), its WAN is 192.168.209.14 which is NAT'd because that is all the modem exposes
The rules configuration is:
From your original screenshot: How can you have both src and dst with a 192.168.1.x address range? Are you double Natting? WAN/LAN should be in separate IP ranges…
-
Is this alert repeating? It says "no match" in the pic… So maybe it was being blocked previously. Clear the Firewall logs, and see if it re-appears...
-
Hi
Using the latest version of pfsense and pfblockerng, when setting to allow an ipv4 rule, it generates an auto rule. I thought, when using the advanced inbound rules that this would modify the auto rule. Instead, it just appears to ignore these settings and create a default auto open rule for dest/port - though it correctly retains the src. Also, when modifying the auto rule every subsequent modification to the pfblocker rule rewrites and resets the auto rule.
Is this by design?
Thanks (fantastic package btw!)
-
@yea:
I thought, when using the advanced inbound rules that this would modify the auto rule.
Is this by design?
Thanks (fantastic package btw!)
Thanks!
See here:
https://forum.pfsense.org/index.php?topic=102470.msg612027#msg612027Change the protocol settings. :)
-
Apologies. I was entering addresses manually, not as the notes said. When using aliases it works perfectly.
-
Interesting … I put things back the way they were (as far as I can tell) and I can't reproduce the problem now ... so all good
Thanks for your help!
Is this alert repeating? It says "no match" in the pic… So maybe it was being blocked previously. Clear the Firewall logs, and see if it re-appears...
-
I just made acquaintance with a certain Latina, the sister of that other Latina. Might be introducing you to her shortly 8)
( ;D ;D ;D ).
BB, could you please look at the attached pic? This doesn't make sense, does it? This is Comodo firewall alerting because Java (used by my media indexing program) wants to go to your 10.10.10.1. Why would it want to do that?
We also had the 10.10.10.1 and NTP server, and I think something is weird. DNS Resolver –- EDIT, see second screenshot, wanted to make a pic of DNS resolver and now MRT.exe also wants to do 'stuff' at 10.10.10.1.
Something is wrong. Obviously must be something on my side, but what?
( :-* )
-
Btw, BB, prollally this is why suddenly this media manager now is DEAD SLOW, when for the past two years it was BLAZINGLY fast.
Can you PLEASE PLEASE PLEASE (please :P ) suggest a solution and/or workaround? Because now every movie lookup takes 2 minutes, it used to take a second. This is not good for my heart, and you know about my heart :-*
-
Hey Mr J… Take it easy with your heart and those Latinas :)
I see that you have multiple VLANs. In the DNSBL tab, there is an option to create a Floating Permit rule. Please check that option and select all of the LAN segments (vlans etc) that need to access the DNSBL VIP... I think the reason why your devices might be slow, is that they can't get to the DNSBL VIP address. That is most likely the issue with your time out (Slowness)...
For the "Three Amigo" issue... Take a look at the Alerts tab in the "DNSBL" section, and it will list whats being blocked by DNSBL... You can click the Suppression Icon if for any FPs... However, this issue might be related to my first comment...
-
Like this plugin, first and only one I'm using so far but I'm having a problem.
Some of the feeds block properly, while some do not. At first I thought this was just Easylist, but I just found another.
I did flush the dns cache on the windowd box first
chrisj@bikatol ~ $ ns Default Server: pfbox.localdomain Address: 192.168.1.254 > 188server.com Non-authoritative answer: Server: pfbox.localdomain Address: 192.168.1.254 Name: 188server.com Address: 95.211.219.66 > zypenetwork.com Non-authoritative answer: Server: pfbox.localdomain Address: 192.168.1.254 Name: zypenetwork.com Address: 69.89.31.176 > www188.nebraskacb.mcarder.chefpa.mggschmitt.dorystarla.com Server: pfbox.localdomain Address: 192.168.1.254 Name: www188.nebraskacb.mcarder.chefpa.mggschmitt.dorystarla.com Address: 10.10.10.1From pfbox cli
[2.3-RELEASE][admin@pfSense.localdomain]/root: grep 188server.com /var/unbound/pfb_dnsbl.conf local-data: "188server.com 60 IN A 10.10.10.1" grep 188server.com /var/unbound/pfb_dnsbl.conf local-data: "188server.com 60 IN A 10.10.10.1" grep 188server.com /var/db/pfblockerng/dnsblorig/* /var/db/pfblockerng/dnsblorig/EasyListElements.orig:||188server.com^$third-party /var/db/pfblockerng/dnsblorig/EasyListFeeds.orig:||188server.com^$third-party grep 188server.com /var/db/pfblockerng/dnsbl/* /var/db/pfblockerng/dnsbl/EasyListElements.txt:local-data: "188server.com 60 IN A 10.10.10.1" [2.3-RELEASE][admin@pfSense.localdomain]/root: grep zypenetwork.com /var/unbound/pfb_dnsbl.conf local-data: "zypenetwork.com 60 IN A 10.10.10.1" grep zypenetwork.com /var/db/pfblockerng/dnsblorig/* /var/db/pfblockerng/dnsblorig/EasyListElements.orig:||zypenetwork.com^$third-party /var/db/pfblockerng/dnsblorig/EasyListFeeds.orig:||zypenetwork.com^$third-party grep zypenetwork.com /var/db/pfblockerng/dnsbl/* /var/db/pfblockerng/dnsbl/EasyListElements.txt:local-data: "zypenetwork.com 60 IN A 10.10.10.1" [2.3-RELEASE][admin@pfSense.localdomain]/root: grep www188.nebraskacb /var/unbound/pfb_dnsbl.conf local-data: "www188.nebraskacb.mcarder.chefpa.mggschmitt.dorystarla.com 60 IN A 10.10.10.1" grep www188.nebraskacb /var/db/pfblockerng/dnsblorig/* /var/db/pfblockerng/dnsblorig/hpHosts.orig:127.0.0.1 www188.nebraskacb.mcarder.chefpa.mggschmitt.dorystarla.com grep www188.nebraskacb /var/db/pfblockerng/dnsbl/* /var/db/pfblockerng/dnsbl/hpHosts.txt:local-data: "www188.nebraskacb.mcarder.chefpa.mggschmitt.dorystarla.com 60 IN A 10.10.10.1"When I thought it was just EasyList I did a: LIST ACTION disabled -> force update -> LIST ACTION enable. All are showing unbound.
Opps: grabed the wrong one above (second Easylist should have been frm my MDS.txt list)
Name: zzz.hudconnecthome.org
Address: 95.46.98.60tail -n 1 /var/db/pfblockerng/dnsbl/MDS.txt
local-data: "zzz.hudconnecthome.org 60 IN A 10.10.10.1"grep zzz.hudconnecthome.org /var/db/pfblockerng/dnsblorig/*
/var/db/pfblockerng/dnsblorig/MDL.orig:127.0.0.1 zzz.hudconnecthome.org
/var/db/pfblockerng/dnsblorig/MDS.orig:zzz.hudconnecthome.orgp.s. BBcan177 I was the guy on twitter talking about it on Sunday April 17th
-
Like this plugin, first and only one I'm using so far but I'm having a problem.
Some of the feeds block properly, while some do not. At first I thought this was just Easylist, but I just found another.
p.s. BBcan177 I was the guy on twitter talking about it on Sunday April 17th
Hey… welcome!
If you ping those domains from the pfSense box do they all resolve to the DNSBL VIP address?
Either your desktop has other DNS servers defined or the browser is bypassing the DNS server... what browser are you using? Ensure that the desktops only have pfSense set as its DNS Server. Might also need to exit and reopen the browser...
Flush the Browser DNS cache, and also flush the OS cache... Another option might be to create a Reject rule in the LAN interface to block any outgoing port 53 other than from the pfSense Box itself...
-
Like this plugin, first and only one I'm using so far but I'm having a problem.
Some of the feeds block properly, while some do not. At first I thought this was just Easylist, but I just found another.
p.s. BBcan177 I was the guy on twitter talking about it on Sunday April 17th
Hey… welcome!
If you ping those domains from the pfSense box do they all resolve to the DNSBL VIP address?
Either your desktop has other DNS servers defined or the browser is bypassing the DNS server... what browser are you using? Ensure that the desktops only have pfSense set as its DNS Server. Might also need to exit and reopen the browser...
Flush the Browser DNS cache, and also flush the OS cache... Another option might be to create a Reject rule in the LAN interface to block any outgoing port 53 other than from the pfSense Box itself...
already have the re-direct rule in place, it's been catching my chromecasts. (learned that by reading this and other threads / reddit, which was an awesome trick to learn btw).
Only working DNS server is the pfSense Box (cygwin):
chrisj@bikatol ~ $ ipconfig /all | grep -i "DNS Servers" DNS Servers . . . . . . . . . . . : fec0:0:0:ffff::1%1 DNS Servers . . . . . . . . . . . : fec0:0:0:ffff::1%1 DNS Servers . . . . . . . . . . . : 192.168.1.254The 2 ipv6 ones are the equiv of the 169 addresses Microsoft used to use for ipv4. Even when I ran the windows hotfix to disable ipv6, the problem remained.
Testing in Cygwin for NSlookup and IE for the sites (because Chrome and Fire Fox have ad blockers already). Also using Chrome on my Android phone.
Ping from pfSense gets the 10.10.10.1 addresses like expected. However even after flushing DNS again the clients still go to the actual ip addresses.
[2.3-RELEASE][admin@pfSense.localdomain]/root: ping 188server.com PING 188server.com (10.10.10.1): 56 data bytes 64 bytes from 10.10.10.1: icmp_seq=0 ttl=64 time=0.169 ms 64 bytes from 10.10.10.1: icmp_seq=1 ttl=64 time=0.115 ms 64 bytes from 10.10.10.1: icmp_seq=2 ttl=64 time=0.149 ms ^C --- 188server.com ping statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.115/0.144/0.169/0.022 ms [2.3-RELEASE][admin@pfSense.localdomain]/root:Same from windows client with flush:
C:\Users\chrisj>ipconfig /flushdns Windows IP Configuration Successfully flushed the DNS Resolver Cache. C:\Users\chrisj>ping 188server.com Pinging 188server.com [69.162.80.55] with 32 bytes of data: Reply from 69.162.80.55: bytes=32 time=47ms TTL=50 -
Ping from pfSense gets the 10.10.10.1 addresses like expected. However even after flushing DNS again the clients still go to the actual ip addresses.
[2.3-RELEASE][admin@pfSense.localdomain]/root: ping 188server[.]com PING 188server[.]com (10.10.10.1): 56 data bytes 64 bytes from 10.10.10.1: icmp_seq=0 ttl=64 time=0.169 ms 64 bytes from 10.10.10.1: icmp_seq=1 ttl=64 time=0.115 ms 64 bytes from 10.10.10.1: icmp_seq=2 ttl=64 time=0.149 ms ^C --- 188server.com ping statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.115/0.144/0.169/0.022 ms [2.3-RELEASE][admin@pfSense.localdomain]/root:Same from windows client with flush:
C:\Users\chrisj>ipconfig /flushdns Windows IP Configuration Successfully flushed the DNS Resolver Cache. C:\Users\chrisj>ping 188server[.]com Pinging 188server.com [69.162.80.55] with 32 bytes of data: Reply from 69.162.80.55: bytes=32 time=47ms TTL=50Ya you can see that the pfSense has no issue in resolving that domain to 10.10.10.1
What does a tracert 188server[.]com (kinda dangerous to post those domains as-is :) )
What happens if you clear out those two IPv6 DNS settings?
-
The following PR #107 for pfBlockerNG has been merged for pfSense 2.3 only:
pfBlockerNG v2.0.10 - Changelog:
-
Cosmetic Improvements to the Widget.
-
Add "Gateway Groups" to "Custom Gateway" Advanced In/Outbound Firewall customizations.
-
Advanced Outbound Firewall Rule customizations:
-
Switched "Custom Port" option from "Source" to "Destination" port.
-
Fix issue with "Custom Protocol".
-
-
Added a patch to fix an issue with 4 missing Countries in the MaxMind Database.
MaxMind is aware of the issue. (Countries = Africa - SS, N.America - BQ,CW,SX) -
Other under-the-hood improvements.
(Note - Double check all of your firewall Rules after this update!)
-
