Bug 4228 - Unbound fails to start if an attempt is made to listen on any except the first IP, on multiple-IP PPP interfaces
Unbound fails to start if an attempt is made to listen on any except the firs...
Status: ASSIGNED
Product: unbound
Classification: Unclassified
Component: server
1.8.3
x86_64 FreeBSD
: P5 major
Assigned To: unbound team
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2019-02-27 05:27 CET by Stilez
Modified: 2019-02-27 07:38 CET (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Stilez 2019-02-27 05:27:34 CET
I'm using Unbound on OPNSense current (19.1), although it's probably identical behaviour on pfSense current, and FreeBSD generally.

SCENARIO:

A user has a PPPoE WAN with a block of IPs (say 1.2.3.0/26)
The user wishes to use 1.2.3.6 for incoming DNS queries from peers on the internet. 

Then the correct  config line "interfaces: 1.2.3.6" prevents Unbound from starting up.

DISCUSSION:

The way that PPP(oE) links work with pf, is that the interface is allocated just the first usable IP in the block, whatever that may be. (1.2.3.1 in the example). By default all traffic goes via this IP. The other IPs in the block must be manually created as virtual IPs on the WAN.

In my own case, the attempt to add lines of config for:

interface: 1.2.3.2
interface: 1.2.3.3
interface: 1.2.3.4
(etc)

prevented Unbound from starting up. Adding a simple "#" to the start of these lines allowed Unbound to start up again, confirming the issue - but because of the commenting out, it couldn't listen to those IPs either.

SHould be testable by anyone with access to a PPP(oE) WAN, consistent here.
Comment 1 Stilez 2019-02-27 05:28:56 CET
Sorry, typo. "interfaces: 1.2.3.6" should read "interface: 1.2.3.6", the discussion is correct and the typo wasn't present in the config when tried.
Comment 2 Wouter Wijngaards 2019-02-27 07:38:33 CET
Hi Stilez,

So, what is the error that unbound prints when it fails to start?

There is a variety of options for binding to non-up or even non-existing interfaces.  Like ip-freebind: yes.  There is also ip-transparent that is similar.

Best regards, Wouter