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, home automation, etc.) and everything is connected on the same network, your house is, digitally speaking, a open field for lateral movements and silly attacksYou don't have to be a big company to have your ports scanned and your network compromised. weak password or an IoT device is exposed to a security flaw.

The idea behind this article is to help you set up, step by step and thoughtfully, a segmented home network with VLANs, firewall, and good hardening practices, so that your home services work just as well, but with Much more control, fewer scares, and a significantly smaller attack surface.We're going to combine the best of several approaches: pfSense/OPNsense, UniFi, Zero Trust (Tailscale, Cloudflare Tunnel), Proxmox, Lightweight Kubernetes, Pi-hole, Home Assistant, etc.

Why your homelab needs segmentation and hardening now

In a classic "flat" network, like 192.168.1.0/24 with everything crammed in there, 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, the attacker can try to jump to your NASyour personal PC, the Proxmox hypervisor, or the server where you store backupsIt doesn't take a very sophisticated attack; a firmware flaw 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, provides too much information about the network. What do you have, what ports do you use, and what services run on your LAN?VLAN segmentation addresses precisely that 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, tunneled applications), unreliable devices (IoT, guests, kids' consoles), and your personal equipment. Each group should be in its own "lane" and only be able to communicate with others via [unclear - possibly "network" or "network"]. very specific and 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 2It's common to associate 1 VLAN with 1 IP subnet, but they are actually distinct concepts. A VLAN defines how Ethernet frames are separated; a subnet defines how traffic is routed at Layer 3. The important thing for you is that devices on one VLAN cannot see broadcasts from another, and they can only communicate with each other if a router or firewall is involved.

Separation is achieved using 802.1Q labels (VID, from 1 to 4095) that switches insert into the packets. A port can work in two basic ways: as access port (access), where traffic enters/exits untagged and all belongs to a single VLAN, or as main port (trunk), where a single cable carries several tagged VLANs at once to a router, another switch, an AP 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, etc. 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 type vmbr0 + 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 sheet with the ranges, names and purposesFor 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 SSID. firewall and access policies that you have 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 is whether the device only performs Layer 2 switching, or if it also does Layer 2 switching. Layer 3 routing at line speedMany "budget" switches can tag and forward frames at high speed, but when you ask them to rotate traffic between VLANs they route it to the CPU and drop 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 might be worthwhile. hardware routing offloadBut 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 homelab services host accessible from Default and IoT without installing strange contraptions 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 conflicts. unlabeled 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 for each interface you assign an IP address, DHCP range, DNS, description, and, most importantly, their independent firewall rulesThese interface rules are the 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 necessaryThat 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 what can access the DMZ or certain sensitive servers. On Guests, however, it's normal to block all access to private ranks and maintain only internet access. If the access point supports client isolation, activate it so that your visitors' mobile devices cannot 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 like “HomelabHost → IP_IoT:port” followed by a general IoT blocking towards 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 switches to limit multicast to only the ports where there are interested clients. Then, on the router/controller, you enable a mDNS/Bonjour relay or an equivalent service, explicitly stating which VLANs you want advertisements forwarded between (e.g., 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, your 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 root shortcut and always activate 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 keysYou can go further and add a second factor with solutions like Duo: even if someone steals your private key, the login attempt generates an approval on your mobile 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…) on your router. Instead, rely on 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 or ports on the InternetYour web apps, dashboards, and SSH will only be accessible after prior authentication and fine-grained 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 imagesUpdate 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), apply basic hygiene: change default passwords, enable regular updates, disable unused services, and configure UFW or equivalent firewalls with a policy of Deny by default and open only what is necessaryFor heavily attacked services like SSH, a Fail2Ban or modern tools like CrowdSec help to 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 point for privacy and control of your network is managing your own DNS. A redundantly deployed Pi-hole (or AdGuard Home) allows you to block advertising, telemetry, and suspicious domains at the network level, without having to configure browser extensions on every device. However, you do need to set up the necessary infrastructure. difficult to knock down and difficult to jump over.

Regarding DNS hardening, the idea is that all devices query only your Pi-hole servers and cannot 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 groups 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 come from your Pi-hole and block them for everyone else..

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 point HTTPS traffic to one or more services in your homelab. No one sees your home IP address or ports; they only see the domain protected by Cloudflare's layers, where you can Requiring login, 2FA, geographic filters, and other niceties.

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, furniture changes), consider Use quality CAT6 or CAT7 cabling and use 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 VID 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 part of network "mysteries" end up being solved. mislabeled port or incorrect PVID.

When something goes wrong (crazy latencies, expired TTL, repeated routes), use basic tools: traceroute from different points (client, router, modem), interface error counters, firewall packet captures, and, if your switch allows it, port mirroring to see which labels and MACs are actually circulating through a problematic link, and follow our guide to troubleshooting 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 ease of management. Fast backups, migrations, and 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, a strict firewall, controlled DNS, secure remote access, monitoring, and backups is a home environment that closely resembles a modern company infrastructure but on a home scaleWith less noise, more visibility, fewer surprises when something falls, and above all, the peace of mind that a failure in a cheap WiFi device shouldn't turn into a major drama.