IP Planning for MSPs: Managing Fifty Clients Who All Use 192.168.1.0/24

A technician at an MSP (a managed service provider, the kind of company that runs IT for dozens of businesses at once) opens a remote session to restart a client's firewall at 192.168.1.1. The restart works, and the wrong client's office drops offline. The firewall was real, the address was right, and the building was wrong, because at an MSP the address 192.168.1.1 is right for almost every client. Every business that plugged in an office router and kept the factory settings ended up with the same IP (Internet Protocol) addresses as every other business that did the same, and most of them did. This post is about the problem that creates for anyone managing many small networks at once: why fifty client networks come out identical, why the obvious fixes stop working around client number three, the two mechanisms that make identical networks livable, and how to keep records that treat the duplication as a fact rather than a mistake.

The sameness is engineered, and nobody involved did anything wrong. The internet's addressing rules set aside a few ranges for private use inside buildings, free for anyone to reuse, a standard called RFC 1918 (from the Request for Comments series, where internet standards live) that we tour in our guide to the 10 reserved IP ranges every network engineer should know. Router manufacturers had to ship a default from somewhere in that space, and they overwhelmingly picked 192.168.1.0/24. The slash notation is explained from scratch in our visual guide to CIDR (Classless Inter-Domain Routing), but for this post it is enough to know that 192.168.1.0/24 means the block of addresses from 192.168.1.1 through 192.168.1.254. For a single office it is a perfectly sensible choice, and that is the whole trouble. Every office made the same sensible choice, so a provider who signs fifty small-business clients inherits fifty copies of the same network, each with a server at .10, a printer at .50, and a firewall at .1.

The instinctive fix is to renumber, and for an MSP it is a trap. When two companies merge and discover they share address space, they eventually converge on one plan, a slow project our survival guide to merging networks after an acquisition walks through in full. An MSP has the same overlap with none of the authority. The networks belong to the clients, renumbering one means touching every printer, camera, scanner, and hand-configured device in someone else's building, and no client wants to pay for a disruptive project whose benefit accrues to their IT provider's bookkeeping. Multiply that refusal by fifty, then notice that the next client signed will arrive with factory defaults anyway. Renumbering fixes one overlap at a time, and a business built on overlaps needs an answer that scales past one.

The pain concentrates wherever the MSP's own systems have to reach into client networks. Support and monitoring usually run through VPNs (Virtual Private Networks, encrypted tunnels that make a distant network reachable as if you were plugged into it), one tunnel from the provider's operations center into each client site. A routing table can hold only one answer for where 192.168.1.0/24 lives, so the moment two client tunnels are up, one client's network silently wins and the other's becomes unreachable, the same quiet failure our guide to VPN and overlay network addressing dissects for home users, multiplied across every pair of clients. Monitoring is no better: a dashboard with fifty devices named 192.168.1.10 is a dashboard that tells you something is down without telling you where. And remote sessions land exactly where our opening technician's did, on the right address in the wrong building, which is how honest, careful people end up rebooting another company's firewall.

The traditional workaround is NAT (Network Address Translation, the technique of rewriting addresses as traffic passes a boundary, sorted out variant by variant in our plain-language tour of NAT). At each client tunnel, the MSP translates the client's real range into a unique alias range that only the MSP's systems ever see. A common scheme folds the client number into the address, so client 7's 192.168.1.0/24 appears to the operations center as 10.107.1.0/24, client 8's as 10.108.1.0/24, and every alias is distinct even though every real network is identical. This genuinely works, and plenty of providers run on it for years. The price is permanent bookkeeping. Every alarm, every log line, and every remote session now involves a mental translation step, performed from memory during an outage at 2 a.m., and the mapping table that makes the whole scheme legible becomes the most load-bearing document in the company, usually maintained in the least reliable place.

The cleaner mechanism lives inside the routers themselves, and it is called a VRF (Virtual Routing and Forwarding instance). A router ordinarily keeps one address book, its routing table, which is exactly why two identical ranges cannot coexist. A VRF lets one router keep several address books, sealed off from one another, so the provider's aggregation router can hold a separate routing table per client, each containing that client's 192.168.1.0/24, with no translation and no possibility of traffic leaking from one client to another. Our guide to VLANs vs VRFs explains the mechanics from the ground up, including how this differs from the VLAN segmentation most people meet first, and it is no accident that its prime example of who needs VRFs is a service provider hosting multiple clients. This is the same technique cloud providers use so that every customer can build on 10.0.0.0/16 without ever colliding with the millions of other customers who chose the same range.

One aggregation router, three clients, one very popular subnet

VRF "client-acme"
  192.168.1.0/24   Office LAN      → tunnel to Acme

VRF "client-bluesky"
  192.168.1.0/24   Office LAN      → tunnel to BlueSky   ← same range, different client

VRF "client-cornerstone"
  192.168.1.0/24   Office LAN      → tunnel to Cornerstone

Three identical ranges, three sealed routing tables.
192.168.1.10 means a different machine in each one.

In practice the two mechanisms cooperate rather than compete. VRFs keep client traffic separated end to end, and a small amount of NAT appears only at the one point where client networks must reach shared MSP infrastructure, like a central monitoring server that fifty VRFs all report into. The comparison worth keeping in your head is between the three strategies as ways of life, because an MSP will be living with the choice for as long as it has clients.

That last catch deserves the emphasis, because the routers are usually the easy half. Documentation built as one flat list collapses the moment the same range legitimately appears fifty times. A spreadsheet has no column for "which routing table," so fifty rows reading 192.168.1.10 look like forty-nine errors, and cleanup-minded colleagues will helpfully delete them, one of the many failure modes catalogued in our post on what spreadsheet IP management actually costs. Real IPAM (IP Address Management, keeping an authoritative record of which addresses are assigned to what) for a provider has to treat the client context as part of the address's identity. The question a record must answer is "what is at 192.168.1.10 in Acme's network," and a tool that can only store the shorter, client-free version of that question will quietly corrupt every answer it gives.

The per-client model also changes what onboarding looks like. Every new client is, from the MSP's side of the table, an inherited network nobody documented, and our guide to building an IP inventory from scratch is effectively an onboarding runbook: walk the routing tables, the DHCP (Dynamic Host Configuration Protocol, the service that hands devices their addresses automatically) leases, and the DNS records before trusting anything a departing IT person wrote down. The difference at a provider is that the resulting inventory lands in its own compartment, the new client's VRF, rather than being merged into a shared list where its 192.168.1.0/24 would collide with everyone else's. Do that fifty times and you have fifty small, clean address plans instead of one large impossible one.

This per-client model is what IPCraft is built around. VRFs are first-class objects, so you create one per client and the uniqueness rule follows real networks: the same subnet can exist in every VRF but never twice within one. The subnet tree filters by VRF, which turns "show me Acme" into one click instead of a squint at fifty identical rows, and CSV import brings a freshly onboarded client's inventory in as a batch. The REST API (Application Programming Interface, the doorway other software uses) takes a VRF on every query, so your monitoring and ticketing systems can ask for "192.168.1.10 in the Cornerstone VRF" without ambiguity, and webhooks push changes back out to them. An activity log records who changed which client's records and when, which matters when the network you mislabel belongs to a paying customer. The Teams plan covers a working MSP help desk, ten technician seats, ten thousand tracked addresses, fifty webhooks, and ninety days of activity history, and the Enterprise plan takes the same model up to the scale where clients stop fitting in a spreadsheet tab even one at a time.

The rule that survives all of this is short. An MSP's overlap is permanent, so treat it as a dimension of every record instead of a flaw to be engineered away: one client, one VRF, one compartment in the documentation, everywhere from the aggregation router to the address plan. Fifty clients on 192.168.1.0/24 is a perfectly manageable state of affairs once every system that touches an address also knows whose address it is. Get that in place and the 2 a.m. restart lands on the right firewall in the right building, which is the entire job, done well, at the moment it counts.