pfBlockerNG-devel feedback
-
@bbcan177 said in pfBlockerNG-devel feedback:
I am not a user of CARP, so all feedback appreciated about it.... I can definately add a "VHID" option and will checkout the Alias option also...
If no one would report other, I'd go with the Alias option if I'd be you ;) Piggy-backing the existing CARP VIP is far easier than creating a separate CARP interface and is also recommended bei the devs itself to reduce network multicast/broadcasting overhead. :)
Offering the CARP option, too, would cover those missing corner cases, whereas someone doesn't use a VIP on LAN (or other interfaces) for some reason or another. :) -
Please I need help with strange behaviour of pfBlockerNG-devel in my network.
I have logs full of denied connections to UA servers 176.119.4.9:53 UDP and 176.119.4.8:53 UDP.
After some research I found that pfsense box is asking continuously for PTR 8.4.119.176.in-addr.arpa and PTR 9.4.119.176.in-addr.arpa. According to "lsof -n|grep UDP" on pfsense box process who is generating these reguest is "php_pfb"..:php_pfb 47639 root 15u IPv4 0xfffff8004cb469e0 0t0 UDP wan_IP:36014->isp_dns_IP:domain
I believe this issue is same as mentioned here.. https://www.reddit.com/r/homelab/comments/9u4nqm/windows_dns_server_dnsexe_sending_to_known_bad/
Thanks for any help
pfBlockerNG-devel 2.2.5_19
pfsense2.4.4-RELEASE (amd64) -
Increase the pfSense Resolver -> Log Verbosity -> 3 (I can't remember if 2 is enough to log outbound DNS requests). Then review the resolver.log to see which Lan device on your network is making those requests.
-
I´ve already done that.
This Lan device is internal DNS server. From logs it´s trying to resolve PTR 8.4.119.176.in-addr.arpa and PTR 9.4.119.176.in-addr.arpa queries by contacting 176.119.4.9:53 UDP and 176.119.4.8:53 UDP. But these queries are coming from pfsense box.In pfsense dns logs is visible that pfsense is asking not only my internal LAN DNS but ISP DNS server as well.
And connections from my LAN DNS server are denied by pfBlockerNG
(to servers 176.119.4.9 and 176.119.4.8 ....this range is blacklisted via feed https://rules.emergingthreats.net/fwrules/emerging-Block-IPs.txt) -
I was alerted of a crash recently and had to manually restart the two pfBlocker processes:
pfb_dnsbl - pfBlockerNG DNSBL service
pfb_filter - pfBlockerNG firewall filter serviceI am running pfBlockerNG-devel net 2.2.5_22
Crash report begins. Anonymous machine information: amd64 11.2-RELEASE-p6 FreeBSD 11.2-RELEASE-p6 #3 518496b29ae(RELENG_2_4_4): Wed Dec 12 07:41:44 EST 2018 root@buildbot2.nyi.netgate.com:/build/ce-crossbuild-244/obj/amd64/ZfGpH5cd/build/ce-crossbuild-244/pfSense/tmp/FreeBSD-src/sys/pfSense Crash report details: PHP Errors: [26-Mar-2019 14:29:44 America/Chicago] PHP Fatal error: Allowed memory size of 536870912 bytes exhausted (tried to allocate 4096 bytes) in /usr/local/www/pfblockerng/pfblockerng_log.php on line 192 [26-Mar-2019 14:29:44 America/Chicago] PHP Fatal error: Allowed memory size of 536870912 bytes exhausted (tried to allocate 12288 bytes) in /etc/inc/notices.inc on line 105
-
@TekGamer You attempted to open a large log file in the Log browser and it ran out of memory. Either need to download the file and view in an offline viewer or view that file from the shell.
-
@BBcan177 Ok, in a future release, is it an option for you have the viewer not attempt to load a log file if it is too large, and just display a message to download it to view in an offline viewer? So it doesn't crash?
-
You can manage the log files size in Log Settings (max lines)
Some of the other types of files available to browse are just too big for any browser/viewer.Increasing memory on the system might help, but again there are limits in what you can do in a browser.
-
I’ll check my log size, I did leave it at the default. As for RAM, I already have 16 GB, which is the max my Qotom Q575G6 supports.
-
You can increase some memory limits in /etc/inc/config.inc, however the changes will be lost on pfsense upgrade.
// Set memory limit to 512M on amd64. if ($ARCH == "amd64") { ini_set("memory_limit", "512M"); } else { ini_set("memory_limit", "128M"); }
-
I installed pfBlockerNG-devel on a fresh 2.4.4 system.
For the Firewall 'Auto' Rule Order, how do I get the "Default Order"(original format) into the drop down selection list? I don't want to allow pfB_Pass/Match before all other rules - I just want pfB_Block/Reject same as pfBlocker 2.1.4 -
@Double-K
Those are the default settings now... If none of those Auto rule settings work for your needs, you can always use "Alias Type" Action settings and manually create the firewall rules to suit. Click on the blue infoblock icon for the Action setting for more details. -
@BBcan177 Thanks! Any plan to offer both options (the new default format & the old original format)?
-
@Double-K said in pfBlockerNG-devel feedback:
@BBcan177 Thanks! Any plan to offer both options (the new default format & the old original format)?
Not really... I never win with Auto Rules... This list would be 100000000000 different variations and no one will be happy with it.... So for now... I give up ;^)
-
@BBcan177 :-)
-
BBcan177, it's with great pleasure to report that I am extremely grateful and happy with pfBlockerNG-devl...never had an issue except the occasional feed load failure which usually recovered later that day or the next day...really appreciate you hard work, thank you.
-
I am so grateful for your work that I will be a patreon member very shortly.
Other than an occasional curl error and for some reason on routes I don't show anything on the vip address but I do on the host address and have stats.
I am investigating that today. -
PfBlockerNG has been working well. I only wish it could do wildcards and/or regex in DNSBL like pihole can do (different DNS server, I know). Also, when I block a domain in Opendns it blocks subdomains too. PfBlockerNG does not. That is all I really want to do.
EDITED: I do now realize that I can enable the TLD feature and it will block subdomains. It was just not where I was expecting to find that.
-
Ran into an interesting issue where a DHCP interface ended up changing IPs and the new IP Address was on a list. While the IP Address being on a list is an issue, it broke other services as the feed stopped traffic (unrelated to the list) that shouldn't have been interrupted.
It would be greatly appreciated if there was a means to categorically exclude each interface - possibly as a choice of: None, IP Address or Network. Something that reveals that an interface IP Address/Network matched in a list and a means to locate the specific list(s) (or pf table) where the IP Address "matched" would be helpful.
FYI - may have missed it, but didn't locate anything that inferred a means to "exclude" an interface's IP Address (or network) - without specifying the IP/Network. This would be critical for interfaces that are DHCP driven. The exclusion of the firewall itself (IP/Network) from any feed would ensure that pfB can remain "first check" ("Default format") before services, without it potentially taking down services. This avoids potentially "unsavory" sources from being able to reach any service(s) in the first place.
Hadn't seen this issue previously, so was caught 'off guard' by the fact that this happened and took a little to determine the source of connections being rejected.
Thanks!
-
@justme2 said in pfBlockerNG-devel feedback:
where a DHCP interface ended up changing IPs and the new IP Address was on a list.
Woow. Impressive.
What IP range ? Where ? What entity hands out thee kind of IP's ? And, most important, what list ?