Private-network DNS from WARP clients gets no reply on 2026.9.3 (UDP times out, TCP reset); 2026.5.0 worked

[onetwomany]

Describe the bug

Since upgrading cloudflared from 2026.5.0 to 2026.9.3, DNS queries that WARP clients send through the tunnel's private-network routing to a DNS server on the origin LAN get no answer. UDP queries time out and TCP queries get "connection reset". Other TCP traffic to the same LAN address through the same tunnel (SSH on port 22) works. The same query worked through WARP while 2026.5.0 was running.

Packet capture on the cloudflared host during one test shows the following:

• UDP: cloudflared does not forward the client's packet. It sends its own query for the same name to the LAN DNS server, with query ID 0 and EDNS. The server answers in under 5 ms, and the WARP client never receives the answer.
• TCP: cloudflared opens a TCP connection to the DNS server's port 53, sends no data and closes it about 100 ms later. The WARP client receives a reset.
• Metric: during the test, cloudflared_virtual_origins_dns_requests_total{protocol="udp"} rose by 4. So cloudflared handles these flows with its built-in DNS resolver, and that path drops the reply.

The DNS server's address is also the first nameserver in the host's /etc/resolv.conf.

To Reproduce

1. Run cloudflared 2026.9.3 with a remotely managed tunnel and WARP routing enabled. Use the Docker image with --network host and tunnel --no-autoupdate run.
2. Route a private LAN range (192.168.50.0/24) to the tunnel. Run a DNS server on a LAN host, 192.168.50.180:53.
3. On a WARP client, run dig @192.168.50.180 example.com and dig +tcp @192.168.50.180 example.com.
4. UDP times out and TCP is reset. On the cloudflared host, the same dig commands answer normally.
5. Pin the image back to 2026.5.0 and run the same queries through WARP to compare.

Expected behavior

The WARP client receives the DNS answer, as it did on 2026.5.0.

Environment and versions

• OS: AlmaLinux 10 host, Docker image cloudflare/cloudflared:2026.9.3, digest sha256:072c067d25ccbe61d46e18f0d0723255f2bb5304f7317caa95b27031520ff92c, network=host
• Last working version: 2026.5.0
• WARP client: macOS 2026.7.1376.0, Gateway with WARP mode
• Tunnel: 4 healthy QUIC connections; ingress with hostname rules and a catch-all http_status:404

Logs and errors

At the default log level, cloudflared logs no error for these flows.

Additional context

The changes between 2026.5.0 and 2026.9.3 include no item about DNS or private-network flows. The bump to quic-go v0.59.1 (TUN-10557) is in that range.

[onetwomany]

Correction: the version is not the cause. After rolling the connector back to 2026.5.0 (image sha256:59bab8d3aceec09bf6bdb07d6beca0225ca5cd7ab79436a87ea97978fe1dc4f9, cloudflared version 2026.5.0), the same tests through WARP fail the same way: the UDP query times out and the TCP query is reset. TCP to port 22 on the same LAN address still connects. The statement in the report that 2026.5.0 worked is wrong. The only earlier success was through WARP on 2026-09-28, while 2026.5.0 was running. Something else changed between then and now, possibly on the edge side of private-network DNS handling. Please treat this report as: DNS answers from a LAN resolver behind a WARP-routed tunnel do not reach the WARP client, on both 2026.5.0 and 2026.9.3.