Failed to send UDP reply (Destination address required)

[emrsmsrli]

Expected Behaviour:

OS: Ubuntu 24.04.3 LTS

 # compose.yml
  pihole:
    container_name: pihole
    image: pihole/pihole:latest
    restart: unless-stopped
    network_mode: host
    volumes:
      - /home/emre/docker_data/pihole:/etc/pihole
      - /home/emre/docker_data/pihole/dnsmasq.d:/etc/dnsmasq.d
    cap_add:
      - NET_ADMIN
    environment:
      - TZ=Europe/Stockholm
      - FTLCONF_webserver_api_password=XXX
      - FTLCONF_LOCAL_IPV4=192.168.0.2     
      - FTLCONF_webserver_port=8125
      - FTLCONF_dns_interface=enp5s0
      - FTLCONF_dns_reply_host_IPv4=192.168.0.2
      - FTLCONF_dns_reply_host_force4=true

Docker version 28.4.0, build d8eb465

When a DNS request is made from an ip address that belongs to a wireguard peer, I get a warning in FTL that says WARNING Connection error (10.100.0.2#45342): failed to send UDP reply (Destination address required. And naturally the client that made the request never receives a reply

Actual Behaviour:

DNS queries are replied correctly from any permitted address

Debug Token:

https://tricorder.pi-hole.net/7LVf6n8g/

[emrsmsrli]

According to my dpkgs logs, I upgraded these packages today and maybe one of these causes the issue?

2025-09-11 15:17:59 upgrade libxml2:amd64 2.9.14+dfsg-1.3ubuntu3.4 2.9.14+dfsg-1.3ubuntu3.5
2025-09-11 15:17:59 upgrade bind9-host:amd64 1:9.18.30-0ubuntu0.24.04.2 1:9.18.39-0ubuntu0.24.04.1
2025-09-11 15:17:59 upgrade bind9-dnsutils:amd64 1:9.18.30-0ubuntu0.24.04.2 1:9.18.39-0ubuntu0.24.04.1
2025-09-11 15:17:59 upgrade bind9-libs:amd64 1:9.18.30-0ubuntu0.24.04.2 1:9.18.39-0ubuntu0.24.04.1

[Bucking_Horn]

Your Pi-hole Docker container is running in host mode, which would allow it to also see traffic from its host's wg0 interface (which is carrying 10.100.0.1/24), but your debug log shows you have configured your Pi-hole's Interface settings to Respond only on interface enp5s0.

listeningMode = "SINGLE" ### CHANGED, default = "LOCAL"

Try switching to Allow only local requests or Permit all origins.

On a side note:

@emrsmsrli

FTLCONF_LOCAL_IPV4=192.168.0.2

That env var has been deprecated (and you also have FTLCONF_dns_reply_host_* in place already).
You can remove it, see also Upgrading from v5.x - Pi-hole documentation.

[emrsmsrli]

Thanks for the reply. My wireguard interface is actually on my router (openwrt) and not on the same host. What you see in the debug logs is the legacy interface I’m no longer using.

Thanks for the side note, I’ll update it

[Bucking_Horn]

@emrsmsrli

My wireguard interface is actually on my router (openwrt) and not on the same host. What you see in the debug logs is the legacy interface I’m no longer using.

Your debug log shows it as active, with an active entry in your host's routing table, which could contribute to your observation, as it is likely messing up traffic destined to your router's wireguard gateway (apparently using the same 10.100.0.0/24 IP range).

If you do not intend to use that wg0 interface on your Pi-hole host, you should remove it from active duty, e.g. by bringing it down with sudo wg-quick down wg0 (or equivalent).
You should also consider to disable or uninstall Wireguard from your Pi-hole machine, to prevent that wg0 would be brought back up on reboots.

[emrsmsrli]

That was certainly the issue, I feel stupid now Thanks for the help!