Building My Proxmox Homelab: Network Design, VLANs, and Secure Remote Access

Note

This article describes my current homelab architecture and some of the improvements I’ve implemented. Your network and security requirements may differ, so treat this as a reference rather than a setup to copy blindly.

When I started my homelab journey, the plan was: get a tiny PC, install Proxmox VE, and start experimenting with a few services. Well, that didn’t last very long!

One service led to another, and before I knew it, I was looking at reverse proxies, virtualized firewalls, VLANs, remote access, and ways to expose selected applications without opening up my entire network to the internet. That’s the thing about technology. You start with a simple idea, and suddenly you’re spending your evenings figuring out why one VLAN can’t talk to another. And honestly, that’s part of the fun.

In my earlier posts, I covered the initial steps of building my homelab, starting with “First Steps with a Tiny PC”. I also explored Building the Network Before Building the Homelab, where I laid the networking foundation needed to bring the homelab to life.

This time, I want to show how I’ve put the network I designed earlier into action and how all the different components come together to form my homelab. Rather than diving into every configuration screen just yet, let’s take a step back and look at the bigger picture: the hardware, network design, VLANs, and how I access my services, both at home and remotely.

A quick look at my setup#

At the centre of everything is my Mini PC running Proxmox VE (Virtual Environment).

I’m using Proxmox to run a combination of virtual machines (VMs) and Linux containers (LXCs). Each runs a specific service, allowing me to keep things organized and experiment without needing a separate physical machine for everything. Here’s the architecture I’ve put together.

At a high level, the setup consists of:

• Proxmox VE: The host that runs my virtual machines and containers.
• pfSense: Handles DHCP, DNS, routing, firewall rules.. etc., within Proxmox.
• Caddy: Provides reverse-proxy access to my internal applications via FQDN (fully qualified domain name) + issuing SSL certificates.
  • More interesting technicalities on this will be covered in my next post.
• Cloudflare Tunnel: Makes selected applications accessible from the internet.
• Cloudflare Zero Trust: Adds access controls and security checks to protected public-facing applications.
• Tailscale: Lets me access my private network remotely limited to homelab network.
  • Will cover more about seperating clients using ACL in another post.
• Home Assistant: Handles home automation and smart IoT devices.
• SnapOtter and Glance: Applications I’m running for my own use.

Each component has a job to do. Proxmox provides the platform, pfSense manages the network, and the other services build on top of that foundation.

I could have put everything on a single network and called it a day. But since I’m already running a virtualisation platform, I figured I might as well use the opportunity to learn more about networking and security.

The Physical network: A Mini PC, two NICs, and a managed switch#

The physical setup is relatively simple. My home router provides the internet connection, and a six-port managed switch connects the router, my Mini PC, and the other devices in the network.

The Mini PC has two network interfaces, and I’ve given each a different responsibility. The first NIC is dedicated to the WAN-side connection for pfSense (via Proxmox bridge). The second carries the VLANs used by my homelab. This means I don’t need a separate physical network interface for every network. Multiple VLANs can travel over the second connection, while Proxmox and pfSense handle the logical separation.

I have explained in detail the ports, vlans and port types in my previous post “Building the Network before building the homelab”.

There’s also a security consideration with my current design. Since VLAN 1 is used for the WAN-side connection, untagged devices on that VLAN share the same Layer 2 segment as the WAN interface. That means the port shouldn’t be treated as an isolated guest network. If I want stronger separation for guest devices, a dedicated guest VLAN with appropriate firewall rules would be a better approach.

For now, the main idea is to make the physical network flexible enough for everyday use while keeping the homelab networks logically organized.

Why I’m using VLANs#

VLANs are probably one of the more important parts of this setup. Rather than putting everything on the same network, I’ve separated my infrastructure, applications, and IoT devices into different logical networks. Here’s the current arrangement.

The reasoning is straightforward. I don’t want my management interfaces sitting on the same network as every application I run. Likewise, I don’t want every IoT device to have unrestricted access to my other services. Separating the networks gives me more control over how devices communicate.

Of course, VLANs alone don’t provide complete security. They establish logical network boundaries, but firewall rules determine which traffic is allowed to cross those boundaries. That’s where pfSense comes in.

Summary of my VLANs#

1. VLAN 100 - Keeping management separate: VLAN 100 is dedicated to management. This is where I keep the management interfaces for Proxmox, my switch, and other infrastructure components. The idea is to avoid making these interfaces directly accessible from every network in my home. It also works nicely with Tailscale, which I’ll get to shortly.

2. VLAN 200 - Where the applications live: VLAN 200 is my main homelab services network. This is where I’ve deployed most of my current applications, including: Caddy, Cloudflare-Tunnel, Tailscale, Home Assistant.. etc. Keeping these services together simplifies communication between them.

3. VLAN 250 - Keeping IoT devices isolated: Home Assistant is running as a VM on VLAN 200, while my IoT devices sit on VLAN 250. I’ve separated them because I don’t want every smart device in the house sharing a network with my other homelab services. The goal is to allow Home Assistant to do its job without giving IoT devices unrestricted access to the rest of the network.

4. VLAN 300 - For future use: At the moment, VLAN 300 is reserved rather than actively used. My current public-facing applications run on VLAN 200, and my idea was use this VLAN for any publicly accessible apps/lxcs/vms until I realized a more simpler way with Cloudflare tunnels, and routing requests to them through the tunnel.

pfSense (Virtual Firewall): My Homelab’s Real MVP#

Every homelab needs a security guard, and mine happens to work 24/7 without coffee breaks or asking for a salary. Meet pfSense, the virtualized firewall that decides who gets in, who gets out, and who gets kicked to the curb! 😎

pfSense acts as the gateway for my internal VLANs, handles routing between them, and applies the firewall rules that control their communication. It also provides internal DNS for my setup. For example, my IoT network needs to communicate with Home Assistant for the functionality I’ve configured, but that doesn’t mean it should have unrestricted access to my management network. With pfSense, I can create rules that permit the traffic I need while restricting everything else.

This is also useful when troubleshooting. If a service on one VLAN cannot reach another, I can investigate the routing and firewall rules rather than immediately assuming that the application itself is broken. And running pfSense as a VM does come with a trade-off, though. If Proxmox goes down, my virtualized firewall goes down with it.

For now, I’m happy with this setup. Running pfSense as a VM gives me the flexibility I want for my homelab, but the dependency on Proxmox is something I’ll need to keep in mind as the setup evolves.

Bringing everything together#

Looking at the architecture as a whole, each component has a clear role. Proxmox provides the platform. pfSense handles routing and firewall rules. Rest of the applications do what their meant to do while establishing the required controls.

Meanwhile, the VLANs help separate management, applications, and IoT devices. It’s not the most complicated homelab in the world, but it has reached the point where I can experiment with different services without having to rethink the entire network every time. That’s what I wanted from the beginning: a flexible environment where I can run things, learn how they work, and gradually improve the setup. And I’m nowhere near finished.

In my next post, I’ll look more closely at the applications running inside the homelab, what each one brings to the table, and how I plan to expand the setup with more automation.

Because if there’s one thing I’ve learnt from this project, it’s that once the foundation is in place, the possibilities are pretty much endless. And, naturally, I’ve already got another idea in mind.