pfBlockerNG DNSBL service not starting/stopped but DNSBL working fine?
-
Greetings all,
the pfb_dnsbl service is reported stopped while the widget reports everything green and in fact pinging the various test sites yields 10.20.10.1 as result as it should. Is there some other issue I am unaware of? The unbound service is working correctly and reporting no anomalies in the logs. Any reason why the service would be reported halted but DNSBL apparently works fine? I am running the latest 2.4.5 release of pfSense and 2.2.5_35 version of pfBockerNG-devel (tried reinstalling it but nothing changed and no errors reported).Cheers!
-
-
After fiddling around I noticed that I had changed the default web configurator port to 8443 which is the same default port of the pfb_dnsbl listener service: this made the dnsbl "pitfall" partially work (I would get the configured pitfall IP when pinging any ad domain), but it would fail to report and count it. Changing the default port to 9443 and force reloading fixed it! So be sure to not overlap the web configurator port with the dnsbl listener service port as there is apparently no error reported in the logs (but probably by manually restarting the service via cli it would report a binding problem though I didn't manage to check if that was the case as I was concentrating on the pfblockerng logs).
-
Yeah, ...
Deciding not to use the default proposed values,
and/or
Having multiple services listening on the same port
are very ancient pitfalls.Like : trying to sell your car to 2 people - or attributing the same phone number to 2 houses ;)
-
Yes - changing default values certainly can be a pitfall, but as they are default values at the same time they can/should be changed as default port values are ultimately a standard point of entry and is actually good practice in hardening security - nes pas? Granted that not all scenarious require this, it is still a suggested practice (and has demonstrated it's validity in time). My bad here was not realizing there were 2 services using the same port as no major red flags were raised: what was surprising to me was the non-report of any errors when scrutinizing the default logs. Upon digging further I see I was not the only one in a similar situation as can be read in this post:
https://forum.netgate.com/topic/133712/pfblockerng-devel-2-2-1-upgrade-fails-to-start-pfb_dnsbl-serviceWhile the issue here was an unexpected overlapping of IP ranges, the same anomaly was seen (unable to bind).
The fact that there is nothing immediately reported in the logs is puzzling and only a manual restart from the shell can reveal this as shown; maybe this should be appearing in the standard log for quicker corrective actions (just my humble suggestion) keeping in mind that errare humanum est (sed perseverare diabolicum!).
