Hardening a homelab with VLANs: a complete home security guide

Informatec Digital » Resources » Hardening a homelab with VLANs: a complete home security guide

If you have a home lab with a handful of gadgets (NAS, miniPCs, Raspberry Pi, cameras, smart home devices, etc.) and everything is connected on the same network, your home is, digitally speaking, an open field for lateral movement and silly attacks . You don't have to be a large company for someone to scan your ports, crack a weak password , or leave an IoT device exposed to a security vulnerability.

The goal of this article is to guide you step-by-step in setting up a segmented home network with VLANs, a firewall, and robust hardening practices. This will ensure your home services function just as well, but with significantly more control, fewer unexpected issues, and a much smaller attack surface . We'll combine the best of several approaches: pfSense/OPNsense, UniFi, Zero Trust (Tailscale, Cloudflare Tunnel) , Proxmox, lightweight Kubernetes, Pi-hole, Home Assistant, and more.

Why your homelab needs segmentation and hardening now

In a classic "flat" network, like 192.168.1.0/24 with everything crammed into it, any device can see and, in many cases, communicate with every other device. If a light bulb, a TV, or a "smart" plug is compromised, an attacker can try to jump to your NAS , your personal PC, the Proxmox hypervisor, or the server where you store backups . It doesn't take a sophisticated attack; a firmware vulnerability that no one patches is enough.

Furthermore, mixing everything on the same network causes discovery traffic (broadcast, multicast, mDNS, etc.) to become uncontrolled. This generates noise, complicates troubleshooting, and, on top of that, reveals too much information about what you have, which ports you use, and what services run on your LAN . VLAN segmentation addresses precisely this problem: separating devices by function and level of trust.

Think of your home lab as a small data center: you have critical services (DNS, VPN, storage), public services (reverse proxy, applications exposed through tunnels), unreliable devices (IoT, guests, kids' consoles), and your personal equipment. Each group should be in its own "lane" and only able to communicate with others through very specific and well-justified firewall rules.

VLANs in the homelab: concepts you will actually use

A VLAN isn't magic: it's simply a separate broadcast domain at Layer 2. It's often assumed that one VLAN equals one IP subnet, but they are actually distinct concepts. The VLAN defines how Ethernet frames are separated; the subnet defines how traffic is routed at Layer 3. The important thing for you is that devices on one VLAN don't see broadcasts from another, and they can only communicate with each other through a router or firewall.

Separation is achieved using 802.1Q tags (VIDs, from 1 to 4095) that switches insert into the packets. A port can operate in two basic ways: as an access port , where traffic enters and exits untagged and all belongs to a single VLAN, or as a trunk port , where a single cable carries several tagged VLANs simultaneously to a router, another switch, an access point, or a hypervisor.

The well-known PVID, or Native VLAN, defines which VLAN is assigned to untagged traffic entering a port. Each manufacturer displays it differently in their web interface (PVID, Access VLAN, Native VLAN, etc.), but the idea is the same: the switch decides which VLAN an untagged frame belongs to and, when it's sent out through an access port, it typically removes the tag so the end device sees "normal Ethernet" and doesn't need to know anything about VLANs.

In a typical homelab setup, you'll have at least one trunk link between your firewall/router (pfSense, OPNsense, UniFi, OpenWrt, etc.) and your main switch, and from there, access ports for PCs, TVs, consoles, cameras, and so on. Additionally, if you use Proxmox or a virtualization host, it's very common to configure a trunk link to the hypervisor and let the VMs or containers tag their traffic directly, using bridges like vmbr0 with VLAN tags.

Practical VLAN design for a modern homelab

Before you frantically open the switch panel, grab some paper (or a text editor) and define which networks you want and for what purpose. A reasonable outline, which encompasses what you see in many real-world configurations, might look something like this, adapting IP ranges and VLAN numbers to your liking:

• “Default” or Home NetworkThis is where the family's personal devices (mobile phones, laptops, desktop computers) reside. It's the "trusted" network and will typically have somewhat more relaxed internet access permissions.
• Guest VLANsDesigned for visitors. Internet only, no access to the rest of the private ranges, with isolation between clients if the AP allows it.
• IoT VLANFor light bulbs, sockets, speakers, Smart TVs, thermostats, robot vacuum cleaners, etc. Very limited traffic inwards and controlled traffic outwards.
• VLAN Homelab / ServicesThis is where your VMs, containers, NAS, Home Assistant, databases, reverse proxies, etc. reside. It usually communicates with IoT and Default, but in a very controlled way.
• VLAN “Secure” or VPN: segment in which all traffic to the Internet goes through a permanent VPN tunnel (e.g., Proton VPN or similar), without the device having to install a client.
• DMZ: optional but highly recommended for potentially exposed services (reverse proxy, web servers, VPNs, etc.), treating them as if they were "semi-trusted" and without a direct bridge to the rest of the internal networks.

A clear way to organize private addresses is to use something like 10.10.X.0/24 for each VLAN and maintain a spreadsheet with the ranges, names, and purposes . For example: 10.10.10.0/24 Default, 10.10.20.0/24 IoT, 10.10.30.0/24 Guests, 10.10.40.0/24 Homelab, 10.10.50.0/24 Secure. This will make your firewall rules and DHCP reservations much easier to maintain over time.

If you use UniFi or similar solutions, it's common to map each VLAN to a network on the controller and, in turn, link each network to a specific SSID. This way, when you select the "Home," "IoT," "Guest," or "VPN" Wi-Fi network, the device automatically falls into the correct VLAN and inherits the firewall and access policies you've defined for that segment.

Choosing hardware and software to manage VLANs and routing

As for the switch, as long as it supports 802.1Q and lets you configure VLAN tagging, trunks, and PVIDs, you're good to go. The big difference lies in whether the device only performs Layer 2 switching or if it also handles Layer 3 routing at line speed . Many "budget" switches can tag and forward frames at high speed, but when you ask them to route traffic between VLANs, they offload it to the CPU and the throughput drops to a few hundred Mbps.

If you want to simplify things, the most common approach in a homelab is to leave inter-VLAN routing to the main firewall/router (pfSense, OPNsense, UniFi Security Gateway, Dream Machine, OpenWrt on a decent router, etc.) and use switches only for Layer 2. If your internal traffic is very high (copies between storage arrays, virtualization clusters, large backups), a Layer 3 switch with hardware routing offload might be worthwhile , but for most homes it's not essential.

In terms of software, there are three main paths:

• OpenWrt en modest routers To begin with, it has the ability to label ports, create multiple networks, and apply basic firewall rules.
• pfSense or OPNsense on an x86 machine (bare metal or VM) if you want advanced rules, GeoIP, IPS/IDS, powerful VPNs, high availability with CARP, etc.
• Unifi (Dream Machine, Dream Router, etc.) if you prefer an integrated environment with APs and switches managed from the same controller, with a somewhat gentler learning curve.

For the hypervisor, Proxmox truly shines in complex networks: simply create bridges associated with the physical NICs (for example, vmbr0 over enp1s0), designate that switch port as a trunk port, and let each VM or container tag it with the VLAN ID it needs. This allows a single server to be part of multiple VLANs simultaneously and act, for example, as a host for homelab services accessible from Default and IoT without requiring any complicated setup on the switches.

From theory to practice: creating and testing VLANs

Once the design is decided, you define each VLAN on the switch with its VID and a descriptive name. Then you designate the ports that connect to the router/firewall, other switches, and Proxmox as trunk ports, allowing the VLANs you want to carry. On these ports, it's best to avoid using different native VLANs at each end to prevent untagged traffic leaks or unusual behavior.

The ports you'll be connecting "dumb" devices to (TV, game console, PC without VLAN support, cameras) should be designated as access ports: a single, unlabeled VLAN with the corresponding PVID. This way, that device will always be on the network you've chosen, preventing it from accidentally connecting to another network due to a configuration error.

On the firewall/router, you create a logical interface for each tag that passes through the network card connected to the switch. pfSense and OPNsense, for example, allow you to create VLAN interfaces on a physical NIC, and you assign each interface an IP address, DHCP range, DNS server, description, and, most importantly, its own independent firewall rules . These per-interface rules are key to isolation.

Once you have it configured, it's time to test: plug a laptop into an IoT access port, see what IP address it receives, check which gateway and DNS it sees, and verify that it cannot ping the Default or Homelab subnets, but that it does resolve public domains and access the internet (if that's what you want). Repeat similar exercises for Guests, Homelab, and Secure until you are sure that each network behaves as intended.

Firewall and rules to block lateral movement

The most effective basic approach is to deny by default and only allow what is necessary . That is, in each VLAN you create an initial rule that allows "established/related" traffic (to allow responses to connections initiated from within) and then deny traffic to other private networks (RFC1918 types) except for justified exceptions.

A convenient technique is to create an IP address group containing all your private blocks (for example, 192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12) and reference it in your rules. This way, a rule that blocks “IoT → PrivateNetworks” instantly prevents light bulbs and other devices from communicating with your NAS or laptop, leaving only access to the internet and, if needed, to specific homelab services.

On the Default network, you can allow "LAN to anywhere" (internet + other VLANs), but it's a good idea to continue limiting access to the DMZ or certain sensitive servers. On Guest networks, however, it's normal to block all access to private ranges and only allow internet access. If the access point supports client isolation, enable it so that your visitors' mobile devices can't even see each other.

For the relationship between Homelab and IoT, a typical pattern is to allow a single host (e.g., the Home Assistant container or VM) to reach certain IoT devices on specific ports (API port, control port), but not vice versa. This is implemented with an allowed rule such as “HomelabHost → IP_IoT:port” followed by a general IoT blocking of Homelab and Default except for established traffic.

Making multicast, mDNS, and the like not a nightmare

As soon as you start separating networks, you realize that things like AirPlay, Chromecast, or some printers "disappear." It's not a bug: many discovery mechanisms use broadcast or multicast and, by design, don't jump between VLANs. To keep them working, you need to be selective about which discovery traffic you allow.

The usual practice is to enable IGMP Snooping on the switches to limit multicast to only the ports where there are interested clients. Then, on the router/controller, you enable an mDNS/Bonjour relay or an equivalent service, explicitly specifying which VLANs you want advertisements to be forwarded between (for example, between Default and IoT, or between Default and Homelab).

In UniFi, you may also need to create LAN-IN rules that allow the port and traffic type for mDNS, or adjust multicast profiles for each SSID. It's best to proceed cautiously: enable relay only between the segments that actually need to be connected and verify that no unnecessary information is leaking between networks you intended to isolate.

Some devices, like Sonos, don't handle VLANs well and can cause a lot of headaches even with relays technically configured. Many people end up leaving them on the default network (or a dedicated multimedia VLAN) and accepting that this part won't be as segmented in exchange for everything working without having to wrestle with the manufacturer's firmware.

Secure management: MFA, SSH with keys, and Zero Trust

Your firewall, Proxmox hosts, NAS devices, and management services are the keys to the kingdom. Leaving a root user with a simple password accessible from anywhere is not acceptable. The sensible approach is to create a dedicated administrator account for the firewall's web panel, disable direct root access , and always enable two-factor authentication (TOTP, for example, in OPNsense).

Furthermore, it's a very good idea to restrict access to these management consoles to only a specific IP address or subnet within the trusted devices VLAN (for example, your main desktop or laptop). This way, if someone manages to break into another network or compromise an IoT device, they won't have easy access to either the firewall panel or the hypervisor's management interface.

For SSH access to servers and VMs, it's best to completely disable password authentication and use only public keys . You can go further and implement a second factor with solutions like Duo: even if someone steals your private key, the login attempt generates an approval on your mobile device, and if you don't authorize it, the connection is rejected.

For remote access, the message is clear: stop opening direct ports (80, 443, 22, etc.) on your router. Instead, use Zero Trust solutions like Tailscale (a mesh VPN powered by WireGuard), Cloudflare Tunnel, or Twingate. These tools allow you to expose internal services in an authenticated and encrypted manner without having to publish your IP address or ports on the internet . Your web apps, dashboards, and SSH connections become accessible only after prior authentication and with robust access policies.

Harden containers, systems and services

Containers give a false sense of security: they are isolated, yes, but if you run everything in privileged mode, sharing write volumes everywhere and using unmaintained images, you end up just as exposed as with services installed directly on the host. The key is to use official or highly reputable images , update regularly, and avoid the `privileged` flag except in very specific cases.

Whenever possible, mount read-only volumes for static data, separate data configurations, and limit container capabilities to the bare minimum. Check Docker socket permissions and don't expose sensitive panels like Portainer directly to the internet; place them behind a secure reverse proxy with additional authentication, or protect them using Tailscale/Cloudflare Tunnel.

On base systems (Raspberry Pi, miniPCs, Linux VMs), basic hygiene applies: change default passwords, enable regular updates, disable unused services, configure UFW or an equivalent firewall with a default deny policy, and only allow access when necessary . For services that are frequently targeted, such as SSH, a Fail2Ban or modern tools like CrowdSec can help block brute-force attempts.

Regarding encrypted communications, serving anything in plain HTTP is no longer practical, even within the LAN. Reverse proxies like Caddy, Nginx Proxy Manager, or Traefik facilitate the use of TLS certificates (Let's Encrypt, etc.) and allow for adding an extra layer of authentication, rate limiting, security headers, and more, both for internal traffic and traffic passing through Zero Trust tunnels.

DNS, Pi-hole, and DoH “blacklist” blocking

A key aspect of privacy and network control is managing your own DNS. A redundantly deployed Pi-hole (or AdGuard Home) allows you to block ads, telemetry, and suspicious domains at the network level, without having to configure browser extensions on every device. However, you do need to set up a robust infrastructure that is difficult to disable and bypass.

Regarding DNS hardening, the idea is that all devices will exclusively query your Pi-hole servers and won't be able to freely access 1.1.1.1, 8.8.8.8, or public DNS-over-HTTPS addresses. For those who insist on ignoring DHCP DNS, you can create IP address pools containing the addresses of major public DNS and DoH providers (Cloudflare, Google, Quad9, etc.) and write firewall rules that allow DNS requests only if they originate from your Pi-hole servers and block them for all others.

In practice, group profiles like "Pi-hole Servers" and ports "DNS" and "TLS-DoH" are typically defined. Then, outbound rules are added that allow Pi-hole to communicate with the internet on those ports, and immediately below these rules prevent any attempt to use those same ports from other IP addresses on the LAN. This way, anyone trying to use their own DNS servers will lose resolution and "learn" to respect your configuration.

To make Pi-hole resilient, it's a good idea to host the instances on different devices (for example, one container on a NAS, another on Proxmox, and another on a Raspberry Pi with an SSD) and configure DHCP to assign multiple DNS IPs to clients. This way, if one node fails, you won't lose internet access, and the service will continue to function while you investigate the problem.

Zero Trust and remote access with Cloudflare Tunnel and Tailscale

Instead of opening direct bridges to your home, you can play with a very powerful combination: Cloudflare Zero Trust to expose selected web services (with identities, policies, and auditing) and Tailscale to access internal resources via mesh VPN as if you were on the LAN, but without touching the router's NAT.

Cloudflare Tunnel (with the cloudflare client running as a container or service) creates outbound tunnels from your network to Cloudflare's infrastructure. From there, you associate a subdomain with that tunnel and route HTTPS traffic to one or more services in your home lab. No one sees your home IP address or ports; they only see the domain protected by Cloudflare's layers, where you can enforce login, 2FA, geo-filters, and other features.

For traditional VPN access to the entire network or specific segments, Tailscale is fantastic. It installs with a simple script, registers each device in your "tailnet," and creates a private network based on WireGuard, with ACLs to determine which users can access which IP address and port. This way, you can restrict access, for example, to only your personal accounts, allowing them to access 192.168.1.10:22 (the hypervisor) or 10.10.40.100:3000 (your CI tool).

If you want to take it a step further, you can describe your entire Zero Trust configuration in Terraform using Cloudflare. This keeps your policy as code, allows you to make changes reproducibly, and enables version control in Git, just like any other infrastructure project. It's a very professional way to manage your home lab, even if it's just sitting in a closet in the hallway.

Cabling, lag, and typical performance issues

Logical hardening won't do much good if your physical network is a joke. Reusing old RJ11 jacks and old cable might be a temporary solution, but it's common to experience dropouts, CRC errors, or speed drops during network negotiation under heavy loads. Whenever you have the opportunity (construction, renovations, moving furniture), consider running high-quality CAT6 or CAT7 cabling and using patch panels with decent keystones.

When interconnecting rooms or cabinets with multiple switches, the backbone link is often a bottleneck. If you notice traffic between areas becoming saturated, consider grouping several physical links into a link aggregation (LAG), provided the switches support it. This increases available bandwidth and provides greater resilience against cable failure.

Physically documenting which port goes where, which VLAN ID is used on each segment, and how the native VLANs are configured will save you hours in the future. Label cables, annotate ports, and keep it synchronized with your logical VLAN diagram. A huge portion of network "mysteries" turn out to be a mislabeled port or an incorrect VLAN ID.

When something goes wrong (crazy latencies, expired TTL, repeated routes), use basic tools: traceroute from different points (client, router, modem), error counters on interfaces, packet captures on the firewall and, if your switch allows it, a port mirror to see which labels and MACs are actually circulating through a problematic link, and follow our guide to troubleshoot connection problems.

Homelab as a laboratory: Proxmox, lightweight Kubernetes, and key services

Once you have the network and security foundation established, the homelab becomes a brutal testing ground for practicing things very close to production environments: clusters with Proxmox, lightweight Kubernetes like k3s, NFS from NAS as shared storage, backups, high availability, etc.

Proxmox lets you orchestrate VMs and containers with a simple web interface, native clustering, snapshots, and built-in backups. You can mount an NFS from your NAS and use it as shared storage for virtual disks, backups, or ISOs. While latency won't be as fast as a local SSD, you gain the resilience of the NAS and the ease of managing backups, migrations, and quick restores.

On Proxmox, many people set up a small Kubernetes cluster with three Ubuntu LTS VMs for the control plane, adding components like kube-vip (high-availability virtual IP), Longhorn (distributed storage and automatic volume backups), ingress controllers like Traefik or Nginx, and observability tools (Prometheus, Grafana, Loki). This allows you to deploy homelab services on Kubernetes using Helm or manifests and version control with Git.

From there, the pieces that make the homelab truly "cool" arrive: Pi-hole for DNS and ad blocking; Home Assistant to integrate home automation, cameras and energy; Homebridge and Scrypted to integrate unsupported devices and cameras into HomeKit; Plex or similar for multimedia; and all of this hanging on your VLANs and your well-secured Zero Trust tunnels.

The result of combining segmentation, strict firewall, controlled DNS, secure remote access, monitoring, and backups is a home environment that closely resembles a modern enterprise infrastructure but on a home scale : with less noise, more visibility, fewer surprises when something goes down, and above all, the peace of mind that a failure in a cheap WiFi device shouldn't turn into a major drama.