Hello, Sorry for the noise, it appears the issue was due to a local misconfiguration after all, the GUA IP used for NAT66 was getting removed and instantly readded back to its interface every time DHCPv6 client renewed its lease from the ISP, which was every 30 minutes. Not surprisingly that breaks all NAT66 mappings made from/to that IP. As also noted in my private E-Mail to Stephen, one issue highlighted here is the lack of notification about such issues with the probe. For instance I didn't notice that anything is wrong until almost a month later (and by then it was already difficult to pinpoint these issues to the configuration changes that I made earlier), as there is no E-Mail notification for probe connection flapping, only for 60+ minutes periods of disconnection. So perhaps it would be a good idea to consider adding more kinds of E-Mail notifications to Atlas in the future. If anyone is curious as to why NAT66 setup in the first place, my ISP only provides a /64, and that's already "spent" on my main primary VLAN. I don't want to subnet the /64 further and have to run DHCPv6 everywhere. For security reasons I want to place the probe into its own separate VLAN. So that one, as well as numerous other guest/VM/untrusted VLANs get their own 66:xxxx:/64s and are then NAT'ed into the router's own IPv6. Let me know if you have any better suggestions for these network conditions, aside from "Get a Different ISP" (only one ISP in my area provides IPv6) or "Demand More IPs" from the current ISP (very unlikely to be successful, they even allocate only /64s to business-class connections, and on residential those are also *dynamic*). -- With respect, Roman