Homelab Rebuild Part 4: Somewhere for Services to Live

Why at all Link to heading

After part 3 the OPNsense routes and the R4 is a switch and access point. What’s missing is somewhere for services to run. FreeRADIUS, an internal CA, a phone system — all of that needs a home.

The firewall isn’t it. A firewall should forward packets and enforce rules, nothing else. The more that runs alongside, the bigger the attack surface and the more unpleasant every update.

What I didn’t do Link to heading

The obvious option was already in the rack: Docker on the Synology. The NAS has 18 GB of RAM and runs anyway.

Two reasons against it, and the second one weighs more.

The obvious one: the CPU isn’t remotely up to it. NAS CPUs are built for file services and low power draw, not for running a dozen services in parallel. RAM alone doesn’t fix that.

The more important one: a NAS should be a NAS. That’s where my backups and my data live. Running a phone system with internet exposure on the same box puts two very different trust levels on one machine. That’s the same mistake as a flat network, one layer up.

Separating roles is cheaper than cleaning up afterwards.

The box Link to heading

A used Dell OptiPlex 3000 Micro: i5, 32 GB RAM, 500 GB NVMe plus a 1 TB SSD. 300 euros.

I spent a while hunting on classifieds and eBay, and it paid off. Used business mini PCs are hard to beat for a homelab: they come off lease in large numbers, they’re built for continuous operation, quiet, frugal and small. Buying 32 GB of RAM new currently costs almost as much as the entire machine used.

What you accept in return: no ECC, no remote management, limited expandability. For a homelab host that’s fine — unlike the firewall, where the missing remote management came back to bite me later.

Why Proxmox Link to heading

Bare metal with Docker would have been the leaner option. Against it: I wanted real isolation as an option, not just container isolation. More on why in a moment.

Proxmox gives me both in one interface — VMs via KVM and containers via LXC — plus snapshots, backups, and a web interface that still lets me reach a machine when its networking is broken. I’ve already missed that painfully once in this series.

It’s a single node, not a cluster. A Proxmox cluster sensibly wants three nodes for quorum. With two you get more complexity and less availability than with one — not worth it here.

Installation Link to heading

Unspectacular: ISO onto a stick, click through, done. I took the installer defaults — ext4 for the system, with an LVM-thin pool on top for the virtual disks. The second SSD is mounted separately as storage for images and bulk data.

The alternative would have been ZFS. That brings checksums against silent data corruption, compression, and replication to a second node. Except: I have one node and no redundancy — ZFS could detect an error but couldn’t repair it without a mirror. And my two disks aren’t mirror material, they’re too different for that. On top of which ZFS costs noticeable RAM that would otherwise go to the VMs.

Honestly, I didn’t think this through during installation, I just took the defaults. In hindsight I still think the decision holds. If you need checksums and replication, use ZFS — but then please with a mirror, otherwise there’s little point.

One thing needs doing by hand afterwards: Proxmox sets up the enterprise repository by default, which isn’t reachable without a subscription. It complains on every update. You swap in the no-subscription repository instead — same packages, just without the enterprise testing cycle in front.

And yes: the subscription reminder at login still nags anyway. I live with it.

VM or container Link to heading

This is the decision you make again with every new service, and I’ve settled on a clear rule.

LXC containers share the kernel with the host. That makes them light, fast and frugal — and it means a kernel vulnerability can turn a container escape into a host compromise. A VM has its own kernel. It costs more RAM and boots slower, but the separation is real.

My rule: anything that talks to the internet gets a VM. Anything purely internal gets a container.

In practice:

The phone system is the interesting case. A SIP server holds standing connections to providers on the internet and accepts data from them. If something goes wrong there, I don’t want a single kernel bug to be all that stands between the attacker and my virtualisation host. For FreeRADIUS the argument doesn’t apply — it only ever talks to my access point.

The networking part Link to heading

This is where Proxmox and the rest of the rebuild meet.

The host hangs off the R4 on a trunk — a port carrying several VLANs at once. For that to work, the bridge on the Proxmox host has to be VLAN-aware. It’s a checkbox in the network settings of vmbr0, and without it you can’t assign a VLAN to a VM at all.

With it set, the rest is pleasantly simple: the host itself stays in the default VLAN, and each individual virtual NIC gets its own tag. On the VM, under Hardware → Network Device → VLAN Tag, and that’s it. The VM lands in the desired VLAN without anything being configured inside the guest.

That lays the groundwork for everything that follows: a service can now sit in exactly the network it belongs in, rather than wherever the host happens to be.

A practical side effect that helps when debugging: Proxmox assigns its virtual NICs MAC addresses from its own range, starting with bc:24:11. In the firewall’s DHCP leases you can therefore tell at a glance which entries belong to virtual guests and which to real hardware.

What’s missing Link to heading

Backups. There are none.

That’s the biggest open gap in this setup, and I’m writing it down rather than quietly leaving it out. Proxmox ships a perfectly good backup mechanism, and a NAS with plenty of space sits two metres away. So there’s no excuse beyond the honest one: I haven’t done it yet.

Snapshots aren’t a substitute, by the way. They live on the same disk in the same box. If the host dies, they die with it.

I fix this in part 6 — before more services pile on top.

Next up Link to heading

The infrastructure is in place: a firewall that can enforce rules, and a host for services to run on. Time for the first VLAN of my own — and I’m deliberately starting with the smallest, most clearly bounded case: telephony.

Part of a series about rebuilding my home network. As of August 2026. Questions, corrections and your own experiences are welcome in the comments.