Multi-Tenant VPN: Shared Gateway, Per-Tenant or Per-Host
A tunnel is not tenant isolation. Compare a shared gateway, per-tenant gateways and per-host connections on identity mapping, routing and retirement.
Decide who admits a customer and what stops that customer reaching another tenant's resources. Those are two decisions, and picking IPsec, WireGuard or a mesh product answers neither. A tunnel that comes up perfectly can still leave every tenant able to reach every other one, and a review that treats the two as the same thing approves the wrong design. Write the customer-to-resource map first: administrators, support access, shared services, and the paths that have to stay denied.
Start with the map, not the product
That map is the first artefact, and every choice below is only a decision about where the boundary enforcing it lives. Keep it reviewable: one row per customer, one row per shared service, and the denied paths written out.
A map nobody can read is a map nobody will enforce.
One admission point and its mapping problem
Each placement is decided by a single operational question, and the table is the whole comparison.
| Placement | The question it lives or dies on |
|---|---|
| One shared gateway | How does an admitted identity end up limited to its own resources and its own routing context? |
| A gateway per tenant | Who owns each gateway, its credentials, its policy, its updates and its eventual retirement? |
| A connection per hosted machine | How do enrollment, per-machine policy and replacement work at fleet scale? |
A shared gateway centralises admission and concentrates the risk in one place: the association between a tenant identity and its policy. Groups or tunnel addresses have to resolve to the right resource permissions, and a different label per customer prevents nothing on its own. Separate routing contexts can hold overlapping prefixes when the platform supports it and the design is complete. A plain shared routing table cannot tell two identical destination prefixes apart just because the people behind them have different accounts.
That is the test for most designs. Two tenants both numbering internally with 10.0.0.0/8 need separated routing state, not a naming convention.
A gateway per tenant buys boundaries and systems
One gateway per customer makes some administrative boundaries easy to explain, because admission and policy for that customer sit together. It also multiplies the systems that need credentials, patches, monitoring and an owner. And it does not force one prescribed public-address arrangement: endpoint sharing, translation and protocol demultiplexing depend on what the implementation actually supports.
Count the systems and the people before you count the security gain. A design with four more gateways than the team can patch is not more isolated in practice.
If the tenant count moves every month, that model needs an automation story rather than a template.
Per-host connections move the work
A connection on each hosted machine does not remove the operational work, it relocates it into the machine lifecycle. Enrollment, per-machine policy, key rotation and replacement all become part of provisioning, and they fail inside the same window as the machine itself. For a handful of long-lived hosts on distinct networks that is often right, and for a fleet that already loses track of which image runs where it rarely is.
Name a role for identity issuance, updates, access removal, monitoring and recovery under each option. Then ask what happens on the day one customer leaves.
Retirement belongs in the comparison
Most comparisons skip retirement. Removing a tenant should invalidate its credentials, drop its policy, release its addresses and routing state, and leave everybody else untouched. NIST's zero-trust architecture guidance is the right reference here, because it puts authentication and authorisation on the resource instead of trusting a network position, and that applies inside a customer's own segment too.
Weigh allowed and denied flows, overlapping-address handling and the retirement procedure before you weigh protocol benchmarks. Then pick a transport and authentication method that fit the boundary you chose. An older product name, or a claim that every business must standardise on one protocol, settles none of it. The map you wrote first does.