Two Clients, Same IP Range, Zero Cross-Contamination
Here's a fact that surprises people outside the MSP world and barely registers for anyone
inside it: it's completely normal for two entirely unrelated clients to be running their
networks on the exact same private IP range. Two different businesses, two different offices,
two different sets of devices — both quietly numbered 192.168.1.0/24, because that's the
default nearly every consumer router ships with and almost nobody changes it. For an MSP
managing both, this isn't a strange edge case to plan for eventually. It's Tuesday.
Why this breaks tools that weren't built for it
A lot of monitoring and management software was never designed with this in mind, because it
was built for one team watching one network, where "the device at 192.168.1.50" is an
unambiguous sentence. Retrofit that kind of tool for multi-client use, and the seams show up in
exactly the places you'd least want them to: a device lookup that matches on IP address alone
and quietly returns the wrong client's data, a dashboard view that filters by the wrong
criteria under load, a support action meant for one client's router landing on another's by
mistake. None of these require malice or a breach. They require exactly the ordinary
coincidence of two clients sharing a common default IP range — which, again, is not rare.
The consequence isn't hypothetical, either. A device renamed at the wrong client's location.
A device incorrectly marked "trusted" that clears a rogue flag somewhere it shouldn't. These
are the kinds of mistakes that don't show up in a demo, don't show up in a sales conversation
about features, and show up exactly once, at the worst possible moment, in front of exactly
the client who now has a very reasonable question about how many other clients' data has ever
touched theirs.
Isolation has to be the foundation, not a setting
The fix isn't a checkbox that says "enable strict client isolation." If isolation is something
that can be turned on or off, it's something that can be forgotten, misconfigured, or quietly
disabled by an integration nobody thought through carefully. It has to be structural — true by
default, for every device, every alert, every ticket, every single time, with no code path that
skips it because nobody remembered to add the check there too.
That's the standard NetMon is built to. Every device, every alert, and every support ticket
belongs to a specific organisation and site, and that scoping isn't an afterthought bolted onto
queries after the fact — it's the assumption baked into how data is stored and retrieved in the
first place. Two clients on identical IP ranges don't share so much as a flicker of visibility
into each other's dashboards, because the system was never asking "what's the IP" as its only
question. It was always asking "whose IP, on which site" — and that second half of the
question doesn't get lost, ever, by design rather than by discipline.
Remote access is where this matters most
Isolation on a dashboard is important. Isolation on remote access is critical, because remote
access is the one feature that, done wrong, doesn't just show the wrong data — it hands over
actual control of a device. A shared credential sitting behind every technician's login, usable
across every client, is a single point of failure that turns one compromised login into
exposure for an entire client base at once.
NetMon provisions remote access per organisation, not from a shared pool. Each client's remote
access is its own scoped, verified credential — not shared, not reused, not one login that
happens to work everywhere because it was convenient to set up that way. A technician logging
in to help one client cannot accidentally end up with visibility into another's devices, because
there's no shared door for that mistake to walk through in the first place.
What this actually buys an MSP
For a client evaluating an MSP, the honest question underneath "is our data secure with you"
is usually really "could your other clients ever see or touch our stuff, even by accident" —
and most MSPs answer that with a confident assurance rather than an architectural fact, because
most of the tools underneath them were never actually built to make the confident answer true.
Being able to say, specifically, that isolation isn't a policy you follow but a structural fact
about how the platform is built — that two clients can sit on identical IP ranges and never
once cross paths in a dashboard, an alert, a ticket, or a remote session — is a genuinely
different, genuinely stronger claim. It's not "we're careful." It's "there's no path for that
mistake to happen," which is the only version of that answer that actually holds up under a
harder question.
The unglamorous truth about good architecture
None of this is a feature a client will ever consciously notice, because the entire point is
that it works invisibly, every time, for as long as the platform is in use. Nobody gets a
notification that says "isolation held today." That's exactly what makes it worth talking
about explicitly rather than assuming it's obvious — the things that are supposed to be
invisible are also the easiest things for a prospective client to underestimate, right up
until the one moment it would have mattered and, because it was built in from the start,
never actually does.
A question worth asking any tool, not just this one
If you're evaluating monitoring or management software for a multi-client business, this is
one of the few questions worth asking directly rather than taking on faith: what actually
happens when two clients share an IP range — is it handled, or has it just never come up yet?
A vendor who's thought about it will have a specific, concrete answer. A vendor who hasn't
will usually reach for reassurance instead of specifics, because the honest answer is that
nobody's tested it.
That's not a gotcha question designed to catch anyone out. It's a genuinely practical one,
because "hasn't come up yet" and "won't happen" are very different claims, and only one of
them holds up once your client roster grows past the handful of networks where every address
happened to be unique by coincidence. The tools that were built for this from the start have
an answer ready. The ones that weren't usually find out the same week a client does.
Born in Colwyn Bay North Wales, Steve's introduction IT & Computers was at secondary school in 1974. That first year, Machine Code was hand written onto gridded paper and sent to Connah's Quay Technical College where is was copied to punch card and then entered into a mainframe computer. The results printed out were sent back for the following week! Yes Steve was around before the Internet and was coding the hard way.
Steve left School in 1976, or as he prefers to say, “I ran away from home and joined a flying circus” - joining the Royal Air Force to work as an Electronics Engineer on analogue and digital RADAR and communications equipment. His last 5 years in the RAF he worked in an Automatic Test Equipment (ATE) department on the System Management Team and also writing models for Microchips. It was a good job that he had kept up with computers which had become rather a passion by the time he started in ATE. After 8 specialist programming courses for ATE Programming and a Cluster Start Course for System Administration, Steve was one of the most flexible people in the department.
During that time the main Mainframe we replaced in a £3.9 million upgrade reducing the run time of the biggest ATE program from just under 2 weeks to the time it took for a finger to come off a depressed return key!
Leaving the RAF after 18 years’ service, Steve worked for a Charity (Apex Leicester Project) before returning to electronics at Sonatest in Milton Keynes which after 3 or 4 years led to a Job at Telematica; the then development arm of Trafficmaster PLC (Tm). Eventually brought in-house at Tm he worked moved into the IT Support Team of 5 people looking after 300 users in the UK as well as sites in Italy, Germany and Benelux countries – 24x7 cover. His last project moving email from a Linux Box to Microsoft Exchange for the 300 users in the company each of whom typically had 5 email addresses.
In 2006 Steve left to start his own company back in North Wales, Computer Technical Solutions Ltd (CTS) was an MSP and became an MSSP following another of Steve's passions Cybersecurity. Whist working full time running CTS, Steve completed a Masters Degree in Computer Science with Cybersecurity at Wrexham University.
Officially semi-retiring in 2025, by May 2026 that overactive mind started thinking about all of the software he had seen not just for MSSPs but also for his clients that was either extremely expensive or that didn't exist with a complete answer to the needs of the SME.
By August 2026 Angstep Ltd was formed and two significant pieces of software had been created. Netmon the Network Monitoring Software and the second release Parkcore aimed at Caravan/Lodge Holiday Parks, now in the final development stages and under Beta Release. Determined, focused and loving life… And so, it begins!
