Azure cross-tenant Cloud NGFW hub

The constraint

A large healthcare enterprise, several Azure tenants, and no realistic path to consolidating them. Tenants existed for reasons that outlast any network design: acquisitions that were never merged, regulatory scope that is cleaner kept separate, and workloads whose data classification made a shared tenant a non-starter.

The design question was therefore not how to collapse the tenants. It was how to inspect traffic across them without doing so.

A hub, not a mesh

Cross-tenant connectivity as a mesh scales as the square of the tenant count, and every new tenant is a change to every existing one. The design is instead hub-and-spoke, with the hub in its own isolated subscription: onboarding becomes a single attachment, and inspection policy stays in one place.

The transit VNet is addressed out of RFC 6598 carrier-grade NAT space — 100.64.0.0/22 — rather than RFC 1918. Shared transit is precisely where RFC 1918 overlap surfaces, and 100.64/10 is the one range an enterprise can reasonably assume its acquisitions and partners have not already consumed. Inspection is Cloud NGFW in its SaaS form, so the hub carries no firewall instances to patch.

Attachment and authorization

Internal workloads attach over standard VNet peering. Third-party tenants attach over cross-tenant subnet peering, where each side creates only its own half of the peering. Neither organization can complete the link unilaterally, so the attachment itself is a record of mutual consent rather than a configuration one party could have made alone.

There are no default routes pointed at the NGFW. Reachability is granted through per-engagement route lists, which makes routing the authorization mechanism: a destination an engagement has no route to is unreachable regardless of what firewall policy would have permitted. Two independent things have to be true before traffic moves, and one of them is not editable from the security policy.

Traffic is inspected without NAT at the firewall. Addresses in the logs are therefore the real ones on both sides, and a finding traces back to a host without a translation table in the middle of the investigation.

Boundaries that survive an org chart

The usual failure mode of a cross-tenant design is that it encodes the organizational structure that existed when it was drawn. A model keyed to reporting lines needs rework at every reorganization, and each rework is an opportunity to get a boundary wrong.

Here the boundaries are the attachment and the route list, and both are keyed to facts that change more slowly than org charts do. An attachment exists because two parties each created their half of a peering, which is a fact about an acquisition or a partnership, not about who reports to whom. A route list exists because an engagement needs a specific set of destinations, which is a fact about the work, not about the team doing it. Reorganizations move people between teams. They do not create peerings and they do not add routes, so they cannot widen what any tenant can reach. The hub outlives the org chart because nothing in it was drawn from one.

In the management plane this hub is one consumer of a single IT_ child in the Strata Cloud Manager tenancy model described in Multi-tenant Strata Cloud Manager. The hub's policy lives there; the tree decides who may edit it.