Home Lab VLAN Segmentation - Architecture Overview

This article covers how I replaced a flat, consumer-grade network with a secure, highly segmented one. The bulk of the bare-metal architecture consisted of a recycled desktop running OPNsense and a managed switch. This was one of the first major infrastructure projects in the lab and is the foundation upon which every new project is built.

Introduction

About a year ago, when I decided to pursue cybersecurity professionally, I started seeing a lot more videos about homelab setups. Working in IT, I am lucky to frequently receive decommissioned equipment my company is retiring. When my company moved out of their previous office, a lot of the tech our department had been hoarding needed to be disposed of. This allowed me the opportunity to take several old Dell OptiPlex desktops... great machines. Purely functional, easily maintained, and small. Along with some switches. Primarily some older but functional Cisco Business Switches. These two pieces of hardware would be the final push of the ledge, plunging me into the spiral down the rabbit hole that is homelabbing.

The Hardware

The Dell OptiPlex is ultimately what became LAB-FW. The hardware was left almost exactly as it was from the factory. The only modification I made was to remove an 8 GB RAM stick from another OptiPlex and add it to the LAB-FW machine. The OPNsense router in my current configuration is very lightweight. Even while handling all of my Layer 3 traffic, DHCP, DNS Forwarding, and firewall policy. I have yet to find its limit... yet.

The switch is a Cisco SG250-28P. It is a managed Layer 2 Switch. It handles switching and tagging; OPNsense handles the routing. That is an important distinction and one I did not fully understand when I initially started trying to configure these devices. This project greatly aided my understanding of exactly what happened at the lower levels of the OSI model.

Starting Point - The Flat Network

When this network was initially created, it was a single subnet. All traffic transited across the default 192.168.1.0/24 subnet. Every device shared the same address space; every port on the VLAN was untagged VLAN 1. There were no firewall rules in place. The LAN interface was configured to assign a device an IP address in the range specified above. The LAN had a blanket ALLOW ALL rule permitting all LAN traffic through the WAN interface.

With this configuration, I reached a point of basic connectivity rivaled in functionality only by every $30 home router on Amazon, but not in capability.

I already knew that I would ultimately require more. Especially considering that my entire home lab project has always been approached with the primary goal of developing my understanding of security and networking principles through trial and error.

The First Attempt - and the Lockouts

The jump from a flat network to a VLAN-segmented network initially sounds like a straightforward prospect. However, in practice, it quickly fell into a predictable and mind-numbingly redundant pattern. The flow is as follows: attempt to set tags on a port, lose access to the switch, reset to factory defaults, start over. An important note I have neglected to mention thus far is that the Cisco SG250-28P in this specific configuration did not include a console port. I have a console cable and a serial cable. Neither was of any use to me.

As previously mentioned, the mechanism causing my failures was port tagging on the switch. In my initial attempts, I tried to bite off more than I could chew. I attempted to create all the VLANs I had imagined. Roughly the same number I have now. However, trying to tag 5 VLANs and plan for future expansion without just confirming basic connectivity was continuously complicating the situation. Realizing this was not feasible, I settled on focusing on the VLAN for wired user devices and the management subnet VLAN. Since the switch is a management device, ensuring that my management host can maintain a stable connection to it would allow me to pivot to the other VLANs without causing a lockout. This, along with slowing down to go port by port rather than making bulk changes, maintained fallback ports unaffected by my configuration changes, preventing a total lockout and reset.

I recall distinctly a very simple but fundamental idea became clear to me during this process. The endpoint sending a packet through its associated switch port might not even know its VLAN ID. It is not until the frame hits the port with an assigned PVID that the switch internally classifies the traffic as associated with a specific VLAN. When the traffic is routed through the trunk port to OPNsense, the switch inserts the 802.1Q VLAN tag. The endpoint might never have known which tag the frame it sent would end up with.

The VLAN Architecture

Once that tagging behavior made sense, building out the VLAN structure was more methodical rather than constant trial and error. As mentioned, I initially targeted two VLANs: a management segment for infrastructure access and a user segment for trusted wired devices. Everything else stayed on the default subnet temporarily until the core segmentation was stable.

From there, VLANs were added incrementally as I spun up services that demanded them. Deploying my database required configuring a VLAN specifically for databases. Admin infrastructure, such as DNS, PKI, and ID management, required a separate subnet to keep those services isolated from other user traffic. Wi-Fi traffic is also distinguished from the general wired user traffic. This traffic is heavily regulated and isolated from anything else on the network.

The current VLAN layout reflects about a year of incremental expansion:

Each VLAN has its own DHCP scope, its own gateway address on OPNsense, and its own firewall policies. Nothing shares a scope across segments.

OPNsense VLAN Configuration

We have thus far focused heavily on the steps for VLAN segmentation that occur at Layer 2. This is only half of the question. At Layer 3, we encounter the other half: where is this traffic going, and more importantly, is it allowed to go there? Additionally, at this level, we will configure DHCP policies to specify IP ranges for many devices on the network.

The physical interface on LAB-FW connects to the switch and carries all VLAN traffic via a TRUNK port. OPNsense sees this as a single physical interface with multiple VLAN sub-interfaces defined on top of it. Every sub-interface is assigned to a named interface in OPNsense. This includes a static IP (the gateway for that VLAN's subnet), a DHCP server scope, and its own firewall rule set.

This last item is critical as OPNsense firewall rules are per interface. A rule on the interface governing wired devices only affects that interface. DMZ rules only affect the DMZ interface and its associated VLAN. Inter-VLAN routing occurs automatically because OPNsense already knows the routes. However, simply knowing how to reach the management VLAN from the wired device VLAN does not mean it should be permitted. That permission is granted or denied via firewall rules.

Routing vs Firewalling

This distinction truly deserves its own section because it is a common point of confusion when building a segmented network for the first time, and understanding it is what ties the disparate branches together so the architecture makes sense.

Routing has the sole objective of answering the question: do I know how to get there?

Firewalling answers a different question entirely: am I allowed to go there?

OPNsense performs both functions on LAB-FW. It handles all inter-VLAN routing; every packet crossing a segment boundary passes through it. Additionally, because it also enforces firewall policy at the same checkpoint, it can permit or deny that traffic before it ever arrives at its destination. For this reason, the OPNsense firewall can be described as both my Policy Engine (PE) and, subsequently, the Policy Decision Point (PDP). A default-deny posture for inter-VLAN traffic means that even though OPNsense has a route to every VLAN on the network, nothing crosses a segment boundary unless a firewall rule explicitly allows it. That is the model this lab runs on.

This is also why the firewall rule design is covered separately in its own post rather than here. The VLAN architecture establishes the segments. The firewall rules determine what those segments are actually allowed to do with each other. The two topics are related but distinct, and conflating them is what leads to networks that are segmented on paper but permissive in practice.

A Note on the Importance of Documentation

I would like to close this post with a brief discussion on a topic that is not about networking at all.

This project happened about a year and a half ago. Writing this post required reconstructing decisions from memory. This necessitated piecing together what I configured, what failed repeatedly, and what the specific moments of understanding felt like when things finally clicked.

At that time, there was no lab journal. There was no portfolio site. There was no structured habit of writing down what was being built and why.

That gap is part of why this site exists. Every entry is written here in real time while the configuration is fresh and the reasoning is still clear. Most importantly, the mistakes are still stuck in my mind. The small lightbulb moments often get lost after pivoting away from the completed project. However, I believe these small moments are what people truly want to hear about when discussing lab projects. Everybody willing to listen to someone ramble on about their home lab probably knows the broad strokes. They know what a firewall does and why a VLAN should be segmented; it's Network+ level knowledge. But when the rubber meets the road and the theoretical is put into practice, things don't work the way you expect; timelines shift, and it molds your understanding of the scope of the work.

My note to anyone building a lab and not documenting it as they go: start now. Not simply because you need it for your portfolio, but because you will desperately want to access that knowledge months and years down the road. Additionally, as AI becomes more intertwined in every project, the context provided by this documentation will become invaluable.