Zone Defense: How I Built a Zone‑Based Firewall That Actually Secures a Smart Home
In my last post I introduced five principles I consider non-negotiable for a well-run smart home. Today I'm going deep on principle 02: Security.
Most home network security advice stops at "use a strong Wi-Fi password and keep your router updated." That's basic hygiene, not protection. If you run smart devices, a NAS, cameras, or a home lab alongside your everyday laptops and phones, you don't have a flat home network; you have infrastructure that deserves infrastructure‑grade controls. My solution is a Zone‑Based Firewall (ZBF): the enterprise model, scaled down to defend a homestead.
Why Zones?
A traditional home network is flat. Everything: your laptop, your smart fridge, your security cameras, your kids' tablets, sits on the same network. If one device is compromised, everything else is reachable. That's not a smart home. That's an open floor plan with no doors.
A zone-based model divides your network into isolated segments, each with its own trust level. Traffic between zones isn't allowed by default. You define exactly what can talk to what, on which ports, in which direction.
The mental model is simple: think of your home network as a building. Each zone is a room. The firewall is the set of doors and locks between them. Some rooms are open to everyone. Some require a key. Some, like the server room, have a locked door, a keypad, and a camera.
Your smart lightbulb doesn't need to be in the same room as your NAS.
The Trust Hierarchy
Before building rules, you need to establish trust levels. Not all zones are equal. Here's how I think about mine, from least trusted to most:
Uncontrolled: The Internet Outside your network entirely. Zero trust. Zero policies. Everything inbound is assumed hostile until proven otherwise.
Unmanaged: Guest Zone Devices you don't own or control. They get internet access and nothing else. No visibility into your internal zones, no route to your services.
Managed: Everything else Your zones with defined, enforced policies. Even within managed zones, the level of access varies significantly.
My Six Zones
Here's how my network is segmented:
Service Zone is the core of my infrastructure: reverse proxies, DNS, an SSH bastion, storage services, and the VMs and containers that run everything. It's the most locked-down zone in terms of what can reach it.
Control Zone houses the physical infrastructure: the router, switches, and NVR. Only specific management traffic reaches here.
Camera Zone contains one thing: cameras. They can talk to the NVR in the Control Zone and nowhere else.
Smart Zone is isolated to Home Assistant and the IoT devices it manages: Zigbee, Z-Wave, and BLE. HA can reach the Service Zone for DNS and backups. Nothing in the Smart Zone can reach User or Control.
User Zone is where everyday devices live — laptops, phones, desktops. They can reach the Service Zone for DNS, the reverse proxy, and the bastion. They can reach Home Assistant's web UI. That's it.
VPN Zone is how I access everything remotely. Two VPN connections, one site-to-site to a family member's home and one for my laptop, both land in the same zone and get the same access as the User Zone.
Guest Zone is the red-bordered outlier. Devices get internet access and nothing else, isolated from every other zone entirely. But it goes further than that: guest devices are also isolated from each other within the zone. A device on your guest network can't see, probe, or communicate with any other device on that same network. No exceptions.
The Diagram
The vertical ZBF policy points in the center are the key. Every arrow, every traffic flow, passes through one of those enforcement points. There is no zone-to-zone communication that doesn't go through the firewall. That's the whole point of the model.
Arrow direction in the diagram indicates the session originator. Return traffic is handled automatically by UniFi's stateful inspection. You define the rule once in one direction, and the return path is managed for you.
Application Intermediaries: The Pattern That Makes It Work
Zones define the boundaries. Application Intermediaries are what enforces them at the service level.
Rather than letting zones talk directly to each other, every cross-zone service request goes through an intermediary: a reverse proxy, a bastion host, a storage endpoint, that terminates the inbound session, enforces authentication and encryption, and opens a new connection to the backend. The client never reaches the destination directly.
Application Intermediaries are a big enough topic to deserve their own post — I'll go deep on the architecture, the specific tools, and the configuration patterns in a future installment.
UniFi Implementation Notes
I run all of this on a UniFi Dream Machine Special Edition. A few things worth knowing if you're implementing this on UniFi:
Zones are configured per-network. You create the zone in UniFi, assign a network to it, then define policies between zones. The firewall rules are written at the zone level, not the interface level, which is what makes ZBF cleaner than traditional ACL-based approaches.
UniFi auto-generates return rules. When you create an allow rule from Zone A to Zone B, UniFi automatically creates the matching return rule in the reverse direction. You don't write return rules manually. This is a significant quality-of-life improvement over managing stateless rules by hand.
Host lists and port lists are your best friends. Rather than writing individual rules for each IP, define named host lists (DNS-Hosts, SSH-Hosts, Proxy-Hosts) and port lists (DNS-Ports, SSH-Ports). Rules reference the lists. When an IP changes, you update the list once and every rule that references it stays correct.
Naming conventions matter. I follow a strict format: Action-SourceZone-DestinationZone-Service. For example: Allow-VPN-Service-SSH. Every rule name tells you exactly what it does without opening it. This matters when you have 30+ rules and need to audit them quickly.
VPN is a zone, not a network. UniFi treats all VPN connections as a single VPN zone. If you have multiple VPN clients or site-to-site connections, they all share the same zone policy. Plan your access accordingly — you can't easily give different VPN connections different permissions within the same zone.
DNS filtering is a first-class security control. My DNS servers aren't just resolvers. They're ad-blocking DNS servers that silently drop requests to known tracking and telemetry domains. This matters most for IoT devices. Most smart home hardware phones home aggressively: usage telemetry, advertising identifiers, sometimes audio snippets. DNS filtering lets devices reach the update servers they actually need while dropping everything else before a connection is ever established. The device doesn't get an error. The request just disappears.
Region blocking at the WAN interface. As a final layer, I've configured geographic blocking on the WAN interface. Traffic originating from regions I have no legitimate reason to communicate with is dropped before it reaches the firewall policy layer. It doesn't replace proper zone rules. A determined attacker can route around it. But it significantly reduces the noise floor of inbound probes and attack traffic that every internet-connected network sees constantly.
The Result
What does all of this actually buy you?
A compromised IoT device in the Smart Zone can't reach your laptops, your NAS, or your cameras. It can reach Home Assistant, because you explicitly allowed that, and it can reach the internet for updates. That's it.
A guest on your Wi-Fi gets internet and nothing else. They can't see your NAS, your cameras, your servers, or your smart home. Not because you trust them less than family, but because the network enforces it automatically, regardless of intent.
Your administrative access has exactly one entry point. That bastion is hardened, logged, and audited. There's no second path in.
And when something does go wrong, a misconfigured container, a device behaving unexpectedly, an IPS alert, the blast radius is contained to the zone it started in.
That's not paranoia. That's just how you build infrastructure that you can trust.
There's always more to do. Security isn't a state you reach. It's a practice. Writing this post alone surfaced a handful of improvements I hadn't gotten around to yet, now sitting in my backlog. That's the nature of it. You build the foundation, you document what you have, and the act of explaining it clearly tells you exactly where the gaps are.
Next up I'll shift gears to principle 03: Simplicity. I'll walk through my blinds automation as a real-world example of what it looks like when automation gets out of the way and just works.
