DEV Community

Cover image for Zonclave: One Wi-Fi Network, Dozens of Independently-Routed Tunnels
ZILL E ALI BUTT
ZILL E ALI BUTT

Posted on • Originally published at zilleali.com

Zonclave: One Wi-Fi Network, Dozens of Independently-Routed Tunnels

Most Wi-Fi networks give you one thing: a shared connection. Every device on the SSID rides the same route out to the internet, same NAT, same exit IP. That's fine until you need isolation separate residential IPs, separate policy routing, separate blast radius per group of devices.

That's the exact problem Zonclave solves.

The Problem

I kept running into the same requirement across different projects: give multiple device groups their own Wi-Fi credential, but route each group's traffic through a completely separate path different VLAN, different tunnel, different exit IP without deploying a separate physical AP or router per group.

Doing this manually on MikroTik is doable but tedious: create the VLAN, write the firewall rules, provision the WireGuard peer, tie it to a RADIUS-assigned group, repeat for every new credential. At any real scale (an ISP, an agency managing client networks, a shared office with per-tenant isolation needs) that manual process doesn't hold up.

How Zonclave Works

Four steps, fully automatic once a credential is provisioned:

Unique password :- a device joins the SSID using a credential generated just for its group. Never shared, never reused.
RADIUS assigns a VLAN FreeRADIUS **authenticates the credential and hands back that group's dedicated VLAN. Nothing else touches it.
A **private tunnel
the VLAN is policy-routed through its own WireGuard tunnel, explicitly pinned, never a shared default route.
Its own residential IP traffic egresses through that tunnel's residential exit, distinct from every other group on the network.

The part I'd call the actual design decision, not just a feature: if a tunnel ever drops, that group's traffic is dropped too — never silently rerouted onto the plain internet connection. Fail-closed by default. A lot of similar setups fail open, which quietly defeats the entire point of the isolation.

The Admin Layer — Peng Balous

Running eight PPSK groups across eight VLANs and eight WireGuard tunnels by hand isn't sustainable, so the management layer (Peng Balous) handles the provisioning and monitoring:

PPSK Groups: create/edit/disable a credential group, see its VLAN and WireGuard tunnel assignment at a glance, track active vs. stale vs. inactive sessions
VLANs: full list with subnet, WireGuard tunnel, gateway, and how many PPSKs are using each one
Network Topology view: a real-time-adjacent map from Internet → OPNsense → each VLAN, showing connected counts and active status
Tunnel Egress IPs, Backups, Admin Log — the operational stuff you actually need once this is running in production, not just at setup

Dashboard example from a live instance:

VLAN 300  10.30.0.0/24  WG_VLAN300  1 active
VLAN 301  10.30.1.0/24  WG_VLAN301  1 active
VLAN 302  10.30.2.0/24  WG_VLAN302  1 active
VLAN 303  10.30.3.0/24  WG_VLAN303  5 connected, 1 active
VLAN 304  10.30.4.0/24  WG_VLAN304  2 connected, 2 active
Enter fullscreen mode Exit fullscreen mode

Tech Stack

Layer Tool
VLAN design & routing MikroTik RouterOS
Firewall / fail-closed policy routing OPNsense
Tunnel isolation per group WireGuard
Credential → VLAN assignment FreeRADIUS
Admin panel Laravel + Filament
Data layer PostgreSQL
Switching/AP layer UniFi

Who This Is For

  • ISPs that want to offer per-customer or per-service-tier network isolation without deploying separate hardware per customer
  • Agencies/MSPs managing multiple client networks off one physical site
  • Any environment — coworking spaces, shared offices, multi-tenant setups — where "everyone's on the same Wi-Fi" is a security or compliance problem

What's Next

I'm treating this as a real product under Developer Zon, not a one-off client build. Next up is documenting the OPNsense/UniFi runbook for live tunnel health checks (the dashboard shows provisioned architecture, not live device status — that's a deliberate scope boundary, not a gap) and expanding the PPSK group management to support bulk provisioning.

About the Author

I'm Zill Ali, a Network Engineer at FiberX Digital Pvt Ltd in Gujrat, Pakistan, working on FTTH B2B/B2C infrastructure and NOC operations. MTCNA Certified | APNIC BCAP 2026 Candidate | Hikvision Certified Installer. I build ISP and network infrastructure tooling under Developer Zon.

🔗 LinkedIn | Fiverr | zilleali.com

Questions about the architecture or want to see the RADIUS/VLAN config? Drop them in the comments.

Top comments (0)