Centralize Partner VPN Access Without Joining the Partners

The pitch is reasonable: five partner tunnels spread across a dozen laptops, five sets of client versions, five help-desk scripts, and one engineer who knows how they fit together. Moving them to a controlled access tier fixes the endpoint sprawl. It also creates a new object in your architecture, a shared access service that now needs its own authorization model, and the failure everyone underestimates is a central appliance with every tunnel enabled quietly becoming a transit network between organizations that never agreed to be neighbors. That risk is a design choice, not something the hardware does on its own. The work below is how I keep the convenience without accepting the accidental side effect.

Start from the contract each partner already signed

Before any configuration, confirm that the partner permits a shared gateway or site connection at all. A personal remote-access account, a device-posture requirement, or an interactive MFA flow may not be transferable to an unattended shared tunnel, and pooling employees behind one copied client identity is the kind of shortcut that survives until the partner audits their logs. For each permitted connection, record destination ranges, private DNS domains, authorized internal sources, the authentication owner, and what should happen when the tunnel fails. Ask the partner to confirm the shared connection in writing, including the source ranges they will accept. Verbal approval tends to change meaning the week their security team rotates.

That record is the deliverable. If you cannot write it for one partner, that partner is not ready to be centralized.

Route by context, not by destination alone

Two partners will eventually use the same private range, because every organization picks from the same RFC 1918 space. A single ordinary routing table cannot choose the correct partner from a destination address alone, so overlapping ranges need separate routing contexts or another agreed design. The forwarding-domain model in RFC 4364 describes why the separation matters, and a deployment does not need to run MPLS to need the same property from its gateway platform.

Ask the platform a blunt question: can two partners share a destination prefix and still be distinguished by which employee context the session came from? If the answer is no, that constraint shapes the design more than any vendor feature list.

Where the answer is yes, the routing context becomes the thing you document and test, because it is invisible in a traceroute.

Decide what the employee types and what the partner logs

Some partner work fits an application proxy or a remote workspace opened inside that partner's context. Other work needs routed network access from an approved employee segment, and the two produce different source addresses and different audit trails at the far end. A shared translated source address can satisfy an allowlist while hiding which device did what, so preserve a reliable employee-to-session record and keep application authentication in place rather than treating a gateway address as an identity, which is convenient right up until the partner asks who did it.

Then walk one real task from the employee's side: what they click, what they are prompted for, and what the partner would see if they asked for a log entry. If that walkthrough is not reproducible, the design is not finished.

Deny partner-to-partner transit explicitly

Shared hardware should never imply shared trust. Add the denial as a deliberate rule with a named owner, not as an accident of missing configuration, and test it from both directions with a request that would otherwise succeed. The test matters because a permit that is merely absent can be restored by the next engineer who adds a route to fix an unrelated complaint.

Write the denial into the partner record beside the permits, so the intent survives staff changes.

Run it as a shared service, not as a bigger laptop

Tunnel renewal, credential rotation, capacity, and gateway replacement all become shared-service changes now, which means they need a schedule and a communication path that individual laptops never required. A partner certificate expiring on a Saturday is no longer one user's outage; it is every session for that partner at once.

Accept the tier only when a denied cross-partner request fails exactly as intended and an allowed employee request reaches the right destination with the right source. Removing laptop conflict while keeping each partner's boundary intact is the whole point; a design where every remote prefix is reachable from every desk has simply moved the problem.

Keep a small table of partner, context, permitted ranges, and owner. It will be the first thing anyone asks for during an incident.