and unbound reloads instantaneously

CoinBlocker feed is on gitlab.io, so maybe that is being blocked? Can you get to that domain?

The Dyre feed is down. Not sure when it will return. The other Abuse feeds came back online tho:
https://www.reddit.com/r/pfBlockerNG/comments/a6zs1u/abuse_sslbl_is_back_online/

@bbcan177 Thank you. I did that and it works!

WORKED LIKE A CHARM !

thx !

@veldthui said in Getting a list of .bid IP's:

and have not had any spam for the last two days.

Music to my ears :)

@tippet5x said in PfBlockerNG Error:

pfSense-pkg-pfBlockerNG: 2.1.4_14 [pfSense]

Update to pfBlockerNG v2.1.4_16 which has this issue fixed... You can also move to pfBlockerNG-devel which is much improved.

Sorry, after further testing, unbound is needing to be manually stopped if pfblocker is enabled in order to make setting changes to DNS resolver. Not the pfblocker services.

Do DNS resolver config changes work fine for you both without needing to manually interfere with stopping unbound? I just find it odd cause ive done 3-4 reinstalls lately and it’s presented this problem to me in all instances.

The only thing that I guess has changed as of recently is using the devel release. I don’t recall having to manually stop unbound previously.

Anyway, this can be marked as resolved as I don’t know if this is how it’s intended to be but I’ve managed a workaround.

Cheers for the awesome package BBcan! It’s some great stuff. I’ll flick you a donation to show my appreciation.

Hi, I believe I had run into this exact issue myself and this happened upon across multiple installs of it too.

I narrowed it down to the fact that some of the log files were not being created for any odd reason. For each of the log files, make sure they exist, and if they don't, manually create them using touch.

More info here.... I'd like to add a page for this in the GUI, but too much to do with so little time....
https://www.reddit.com/r/pfBlockerNG/comments/9vwkmm/ip_ranges_for_amazon_aws/

ps - Come and subscribe to the reddit page :)

Hmm, I see.

edit: Or at least I think I see. In the above example it’s only timing out when actually trying to talk (ping) to the resolved address. The lookup works fine. I don’t really see why that is a big issue since talking to a blocked domainname from PFsense itself should not be necessary anyhow. I mean, that doesn’t work now with the VIP adress either. You are only talking with an “empty” replacement Weebservice that has no data. Is there any situation where you are depending on the firewall itself needs to be able to ping the address?

Anyhow

Two things:
1: Could this issue be solved by making a VIEW in UNBOUND so the PFsense box itself is in another VIEW Zone with no PFblock.conf attached?

2: Alternatively, could “disabling VIP Alias” also entail that the PFsense box itself then is setup to NOT use the build in UNBOUND resolver?

Posted two PR to fix this issue. See my recent posts in this forum.

@guardian said in When is pfblockerNG-devel going to be pfblockerNG?:

Any idea when pfblockerNG-devel going to be the production version?

Likely Feb 2019

@ronpfs

That was it!..
thx

@bbcan177 said in Unbound crashing:

@bouke said in Unbound crashing:

pfBlockerNG-devel 2.2.5_19

You can try the new "Live Sync" feature, which will update the changes on the fly without an Unbound Reload. But that is only when the package updates DNSBL/Unbound and not any DHCP updates to Unbound from the pfSense side.

Happy new year and thanks. Just enabled this feature on 01-01-2019 08:05 am (local time) ;-)

I have already determined the cause of my problem. The lab workstation i was using to test this out with still had static DNS server entries configured on one of the network adapters I was using. Once I pointed them all to my pfsense box, everything was working fine. I feel stupid for having overlooked something so simple. 😣

@gertjan said in Getting Hammered:

I you liked the port-knocking on "22", have a look at what happens on your port "25" and "443", you'll be amazed.

Seeing a few on 443 and a couple on 25.

Normally, your mail server already has something like fail2ban and a rather huge setup to filter out fake connection, like temptation to relay, temptations to load your inbox with spams, etc.
A (internal, on a LAN) web server (port 443) : same thing : a real hail storm.
Not filtering these servers can put a real load on your servers.

It is a Exchange server and not set up for routing mails and any attempt to route through it just gets rejected. I also have a large set of rules to reject spam but wanted to use pfBlockerNG to block out spamming IP's. YEs exchange can do it but requires the Edge Server to do it. Dont want another VM running to to do IP filtering.

I realise they are scripts trying as well on the ports rather than real humans.