You manage thirty client networks. At least half of them sit on 192.168.1.0/24. The moment you need a VPN tunnel into two of those clients from the same technician workstation at once, routing breaks — silently, then loudly.
This isn’t a one-off. It’s the default state of an MSP’s network estate, and it gets worse every quarter you keep onboarding clients without an allocation plan.
Nobody at any of your clients chose 192.168.1.0/24 on purpose. It shipped that way. Consumer and small-business routers come from a small handful of vendors, and those vendors ship a small handful of default LAN ranges: 192.168.1.0/24, 192.168.0.0/24, occasionally 192.168.100.0/24 or 10.0.0.0/24 on newer ISP gateways. Whoever racked the router at Client A never coordinated with whoever racked the router at Client B, because there was no reason to — each network was designed in isolation, with no expectation it would ever need to talk to another network.
You are the one who aggregates them. You’re the party that puts thirty independently-designed networks under one operational umbrella, and the collision is a direct consequence of that aggregation — not a client mistake, and not something you can fix by asking clients to “just use a different range.” It’s an inevitable outcome of connecting things that were never designed to coexist, and the fix has to live on your side of the relationship, because you’re the only party with visibility into the whole set.
This is also why the problem stays invisible until it isn’t. A network on 192.168.1.0/24 works perfectly for its own client, forever, right up until you need simultaneous reachability between it and a second client on the same range — a joint project, a shared vendor integration, or a technician needing two tunnels open at once. The design assumption was “this will never need to route to a network with the same range,” and that assumption was wrong from day one for every client on your books.
Diagram 1. When every client’s router ships with the same default range, the collision is structural, not accidental.
Overlapping ranges don’t fail in one consistent way. They fail differently depending on which two networks you’re trying to bridge, and that inconsistency is exactly why the root cause gets missed — each symptom looks like a different, unrelated problem.
All four of these get misdiagnosed. A shadowed VPN route looks like a firewall rule. A silently-dropped VPC peering connection looks like a misconfigured route table. A tech who can’t reach their own printer while connected to a client VPN looks like a driver issue. None of it looks like what it is, which is two networks with identical address space trying to occupy the same routing table.
It’s worth contrasting this against a failure mode that looks similar but isn’t: large file transfers or attachments stalling over a VPN while everything else works fine. That’s almost always an MTU/MSS mismatch — packets above a certain size getting dropped somewhere in the tunnel stack — and it breaks selectively by packet size, not by destination. If your VPN comes up clean and small requests work but big transfers hang or stall, that’s a different problem with a different fix; see our MTU/MSS overhead calculator for that case rather than chasing an overlap that isn’t there.
Once you’ve confirmed two networks actually overlap, you have three options. They are not equivalent, and presenting them to a client as interchangeable is how you end up defending an interim NAT hack five years after it should have been retired.
a. Renumber the client network. This is the correct, permanent fix. It’s also the disruptive one: it requires a maintenance window, and it touches DHCP reservations, static assignments on servers and printers, firewall rules referencing the old range, site-to-site VPN configs, and anything with the old subnet hardcoded — including that one line-of-business app nobody remembers configuring. Renumber when the client is small enough that the change is contained, when they’re heading toward more cloud or partner connectivity (where overlaps will keep recurring until this is fixed), or when you’re already doing infrastructure work at that site and can fold the readdressing into it.
b. NAT the overlap at the tunnel edge. A 1:1 or twice-NAT translation at the VPN endpoint lets both ranges keep their addresses locally while presenting a translated, non-overlapping range to the tunnel. It’s fast and causes zero disruption to the client’s existing configuration. The cost is a permanent translation layer that makes every future troubleshooting session harder — packet captures show translated addresses that don’t match what’s configured on either end — and it breaks any protocol that embeds IP addresses in its payload rather than just the packet header (some legacy VoIP signaling and a handful of industrial protocols are the usual culprits). Use NAT when a maintenance window genuinely isn’t available, when the connectivity need is narrow and well-defined (one specific integration, not general reachability), or as a bridge while you schedule the real renumber.
c. Live with it and never connect the two. This is legitimate, not a cop-out, for clients who will never need direct reachability to each other or to your other client networks. Plenty of small-business clients fit this description permanently. The risk is that “never” is a prediction, not a guarantee — the client heading toward a cloud migration, a merger, or a new SaaS integration that needs a site-to-site tunnel is on a ticking clock, and the moment they announce that project is the worst possible time to discover the overlap.
Diagram 3. Three questions get you to the right fix — most overlaps don’t need the disruptive option.
Fixing today’s overlap is a one-time project. Stopping the next one from ever existing is a system, and it’s the part of this that actually earns its keep.
Carve every client network out of 10.0.0.0/8, using the second octet as the client identifier: 10.<client-id>.0.0/16 per client. That’s far more space than any 5–50-seat client will use, but the point is collision-proofing, not utilization — distinct second octets mean no two client networks can ever overlap, no matter how each one is subnetted internally. Reserve a block for your own management infrastructure (RMM, VPN concentrator, monitoring) well outside the client-numbered range, so it never needs renumbering as you grow. Keep 172.16.0.0/12 in reserve, untouched, for the cases 10.x.x.x can’t cleanly absorb — a client already running 10.x.x.x internally (common with anyone who’s touched AWS), or two existing clients merging after an acquisition.
| Allocation | Range | Notes |
|---|---|---|
| MSP management | 10.255.0.0/16 | RMM, jump boxes, monitoring, VPN concentrator |
| Client A | 10.10.0.0/16 | Standard onboarding allocation |
| Client B | 10.20.0.0/16 | Standard onboarding allocation |
| Client C | 10.30.0.0/16 | Standard onboarding allocation |
| Client D | 10.40.0.0/16 | Standard onboarding allocation |
| Client E | 10.50.0.0/16 | Already ran a 10.50.0.0/16 AWS VPC — matched instead of reassigned, to avoid creating a second overlap |
Five clients, five non-overlapping /16s, zero coordination required between them because the second-octet rule guarantees no two allocations can ever collide. Use a subnet calculator when you’re carving smaller subnets out of a client’s /16 internally — VLANs, a guest network, a separate range for IoT devices — so the pieces stay inside that client’s block and don’t drift into another client’s space.
The part that actually prevents the next collision: a new client gets their allocation assigned at onboarding, before any router, switch, or firewall gets touched. Not after the network’s already built with whatever the hardware shipped with — before. Onboarding checklist item one is “assign the client’s /16,” and every piece of equipment that goes in gets configured against that allocation from the first device.
Diagram 2. The same three clients, planned instead of defaulted: distinct second octets mean the ranges can never collide.
Most MSPs don’t get to build this system from scratch — you inherit an estate that’s grown for years without one, and you need a way to find out how bad it is before you can fix it.
Start with inventory, not remediation. You can’t identify collisions in ranges you haven’t recorded, and half the value of this exercise is the documentation itself — the same IP Spreadsheet Audit tool that flags overlaps will also flag near-exhausted pools and malformed entries while you’re pulling every client’s ranges into one sheet, so do the inventory pass properly rather than just eyeballing router configs one client at a time.
Once you have every client’s ranges in one place, identify the actual collisions. Paste the full set into the Subnet Overlap Checker and let it flag every pair that overlaps — checking pairs by hand across thirty-plus client networks is exactly the kind of exhaustive comparison a human misses under time pressure, and the tool checks every combination in one pass.
Then prioritize by what actually needs to change. Not every collision on the list needs remediation today — some of those client pairs will never need to talk to each other, and pushing every one of them through a renumber is wasted disruption. Sort the collision list by which client pairs have a real or likely reason to connect: shared vendors, planned cloud migrations, technicians who regularly need tunnels into both. Those go to the top of the renumber queue. Everything else goes on the “live with it, but it’s documented now” list — which, notably, is a very different position than “live with it and hope nobody ever asks.”
Can two clients use the same IP range if they’ll never connect to each other?
Yes. An overlap only matters if something needs to route between the two networks — directly, through a VPN, or through a shared third network like your management VLAN. Two clients on identical ranges with no path between them and no shared infrastructure touching both are not at risk. The catch is confidently knowing “never” — document the overlap so future-you (or whoever inherits the account) doesn’t have to rediscover it during an incident.
Does NAT fully solve an overlapping subnet VPN fix, or is it just a workaround?
NAT solves the immediate reachability problem, not the underlying overlap — the two networks still have identical address space, you’re just translating around it at the tunnel edge. It’s a legitimate long-term choice when a client will never be renumbered, but it’s not “fixed” in the sense that documentation, troubleshooting, and any protocol embedding IP addresses in its payload still have to work around the translation forever.
What IP range should we standardize on for new clients?
10.0.0.0/8, allocated per client by second octet (10.<client-id>.0.0/16), with a dedicated block reserved for your own management infrastructure. It gives you 254 possible client allocations before you’d need a second scheme, more address space per client than any 5–50-seat network will use, and — critically — no coordination required between clients because distinct second octets can’t collide by construction.
How do we renumber a client network without an outage?
Run both ranges in parallel during a maintenance window: bring up the new subnet alongside the old one, migrate DHCP scope and static reservations first, cut over device by device or by VLAN rather than all at once, and hold the old range live but unrouted for a rollback window before decommissioning it. The work that actually takes the time isn’t the router config — it’s finding every place the old range is hardcoded: firewall rules, VPN configs, monitoring tooling, and that one line-of-business app.
Does this affect cloud VPN differently than site-to-site between two offices?
The mechanism is identical — two ranges with common address space can’t both be routed — but cloud providers tend to fail loudly where two offices might fail silently. AWS, Azure, and GCP generally reject a VPC peering connection or site-to-site VPN outright if the CIDRs overlap, which at least surfaces the problem immediately instead of leaving you with a tunnel that comes up but silently drops half its traffic.
The underlying fix for all of this is the same regardless of which client pair you’re looking at: run the estate through the Subnet Overlap Checker before the next VPN request forces you to find out the hard way.