pfBlockerNG Devel 2.2.1 upgrade fails to start pfb_dnsbl service

[mcampbell]

2gb of ram:

DNS Resolver config (when pfblockerNG is running):

[mcampbell]

forgot to mention that I restarted dns resolver with pfblockerNG disabled, and the errors in resolving stopped showing up in the logs... maybe it was because nothing else uses it, not sure.

[RonpfS]

@bbcan177 said in PfBlockerNG v2.0 w/DNSBL:

pfSense has two types of DNS Services

• DNS Forwarder

• DNS Resolver

If you plan on using the DNSBL feature, you will need to use the DNS Resolver for your DNS queries, the DNS Forwarder is not an option for DNSBL. Its probably best to ensure that the DNS Resolver is working before using DNSBL.

The DNS Resolver is developed by NLnet Labs and is named 'Unbound'. It is a validating, recursive and caching DNS resolver. https://www.unbound.net/index.html

Some recommendations:

• The DNS Resolver can also be used in 'Forwardering mode'; however its best to not use this 'Forwarding mode' and keep it in 'resolver mode' as this will query the Root DNS servers for the DNS queries instead of relying on an ISPs DNS etc…

• If you use the 'DNS Resolver Forwarder mode', only configure 'DNSSEC' if the configured DNS servers support DNSSEC. The enabling of 'DNSSEC' to harden your DNS security is highly recommended.

• Disable the two "DHCP registrations" checkboxes, unless you really require those options.

Here is a good primer about the DNS Resolver (Unbound) https://calomel.org/unbound_dns.html

Disable DHCP Registrations as every new lease will restart Unbound
Static registration will restart unbound on DHCP services modification.

[RonpfS]

@mcampbell said in pfBlockerNG Devel 2.2.1 upgrade fails to start pfb_dnsbl service:

2gb of ram:

Well this isn't much memory for DNSBL usage.
You are also using RAM Disk for /var and /tmp, so they are competing for RAM with unbound when a Reload or Cron update is running.

[mcampbell]

I never had a problem with it before on the non devel version of pfblockerNG. I was using the standard version of pfblockerNG for months without issues--except when trying to use the the Amazon app on my phone on the network--it was constantly giving errors. My desire for greater visibility into what exactly was being blocked is what prompted me to upgrade to the devel version. Unless you're saying the new version is that much more memory intensive? At any rate, I can probably upgrade the ram without much issues... it's a little bookshelf type PC, but it should support up to 4GB of RAM.

[Qinn]

@mcampbell Maybe it's an idea to reinstall the 2.2.1 develop and only enable DNSBL_ADs in DNSBL (certianly not TLD) and the force an update (my 2 cents),

btw what's your pfSense version?

[BBcan177]

Check the pfSense system log and the resolver.log for any error messages. For unbound, suggest to increase the Adv setting "Log Verbosity" to "2".

You can also run the following command to see if it reports and errors:

/usr/local/etc/rc.d/pfb_dnsbl.sh restart

[mcampbell]

@Qinn , when I uninstalled everything, including settings, it still wasn't starting up, even with no settings loaded. I would think it should start up then. 2.4.3-RELEASE-p1 is what I'm currently on, though when I started this venture, I was on 2.4.3.

@BBcan177 , thanks for the advice, I will definitely try those out. I am linux savvy, so I know my way around on the linux side of things, but wasn't sure where the scripts ran on pfsense. I will happily try it out.

[mcampbell]

it already bore unexpected fruit:

[2.4.3-RELEASE][root@pfsense.home]/usr/local/etc/rc.d: ./pfb_dnsbl.sh restart
2018-08-14 21:35:14: (network.c.313) can't bind to socket: 10.1.10.2:443 Can't assign requested address

I don't believe anything is bound to that IP. Worth trying a different one?

[mcampbell]

Holy smokes, tried 3 or 4 very different IPs within the 10.x.x.x subnet, all ones that are not being used by my pfsense for any of its networks, before I finally decided to try 10.254.254.254. That did it! it's actually running. No idea why it wasn't working with any of the others... I'll take it though. Thanks everyone for helping me out!

[BBcan177]

What does this report? What IP range did you use for Openvpn? You don't need to stay in the 10 range... Can also try 192.168 or any other private IP range (RFC1918)

ifconfig

[mcampbell]

So it looks like the openvpn range had the range it was last configured for, but not some of the others that had failed.

[2.4.3-RELEASE][root@pfsense.home]/root: ifconfig | grep inet
        inet6 fe80::224:b2ff:fedf:a196%bge0 prefixlen 64 scopeid 0x1
        inet 73.82.108.146 netmask 0xfffffe00 broadcast 255.255.255.255
        inet6 fe80::2e0:66ff:fe6a:c58f%bge1 prefixlen 64 scopeid 0x2
        inet 10.10.0.1 netmask 0xffffff00 broadcast 10.10.0.255
        inet 10.254.254.254 netmask 0xffffffff broadcast 10.254.254.254
        inet6 ::1 prefixlen 128
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
        inet 127.0.0.1 netmask 0xff000000
        inet6 fe80::2e0:66ff:fe6a:c58f%bge1.2 prefixlen 64 scopeid 0x7
        inet 10.1.0.1 netmask 0xffffff00 broadcast 10.1.0.255
        inet6 fe80::2e0:66ff:fe6a:c58f%bge1.5 prefixlen 64 scopeid 0x8
        inet 10.2.0.1 netmask 0xffffff00 broadcast 10.2.0.255
        inet6 fe80::224:b2ff:fedf:a196%ovpns1 prefixlen 64 scopeid 0x9
        inet 10.2.10.1 --> 10.2.10.2  netmask 0xffffffff
        inet6 fe80::224:b2ff:fedf:a196%ovpns2 prefixlen 64 scopeid 0xa
        inet 10.1.10.1 --> 10.1.10.2  netmask 0xffffffff

I think that my choice works out fine though, 10.254.254.254 is way out of the way.