Back to blog

Enhancing Network Security with VLANs in My Homelab

Discover how granular network segmentation can transform a standard homelab into a hardened, high-performance infrastructure.

Post

Introduction

VLANs are one of the most impactful changes I've made to my homelab. By segmenting my network into distinct zones, I've simplified traffic management, enforced separation of duties, and added a meaningful layer of defence in depth. Even if something goes wrong in one segment, the blast radius is contained.

Segmentation Strategy

When balancing a household with a homelab, network segmentation becomes critical; not just for security, but to maintain clear boundaries between different types of traffic and workloads. My network is divided into four VLANs, each serving a specific purpose.

Trusted

Of all my network segments, trusted is the least restricted, but that trust is earned, not given. Only devices I own and control are permitted on this VLAN. It functions as my management network and hosts the majority of my infrastructure. Core services, servers, and anything that needs the highest level of access. Even if another segment is compromised, strict inter-VLAN firewall rules ensure that trusted resources remain unreachable.

Wireless

The wireless VLAN handles all wireless client devices: phones, tablets, laptops, etc. I treat this segment as untrusted by default. Wireless devices present a larger attack surface than wired ones, and I have no interest in wireless traffic having any visibility into my trusted or work environments.

Work

The work VLAN is dedicated to my company-issued work device. Since I work from home, keeping work traffic on its own segment made sense. I have no visibility into what the company MDM is doing on that device, and I'd rather it not have visibility into the rest of my network either. Isolating it from trusted and wireless keeps work traffic contained and eliminates any risk of lateral movement between my employer's device and my personal infrastructure.

DMZ

Lastly, the DMZ sits between my internal network and the outside world, hosting services that require some degree of public accessibility. Most notably, this is where my web server lives, the Debian VM running nginx that serves this very site, which I cover in detail in here. Anything in the DMZ is treated as explicitly hostile. Strict firewall rules prevent it from reaching trusted, wireless, or work resources under any circumstances.

DNS & Internal Services

Both trusted and wireless VLANs have access to my Pi-hole + Unbound recursive resolver stack, as well as my internal Caddy reverse proxy which handles SSL for self-hosted services. DNS is enforced at the pf level, the wireless VLAN is blocked from using any resolver other than Pi-hole, preventing DNS leaks or bypass attempts.

The work and DMZ VLANs use external resolvers only. I have no interest in my employer's DNS queries passing through my infrastructure, and DMZ services shouldn't need to resolve anything internal.

Infrastructure

The underlying infrastructure runs on Proxmox VE. Most of my stack, Pi-hole, Unbound, internal Caddy, and other self-hosted services, run on Debian LXC containers for efficiency and isolation. The exception is my UniFi OS Server, which runs as a full Debian VM. Some software just doesn't play nicely in a container unfortunately.

Yes, I use Ubiquiti switches at home. No, I don't think that's a problem. What else would you expect from a blog like this?

Nothing Faces the Internet Directly

Despite running a number of self-hosted services, nothing is exposed to the hostile internet directly. The only ports ever opened on my router are 80 and 443, and only temporarily when Caddy needs to renew certificates. Everything else, Nextcloud, my password manager, and the rest of my internal services, are accessible exclusively over WireGuard. If you're not on the VPN, you don't exist to my network.

Wrapping Up

Network segmentation is one of the most effective things you can do to harden a homelab, or any network for that matter. The beauty of VLANs is that they enforce trust boundaries at the infrastructure level, not just through software controls. Even if a device is compromised, the damage is contained to its segment. In a follow-up post I'll dive into the pf firewall rules that enforce all of this; because segmentation is only as strong as the access controls that back it up.

The architecture diagram below summarises the full stack.

sandover.ca architecture diagram

Sources

  1. pf.conf (5) - OpenBSD manual pages
  2. vlan (4) - OpenBSD manual pages
  3. UniFi VLAN Configuration
  4. Pi-hole documentation
  5. unbound.conf (5) - OpenBSD manual pages
  6. RFC 1918 - Address Allocation for Private Internets
  7. Caddy documentation