Network Segmentation Strategies for Homelab Security

Network Segmentation Strategies for Homelab Security

CompactHost ·

We earn commissions when you shop through the links on this page, at no additional cost to you. Learn more.

I learned the hard way that a flat homelab network is a security nightmare. One compromised container or vulnerable service can pivot laterally to everything else—your NAS, your development box, even your home automation system. After recovering from a ransomware incident in my lab, I rebuilt my entire network infrastructure around segmentation. This article covers the practical strategies I now use to keep my services isolated, monitored, and resilient.

Why Network Segmentation Matters in a Homelab

Most homelabbers start with everything on the same network segment. It's convenient: Docker containers talk to each other, services discover each other easily, and there's no complexity. But this creates a critical weakness. If a self-hosted application (say, Nextcloud or Gitea) gets compromised, an attacker gains access to your entire network—your backups, your VPS infrastructure, even devices you didn't realize were exposed.

Network segmentation is the practice of dividing your network into multiple zones with controlled traffic between them. Think of it like a medieval castle with walls between courtyards rather than one open field. A breach in one section doesn't automatically compromise everything.

I now run three distinct network segments in my homelab:

This segmentation means a compromised smart bulb or a vulnerable web app can't automatically reach my database servers or backup storage.

VLAN-Based Segmentation with Hardware Firewalls

If you have a managed switch and a decent router or edge firewall (like OPNsense, pfSense, or even a high-end consumer router), VLAN segmentation is the cleanest approach. I prefer this for any homelab with more than five or six services.

Here's how I structured my setup. I have a Ubiquiti UniFi switch and an old PC running OPNsense as my firewall.

VLAN Configuration:

Each VLAN gets its own IP subnet, DHCP scope, and firewall rules. Traffic between VLANs only flows if explicitly permitted.

On the OPNsense firewall, I create rules like:

# Allow Services VLAN to reach database on Management VLAN
pass from  to  port 5432

# Block IoT from reaching Services
block from  to 

# Allow DMZ reverse proxy to reach Services backend
pass from  to  port 80,443

The critical move is making the firewall the default gateway for each VLAN, so all inter-VLAN traffic is inspected and logged. This lets me catch suspicious activity—like a Philips Hue bulb trying to reach my password manager database at 2 AM.

Tip: Use firewall logging extensively. I send logs to a syslog server (even a simple instance of Loki in Docker) and set up alerts for policy violations. A single unexpected connection attempt might indicate compromise before damage occurs.

Container-Level Segmentation with Docker Networks

Not everyone can deploy VLANs—renters, people with ISP-provided routers, or labs in smaller spaces. But you can still achieve meaningful segmentation using Docker custom bridge networks.

I use this approach for development and testing labs. Instead of running everything on the default bridge network, I create isolated networks and control which containers can talk to which.

#!/bin/bash
# Create separate Docker networks for each segment

docker network create \
  --driver bridge \
  --subnet=172.20.0.0/16 \
  management

docker network create \
  --driver bridge \
  --subnet=172.21.0.0/16 \
  services

docker network create \
  --driver bridge \
  --subnet=172.22.0.0/16 \
  public

# Example: Run Nextcloud on the services network only
docker run -d \
  --name nextcloud \
  --network services \
  -e MYSQL_HOST=db \
  -p 8080:80 \
  nextcloud:latest

# Run database on services network (can reach Nextcloud, nothing else)
docker run -d \
  --name db \
  --network services \
  -e MYSQL_ROOT_PASSWORD=secure_password \
  mysql:8.0

# Run reverse proxy on both public and services
# (it bridges traffic)
docker run -d \
  --name caddy \
  --network public \
  --network services \
  -p 80:80 -p 443:443 \
  caddy:latest

Now Nextcloud and its database can talk freely, but they're isolated from other services. A compromised Gitea container on a different network can't reach the Nextcloud database.

I take this further with network policies using tools like Calico (if you run Kubernetes) or Cilium, but for pure Docker Compose, custom bridge networks are sufficient.

Watch out: Docker's default bridge network allows all containers to reach all others if they share the network. Also, the host itself can access any container port. Use `--cap-drop` and `--read-only` flags to further restrict container privileges, and never expose the Docker socket to untrusted containers.

Firewall Rules and Access Control

Segmentation only works if you have rules enforcing it. I use a tiered firewall approach:

Inbound Rules (from the Internet):

Inter-VLAN Rules:

I log all denied connections and review them weekly. This catches port scanning, lateral movement attempts, and misconfigured services quickly.

Public vs. Private Services

I physically separate services based on exposure level. Public-facing applications (the ones accessible via Caddy on the internet) run in a dedicated segment. They can only talk to their own database and a few backend services.

For example, my public Gitea instance:

If Gitea is compromised, the blast radius is small. The attacker can access Gitea's database and files, but nothing else.

Private services (Nextcloud, Immich, internal Gitea) can optionally live on the Services VLAN with tighter inbound restrictions—only accessible via the reverse proxy, not directly.

Monitoring and Alerting Across Segments

Segmentation is useless without visibility. I run Prometheus and Grafana on the Management VLAN with scrape configs that reach exporters in the Services VLAN. This lets me monitor resource usage, network connections, and service health without weakening the firewall rules.

I also monitor firewall logs for suspicious patterns:

Any of these can indicate compromise. A simple Grafana alert can notify me in minutes.

Practical Implementation: A Real Example

Here's a simplified version of my current setup. I run Caddy on a public VPS (around $40/year from providers like RackNerd) and use Cloudflare Tunnel to connect my homelab services without exposing my home IP or opening ports.

Services on my homelab:

The reverse proxy (Caddy) runs on both the Management VLAN and Services VLAN, so it can route requests to backend services without them being exposed to the internet. Firewall rules ensure:

Next Steps for Your Homelab

Start small: if you're using Docker Compose, create separate networks for your applications today. It's a five-minute change that significantly improves isolation.

If you have hardware firewall access, set up two VLANs: one for public/exposed services and one for internal services. Block traffic between them by default. This single change will prevent most lateral movement attacks.

Finally, monitor. Enable firewall logging and review it regularly. Alerts on policy violations catch problems before they become breaches.

Network segmentation isn't a silver bullet, but it's the foundation of defense in depth. Combined with strong authentication, regular updates, and least-privilege access, it makes your homelab far more resilient to compromise.

Discussion

```