Just finished deploying a new multi-tenant security lab to simulate a service provider edge for some compliance and traffic isolation testing. I see a lot of theoretical posts about SRX multi-tenancy, but few that show the actual, working config structure with all the necessary glue. This isn't a basic routing-instance example. This is a full template for tenant isolation covering security policies, logical interfaces, zone structure, and routing. I built this on an SRX380 running Junos OS 21.2R3.
The core design principles were:
* Each tenant must have completely independent firewall policies and address books.
* Inter-tenant communication must be explicitly configured via a shared services instance; no accidental leakage.
* Must support overlapping RFC 1918 address spaces between tenants.
* Infrastructure management access (SSH, NTP, DNS) must be segregated into its own context.
* The config must be template-driven for quick replication.
Here is the structural overview. I'm using logical-systems for true configuration separation, not just VRFs. Logical systems are the only way to get fully independent security policies and NAT tables per tenant on a single chassis.
```
# Top-Level System Configuration for the Physical Device
set system syslog user * any emergency
set system services ssh
set system services netconf ssh
# Management logical system is configured at the root level
set interfaces irb unit 0 family inet address 172.16.0.1/24
# Define Logical Systems
set logical-systems TENANT-A
set logical-systems TENANT-B
set logical-systems INFRA-MGMT
```
Each tenant logical system gets its own full firewall configuration. Here's the template applied to `TENANT-A`. Notice how every security element is scoped within the logical system.
```
# Configuration Snippet for TENANT-A Logical System
edit logical-systems TENANT-A
# Internal Routing Instance
set routing-instances TENANT-A-VRF instance-type virtual-router
set routing-instances TENANT-A-VRF interface lt-0/0/0.1
set routing-instances TENANT-A-VRF interface irb.1
# Logical Tunnel to Core Router Simulating Customer Edge
set interfaces lt-0/0/0 unit 1 description "TO-TENANT-A-CORE"
set interfaces lt-0/0/0 unit 1 encapsulation ethernet-vlan
set interfaces lt-0/0/0 unit 1 peer-unit 101
set interfaces lt-0/0/0 unit 1 family inet address 192.168.10.1/30
# Internal VLAN Interface
set interfaces irb unit 1 description "TENANT-A-INSIDE"
set interfaces irb unit 1 family inet address 10.10.1.1/24
# Security Zones
set security zones security-zone TENANT-A-TRUST interfaces irb.1
set security zones security-zone TENANT-A-UNTRUST interfaces lt-0/0/0.1
# Address Books Scoped to this Logical System
set security address-book global address TENANT-A-SERVER 10.10.1.10/32
set security address-book global address TENANT-A-USERS 10.10.1.0/24
# Policies Scoped to this Logical System
set security policies from-zone TENANT-A-TRUST to-zone TENANT-A-UNTRUST policy PERMIT-WEB match source-address TENANT-A-USERS
set security policies from-zone TENANT-A-TRUST to-zone TENANT-A-UNTRUST policy PERMIT-WEB match destination-address any
set security policies from-zone TENANT-A-TRUST to-zone TENANT-A-UNTRUST policy PERMIT-WEB match application junos-http
set security policies from-zone TENANT-A-TRUST to-zone TENANT-A-UNTRUST policy PERMIT-WEB then permit
```
The critical piece is the shared services instance for controlled inter-tenant communication. This is a separate routing instance (`SHARED-SVC`) at the root level, with static routes pointing to the tenant VRFs. Each tenant has a dedicated logical tunnel into this shared instance. Policies for inter-tenant flows are written *within* the shared instance's security context.
Pitfalls I had to engineer around:
* **Logical tunnel limits:** You burn interfaces quickly. Plan your chassis I/O and license limits (if applicable) accordingly.
* **Observability:** You must scope all `show` commands with `logical-system `. Your monitoring tools (SNMP, Syslog, Flow) must support logical system context. I used Grafana with a plugin that tags data by logical system.
* **Config commit time:** Committing a change at the root level invalidates the entire candidate configuration for all logical systems. This is a known Junos behavior. Make changes within the logical system scope whenever possible to avoid full device validation.
* **Hardware offload:** Certain traffic acceleration features may not function across logical systems. Test performance expectations thoroughly.
This template has proven stable under load testing. It's now the baseline for all new lab tenant onboarding. If you're trying to do true multi-tenant segmentation on SRX, logical systems are non-negotiable. VRFs alone are insufficient for firewall policy isolation.
-- as