I built a lab network with 56 devices and zero security. Every device that connected got full network access. Every smart bulb, every guest’s phone, every IoT gadget, they all lived on the same flat network as my servers, workstations, and production systems. This is how most home networks work. It’s also how most ransomware attacks spread.
As a CIO who spent years implementing PCI-DSS controls at Fontainebleau, I knew better. But like many IT professionals, my network ran on convenience, not security. That changed when I decided to build a proper Network Access Control (NAC) system, the kind you’d see in an enterprise environment, for my lab environment.
The Problem: Trust by Default
My network topology was embarrassingly simple: a UniFi Dream Machine acting as gateway, a 48-port core switch, and everything else on 192.168.0.0/24. Want to connect a device? Plug it in. It gets an IP, full internet access, and can reach every other device on the network. No questions asked.
This is the opposite of zero-trust architecture. I had 56 physical devices, Proxmox nodes, network infrastructure, IoT devices, workstations, all with lateral movement capabilities. A compromised smart TV could theoretically access my NetBox server. A malicious guest device could scan my entire infrastructure.
The manual alternative wasn’t much better. I could assign VLANs manually, configure switch ports one at a time, maintain spreadsheets. But we all know what happens with manual processes: they get skipped under time pressure, documentation falls out of date, and exceptions become the rule.
The Solution: Automated Network Access Control
I designed a NAC system built on a simple principle: default-deny with automated approval for known devices. Every new device lands in quarantine. Known devices (tracked in NetBox, my source of truth) get automatically approved to their correct security zone. Unknown devices trigger a notification requiring human approval.
Five Security Zones
- VLAN 5 (Quarantine): 10.0.5.0/24 – Unknown devices land here with zero access. No internet, no local network, only DHCP and DNS.
- VLAN 10 (Management): 10.0.10.0/24 – Network infrastructure, switches, access points, monitoring systems.
- VLAN 25 (IoT-Restricted): 10.0.25.0/24 – Smart home devices with internet-only access, completely isolated from other networks.
- VLAN 50 (Trusted): 10.0.50.0/24 – Workstations, servers, systems requiring full network access.
- VLAN 90 (Multimedia): 10.0.90.0/24 – TVs, gaming consoles, streaming devices.
The key insight: every zone has a specific purpose and appropriate restrictions. IoT devices don’t need access to your file servers. Guest devices don’t need to see your management network. The architecture enforces this by default.
The Automation Stack
pfSense handles the heavy lifting: VLAN routing, per-zone DHCP servers, and firewall rules. I chose pfSense CE 2.7.2 over the UniFi Dream Machine because I needed granular firewall control and API automation capabilities.
NetBox serves as the source of truth. Every device has a custom field called fw_zone that determines its security zone. When a device’s MAC address appears in NetBox, that’s the approval, no separate whitelist to maintain.
n8n provides workflow automation. Every 60 seconds, it polls the UniFi controller for new MAC addresses on the quarantine VLAN. When it finds one, it queries NetBox. Known device? Auto-approve. Unknown device? Send email with one-click approval links.
Ansible executes the changes. When a device is approved (automatically or manually), Ansible reconfigures the UniFi switch port profile, moving the device to its target VLAN. I built a custom UniFi Ansible collection specifically for this, four modules handling authentication, port profiles, and device management.
Why This Matters (Even for a Lab Environment)
Some people ask why I’m implementing enterprise security controls in a lab. The answer has three parts:
First, home networks are under attack. IoT botnets scan constantly for vulnerable devices. A compromised security camera can become part of a DDoS attack. A smart TV with outdated firmware can be the entry point for ransomware. These aren’t theoretical threats, they’re documented attack patterns.
Second, this is a production environment. I host real services: a documentation wiki, password vault, automation systems, monitoring infrastructure. When I lose access to my password vault because a guest device introduced malware, that’s not just inconvenient, it’s a security incident affecting real operations.
Third, the patterns scale. The NAC architecture I built here uses the same principles I’d deploy in an enterprise: source-of-truth-driven automation, least-privilege access, defense in depth. The difference is scale, not approach.
What Makes This Enterprise-Grade
Source of Truth Architecture: NetBox isn’t just documentation, it’s the authoritative source for device classification. The fw_zone field doesn’t describe what VLAN a device should be on. It determines what VLAN the device gets assigned.
Default-Deny Enforcement: Unknown devices get nothing. Not limited internet. Not restricted access. Nothing. They can request DHCP and query DNS, but all other traffic is blocked. No exceptions.
Auditable and Logged: Every device approval writes to a log. Every port profile change has a timestamp and approval type (auto or manual). Every blocked connection creates a firewall log entry.
Firewall Rules: The Real Enforcement
VLANs provide segmentation, but pfSense firewall rules provide enforcement. The quarantine VLAN has the strictest rules:
- Allow UDP 67-68 to pfSense (DHCP)
- Allow UDP 53 to pfSense (DNS)
- Block all RFC1918 addresses (10.x, 172.16.x, 192.168.x)
- Block all other traffic
Every rule logs blocked traffic. When something in quarantine tries to scan the network, I see it immediately.
The IoT-Restricted VLAN gets internet access but can’t reach any local networks. Trusted devices can access servers and infrastructure. Management VLAN has full access to everything. Each zone has exactly the permissions required for its purpose, nothing more.
Lessons Learned
API-First Design: Every component has an API, and every configuration change uses it. This isn’t just about automation, it’s about reproducibility. I can tear down the entire NAC system and rebuild it from code.
Source of Truth is Non-Negotiable: Early in the design, I considered maintaining device lists in multiple places. Bad idea. Single source of truth means NetBox is always correct, and the network always reflects what’s in NetBox.
Default-Deny Requires Discipline: When a device lands in quarantine and can’t access anything, the temptation is to “just temporarily” bypass the approval process. Don’t. Every exception becomes a policy. If the process is too slow, fix the automation, don’t undermine the security model.
Applicability to Enterprise Deployments
This design scales directly to enterprise environments. The technology stack might change, Cisco ISE instead of pfSense, ServiceNow instead of NetBox, enterprise switch vendors instead of UniFi, but the pattern remains identical:
- Define security zones based on device purpose and risk profile
- Default-deny for unknown devices
- Source of truth (CMDB, IPAM) drives automated classification
- Network infrastructure enforces policy defined in the source of truth
- Human approval required only for truly unknown devices
- Comprehensive logging and audit trails
The lab gives me a sandbox to validate these patterns at a scale where mistakes are recoverable. When I design NAC architectures for organizations, I’m not working from theory. I’m working from a production implementation that I’ve tested, broken, fixed, and refined.
Because if you can’t secure 56 devices in your lab environment, you’re not ready to secure 5,600 devices in an enterprise environment. The principles are identical. The stakes just get higher.
Go Deeper: This NAC architecture is part of a larger enterprise infrastructure management platform. Read the full case study for the complete security architecture and how automation drives zero-trust enforcement at scale.
Want to discuss network security architecture or NAC implementations? Reach out. I’m always interested in conversations with fellow security-minded IT leaders.