sure I used SECOIT GmbH's solution (crediting the original guy). His post is here. https://forum.pfsense.org/index.php?topic=89589.msg517047#msg517047 Be aware with this solution, if you do an action that requires a unbound restart/configure, you will manually need to stop and then start in the gui. pfblockerng will still be fine tho.

ok will keep that in mind, thanks.

sorry I didnt think of the obvious :)

awesome… thanks a ton

@lpallard: @BBcan177: Typically best to use "Permit Outbound", so that it only allows access to those IPs when the LAN makes the request… Also ensure that the Permit rule is above the Block rules on the LAN interface. If you're using "Auto type" rules, you might need to select the correct "Rule Order" option in the General Tab. Thanks for you reply.  I think the rules order was the problem.  I completely forgot to change it from defaults after I had reinstalled the package and did not click the checkbox to retain the settings.. Thanks Anthony! Anytime my friend :)

Excellent!!! Thank you so much. It 's because i didn't known if it was a normal behaviour or not :) Thanks! I will keep an eye to see if everything seems to be fine with the update and the catch of any ip listed in the list.

Any suggestions as to which lists would be better to use?

Thank you this has now worked for me Which I have also added to the page https://www.facebook.com/groups/pfsense.official/ to help others…

There was a request for this awhile back… Hasn't really gone anywhere, so I'm working on it as time permits...      https://twitter.com/pfsense/status/788203605950025728 Here is a sneak peak of what it will look like... [image: BfKVr5S.png]

@gabrimonfa: IMHO it would be better to warn the user if he/she sets the ports and protocol is left to any. Or maybe the UI should be made consistent with the "Add rule". Default protocol is TCP and choosing any hide source and dest ports This is already fixed in the next package release… Just in testing phase now ...

the reason for the blank img method is some sites check for a 200 status.

Yes of course, there's nothing special required to run both.

Thanks for the script, it was quite a timesaver. A number of the lists ought to end up in the DNSBL section rather than IP4 (Privacy/SomeoneWhoCares is one example) - if you're maintaining the script that's something to check.  If I get some time I might take a look.

You don't. Not possible. Put them on a non-proxied VLAN.

@micropone: i noticed 2 of my list one has 0.0.0.0 x.com and 127.0.0.1 q.com. the one with 0.0.0.0 has no count of hosts but the txt file has like 200 hosts in it! Does pfsense prefer 0.0.0.0 or 127.0.0.1. at the beginning ? DNSBL will parse those feeds and collect the domain name, regardless of the two formats you indicate… So no issue with either...

@healeyc: where did I lose you? Right in the subject of the thread.  ::) I cannot see how pfBNG would be causing any interface to lose an IP, except that you did not RTFM and configured the DNSBL IP to be inside your current networks. The VIP must be completely outside of any subnets used on pfSense. [image: Screenshot_pfBNG_DNSBL_VIP.png_thumb] [image: Screenshot_pfBNG_DNSBL_VIP.png]

@rnmixon: Arrggh! Thanks - I made a (bad) assumption that they would be ordered/condensed for faster lookup. Does that happen when they get loaded? The alias table seems to be created by appending the file one after the other (US_v4 + CA_v4 + AU_v4 > pfB_PERMITTED_AUTH_IP.txt).

IMHO Its just as important to protect the outbound… YMMV

Run the following command from the shell to re-download/re-build the MaxMind DB: php /usr/local/www/pfblockerng/pfblockerng.php dc Follow that with a "Force Reload - ALL".