DNS breaks after installing pfBlockerNG?
-
First of all, upgrade your pfSense. And while there, I'd suggest to stop using nanobsd and use amd64 full install.
-
Yes, it's because Unbound cannot start with the DNSBL custom options present before pfBlocker has populated them. But also pfBlocker cannot download the lists until Unbound has started.
In the full install the list contents persist across a reboot so it's not an issue.If you disable DNSBL you will be able to start Unbound and then you can re-enable DNSBL.
Steve
-
First of all, upgrade your pfSense. And while there, I'd suggest to stop using nanobsd and use amd64 full install.
Can you even do that on a firebox? https://doc.pfsense.org/index.php/PfSense_on_Watchguard_Firebox
-
No idea about 64bit, however at least you could use the full install (and avoid this issues with ramdisk, and tons of others).
As for the catch-22 DNS issue mentioned above, configuring DNS servers in System should help. I.e., Unbound should NOT be the only DNS server configured for the firewall itself.
-
Depends which firebox, most are 32bit only. Most covered there anyway. But you can boot from HD or run a full install from CF if required. I would normally recommend moving /var and /tmp to ramdisks but that defeats the purpose here.
As for the catch-22 DNS issue mentioned above, configuring DNS servers in System should help. I.e., Unbound should NOT be the only DNS server configured for the firewall itself.
Yep, I would have assumed that yet I have DNS servers defined and it fails everytime on a Nano install I have here. And not just until the cronjob runs either. I'll have to dig deeper.
Steve
-
Ah, I'm wondering if its the cause (catch-22) that at any time when a IP4/IP6/VPN Client IP got renewed, Unbound failed to restart itself. It is becoming a nightmare for us, we have to manually start unbound until we disabled DNSBL.
so adding extra DNS servers in System/General would solves??
-
If you are able to simply restart Unbound without disabling DNSBL first then it's probably not that. Sounds more like a timing issue.
However it's easy to test adding an alternative DNS server in general setup so you might as well try it.
Steve
-
If you are able to simply restart Unbound without disabling DNSBL first then it's probably not that. Sounds more like a timing issue.
However it's easy to test adding an alternative DNS server in general setup so you might as well try it.
Steve
You are right. It didn't work by adding an alternative DNS server, always got the error when IPs got renewed/any changes made under the System menu(ie. DNS servers changed and applied…): "/system.php: The command '/usr/local/sbin/unbound -c /var/unbound/unbound.conf' returned exit code '1', the output was '[1483291498] unbound[77155:0] error: bind: address already in use [1483291498] unbound[77155:0] fatal error: could not open ports'"
It is currently a nightmare to us. Manually restart Unbound is not an option. we have to disable DNSBL until this is addressed by pfSense dev teams.
-
Ok, that's something else. It implies either Unbound isn't stopping correctly or something else is already listening on port 53.
If you can trigger that again try running:
sockstat|grep :53If nothing shows it could still be a timing issue in restarting Unbound.
Steve
-
Also, if you have Services Watchdog package installed, make sure you did NOT add Unbound to it. (That causes race conditions and wreaks complete havoc on DNS when pfBNG updates the DNSBLs.)
-
Might just be that unbound take a long time to start (mine take up to 3 minutes)
When it boots unbound starts more than once, so while one instance is starting, a restart/reload happens and it can not bind to the port of the previous unfinished unbound. -
Also, if you have Services Watchdog package installed, make sure you did NOT add Unbound to it. (That causes race conditions and wreaks complete havoc on DNS when pfBNG updates the DNSBLs.)
No, I don't have Watchdog package installed.
-
Just wondering, Whats the difference between manually restart Unbound vs. Auto restart Unbound by pfSense? I'm really confused since the start process should be the same, manually restart works but auto restart doesn't work.
-
note my thread in the pfsense 2.4 forum, my unbound doesnt start on boot if I do not select the default ALL interfaces, when specific interfaces are chosen the bootup script gets all confused and breaks, although I can always start it fine from the gui.
So if you got specific network interfaces selected. change it to ALL to see if it fixes the boot problem.
-
I haven't had a chance to dig thru the Unbound/pfSense code to figure out this issue… but there definitely is an issue when utilizing DHCP... Hopefully one of the pfSense devs get a chance to improve that part of the code. I am unable to replicate in my environment as I am static...
-
Ah that's interesting. Do you know how that applies if you are using DHCP, as I am?
Like, DHCP WAN?
Steve
-
I have dhcp wan for ipv4 and ipv6.
On my setup there seems to be no ipv4 renewals been logged and as such no affect on unbound, but the dhcp wan ipv6 renews twice an hour and will restart unbound, I fixed it by manually patching the services.inc file to stop the configure_unbound function from restarting unbound.
Pfblockerng doesnt use that function so it can still restart unbound when it does its dnsbl updates.
-
I have dhcp wan for ipv4 and ipv6.
On my setup there seems to be no ipv4 renewals been logged and as such no affect on unbound, but the dhcp wan ipv6 renews twice an hour and will restart unbound, I fixed it by manually patching the services.inc file to stop the configure_unbound function from restarting unbound.
Pfblockerng doesnt use that function so it can still restart unbound when it does its dnsbl updates.
May I know what/how you fixed in services.inc?
-
sure
I used SECOIT GmbH's solution (crediting the original guy).
His post is here.
https://forum.pfsense.org/index.php?topic=89589.msg517047#msg517047
Be aware with this solution, if you do an action that requires a unbound restart/configure, you will manually need to stop and then start in the gui. pfblockerng will still be fine tho.
