One remote-access VPN lands into two merged estates using overlapping RFC1918 space - how do you scope reach?

## Why the merger breaks the pool Both companies built inside 10.0.0.0/8 and both used the obvious subnets. After the merger a single address is ambiguous: `10.20.4.15` exists on both sides and means two different machines. Meanwhile one remote-access service has been pointed at both estates, because that was the fastest way to let the acquired company's staff work, and it hands every session an address out of one shared pool. That produces three problems at once, and a good answer separates them: 1. **Routing ambiguity.** One routing table cannot hold two meanings for the same prefix, so whichever side's route wins silently steals traffic destined for the other. 2. **Policy ambiguity.** A filter rule written against a destination prefix cannot say which estate it means, so the rule base is unreviewable from the day it is written. 3. **Trust inheritance.** The shared pool routes into your core, and the accounts entitled to it now include a directory you have never assessed - its password policy, its joiner-mover-leaver process and its administrator population are all unknown to you. ## The design **Separate populations into separate pools.** The pool is the handle. Give the acquired company's staff their own pool, contractors another, and privileged administration another again. A pool is cheap; it is the only durable way to express "this class of remote user" as something a filter can match on. **Keep the duplicate space in separate routing tables.** Each pool is carried in a routing context that reaches exactly one estate. The overlap then stops being a correctness problem, because no table ever holds both meanings of a prefix. **Filter immediately behind each pool.** This is the vantage that matters. One hop further in, the remote traffic has merged with everything else on the wire and is no longer distinguishable; at the pool boundary you can still write policy about the remote population as a population. Default-deny there, with an enumerated allow list, is the only position that produces a falling destination count. **Translate only the enumerated crossings.** Some flows genuinely must cross - a payroll consolidation, a shared identity service during migration. Translate those specific flows and nothing else. A general-purpose translation between the two estates is a merged network with extra steps, and it re-creates every problem you just separated. ## Sequencing, because you cannot do it in one night Stand the new pools up in parallel and move populations onto them one at a time, starting with the population whose needs are smallest and best known - usually third-party or contractor accounts. New pools start default-deny; the legacy shared pool stays permissive and shrinks as it empties. That ordering means every failure is scoped to the group you just moved, and you always have a working path to fall back to. ## What it costs, and who feels it The technical cost is straightforward and the human cost is not. Anything that resolves a name to an address which now means two things breaks: monitoring pollers, backup jobs reaching agents, admin jump paths, hard-coded addresses inside applications that nobody has read in a decade. Discovering which flows the moved population legitimately needs is the burden nobody can staff - the application owners can describe their own front door but not the calls their application makes, and half the callers are on the other side of the merger. A wrong deny is not a ticket in a queue; it is a business process stopped, with a named owner asking why. So you buy the information the only way it is affordable: move a small population, watch what the new default-deny pool rejects during a defined window, and turn those rejections into the allow list before the next tranche. That is a schedule and an outage-window negotiation, not a configuration task, and answering the question as if it were only a configuration task is the failure mode. ## The sentence to have ready Asked to justify the work, the compact statement is that today one accepted login in the estate you have not assessed obtains an address routed into the estate you are responsible for, and no control between the two examines it. Separate pools, separate routing tables and a filter at the pool boundary are what convert that into a scoped, countable reach.