@ronpfs said in Problem after pfBlockerNG-devel 3.0.0_16 update:

@chudak Your FW Rules is only for TCP/IP, you need FW Rules to allow ICMP if you wanna use Ping.

Of cause, I have FW rule to allow ICMP, otherwise I won't be able to ping at all !

You can search de GeoIP .txt files for the Networks that puzzle you.

There are probably good guides or posts on how to configure your pfSense to achieve your goals.

You seem to be suggesting a mis-configuration, which is possible. But I've provided a detailed tests and settings, that can be repeated and/or confirmed and/or proofed wrong.

What exactly do you suspect wrong with the settings based on what's shown ?

One note - the same pfBNG configuration has been in use with no issues for long time.

@BBcan177
I had to do a clean install of pfSense to make python mode work. Not sure why. It was a two year old working configuration with multiple updates and never had an issue.

Now with python mode can I let go of unbound dns now or still need to use it? I have an internal well configured BIND dns which I would like to use instead of unbound.

@gerardomdp

EDIT: I was looking inside logs and I found this in system.log

coApr 10 07:56:58 pfSense kernel: sonewconn: pcb 0xfffff8001ad2e5b8: Listen queue overflow: 193 already in queue awaiting acceptance (16 occurrences) Apr 10 07:58:09 pfSense kernel: sonewconn: pcb 0xfffff8001ad2e5b8: Listen queue overflow: 193 already in queue awaiting acceptance (12 occurrences) Apr 10 07:59:27 pfSense kernel: sonewconn: pcb 0xfffff8001ad2e5b8: Listen queue overflow: 193 already in queue awaiting acceptance (20 occurrences) Apr 10 08:00:00 pfSense php[58548]: [pfBlockerNG] Starting cron process. Apr 10 08:00:30 pfSense kernel: sonewconn: pcb 0xfffff8001ad2e5b8: Listen queue overflow: 193 already in queue awaiting acceptance (96 occurrences) Apr 10 08:01:35 pfSense kernel: sonewconn: pcb 0xfffff8001ad2e5b8: Listen queue overflow: 193 already in queue awaiting acceptance (706 occurrences) Apr 10 08:02:39 pfSense kernel: sonewconn: pcb 0xfffff8001ad2e5b8: Listen queue overflow: 193 already in queue awaiting acceptance (592 occurrences) Apr 10 08:03:40 pfSense kernel: sonewconn: pcb 0xfffff8001ad2e5b8: Listen queue overflow: 193 already in queue awaiting acceptance (616 occurrences) Apr 10 08:04:43 pfSense kernel: sonewconn: pcb 0xfffff8001ad2e5b8: Listen queue overflow: 193 already in queue awaiting acceptance (301 occurrences) Apr 10 08:05:44 pfSense kernel: sonewconn: pcb 0xfffff8001ad2e5b8: Listen queue overflow: 193 already in queue awaiting acceptance (250 occurrences) Apr 10 08:06:44 pfSense kernel: sonewconn: pcb 0xfffff8001ad2e5b8: Listen queue overflow: 193 already in queue awaiting acceptance (1372 occurrences) Apr 10 08:07:44 pfSense kernel: sonewconn: pcb 0xfffff8001ad2e5b8: Listen queue overflow: 193 already in queue awaiting acceptance (1082 occurrences) Apr 10 08:08:44 pfSense kernel: sonewconn: pcb 0xfffff8001ad2e5b8: Listen queue overflow: 193 already in queue awaiting acceptance (1164 occurrences) Apr 10 08:09:44 pfSense kernel: sonewconn: pcb 0xfffff8001ad2e5b8: Listen queue overflow: 193 already in queue awaiting acceptance (1551 occurrences) Apr 10 08:10:44 pfSense kernel: sonewconn: pcb 0xfffff8001ad2e5b8: Listen queue overflow: 193 already in queue awaiting acceptance (1339 occurrences) Apr 10 08:11:46 pfSense kernel: sonewconn: pcb 0xfffff8001ad2e5b8: Listen queue overflow: 193 already in queue awaiting acceptance (1459 occurrences) Apr 10 08:12:46 pfSense kernel: sonewconn: pcb 0xfffff8001ad2e5b8: Listen queue overflow: 193 already in queue awaiting acceptance (1777 occurrences) Apr 10 08:13:47 pfSense kernel: sonewconn: pcb 0xfffff8001ad2e5b8: Listen queue overflow: 193 already in queue awaiting acceptance (1394 occurrences) Apr 10 08:14:49 pfSense kernel: sonewconn: pcb 0xfffff8001ad2e5b8: Listen queue overflow: 193 already in queue awaiting acceptance (1712 occurrences) Apr 10 08:15:50 pfSense kernel: sonewconn: pcb 0xfffff8001ad2e5b8: Listen queue overflow: 193 already in queue awaiting acceptance (2304 occurrences) Apr 10 08:16:50 pfSense kernel: sonewconn: pcb 0xfffff8001ad2e5b8: Listen queue overflow: 193 already in queue awaiting acceptance (1295 occurrences) Apr 10 08:17:51 pfSense kernel: sonewconn: pcb 0xfffff8001ad2e5b8: Listen queue overflow: 193 already in queue awaiting acceptance (726 occurrences) Apr 10 08:18:51 pfSense kernel: sonewconn: pcb 0xfffff8001ad2e5b8: Listen queue overflow: 193 already in queue awaiting acceptance (1534 occurrences) Apr 10 08:19:54 pfSense kernel: sonewconn: pcb 0xfffff8001ad2e5b8: Listen queue overflow: 193 already in queue awaiting acceptance (1434 occurrences) Apr 10 08:20:54 pfSense kernel: sonewconn: pcb 0xfffff8001ad2e5b8: Listen queue overflow: 193 already in queue awaiting acceptance (1120 occurrences) de_text

@wolfsden3 said in Another block for no good reason:

172.56.8

grep "172.56.8." /usr/local/share/GeoIP/cc/*.txt /usr/local/share/GeoIP/cc/North_America_v4.txt:172.56.8.0/22 /usr/local/share/GeoIP/cc/North_America_v4.txt:172.56.8.0/22 /usr/local/share/GeoIP/cc/US_rep_v4.txt:172.56.8.0/22 /usr/local/share/GeoIP/cc/VI_v4.txt:172.56.8.0/22

So that range is both in VI_v4.txt and US_rep_v4.txt, the Filterlog service report one of the 3 it finds.

Try putting the allow rule before the deny rules. Or put the IP or Network in a Whitelist group.

@aweidner said in [TLD blacklist, exclusion and whitelist]

For a new-to-pfblockerng-person like me this sounds unnecessary unintuitive. If there is a blacklist, why can't i use the whitelist in the same realm?

Unbound mode is the original/first generation of DNSBL. It relies on Unbound local-zone and local-data entries to block domains.

TLDR;
Unbound Mode is too restrictive in wildcard blocking. Unbound Python mode (the next generation of DNSBL) doesn't use Unbound's local-zone/local-data entries, and removes all these types of restrictions. Therefore, you can use the DNSBL Whitelist feature with Python mode in this circumstance.

Existing pfBlockerNG DNSBL Unbound mode:

In this mode, entries are added to Unbound with an include file located at:

/var/unbound/pfb_dnsbl.conf

For each single domain to be blocked, a local-data entry is added:

local-data: "example.com A 10.10.10.1"

Any DNS request for example.com would be sinkholed to 10.10.10.1 where the DNSBL Webserver will respond to that request.

If the TLD Wildcard blocking option is enabled, entries will be added to Wildcard block domains:

local-zone: "xyz" "transparent" local-data: "example.xyz 60 IN A 10.10.10.1" local-data: "example2.xyz 60 IN A 10.10.10.1"

For each TLD (ie: xyz), a transparent zone is created, and any xyz domains that need to be wildcard blocked are added to the associated transparent zone entry with local-data entries.

When users want to Wildcard block a whole TLD, TLDs would be added to the TLD Blacklist with a local-zone redirect entry:

local-zone: "ru" redirect local-data: "ru 60 IN A 10.10.10.1"

If "ru" is wilcard blocked, and a user wants to allow a specific ru domain to be allowed, domains can be added to the

TLD Whitelist. The entries in Unbound will use a local-zone static entry to block all domains except for domains that are
explicitly defined with a local-date entry;

local-zone: "ru" "static" local-data: "ramblr.ru A 31.31.205.163"

Possible workaround after a brief off-thread conversation: I set GeoIP Top Spammers to Alias Native and then disabled it again. I then manually ran the cron entry "/usr/local/bin/php /usr/local/www/pfblockerng/pfblockerng.php dcc >> /var/log/pfblockerng/extras.log 2>&1" and it didn't log the alert into extras.log like the others. If I don't post back in a month it worked. :) Also there will be an update coming at some point, though we'd have to get current to update.

I can also (kind of) confirm this.

But just to be clear - a speed test will result in full speed.
But some web pages will open very slow, at first i thought my dns is very slow.
As when the page load it does at a normal speed, just very delayed.

As nearly every website is using sources(scripts, ad, tracker,...) from all over the place, its hard to pinpoint.
I think it might be slow if some parts of the page are blocked.

But I don't know if the browser is waiting for a timeout or a js script has trouble.

@bbcan177

Thank you for being so fast in fixing this and the great work you are doing with pfBlockerNG!

With the modifications all is working well :).

@bbcan177 I believe the problem is PHP. See this thread and this Redmine bug report which in turn references this likely root cause Redmine bug report.

@rtw915 said in More frequent CRON interval options:

I am still stuck on this. Under the CRON jobs I tried to edit this from this:

0 * * * * root /usr/local/bin/php /usr/local/www/pfblockerng/pfblockerng.php cron >> /var/log/pfblockerng/pfblockerng.log 2>&1

to this:

*/15 * * * * root /usr/local/bin/php /usr/local/www/pfblockerng/pfblockerng.php cron >> /var/log/pfblockerng/pfblockerng.log 2>&1

However, the Updates tab in pfBlockerNG says that the CRON job is missing, and then deletes the job and creates a new one with the hourly update interval.

So this does not work

You should not change these cron entries.
They are set and maintained by the pfblockerng package.

@ertnec said in pfBlockerNG-devel v3.0.0_15 not clearing down tmp files, slowly fills /tmp up.:

@bbcan177 said in pfBlockerNG-devel v3.0.0_15 not clearing down tmp files, slowly fills /tmp up.:

@ertnec
Download an updated script for ASN processing and see how that goes.

curl -o /usr/local/pkg/pfblockerng/pfblockerng.sh "https://gist.githubusercontent.com/BBcan177/3aabea5edf7b40554d93085bff380b6f/raw"

Hi, I've replaced the file you suggested, however, it still seems to be leaving these files alone & /tmp is still filling up.

I can confirm this.
Update: Still present in v3.0.0_16
(I added a cron-job: rm /tmp/pfbt* )

Regards,
fireodo

@rk0
I'd just reinstall if you think you have the 'Save Settings' checkbox marked. You could always just build fresh and restore the config, too.

@tzvia Thank you! I should have thought about adding in-addr.arpa to domain overrides. I added one for each 24-bit subnet, and that did the job.

@cobra_phil
Redirecting the DNS traffic should work anyway.
Possibly unbound sends it's traffic to the ISPs DNS. Or you did something wrong. Since you don't provide your settings, it's hard to say.
You can sniff the packets to see, what's going on.

However, also not clear what the goal of the WAN-LAN bridge is indeed. If you only want your clients to pull network settings from the ISP you can enable the DHCP relay and configure the clients network accordingly.

@gertjan Downloads are instant.
Filtering through 1m takes most of the time.
And no, the pipes are not saturated @100Mbits

And dns doesn't suffer overall.
If I get the dreaded error in resolver logs, no resolution is possible.
Ping with ip works great.

I need to experiment a bit more, but since this is service affecting during normal hours

@derelict said in Disable NAT rule creation:

@thisisme It can also render the page much less pleasant, with broken image placeholders (browser-dependent), ALT text, etc.

Adaway for Android does the same. Im fine with that. Why am I not allowed to decide this myself?

@mind12 Hello,

I have reviewed each of the recommended steps:
1- DNS resolver is listening for all interfaces, if I configure that it only listens for the Bridge interfaces, it presents us with the same result.

2- Modify the validation code for the virtual IP, add an IP of the example segment 192.168.1.203 and the same result still does not block domains, for verification use nslookup and it continues to show the original IP of the domain which was used as test, in few words is not blocking.

3- Well my opinion about this is that apparently there is a link between the DHCP service and the DNSBL to work with it, but as I said this is only my opinion.

Previously I was looking for more information and I was with that unknown that if I wanted to make a bridge interface with DNS blocking, I would have to configure one of the interfaces that comprise the Bridge for this case the LAN will activate the DHCP service.

@digdug3 thank you

@xentrk If you have huge log files, the Report Alert Filter may timeout. Grep the log files from a Shell instead.

@bbcan177 said in ship pfblockerbg-devl logs?:

@rtw915
As an example:
https://www.reddit.com/r/pfBlockerNG/comments/bu0ms0/pfblockerngtelegrafinfluxdb_ip_block_list/

That is cool! I did not know that was possible. I saw in your Reddit post that you stated "pfSense doesn't have a lot of graphing/logging functionality." I 100% agree with you that it should not be part of the firewall, but it would be awesome to have a Netgate preferred solution like Graylog with a step by step guide to integrate the logging from the firewall and its common packages into a centralized visualization platform.

Looks like this is related to the GeoIP2 Lite lists for representative countries. Details in this forum post and the Max Mind release notes.

@bob-dig
I temporarily disabled my feed and added reddit.com and www.reddit.com to the DNSBL Custom_List and the website (and others) is still not blocked. (Yes, I did a force update all)

I have tried on different computers on the network and they can still access it.

I have also tried on three different browsers.

I am really confused why some sites are blocked while others are not.

I'm not an expert but I used 3cx with pfsense for 3 years at my previous job.

I had the same issue with no audio on one side on two different occasions with 3cx. 1. was when I did not have the full cone NAT configured properly. I don't have access to 3cx anymore but I remember there was a network troubleshooting utility. Until I fixed the NAT problem it would not return successful. This might help https://www.3cx.com/docs/pfsense-firewall/

The other time I had a similar issue was because the user vpn was not routing and using NAT instead. After I changed the OpenVPN config to routing and added the VPN static routes in pfsense pointing to the VPN server it worked.

I also remember there were instances where we would receive calls from external entities that used VOIP and those connections did not need to go through our SIP provider. I realized this because I had originally opened the SIP ports with the src address of the SIP provider, and most calls would work except from some specific vendors. After opening up the the SIP ports from "any" those vendors started working as well.

As far as iTalkBB, I have never used it, but pfBlockerNG just uses regular firewall rules. You can turn on logging and see if something is a miss. Or even faster test just temporarily disable the firewall rules and see if stuff starts working.

I have noticed the Geo IP is not 100%, so maybe you are running into an issue there. It was recommended somewhere that you don't block the world. I prefer to do the reverse which is just to allow specific countries.

Hope this helps!

@bbcan177 Thanks. I fixed it the usual way: delete and add it back in :-)

@gertjan You misunderstand me...

Firewall has a LAN IP.

I installed it from a workstation with a fixed ip.... not given by DHCP

@gertjan Can you share me Skype id or phone number for help. if you no issue.