core: Unbound does not allow access WireGuard interface despite told to

Describe the bug

After setting up WireGuard VPN and specify the OPNsense unbound as the DNS server, I noticed that VPN clients cannot resolve DNS names. However if I restart the unbound after the system boots up manually, everything resumes working.

Here is a brief diagram of my interfaces set up.

WAN (ipv4, ipv6 address from ISP)
    |
LAN (10.0.1.1/24)
    |
IOT (vlan, 10.0.50.1/24)
    |
WG (tunnel address 10.252.0.1/24)

firefox_OP26kLWdP3 firefox_hWbwx12d3l

LAN clients are not affected by this bug.

Firewall log indicated the DNS request successfully made it to the unbound port. The WireGuard interface has already been assigned to interface “WG” (so I have a WG under “interface” and a “WireGuard” and “WG” under firewall rules).

Changing “Services->Unbound DNS->General->Network Interfaces” from “all” to manually picking “LAN WAN WG” does not resolve the bug. Checking access list conf file suggests that the WG interface (whose “address” is 10.252.0.1) is not allowed immediately after the system starts up, but somehow appears after a manual restart of unboud itself.

The Web GUI however successfully lists the WG address as being allowed in “Services->Unbound DNS->General->Allowed list” despite the address is not in the conf file.

firefox_Q0ImdnydR7

Could this be because unbound started “too early” than WG, that it cannot see the interface? I also noticed that my WAN for some reason often has ipv6 address bound very late, potentially 1 or 2 minutes after the system starts. And checking the access list of unbound suggests that the WAN ipv6 address is not in the list neither if it is not bound during the system start up, only appears after a manual unbound restart.

Steps to reproduce the behavior:

  1. Set up WireGuard following official doc with tunnel address “10.252.0.1/24”
  2. Add interface “WG” over “wg0”
  3. Configure unbound to listen on all interfaces
  4. Connect to VPN from a client, assign “10.252.0.1” as the dns address
  5. Client cannot resolve DNS names.
  6. Manually restart unbound from Web GUI.
  7. Client can resolve DNS names.

Relevant log files /var/unbound/access_lists.conf Immediate after boot:

access-control: 127.0.0.1/8 allow
access-control: ::1/64 allow
access-control: 10.0.50.1/24 allow
access-control: fe80::4262:31ff:fe08:8c1d/64 allow
access-control: 10.0.1.1/24 allow
access-control: 2604:4080:11ac:86e0:4262:31ff:fe08:8c1d/64 allow
access-control: 24.35.90.97/25 allow
access-control: fe80::4262:31ff:fe08:8c1c/64 allow

After a manual restart of unbound, notice the last line which is the WG interface. Also the second IPv6 address was on WAN port, which may suffer from the same issue as the WG interface.

access-control: 127.0.0.1/8 allow
access-control: ::1/64 allow
access-control: 10.0.50.1/24 allow
access-control: fe80::4262:31ff:fe08:8c1d/64 allow
access-control: 10.0.1.1/24 allow
access-control: 2604:4080:11ac:86e0:4262:31ff:fe08:8c1d/64 allow
access-control: 24.35.90.97/25 allow
access-control: 2604:4080:11ac:0:4262:31ff:fe08:8c1c/64 allow
access-control: fe80::4262:31ff:fe08:8c1c/64 allow
access-control: 10.252.0.1/24 allow

ifconfig:


igb0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=400b8<VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,VLAN_HWTSO>
        ether 40:62:31:08:8c:1c
        hwaddr 40:62:31:08:8c:1c
        inet6 fe80::4262:31ff:fe08:8c1c%igb0 prefixlen 64 scopeid 0x1
        inet6 2604:4080:11ac:0:4262:31ff:fe08:8c1c prefixlen 64 autoconf
        inet 24.35.90.97 netmask 0xffffff80 broadcast 24.35.90.127
        nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
igb1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=400b8<VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,VLAN_HWTSO>
        ether 40:62:31:08:8c:1d
        hwaddr 40:62:31:08:8c:1d
        inet6 fe80::4262:31ff:fe08:8c1d%igb1 prefixlen 64 scopeid 0x2
        inet6 2604:4080:11ac:86e0:4262:31ff:fe08:8c1d prefixlen 64
        inet 10.0.1.1 netmask 0xffffff00 broadcast 10.0.1.255
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
igb2: flags=8c02<BROADCAST,OACTIVE,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=6403bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6>
        ether 40:62:31:08:8c:1e
        hwaddr 40:62:31:08:8c:1e
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
        media: Ethernet autoselect
        status: no carrier
igb3: flags=8c02<BROADCAST,OACTIVE,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=6403bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6>
        ether 40:62:31:08:8c:1f
        hwaddr 40:62:31:08:8c:1f
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
        media: Ethernet autoselect
        status: no carrier
igb4: flags=8c02<BROADCAST,OACTIVE,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=6403bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6>
        ether 40:62:31:08:8c:20
        hwaddr 40:62:31:08:8c:20
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
        media: Ethernet autoselect
        status: no carrier
igb5: flags=8c02<BROADCAST,OACTIVE,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=6403bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6>
        ether 40:62:31:08:8c:21
        hwaddr 40:62:31:08:8c:21
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
        media: Ethernet autoselect
        status: no carrier
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
        options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6>
        inet6 ::1 prefixlen 128
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x7
        inet 127.0.0.1 netmask 0xff000000
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
        groups: lo
enc0: flags=0<> metric 0 mtu 1536
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
        groups: enc
pflog0: flags=100<PROMISC> metric 0 mtu 33160
        groups: pflog
pfsync0: flags=0<> metric 0 mtu 1500
        groups: pfsync
        syncpeer: 0.0.0.0 maxupd: 128 defer: off
igb1_vlan50: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        ether 40:62:31:08:8c:1d
        inet6 fe80::4262:31ff:fe08:8c1d%igb1_vlan50 prefixlen 64 scopeid 0xb
        inet 10.0.50.1 netmask 0xffffff00 broadcast 10.0.50.255
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
        vlan: 50 vlanpcp: 0 parent interface: igb1
        groups: vlan
wg0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1420
        options=80000<LINKSTATE>
        inet 10.252.0.1 --> 10.252.0.1 netmask 0xffffff00
        nd6 options=103<PERFORMNUD,ACCEPT_RTADV,NO_DAD>
        groups: tun wireguard
        Opened by PID 31549

Additional context This appears to be similar to this issue: https://github.com/opnsense/core/issues/3342, but the difference is that in my case the WG interface is not even showing up in the /var/unbound/access_lists.conf file until unbound being restarted.

Environment OPNsense 20.1.7-amd64 Intel® Core™ i5-7200U CPU @ 2.50GHz (4 cores) Network Intel® I210-AT

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Comments: 28 (12 by maintainers)

Most upvoted comments

Just to chime in since I ran into this exact same issue. The ‘best’ work around for me was to manually add the WireGuard network (i.e. 10.0.0.0/24 which is used by the configured WireGuard ‘peers’) to the UnBound ACL.

@Brainfrazzle This is the UnBound ACL config that I used:

image

Just to chime in since I ran into this exact same issue. The ‘best’ work around for me was to manually add the WireGuard network (i.e. 10.0.0.0/24 which is used by the configured WireGuard ‘peers’) to the UnBound ACL.

Thank you very much @QNimbus! This solved my issue. I was starting to think I misconfigured something until I found your post.