Unbound stops listening on Interface
Since the update to the latest pfsense version unbound is broken. I'm using multiple interfaces/vlans on my system. All of them work properly except one. Unbound stops listening on this interface daily. Pfsense shows an open socket (port 53)for every interface/vlan except for this one every morning. A restart of unbound resolves the issue. The only special thing is that I have only one PC connected to this interface. Maybe the interfaces goes down when I shutdown the PC and unbound stops listening because of this.
Any idea how to fix this and why is it only happening with the latest pfsense?
Gertjan last edited by
I'm not using vlan's myself, so can't test such a setup, but I just ripped out the connector of one of my OPTx interfaces. Unbound didn't move.
When It back in, DNS (unbound) on that interface worked.
In the logs, no messages from unbound.
Some tasks were activated as a result of the interface down/up event, like - system log :
em2: link state changed to DOWN
/rc.linkup: Hotplug event detected for PORTAL(opt1) static IP (192.168.2.1 )
em2: link state changed to UP
but nothing in the unbound / resolver log.
Workaround : put a switch between the PC and pfSense.
Is this interface part of a VLAN ?
The PC ist directly connected to a physical port. No VLAN involved on this port, but a different subnet. I can't reproduce the problem with unplugging the device for a short time too. But every morning it is broken and only this interface is not listed with an open dns socket. Maybe pfBlockerNG ist somehow involved. I'll try to disable it this night.
I can reproduce it: Connect a PC directly with a LAN port of the pfsense and boot the PC up. Stop DNS Resolver (no reload), unplug lan cable, start Resolver, wait for start, wait some seconds more, connect PC. Then I can't resolve DNS with my PC. (Maybe need two tries to get the result)
Can someone else confirm this?
Gertjan last edited by
I think I understands what happens.
unplug lan cable, start Resolver
What happens at this very moment :
When unbound starts, it enumerates active interfaces. It will not 'bind' to interface that are not used/active. I have myself an quand Intel NIC PCI card, two of the ports are unused. These are unknown to unbound. After all, these NICs have no IP assigned.
Now for the fun part :
wait some seconds more, connect PC
So the NIC comes on line. It was already known to pfSEnse, so an IP gets assigned
And I do presume that the assigned DHCP server process gets waked up, and start dealing out leases.
But ..... unbound does not do something as "reacting to NIC up link messages". It keeps the list of known NIC's that were on line when it started. Your NIC comes up later on. unbound doesn't care. You have to re "start" unbound.
When you restart unbound now, it will 'see' the NIC, and serve that NIC with DNS services.
As said : Workaround : put a switch between the PC and pfSense. This way, the interface won't go down anymore - unbound keeps 'seeing' it as active, and even when unbound restarts, the interface won't get lost.
Stubbs last edited by
This post is deleted!
Can I report this somewhere? Never had any problems before. This comes up with the latest update.
Same here. I'm using multiple VLAN interfaces in pfSense. And just upgraded to pfSense2.5. After that the DNS resolver keep stopped working. i have to start it again and again. no logs showing why the Unbound stopped.
. All of them work properly except one. Unbound stops listening on this interface daily. Pfsense shows an open socket (port 53)for every interface/vlan
bingo600 last edited by
Have you seen this one
Thanks so much for pointing me to that thread!
Updated Unbound to 1.13.1 by running pkg upgrade -fy unbound
And so far it is stable for at least 2 hours!
I think the problem resolved!!
BTW, i have both "Register DHCP leases in the DNS Resolver" and the Register DHCP static mappings in the DNS Resolver enabled.
still crashing after updating to Unbound to 1.13.1
possibly just not as often
had crash around 1-2 days after upgrade that is still not acceptable.