Unbound not responding on all chosen interfaces after reboot
-
@gertjan said in Unbound not responding on all chosen interfaces after reboot:
unbound gets restarted and now it will find the OpenVPN interface and 'bind' (use) to it. Did you saw such an event ?
Thank for your time.
I don't use "All" interfaces so that all DNS queries are routed to the VPNs (I have at the moment a total of 3 to test redundancy) for privacy reasons. It is said that this is the only way to prevent DNS leaks to the actual ISP at WAN.
Unbound doesn't seem to restart at all after initial boot for any reason. Watchdog not helpful in this case as the service is really running.
I just increased log level from 3 to 5 but I don't think it will show me any new information for what I am looking for.
Will shutdown and boot again to have a new look at it.
Thanks again. -
@gertjan
Tried removing the physical WAN cable and it brings unbound to apparently resolve itself.Tried removing all VPNs but leaving only 1.
Unbound starts 2 seconds before every interface and does nothing after that.Thank you once more.
-
@robotox said in Unbound not responding on all chosen interfaces after reboot:
@gertjan said in Unbound not responding on all chosen interfaces after reboot:
unbound gets restarted and now it will find the OpenVPN interface and 'bind' (use) to it. Did you saw such an event ?
Thank for your time.
I don't use "All" interfaces so that all DNS queries are routed to the VPNs (I have at the moment a total of 3 to test redundancy) for privacy reasons. It is said that this is the only way to prevent DNS leaks to the actual ISP at WAN.Why not just enable forwarder mode in the unbound configuration and tell it to forward to a DNS server on the other end of your VPN ? (Presumably head office) That way it will not try to query root servers.
Also you could use egress rules in floating rules to block outgoing queries on the WAN interface so that even if unbound tried to send dns queries outside your VPN's they would be blocked.
Because unbound runs on the firewall itself only egress rules can block its query traffic.
-
@dbmandrake
Hi, unbound is in forwarding mode with selected Outgoing Interfaces -- not "All".
Tried with or without declaring the VPN provider's DNSs.
Floating rules are set up to prevent leaks to WAN.
As far as I understood, those would apply to the client devices only -- the firewall's setup for Unbound is managed separately.
As far as I understood, to achieve the desired solution I need to unselect "All" and select only those desired interfaces.
Thanks. -
@dbmandrake
This is potentially wildly off topic; but are we attempting to spoof MACs?
I could potentially see it initially come up with real MAC; then swap to fake MAC and bork things. -
Added my plea here https://redmine.pfsense.org/issues/13707.
-
I'm with that problem too. I'm using pfsense+ 23.01 but it happened on 2.6 too. My setup is a virtual pfSense running on qemu (Linux) with explictly passed through intel dual port 1 Gig adapter to the pfSense so it works as bare-metal NIC.
Each and every reboot of pfSense guest, machine reboot, renders Unbound unusable - it starts but it doesn't resolve a thing. Only restart of the service helps immediately.
My setup is similar to those described in the other places - listen on LAN, localhost, outgoing interface WAN. I tried various workarounds for this eg. setting gateway monitoring address to something few hops further than default ISP gw - like 1.1.1.1 but no avail... the issue persist.
-
Hi,
I now have an SG-2100 with 23.05.1 for the same setup and still the same problem.
Unbound fails to start as I have OpenVPNs as Outgoing Network Interfaces.
Still trying to get attention at https://redmine.pfsense.org/issues/13707. -
While it's technically only a workaround and I would hope this will get fixed one day, the pragmatic solution is to just set "Network Interfaces" and "Outgoing Network Interfaces" to All, and simply use firewall rules to block / allow access to the DNS server from client devices.
That way, no matter how interfaces go up or down during boot or later on (including VPN's going up and down after the system has booted) unbound will always bind to all interfaces, but access will be dictated by the firewall rules for each interface.
This is how I have been running ever since reporting the issue, and in some ways blocking using firewall rules is a more explicit and secure way to prevent access to the DNS server for clients who should not have access than relying on unbound to bind to the correct interfaces in its own configuration.
Given the default firewall rules for an interface are to block, this is fairly easy because unless you add an allow rule access to the DNS server is blocked by default including attempts to query from the WAN side.
-
Consider also using Unbound ACL rules.
-
@Gertjan Much less secure, because unbound still receives and processes the packets and then decides whether they should be ignored or responded to based on its own configuration file.
If there was ever a problem like a buffer overflow found in unbound it would be vulnerable to attack from clients that are "blocked" by the ACL list but allowed by firewall rules.
Firewall rules on the other hand are absolute, and do not allow any packets to reach unbound for processing and would prevent such exploitation. So if you're going to bind to all interfaces (as in this workaround) why not just set access to unbound using firewall rules. I would not rely on unbounds own ACL's except to allow remote subnets which are normally denied by default. I would not rely on it as a means of blocking.
-
Now that's what I call 'considering'
-
Thank you for bringing the thread back to life!
But in my case, the problem being with Outgoing Interfaces, rules won't apply to the firewall. -
Now testing the SG-2100 with 23.05.1 for the similar setup but with multiple Wireguards instead of multiple OpenVPNs.
Unbound starts correctly.
I am guessing that Wireguard is faster than OpenVPN starting at boot.
Thanks again.
