IPv6-only home network times out on IPv4-only websites after switching to DHCPv6-only LAN

Environment

Home network: Ubiquiti EdgeRouter X (firmware 2.0.9) as router, ISP provides native dual-stack on WAN. LAN configured with DHCPv6 (stateless) and RA; IPv4 DHCP disabled on LAN; clients include Windows 11 laptop, Android phone (Android 13), and Debian 12 server (server runs dnsmasq 2.86 on 192.168.0.2 as local resolver).

Symptoms

Many websites (e.g., example.com, some news and banking sites) consistently time out in browsers on all clients. Sites that have IPv6 records load normally. Mobile apps that rely on IPv4-only endpoints also exhibit failures. Pinging IPv6-only hosts succeeds.

Observations

On a Windows laptop, traceroute to example.com resolves to an IPv4 address and hangs after router hop; traceroute6 to ipv6.google.com completes. DNS queries using system resolver return both A and AAAA where available. The Debian server shows no default IPv4 route for the LAN (ip -4 route missing); curl -4 to an IPv4-only site returns 'Connection timed out' immediately; curl -6 to an IPv6 site works. Router configuration shows DHCPv4 server disabled; firewall rules include MASQUERADE for WAN IPv4 NAT but source NAT statements reference an IPv4 LAN subnet that devices no longer use.

Already attempted

Re-enabled dnsmasq on server and checked resolv.conf; tried switching Android phone to mobile data (works); enabled IPv4 DHCP on one test client with a static 192.168.0.0/24 address and it reached IPv4 sites via NAT successfully; temporarily enabled IPv4 DHCP server on router for a single client and that client could reach all sites; rebooted router and clients; flushed client DNS caches; disabled any IPv6-only forwarding settings in router (no change).

Question

What diagnostics should I run next to determine whether this is a missing NAT64/DNS64 requirement, an ISP-side limitation, or a local router misconfiguration? How can I restore IPv4 reachability without reverting the entire LAN to dual-stack DHCPv4 immediately?

Post timeline

COMMUNITY RESPONSES

Verified community troubleshooting

0 replies

No answers yet..

Showing 0 of 0 community responses

AI DIAGNOSTICS

Incident analysis

Updated 1w ago• Trouble ID

Most likely causes

LAN moved to IPv6-only addressing (clients have IPv6 but no IPv4 addresses) while router NAT/masquerade configuration still expects IPv4 LAN addresses. 95%

Firewall rules on router are filtering IPv4 traffic from current client addresses or lacking an IPv4 source NAT rule for new addressing. 90%

Missing or misconfigured NAT64/DNS64 service if the intention was IPv6-only LAN to reach IPv4-only destinations. 20%

Summary

Symptoms point to a LAN that has become effectively IPv6-only for client addressing while Internet content remains a mix of IPv4-, IPv6-, and dual-stack-only sites. Clients resolve IPv4 addresses but lack an IPv4 path because IPv4 addressing/NAT or router rules no longer apply to current client addresses. Working-by-enabling-IPv4-DHCP-on-a-client indicates the issue is local to how the LAN is provisioned or NATed rather than the upstream ISP completely blocking IPv4.

Suggested Fixes

Diagnostic step 1

Check each client for an IPv4 address (ipconfig /all or ip -4 addr). If clients lack IPv4, confirm whether that was intended and whether NAT64/DNS64 is configured on the router.

Diagnostic step 2

On the router, verify IPv4 masquerade/NAT rules apply to the active LAN subnet(s). If you disabled DHCPv4, ensure NAT rules don't reference the old subnet address space.

Diagnostic step 3

Temporarily re-enable IPv4 DHCP for a small test group (as you did) to confirm persistent reachability; this is reversible and helps isolate whether IPv4 addressing is the issue.