VLAN Design Patterns for Multi-Tenant Office Buildings

A shared office with 3-15 tenants is a network design problem most IT consultants quietly hate. The tenants do not trust each other. The building manager does not understand networks. The internet drop is a single uplink that has to serve everyone fairly. The default configuration is "one flat network for everyone" — which works exactly until the first tenant gets compromised and the rest discover their printers are now part of a botnet.

This article is the VLAN design pattern we use for shared-office deployments. Aimed at the network engineer who has been asked to "set up wifi for the new co-working floor" and wants to do it once, correctly, with a topology that survives tenant churn over 3-5 years.

The threat model nobody writes down

The actual threats in a multi-tenant office, in order of likelihood:

1. Tenant-on-tenant lateral movement. Tenant A's compromised laptop discovers tenant B's network printer, then tenant B's NAS, then tenant B's RDP server.
2. Guest abuse. A guest device floods the upstream, breaks ABR, hits the captive-portal logic with edge-case payloads.
3. IoT device misbehaviour. Shared building IoT (door access, HVAC, cameras, badge readers) running on the same network as productivity traffic.
4. DHCP/DNS spoofing by tenant equipment. A tenant's rogue server hands out DHCP leases or DNS responses that affect other tenants.
5. Bandwidth hogging. One tenant's 4K Teams meetings starve another tenant's normal traffic.
6. Building manager wants to "see everyone's traffic" for billing. This is a feature request, not a threat, but architectural decisions have to anticipate it.

The reference topology

The canonical design has four layers:

1. Edge: the building's internet uplink (or pair, for redundancy) terminating on a firewall that owns the WAN address space.
2. Core switch: a single layer-3 capable switch (or stack) that handles inter-VLAN routing where allowed and isolation where required.
3. Access switches: per-floor or per-tenant edge switches, trunked back to the core.
4. Wireless: a cloud-managed AP fleet broadcasting per-tenant SSIDs mapped to VLANs.

VLAN allocation scheme

The numbering convention that scales:

VLAN range	Purpose	Trust level
VLAN 10	Management (switches, APs, firewall management interfaces)	Highest — IT only
VLAN 20	Building services (door access, IoT, badge readers)	High — locked
VLAN 100-199	Tenant A (split into sub-VLANs: corp, voice, IoT, guest)	Tenant-controlled within boundary
VLAN 200-299	Tenant B (same pattern)	Tenant-controlled within boundary
VLAN 300-399	Tenant C	...
VLAN 900	Shared guest WiFi for visitors of any tenant	Lowest — isolated
VLAN 999	Quarantine (used for un-authenticated or non-compliant devices)	Sandboxed

The 100-block-per-tenant pattern gives each tenant room for ~7-8 sub-VLANs (corp data, corp voice, corp IoT, guest WiFi for their visitors, dev/test, etc.) without exhausting the 4094 VLAN ID space. For a 15-tenant building, this still leaves 25+ tenants of headroom.

Trunk topologies — the choice that drives everything

Three trunk patterns, ranked by complexity:

Pattern A: Single trunk per access switch

Each access switch carries every VLAN as a single 802.1Q trunk back to the core. Simplest to configure; works for small deployments (under 5 tenants); requires no per-tenant patch panel planning.

The trade-off: a misconfiguration on the access switch can leak traffic between tenants. Mitigation: lock the trunk's allowed-VLAN list to only the VLANs that should be on that switch, plus port-level VLAN binding (configure each port for exactly one access VLAN, no exceptions, no voice-VLAN promiscuity).

Pattern B: Per-tenant trunks

Each tenant gets dedicated access switches. The trunks carry only that tenant's VLANs back to the core. Physical separation of tenant traffic at the access layer.

The trade-off: more switches, more cabling, more cost. Worth it for tenants who explicitly require physical-layer isolation (financial services, regulated industries with auditor sensitivity).

Pattern C: VRF-per-tenant on the core

One step beyond VLAN isolation. Each tenant's VLAN routes within its own VRF (Virtual Routing and Forwarding) instance. Inter-VRF routing is impossible without explicit policy.

The trade-off: requires a layer-3 switch or router that supports VRF (most enterprise gear does; cheaper SMB gear often does not). Significantly stronger isolation; appropriate for buildings where tenants are direct competitors or have hard regulatory separation requirements.

Our default for new shared-office deployments: Pattern B + Pattern C combined. Per-tenant access switches feeding a core with VRF-per-tenant. The premium over Pattern A is meaningful but small relative to the building's monthly rent line.

DHCP and DNS — where most leakage actually happens

VLAN isolation is necessary but not sufficient. The DHCP and DNS planes need explicit design or they undo the VLAN work.

DHCP scoping

Each tenant VLAN gets its own DHCP scope. The DHCP server must not span tenants. Three implementation patterns:

• Firewall-as-DHCP-server (default for small deployments). The firewall (pfSense, OPNsense, Sophos, Fortigate, etc.) runs scoped DHCP per interface. Simple, well-understood, sufficient for under 10 tenants.
• Dedicated DHCP server with VRF awareness. Windows Server or Linux ISC-Kea. More flexibility, more operational overhead.
• Tenant-owned DHCP servers. The tenant brings their own DHCP appliance in their VRF. The building network just transports. Used when tenants have specific DHCP requirements (e.g., PXE boot, IPAM integration with their corporate IDP).

The trap: DHCP snooping disabled or misconfigured. Without snooping, any device on a VLAN can hand out DHCP responses. Configure DHCP snooping on every access switch with the trusted-port list explicitly set to the uplink trunks only.

DNS isolation

Tenants should not be able to discover each other via DNS. Three layers:

• Per-tenant DNS resolvers (typically running on the firewall or a dedicated VM in the tenant's VRF)
• No conditional forwarders between tenant DNS instances (any cross-tenant resolution is a leak)
• Upstream DNS defaults to a public resolver (Cloudflare 1.1.1.1, Google 8.8.8.8, Quad9 9.9.9.9) — never another tenant's internal DNS

The mDNS question: Bonjour, mDNS, SSDP, UPnP — the discovery protocols that make printers / Chromecasts / AirPlay devices "just work" within a network and "leak everywhere" without segmentation. By default, these protocols are blocked at VLAN boundaries. If a tenant needs cross-VLAN AirPlay (rare), it gets explicit policy permitting only the necessary multicast groups.

Inter-VLAN routing — what is allowed

The default policy on the core router is "block everything except explicitly permitted". The permitted flows:

From	To	Allowed	Reason
Tenant A (any sub-VLAN)	Tenant B (any sub-VLAN)	❌	No cross-tenant traffic
Tenant A (any)	Internet	✅	Production usage
Tenant A (any)	Building services VLAN 20	Selected services only	Door access from tenant lobby
Tenant A guest VLAN	Tenant A corp VLAN	❌	Guest never talks to corp
Building IoT	Internet	Permitted destinations only	NTP, vendor cloud, OTA updates
Building IoT	Any tenant VLAN	❌	IoT never talks to tenants
Management VLAN 10	Any other VLAN	From IT subnet only, jump-host required	Operations
Quarantine VLAN 999	Captive portal only	Authentication path	Onboarding

The policy lives in the firewall (or VRF leakage rules on the core). It is version-controlled. Changes go through code review like any other infrastructure config.

Wireless — per-tenant SSIDs with VLAN mapping

Cloud-managed AP fleets (UniFi, Meraki, Aruba Central, Ruckus Cloud) all support broadcasting multiple SSIDs with per-SSID VLAN tagging. The standard pattern:

• Tenant-Corp-A SSID → VLAN 101 (corp data)
• Tenant-Voice-A SSID → VLAN 102 (voice traffic with QoS)
• Tenant-IoT-A SSID → VLAN 103 (IoT with restricted egress)
• Tenant-Guest-A SSID → VLAN 199 (Tenant A's own guests)
• (Repeat per tenant)
• Building-Guest SSID → VLAN 900 (visitors who don't know which tenant)

The trap: too many SSIDs degrades RF performance. Each SSID consumes airtime via beacon overhead. The practical ceiling is 6-8 SSIDs per AP before measurable performance impact. For buildings with >5 tenants, the solution is 802.1X-driven dynamic VLAN assignment: one or two SSIDs that authenticate via RADIUS and put the user on the right VLAN based on their identity. More operational overhead at setup, much cleaner at scale.

The RADIUS architecture for dynamic VLAN assignment

Per-tenant RADIUS instances feeding the AP fleet, with each tenant managing their own user database. The tenant authentication produces a RADIUS Access-Accept with the VLAN ID in a Tunnel-Private-Group-ID attribute. The AP places the user on that VLAN.

For tenants without their own RADIUS, FreeRADIUS instances run per tenant on the building infrastructure with credentials managed via the tenant portal. Cleaner for tenants; one more operational layer for the building IT.

QoS and bandwidth fairness

The single uplink shared across tenants needs explicit QoS or one tenant's bursty workload starves the others. Three layers:

1. Per-VLAN egress shaping at the firewall. Each tenant gets a guaranteed minimum + a maximum burst. Configurable per the tenant's lease agreement.
2. Voice prioritisation via DSCP marking. Voice VLAN traffic gets EF (Expedited Forwarding) class regardless of other policy.
3. Real-time monitoring with alerts when any tenant sustains over their lease.

For buildings with high-bandwidth tenants (video production, software development with CI/CD), the lease should explicitly cover bandwidth allocation rather than treating it as an implicit shared resource.

The captive portal and guest onboarding

The building-guest VLAN (VLAN 900) typically uses a captive portal. The portal:

• Branded with the building's name + a "you are at $building" landing
• Collects an email address (GDPR-compliant: explicit consent, retention period documented)
• Optionally collects which tenant they are visiting
• Issues a time-limited access token (typically 8 hours)
• Logs the access for incident-response purposes

The legal piece: the GDPR record-of-processing has to cover the guest authentication data. The retention policy should be aggressive (30-90 days is standard) to minimise data-protection exposure.

Monitoring and operational visibility

Per-tenant visibility is the building IT team's responsibility. The dashboard pattern:

• Per-tenant bandwidth usage (current + 24h + 7-day trend)
• Per-tenant device count
• Per-tenant lease compliance (are they over allocation?)
• Per-tenant uptime SLA (uplink + AP + switch reach)
• Building-level signals (uplink utilisation, AP density, RF anomalies)

Tools: Grafana fed by SNMP exporters + flow data (sFlow or NetFlow) from the core + AP-vendor analytics. The vendor's cloud dashboard (UniFi Cloud, Meraki Dashboard, Aruba Central) is usually the starting point; we layer Grafana on top for cross-vendor consistency.

The tenant change process

Tenants come and go. The change process matters:

Onboarding a new tenant

1. Allocate VLAN range (next free 100-block)
2. Configure core router VRF + interfaces
3. Configure firewall policy for the new tenant's traffic patterns
4. Provision access switches (or re-trunk existing ones)
5. Configure AP SSIDs or RADIUS profile
6. Set up tenant-specific monitoring dashboards
7. Document the configuration in the building's network runbook
8. Hand over tenant-portal credentials for the tenant to self-serve guest WiFi management, etc.

Offboarding

1. Confirm tenant has migrated all their data + equipment
2. Wipe building-managed equipment that was tenant-specific (APs labelled for that tenant, etc.)
3. Remove RADIUS users + DHCP scopes + DNS entries
4. Decommission VLAN range (do not reuse for 30 days to avoid stale ARP / DNS cache hits)
5. Update documentation
6. Generate exit certificate confirming data wiped + traffic logs retained per policy

Hardware reference for a 5-tenant deployment

The bill of materials for a realistic mid-size shared office:

Layer	Equipment	Cost (EUR, list)
Edge firewall (HA pair)	2× Sophos XGS 2100 or Fortigate 60F	€4,000-€6,000
Core switch	Aruba CX 6300M (24 port, layer 3, VRF support)	€3,500
Access switches	5× per-tenant Aruba 6200F (24-port PoE)	€5,000
APs (4 per tenant + 4 common areas)	24× UniFi U7 Pro or Aruba 615	€7,200
Cabling + patch panels + rack	Cat 6A + fibre uplink + 42U rack	€3,000
RADIUS / Portal VMs (or appliance)	2× small Intel NUCs running FreeRADIUS + Captive portal	€800
Monitoring (Grafana stack)	VM on existing infra	€0 marginal
Backup uplink (different carrier)	4G/5G modem for fail-over	€300 + monthly data plan
Total CAPEX		€23,800-€25,800

Amortised over a 5-year lifecycle, this is €4,800-€5,200/year of network infrastructure for a 5-tenant building — €80-€90 per tenant per month. Most building leases already include "internet and network" as a service line; the engineering cost is what gets debated.

What we would do differently for the sixth deployment

Lessons from five real shared-office deployments:

1. VRF from day one, not "we'll add it later". Retrofitting VRFs onto a VLAN-only design is painful. Start with VRFs even when only 2 tenants are using them.
2. Per-tenant RADIUS earlier. The static-SSID-per-tenant pattern works for 3-5 tenants and breaks at 6+. Going dynamic-VLAN-via-RADIUS at the start saves a re-architecture.
3. The captive portal is more political than technical. Tenant marketing teams want to brand the portal. The legal team wants strict retention. The IT team wants minimum touch. Resolve the politics in week 1.
4. 4G/5G failover is non-negotiable. Shared-office tenants do not understand carrier outages but they do escalate when their video calls drop. Budget for the failover.
5. The tenant portal pays for itself. A simple web app where tenants can manage their own guest WiFi credentials, view their bandwidth, and see device counts reduces operational tickets by 60-80%.

The one paragraph version

Multi-tenant office networks default to "one flat network for everyone" and break the moment a single tenant gets compromised. The reference design: VLANs per tenant within a 100-block numbering scheme, VRFs on the core for hard isolation, dedicated DHCP / DNS planes per tenant, per-tenant SSIDs (or dynamic-VLAN-via-RADIUS at scale), explicit inter-VLAN routing policy, QoS for fair-share uplink, and per-tenant operational visibility. CAPEX for a 5-tenant building is €23-26k amortised over 5 years. The political work (lease addenda, GDPR DPA, captive portal branding) takes longer than the technical work. The pattern survives tenant churn over 3-5 years because it was designed for it.

If you want a shared-office network designed from scratch or audited against this pattern, that is the engagement shape under our Azure Cloud Infrastructure + adjacent Microsoft 365 Defender services where M365 is part of the tenant stack. The free Bloodbath Scan can spot obvious network-layer findings during the initial diagnostic.