IPv6-only LAN: HTTPS to IPv4-only sites times out while ICMP to synthesized addresses succeeds

Environment

Home lab: OpenWrt 22.03 router configured DHCPv6-only (prefix delegation routed to LAN), NAT64/DNS64 implemented by tayga+bind on same box; client OS Ubuntu 22.04 LTS and iOS 16.5 devices on LAN

Symptoms

From client browsers, navigation to several well-known IPv4-only websites (no AAAA records) times out at the HTTP/TLS layer. Curl returns 'Connection timed out' after TCP handshake attempt; small HTTP requests occasionally succeed. Ping6 to the DNS64-synthesized IPv6 (64:ff9b::/96) address responds. ICMPv6 traceroute reaches translator but TCP connections stall.

Observations

DNS64 synthesizes AAAA for queried names (dig AAAA shows 64:ff9b::aaaa). 2) ping6 to synthesized address succeeds. 3) curl -v --ipv6 shows TCP SYN sent but no SYN-ACK for large response pages; small responses (100–200 bytes) sometimes complete. 4) tcpdump on router shows IPv6 packets forwarded to NAT64 translator, but corresponding IPv4 side never returns ICMP 'fragmentation needed' messages. 5) MTU on PPPoE uplink is 1492; LAN IPv6 MTU 1500. 6) Disabling firewall's MSS clamping did not change result. 7) Temporary bypass by forcing IPv4 (using forced A lookup via another resolver) works.

Already attempted

Restarted tayga and bind, toggled firewall rules, disabled iptables conntrack helper modules, enabled and then disabled MSS clamping on the router, tested with different client devices, replaced DHCPv6-only with dual-stack (IPv4+DHCPv6) which restored connectivity to IPv4-only sites.

Question

Why do TCP connections to IPv4-only sites stall when using my NAT64/DNS64 setup over an IPv6-only LAN, while ICMP and small payloads succeed? How can I make NAT64 reliably handle regular HTTPS traffic without reverting to dual-stack?

Post timeline

COMMUNITY RESPONSES

Verified community troubleshooting

0 replies

No answers yet..

Showing 0 of 0 community responses

AI DIAGNOSTICS

Incident analysis

Updated 3h ago• Trouble ID

Most likely causes

PMTU black hole due to MTU mismatch (PPPoE or lower-MTU IPv4 path) combined with missing ICMPv6 'Packet Too Big' from IPv4 side to IPv6 sender (no path for signals), causing TCP packets to be dropped 85%

Router firewall or ISP blocking ICMP or fragment/MTU messages needed for PMTU discovery between IPv4 and IPv6 domains 50%

Stateful NAT64/translator (tayga) running out of conntrack/NAT entries or dropping initial SYN/SYN-ACK packets under load, so TCP handshakes never complete 30%

Summary

Symptoms indicate a translator/path MTU or TCP MSS issue: ICMPv6/ICMP 'fragmentation needed' messages are likely being blocked or not generated on the IPv4 path (PPPoE MTU 1492 vs IPv6 MTU 1500). Large TCP connections stall because packets exceed MTU and the translator or remote IPv4 path cannot notify the IPv6 sender with ICMPv6 'Packet Too Big'. Intermittent success for small responses fits PMTU black hole behavior. Secondary possibilities include stateful NAT64 conntrack exhaustion causing new TCP handshakes to be dropped, or misconfigured DNS64 synthesizing addresses that reach different IPv4 endpoints causing asymmetric routing/filtering.

Suggested Fixes

Diagnostic step 1

Verify MTU end-to-end: from a client, use ping6 with large payloads and 'don't fragment' equivalent (e.g., ping6 -s) to find the largest working packet size; note 'Packet Too Big' responses if any.

Diagnostic step 2

Temporarily enable TCP MSS clamping to the lowest common MTU (e.g., 1420) on the router/translator to force path-safe segments; test HTTPs transfers for stability.

Diagnostic step 3

On the router, capture tcpdump on both IPv6 and IPv4 faces during a failing transaction and check for 'ICMPv4 fragmentation needed' on the IPv4 side and 'Packet Too Big' on IPv6 side. If missing, check ISP/PPPoE device for ICMP filtering.