Unbound fails to start because of repeated interface entries in config file, VIP/RA/Multi-WAN interaction

marcg

Running 26.03.1.

The unbound.config file can contain repeated interface directives. This prevents unbound from starting. Repeated entries are reliably generated in a particular VIP/RA/Multi-WAN scenario that I'll explain.

Example config file snippet below. Note that both fd04:f95f:5a7f:15::1 and fd04:f95f:5a7f:0015::1 appear, as do similar address pairs with the 15 replaced by 20 and 40.

interface: 192.168.15.1
interface: fd04:f95f:5a7f:15::1
interface: 192.168.20.1
interface: fd04:f95f:5a7f:20::1
interface: 192.168.40.1
interface: fd04:f95f:5a7f:40::1
interface: 192.168.10.2
interface: 192.168.99.1
interface: 192.168.50.1
interface: 192.168.51.1
interface: fe80::e63a:6eff:fe61:c5ee%igc1.15
interface: fe80::e63a:6eff:fe61:c5ee%igc1.20
interface: fe80::e63a:6eff:fe61:c5ee%igc1.40
interface: fe80::e63a:6eff:fe61:c5ee%igc1.95
interface: fe80::e63a:6eff:fe61:c5ee%igc1
interface: fe80::e63a:6eff:fe61:c5ef%igc2
interface: fe80::e63a:6eff:fe61:c5f0%igc3
interface: fd04:f95f:5a7f:0015::1
interface: fd04:f95f:5a7f:0020::1
interface: fd04:f95f:5a7f:0040::1
interface: 127.0.0.1
interface: ::1

Unbound fails in this situation, choking on the second instance of fd04:f95f:5a7f:15::1.

26.03.1-RELEASE][admin@pfSense.home.arpa]/var/log: !986
/usr/local/sbin/unbound -d -vvv -c /var/unbound/unbound.conf
[1781032523] unbound[88958:0] notice: Start of unbound 1.25.1.
[1781032523] unbound[88958:0] debug: setting ip-ratelimit-slabs: 4
[1781032523] unbound[88958:0] debug: setting ratelimit-slabs: 4
[1781032523] unbound[88958:0] debug: setting dnscrypt-shared-secret-cache-slabs: 4
[1781032523] unbound[88958:0] debug: setting dnscrypt-nonce-cache-slabs: 4
[1781032523] unbound[88958:0] debug: creating udp4 socket 192.168.15.1 53
[1781032523] unbound[88958:0] debug: creating tcp4 socket 192.168.15.1 53
[1781032523] unbound[88958:0] debug: creating udp6 socket fd04:f95f:5a7f:15::1 53
[1781032523] unbound[88958:0] error: can't bind socket: Can't assign requested address for fd04:f95f:5a7f:15::1 port 53(len 28)
[1781032523] unbound[88958:0] fatal error: could not open ports

Removing the duplicate entries manually allows unbound to start. Even so, LAN<>WAN communications and LAN<>unbound communications don't work reliably in the scenario when the primary WAN is down (guessing more than unbound is affected by the underlying issue)

Here's the scenario and config. This config worked reliably across multiple previous pfSense+ releases, including 25.11.

Two WAN interfaces. First is v4+v6. Second is v4 only. The v4 part of the first interface and the second interface are configured as an IPv4 failover gateway group.
Three internal interfaces -- igc1.{15,20,40} -- are configured for Track Interface to get respective GUA prefixes from the ISP on the first WAN interface.
Each of those internal interfaces has a corresponding VIP of the form fd04:f95f:5a7f:{15,20,40}::1/64 to create a ULA
The RA for each of those interfaces includes the respective VIP subnet as an RA Subnet

The duplicate config file entries and other breakage occur only when the following conditions are met: primary WAN interface is down and the VIP and RA entries for the interface are identically entered in the GUI. The following entries are not identical in this sense. They refer to the same address, but one is entered as :0015: and the other as :15:.

The following two entries are identical in this sense. Both have :0020:

When the VIP and RA address entries are entered with identical strings, duplicate entries appear in unbound.conf in a failover situation (v4 WAN only in my case). In a non-failover situation, the system works fine (v4 and v6 WANs in my case).

For now, I have non-identical strings in the RA Subnet and VIP -- e.g., 0015 and 15 -- which seems to solve the problem. Duplicate interface directives do not appear in unbound.conf while in failover.

marcg

Reported at https://redmine.pfsense.org/issues/16906

marcosm

The RA subnet shouldn't affect the DNS Resolver interface binding. Do you have custom configuration added to unbound? Any custom patches or scripts? You can also share the status file from /status.php here.

As for the RA subnets, any VIPs would indeed need to be included there as needed. For reference the RA configuration is at /var/etc/radvd.conf.

marcg

@marcosm, thanks.

I've uploaded a status file. It was taken in the broken failover state with identical GUI entries of fd04:f95f:5a7f:0020::1/64 for the igc1.20 VIP and igc1.20 RA Subnet. The duplicate entries appear in the status file's DNS-Resolver Configuration.txt.

No custom configurations to unbound other than some Host Overrides. No custom patches.

On scripts, I start a daemonized iperf3 via the shellcmd package. Also, on the primary WAN interface, there's a DHCP6c Configuration File Override to the following file, which is needed with ATT to get multiple /64 prefixes from their gateway. Nothing else.

interface igc0 {
    send ia-na 0;
    send ia-pd 0;
    send ia-pd 1;
    send ia-pd 2;
    request domain-name-servers;
    request domain-name;
    script "/var/etc/dhcp6c_wan_script.sh";
};
id-assoc na 0 { };
id-assoc pd 0 {
    prefix-interface igc1.15 {
        sla-id 0;
        sla-len 0;
    };
};
id-assoc pd 1 {
    prefix-interface igc1.20 {
        sla-id 0;
        sla-len 0;
    };
};
id-assoc pd 2 {
    prefix-interface igc1.40 {
        sla-id 0;
        sla-len 0;
    };
};

marcosm

I think I see what's happening, though I don't expect this to be a new issue. Since the track interface doesn't have an IPv6 address yet then the fallback address ends up being the VIP. Hence when the unbound configuration is generated it adds the VIP twice, first for the select LAN interface then for the selected VIP. I've posted a patch on the redmine that should resolve the issue.

marcg

@marcosm , thanks, that fixed it: no dupes in unbound.conf in failover mode when the VIP and RA Subnet addresses are entered identically in the GUI.

I don't know the exact release where the issue arose. My primary ISP has few outages nowadays. Failover definitely worked as recently as last year with similar (identical? ... can't recall) configs. That would have been on one or more of 24.11, 25.07, 25.11.

Anyways, glad it's working now ... thanks again!