Network Segmentation with Unifi

When you start self-hosting services, your home network becomes more than a way to get to the internet. It becomes infrastructure. And infrastructure needs to be designed with security in mind.

The problem with flat networks

Most home networks are flat. Every device on the same network can talk to every other device. Your smart TV, your laptop, your server, your IoT thermostat: all neighbors.

Convenient, and risky. A compromised IoT device can scan and attack the machines sitting next to it, guest devices get the same access as your personal devices, and nothing separates the trusted machines from the untrusted ones.

When I started running real services, I knew I needed to think differently about network design.

The Unifi ecosystem

I run Unifi gear: router, switches, and access points.

Why Unifi

The controller manages routing, switching, and wireless from a single interface, and it puts VLAN segmentation within reach without enterprise complexity. Firewall rules between networks live in the same place, and the traffic analytics tell me which devices are doing what.

My network design

Segmentation philosophy

I think about the network in trust levels:

• Trusted holds my workstations and phones, the devices I control and update.
• Server holds the infrastructure that runs services.
• IoT holds smart devices that might be compromised but still need network access.
• Guest is temporary access for visitors.

Each trust level maps to its own segment with its own access controls.

Traffic rules

The firewall rules follow least privilege. Between segments the default is deny, and traffic moves only where I've written a rule for it. Servers can't initiate connections back to trusted devices, IoT reaches what it needs and nothing else, and Guest gets the internet and nothing internal.

Management access

Management interfaces for the router and switches answer only to specific trusted networks. Compromise a guest device and you still can't reconfigure my network.

Controlled ingress

Minimal exposure

Only the ports that absolutely need to be open are open; most services are internal-only, and I reach them over Tailscale when I'm remote.

Origin allowlisting

For services proxied through a VPS, my home firewall accepts connections from the VPS's IP address and nothing else. The public service is visible to the internet. My home infrastructure isn't.

Logging and monitoring

Firewall logs feed into my monitoring stack, where I can see what's being blocked, identify scanning attempts, and detect anomalies.

Practical benefits

The design has paid off more than once.

Isolation contains blast radius

When I was experimenting with a new service and it misbehaved, it could only affect its own segment. My workstations and the other services were unaffected.

Clear security posture

I can answer "what's exposed?" quickly. The attack surface is documented and intentional, not accidental.

Safe experimentation

New devices land on restricted networks first, so I can watch how they behave before deciding whether they deserve more access.

Lessons learned

Segmenting the network taught me a few things:

1. Flat networks are a liability. The convenience isn't worth the risk when you're running real services.
2. VLANs have stopped being enterprise-only. Modern prosumer gear makes segmentation accessible.
3. Default deny is the right starting point. Allow what's needed, not what's convenient.
4. Documentation matters. Future me needs to understand why rules exist.

The ongoing work

None of this is finished. I go back through the firewall rules to remove stale entries, watch for devices that turn up unannounced, and adjust access when services and requirements change. The topology is documented, mostly so I can rebuild it after a disaster.

If you're running a homelab, think about the network before you add the next service. The time you put into segmenting it properly comes back in security, in troubleshooting, and in peace of mind.