Clients time out to IPv4-only sites after enabling DNS64/NAT64 on OpenWrt router (intermittent synthesis failures)

Environment

Home network: OpenWrt 22.03 router running dnsmasq + tayga-based NAT64; LAN clients dual-stack (SLAAC + DHCPv4); clients include Windows 10, macOS 12, Android 11; upstream ISP provides IPv4/IPv6.

Symptoms

Random subset of devices (Windows laptops and Android phones) experience timeouts when visiting IPv4-only websites (e.g., example-v4.test) while other IPv6-capable sites load normally; browser shows long hang then DNS or TCP timeout; HTTPS sites sometimes fail TLS after long stall.

Observations

tcpdump on router shows AAAA queries for IPv4-only sites returning synthesized IPv6 addresses occasionally, but many AAAA responses are missing during failures; when AAAA returned, traffic to NAT64 prefix (::ffff:...) is attempted; ping to synthesized address sometimes responds, sometimes no route; router kernel logs show occasional conntrack failure and nat64 translation errors; tayga process occasionally restarts a few seconds before outages.

Already attempted

Restarted tayga and dnsmasq (recovered connectivity temporarily); disabled NAT64 and forced client DNS to use upstream IPv4 resolver (clients could then reach IPv4-only sites again); increased tayga tun MTU to 1280 (no change); rebooted router (short-lived fix); captured full packet traces and saved router config.

Question

What are likely causes for intermittent DNS64/NAT64 synthesis or translation failures on OpenWrt, and what reversible diagnostics and mitigations can I run to isolate whether the problem is DNS64, kernel NAT, conntrack limits, or tayga instability?

Post timeline

COMMUNITY RESPONSES

Verified community troubleshooting

0 replies

No answers yet..

Showing 0 of 0 community responses

AI DIAGNOSTICS

Incident analysis

Updated 2d ago• Trouble ID

Most likely causes

tayga process crash or memory leak causing intermittent loss of NAT64 translation 90%

conntrack table exhaustion on the router causing new flows to be dropped (translation requires conntrack entries) 80%

dnsmasq/DNS64 returning no AAAA answers intermittently due to cache corruption or upstream rate-limiting 55%

Summary

Symptoms show the problem occurs at the synthesis/translation layer: AAAA answers are not consistently available and when present, packets to the NAT64 prefix sometimes fail to be translated. Temporary recovery after restarting tayga/dnsmasq and router reboots suggests a resource exhaustion or a transient service crash. Kernel conntrack or nat table exhaustion, tayga crashes due to edge cases (e.g., TCP state collisions), MTU mismatches, or dnsmasq returning incorrect answers under load are all plausible. TLS failures after long stalls suggest broken intermediary state (partial TCP connections) rather than pure DNS.

Suggested Fixes

Diagnostic step 1

Enable persistent logging and capture: increase router log level, collect kernel dmesg, and rotate logs to remote syslog host before reproducing failure to preserve crash output (do not share private keys or credentials).

Diagnostic step 2

Monitor conntrack usage: run watch -n1 'cat /proc/sys/net/netfilter/nf_conntrack_count && cat /proc/sys/net/netfilter/nf_conntrack_max' during normal and failure periods to see if count approaches max; if high, temporarily increase nf_conntrack_max and note effect.

Diagnostic step 3

Instrument tayga: run tayga under systemd with Restart=no and use journalctl -f to observe crashes; enable core dumps to a safe location (ensure no sensitive memory is uploaded) and collect process logs for debugging before restarting.