Building the Network Before Building the Homelab

In my earlier post, I shared how my homelab journey began and some of the lessons I learned along the way. Continuing from where I left off, I wanted to document how I planned and structured my network before getting started. A little preparation goes a long way, especially when you’re experimenting with new setups and want to avoid disrupting your existing network.

The Network Before the Network#

Proxmox was finally installed and running, and naturally, I was eager to start building things. But there was just one small problem: I needed a network plan first. The last thing I wanted was for my homelab experiment to turn into a household incident, with my better half asking the dreaded question: “Why is the internet not working?” 😅

So, before diving into anything else, I went back to the drawing board. The goal was simple: build and experiment with my homelab in its own isolated network, without touching the home network that was already working perfectly fine. After all, troubleshooting a complex network inside my homelab is one thing. Having to explain why the Wi-Fi is down at home? That’s an entirely different challenge! And trust me, I’d much rather deal with the former than the drama that comes with the latter. 😂

With that in mind, I started thinking about how to structure the network, keep things isolated, and give myself enough room to experiment without disrupting the household.

And that’s where things started getting interesting.

Starting With What I Had#

My Lenovo ThinkCentre M730q had one physical network interfaces (NICs), and I already had a managed router/switch with VLAN support. To keep my WAN and LAN physically isolated, I added a USB-to-LAN adapter to the setup.

Initially, I wanted to use the Mini PC as a pass-through between my router and monitor (a Dell 43” inch one with LAN port built-in), using the USB-to-Ethernet adapter for the second connection.

The idea looked something like this:

My monitor has a built-in Ethernet port and USB connectivity. I wanted anyone connecting their device through the monitor’s USB-A or USB-C connection to get ordinary internet access without worrying about VLANs or network configurations.

For my own devices, though, I wanted something more flexible: the ability to use the same connection while tagging VLANs whenever I needed access to additional networks (coming through my Proxmox homelab).

Simple for everyone else, flexible for me. That was the plan. 😎#

Then Came The Managed Switch#

As I explored the possibilities, I realized that introducing a managed switch would give me a much cleaner way to handle the network. Rather than trying to make the Mini PC do everything, I could use the switch to control how traffic entered Proxmox and which VLANs reached the monitor.

My revised design used four switch ports:

The important part was separating the everyday connection from the networks I wanted to experiment with. My spouse or another novice user could connect their PC through the monitor and get the usual internet connection. Meanwhile, I could configure my own PC’s network adapter to tag a VLAN when I needed access to a different network.

One physical connection, different possibilities. And hopefully, fewer household complaints. 😂😂😂

Understanding How Proxmox Sees The Network#

This was where I had to stop thinking of Proxmox as just another operating system and start understanding how it handles networking. Proxmox uses Linux networking underneath, including Linux bridges that connect physical network interfaces to virtual machines and containers.

For example, my physical NICs could be represented like this:

• eth0 — the first physical network interface
  • vmbr0 — the Linux bridge associated with the first interface
• eth1 — the second physical network interface
  • vmbr1 — the Linux bridge associated with the second interface

Think of a bridge as a virtual switch. Instead of connecting every VM or container to a physical network cable, I could connect them to a bridge and let Proxmox handle the virtual networking.

Physical NIC → Linux bridge → VM / LXC

That simple concept helped me understand how Proxmox connected the virtual world to the physical network. On a relate note: eth0 and eth1 are names that appeared on my setup (mostly the same for you). However, actual interface names vary, and a bridge isn’t necessarily a one-to-one match with a physical NIC.

And Where Do VLANs Fit In?#

Once I understood bridges, VLANs started making more sense. A VLAN (Virtual LAN) allows multiple logically separate networks to share the same physical infrastructure. A managed switch can carry those networks over a trunk connection, using VLAN tags to distinguish their traffic.

Proxmox can work with VLAN-aware bridges and VLAN-tagged interfaces, allowing VMs and containers to connect to the appropriate networks. For example, I might have:

• VLAN 100 - Management
• VLAN 200 - VMs and Containers/LXCs (within Proxmox)
• VLAN 300 - Public Apps

With a VLAN-aware bridge such as vmbr1, Proxmox can pass tagged traffic to VLAN-aware guests. It can also use VLAN sub-interfaces such as vmbr1.20 or vmbr1.30 when the proxmox host itself needs an interface on a particular VLAN. These are related but different approaches: a VLAN-aware bridge can carry multiple VLANs, while a VLAN sub-interface represents a particular VLAN on the host.

The key takeaway for me was that a single physical NIC could carry traffic for several networks without needing a separate cable for every VLAN. That was a big step forward in understanding the design.

VMs, LXC and More Things to Learn!#

While exploring Proxmox, I also came across two ways of running workloads: virtual machines and LXC containers. A Virtual Machine (VM) behaves like a separate computer, with its own virtual hardware and operating system. An LXC container is more lightweight. It provides an isolated environment for applications while sharing the underlying Linux kernel.

The simplest way I could remember the difference was:

• VM: “Give me my own system/setup with its own services and apps.”
• LXC: “Give me an isolated environment on the system itself to run this.”

Both can connect to Proxmox bridges and, when configured appropriately, use VLANs. I didn’t need to master everything immediately. I just needed to understand enough to make sensible decisions about how my homelab would grow.

Putting All Together#

At this point, the pieces were finally starting to fit together:

• The router provided the existing internet connection.
• The managed switch handled physical connectivity and VLAN membership.
• The two NICs on my MiniPC gave me separate physical paths for the WAN and LAN.
• Proxmox bridges connected the physical network to virtual machines and containers.
• VLANs gave me the flexibility to separate networks and experiment without putting everything on the same LAN.
• The hybrid switch port gave the monitor a convenient everyday connection while supporting the additional tagged VLANs I wanted to use.

The aim wasn’t to build an enterprise network in my spare time. It was to create something understandable, flexible and safe to experiment with.

And, most importantly, I wanted to avoid becoming the reason everyone at home suddenly lost their internet connection. 😅

At Last, a HomeLab Design That Can Evolve#

Looking back, this exercise taught me something important: installing Proxmox was only the beginning. The real learning started when I had to think about how everything would connect, how to keep the networks organized, and how to leave room for things I hadn’t even tried yet.

I’m sure I’ll revisit this design as my knowledge grows. That’s part of the fun of building a homelab: you don’t need to know everything on day one. You just need a plan, a little curiosity, and a willingness to break things — preferably without breaking the household internet. 😅

For now, the network design was taking shape. The next step was to start putting it to work.