When Every Network is 192.168.1.x

Summary

The Problem If you manage devices at multiple customer sites, you already know this problem. Every consumer router and ISP modem ships with the same default subnet. The specific range varies by manufacturer (192.168.1.0/24, 192.168.0.0/24, 10.0.0.0/24), but the result is the same: every site ends up on one of the same few subnets. Security integrators, MSPs, AV installers, home automation companies. Anyone who deploys equipment at residential sites encounters this immediately. The NVR at one customer's home is 192.168.1.100. The NVR at the next customer's home is also on 192.168.1.x. And the one after that. One remote site isn't a problem. Set up a VPN gateway, add a route for 192.168.1.0/24, and traffic flows to the right place. Two sites with different subnets, still fine. But the moment two sites share the same address range, you have an ambiguity that IP routing cannot resolve. A packet destined for 192.168.1.100 has two valid destinations. The routing table accepts one entry per prefix. One site works. The other is unreachable. At 50 or 300 sites, the problem is absurd. You can't maintain unique subnet assignments across networks you don't control. You didn't configure these routers. You don't have admin access to most of them. And re-addressing a customer's home network to avoid conflicts with your other customers isn't realistic. There's a second problem compounding the first. The devices you need to reach, cameras, NVRs, NAS units, etc., are embedded systems with fixed firmware. There's no SSH, no package manager, no way to install a WireGuard client. You need to reach them, but they can't participate in any overlay network directly. Why Traditional Approaches Fail Port forwarding The most common workaround. Open ports on the customer's ISP modem and map external ports to internal devices. This works until the ISP replaces or resets the modem. When that happens, the port forwarding configuration is gone. You're dispatching a technician. Port forwarding also ...