DEV Community: ZILL E ALI BUTT

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

ZILL E ALI BUTT — Fri, 31 Jul 2026 04:30:00 +0000

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

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.

DEV WEEKEND with AWS Student Builder Group, QAU Islamabad

ZILL E ALI BUTT — Tue, 28 Jul 2026 04:30:00 +0000

Spent 3 days at Quaid i Azam University Islamabad for DEV WEEKEND, organized by the AWS Student Builder Group.

What was covered:

Tech career journeys in data, led by Taskeen Fatima (DataCamp)
Git and GitHub fundamentals, led by Shiza Asghar
Agentic AI with Kiro and Amazon Bedrock, led by @wardaliaqat01

The Bedrock session stood out since Warda has been mentoring me directly. Watching the concepts she explained get applied live in a workshop format made a lot of things click.

I work as a Junior Network Engineer at FiberX Digital, and I am building NexaLink, an ISP management SaaS, on the side. Events like this are a good checkpoint while I expand from networking into cloud and AI.

Credit to Ali Mumtaz and the AWS SBG QAU team for a well run event.

I built an AI powered RouterOS config generator for MikroTik network engineers

ZILL E ALI BUTT — Thu, 02 Jul 2026 08:32:54 +0000

As a Junior Network Engineer managing FTTH infrastructure across dozens of sites, I spend a lot of time writing and reviewing MikroTik RouterOS configs. Same categories of tasks come up constantly: PPPoE server setup, VLAN configuration, firewall hardening, RADIUS integration, WireGuard tunnels.
I built MikroTik Config Generator to turn plain language requirements into deployable RouterOS v7 scripts.

How it works:

The frontend takes a plain language description of what you need. A Supabase edge function connected to Lovable AI Gateway processes the request through a system prompt that enforces RouterOS v7 syntax, applies security defaults (restricted management access, disabled unused services, dropped invalid connections), and asks for missing critical details like a WAN interface or LAN subnet instead of guessing.
Generated configs and summaries return as structured JSON so the frontend renders the script and explanation separately.
It also supports a review mode where you paste an existing config export and get back flagged issues with corrected commands.
Stack: Lovable, Supabase (Auth, edge functions, Postgres with row-level security for per-user config history), Lovable AI Gateway.

Try it: https://zille-skill-mikrotik.lovable.app/

Open to feedback from anyone working with RouterOS in production, especially around edge cases in firewall or NAT logic.

How I blocked all Social Media + DoH/DoT on MikroTik for an ISP network (step-by-step)

ZILL E ALI BUTT — Sat, 16 May 2026 15:04:54 +0000

Managing an ISP network means you often need to enforce content policies — whether for a corporate client, a school, or a regulated environment. In this post, I'll walk through exactly how I built a robust social media and app-blocking system on MikroTik RouterOS, including blocking DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT) to prevent users from bypassing your filters.

This is a real setup I implemented at FiberX Digital, where I work as a Junior Network Engineer managing FTTH B2B and B2C infrastructure.

What We're Building

Block social media platforms (Facebook, Instagram, TikTok, YouTube, Twitter/X, Snapchat, etc.)
Block messaging apps (WhatsApp, Telegram, Signal)
Force all DNS through your controlled resolver
Block DoH and DoT so users can't bypass your DNS filters
Use dynamic address lists for easy management

Prerequisites

MikroTik router running RouterOS v6.49+ or v7.x
Admin access via Winbox or SSH
Basic knowledge of MikroTik firewall rules

Step 1 — Force DNS to Your Router

First, redirect all outbound DNS (port 53) back to your router so no client can use an external resolver directly.

/ip firewall nat
add chain=dstnat protocol=udp dst-port=53 action=redirect to-ports=53 comment="Force DNS to router UDP"
add chain=dstnat protocol=tcp dst-port=53 action=redirect to-ports=53 comment="Force DNS to router TCP"

Set your router's DNS and disable remote requests if not needed:

/ip dns
set servers=1.1.1.1,8.8.8.8 allow-remote-requests=yes cache-max-ttl=1d

Note: allow-remote-requests=yes is required for the NAT redirect to work. Lock it down at the firewall level instead (Step 4).

Step 2 — Block DoH (DNS over HTTPS)

DoH runs over port 443 HTTPS, so you can't just block a port. You need to block the known DoH provider IPs using an address list.

/ip firewall address-list
add list=doh_servers address=1.1.1.1 comment="Cloudflare DoH"
add list=doh_servers address=1.0.0.1 comment="Cloudflare DoH"
add list=doh_servers address=8.8.8.8 comment="Google DoH"
add list=doh_servers address=8.8.4.4 comment="Google DoH"
add list=doh_servers address=9.9.9.9 comment="Quad9 DoH"
add list=doh_servers address=149.112.112.112 comment="Quad9 DoH"
add list=doh_servers address=94.140.14.14 comment="AdGuard DoH"
add list=doh_servers address=94.140.15.15 comment="AdGuard DoH"
add list=doh_servers address=185.228.168.9 comment="CleanBrowsing DoH"
add list=doh_servers address=76.76.2.0 comment="ControlD DoH"

Now drop traffic to those IPs on port 443:

/ip firewall filter
add chain=forward dst-address-list=doh_servers dst-port=443 protocol=tcp action=drop comment="Block DoH"

Step 3 — Block DoT (DNS over TLS)

DoT uses port 853. This one is easier — just block the port.

/ip firewall filter
add chain=forward dst-port=853 protocol=tcp action=drop comment="Block DoT port 853"
add chain=forward dst-port=853 protocol=udp action=drop comment="Block DoT UDP 853"

Step 4 — Build Dynamic Address Lists for Social Media

Instead of hardcoding IPs (which change), use DNS-based address lists with the MikroTik scripting engine to resolve and populate them automatically.

First, create the address lists:

/ip firewall address-list
add list=blocked_social address=facebook.com comment="Facebook"
add list=blocked_social address=www.facebook.com
add list=blocked_social address=instagram.com
add list=blocked_social address=www.instagram.com
add list=blocked_social address=tiktok.com
add list=blocked_social address=www.tiktok.com
add list=blocked_social address=twitter.com
add list=blocked_social address=x.com
add list=blocked_social address=snapchat.com
add list=blocked_social address=youtube.com
add list=blocked_social address=www.youtube.com
add list=blocked_social address=whatsapp.com
add list=blocked_social address=web.whatsapp.com
add list=blocked_social address=telegram.org
add list=blocked_social address=web.telegram.org
add list=blocked_social address=reddit.com
add list=blocked_social address=www.reddit.com
add list=blocked_social address=linkedin.com
add list=blocked_social address=www.linkedin.com
add list=blocked_social address=pinterest.com

Step 5 — Use Layer-7 Matchers for SNI-Based Blocking

For HTTPS traffic you need Layer-7 patterns to match the SNI (Server Name Indication) field before TLS is established.

/ip firewall layer7-protocol
add name=facebook regexp="^.+(facebook\\.com|fbcdn\\.net|fb\\.com).*\$"
add name=instagram regexp="^.+(instagram\\.com|cdninstagram\\.com).*\$"
add name=tiktok regexp="^.+(tiktok\\.com|tiktokv\\.com|muscdn\\.com).*\$"
add name=youtube regexp="^.+(youtube\\.com|googlevideo\\.com|ytimg\\.com).*\$"
add name=twitter regexp="^.+(twitter\\.com|x\\.com|twimg\\.com).*\$"
add name=whatsapp regexp="^.+(whatsapp\\.com|whatsapp\\.net).*\$"
add name=telegram regexp="^.+(telegram\\.org|t\\.me).*\$"

Apply the Layer-7 rules in the forward chain:

/ip firewall filter
add chain=forward layer7-protocol=facebook action=drop comment="Block Facebook"
add chain=forward layer7-protocol=instagram action=drop comment="Block Instagram"
add chain=forward layer7-protocol=tiktok action=drop comment="Block TikTok"
add chain=forward layer7-protocol=youtube action=drop comment="Block YouTube"
add chain=forward layer7-protocol=twitter action=drop comment="Block Twitter/X"
add chain=forward layer7-protocol=whatsapp action=drop comment="Block WhatsApp"
add chain=forward layer7-protocol=telegram action=drop comment="Block Telegram"

Performance note: Layer-7 inspection is CPU-intensive. On high-traffic routers (1Gbps+), consider using a dedicated content filter or combining with address-list drops to reduce L7 load.

Step 6 — DNS-Level Blocking (Fastest Method)

The most efficient block is at DNS level. When a client requests facebook.com, your router returns NXDOMAIN or a redirect IP.

/ip dns static
add name=facebook.com address=0.0.0.0 comment="Block Facebook DNS"
add name=www.facebook.com address=0.0.0.0
add name=instagram.com address=0.0.0.0
add name=www.instagram.com address=0.0.0.0
add name=tiktok.com address=0.0.0.0
add name=www.tiktok.com address=0.0.0.0
add name=twitter.com address=0.0.0.0
add name=x.com address=0.0.0.0
add name=youtube.com address=0.0.0.0
add name=www.youtube.com address=0.0.0.0
add name=whatsapp.com address=0.0.0.0
add name=web.whatsapp.com address=0.0.0.0
add name=telegram.org address=0.0.0.0
add name=t.me address=0.0.0.0
add name=snapchat.com address=0.0.0.0
add name=reddit.com address=0.0.0.0
add name=pinterest.com address=0.0.0.0

This works because we already forced all DNS through the router in Step 1.

Step 7 — Apply Blocks to Specific IP Ranges Only (Optional)

If you only want to block social media for certain customers (e.g., a B2B client's LAN) and not your entire network:

/ip firewall address-list
add list=restricted_clients address=192.168.100.0/24 comment="Client LAN to restrict"

Then modify your drop rules to match the source:

/ip firewall filter
add chain=forward src-address-list=restricted_clients dst-address-list=blocked_social action=drop comment="Block social for restricted clients"

Step 8 — Schedule DNS Refresh Script

MikroTik static DNS entries don't auto-update if CDN IPs change. Run a scheduler to flush and re-resolve periodically:

/system scheduler
add name=flush-social-dns interval=12h on-event="/ip dns cache flush" comment="Flush DNS cache every 12 hours"

Testing Your Setup

Test DNS blocking:

# From a client PC
nslookup facebook.com YOUR_ROUTER_IP
# Should return 0.0.0.0

Test DoT is blocked:

# Try resolving via DoT (kdig from knot-resolver)
kdig @1.1.1.1 +tls facebook.com
# Should time out

Test from MikroTik terminal:

/ip firewall filter print stats
# Check hit counters on your drop rules

Common Issues & Fixes

Problem	Cause	Fix
Social media still works	Client using DoH	Ensure DoH IPs are in address list and port 443 drop rule is active
Blocking too much traffic	Layer-7 regex too broad	Narrow your regexp patterns
High CPU usage	Too many L7 rules	Prioritize DNS + address-list blocking, reduce L7 rules
VPN bypass	Client using VPN	Block common VPN ports (1194, 1723, 500, 4500) separately
Mobile apps still work	Apps using IP directly	Add CDN IP ranges to address list

Final Thoughts

A layered approach works best:

DNS blocking — fast, low CPU, first line of defense
Address list drops — catches direct IP access
Layer-7 matching — catches SNI-based HTTPS
DoH/DoT blocking — closes the bypass route

No single method is 100% foolproof (determined users can always use VPNs), but this combination covers 95%+ of use cases in a managed ISP or enterprise environment.

About the Author

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

🔗 LinkedIn | Fiverr | zilleali.com

Have questions about your MikroTik setup? Drop them in the comments — happy to help!