1
Diagnostic step 1
Capture synchronized packet traces (tcpdump) on the IPv4 client-facing interface of the NAT64 gateway and on the IPv6 backend interface for the same flow when a failure occurs; include packet lengths, MSS, and observed TCP flags.
FULL AI ANALYSIS
IPv6-only backend reachable but client connections intermittently reset by NAT64 gateway
Generated Oct 3, 2026, 12:35:03 AM
Analysis summary
Intermittent RSTs from a NAT64 gateway are commonly due to state tracking issues (conntrack evictions or timeouts), packet MTU/fragmentation problems leading to connection failure (especially if ICMP v6 'Packet Too Big' messages are blocked), or a bug/limitation in the NAT64 implementation (race when mapping block devices or handling large packets). TCP offload or checksum offload can interact poorly with translation and fragmentation. The fact that reducing MTU reduced resets points to an MTU/fragmentation-related path or PMTU discovery failure, but conntrack pressure and kernel-level implementation bugs remain plausible.
Possible causes
PMTU / fragmentation issues (ICMPv6 'Packet Too Big' blocked between backend and gateway) causing retransmission behavior that leads gateway to reset connections
90%conntrack table evictions or timeouts causing the gateway to no longer recognize an established session and closing it with RST
65%a NAT64 implementation bug or race condition in tayga or kernel translation code under certain packet sizes
45%interaction between TCP segmentation offload (TSO/GSO) and NAT translation producing malformed packets seen as invalid by the peer
15%Suggested fixes
2
Diagnostic step 2
Monitor conntrack usage (conntrack -L / -S or /proc/net/nf_conntrack) while reproducing; increase nf_conntrack_max further and enable conntrack UDP/TCP timeout tuning to see if evictions correlate with failures.
3
Diagnostic step 3
Temporarily disable TSO/GSO/TSO6 on the gateway interfaces (ethtool -K <if> tso off gso off gro off) to rule out offload-induced corruption.
4
Diagnostic step 4
Verify that ICMPv6 'Packet Too Big' messages are allowed between backend and gateway; run traceroute6 and test with forced smaller MTU (ip link set dev <if> mtu <n>) to determine if reduced MTU removes failures consistently.
5
Diagnostic step 5
Upgrade or test an alternate NAT64 implementation (or a newer kernel/tayga version) on a spare node to see whether behavior changes, and review changelogs for known NAT64 bugs. If an implementation bug is suspected after diagnostics, escalate to the OS/NAT64 implementation community or vendor with packet captures and conntrack logs.