Homelab Rebuild Part 1: Where I Started

What this is about Link to heading

My home network grew the way most of them do: add a device, it works, stop thinking about it. Eventually everything hung off one box and lived in one subnet.

That works fine for a surprisingly long time. But at some point I wanted to do things the setup had no room for — separate devices from each other, push Wi-Fi clients automatically to where they belong, issue my own certificates. That needs a different foundation.

This series is the log of the rebuild. Not a polished tutorial, just what it actually was: decisions, dead ends, and a few moments where I locked myself out of my own network. I’m writing it down because this is exactly what I went looking for while building, and rarely found.

One thing up front, because it gets misread: what I’m building here isn’t a hobbyist network held together with hobbyist methods. These are the same pieces that sit in corporate networks — a dedicated firewall, VLANs, 802.1X with RADIUS, an internal PKI, virtualisation, infrastructure as code. More on that below.

How it started Link to heading

At the beginning there was exactly one device: a Banana Pi BPI-R4 running OpenWrt. Router, switch and access point in one. Behind it, one network, 192.168.1.0/24, gateway 192.168.1.1. No server, no virtualisation, no separation.

Internet comes in over Init7 fibre. That matters later, because their TV7 IPTV service runs over multicast — a detail that cost me an entire evening during the rebuild.

What was in there Link to heading

Work and storage

• Workstation (desktop, wired)
• Lenovo laptop
• Synology NAS
• Brother network printer

Mobile devices

• OnePlus 11
• OnePlus 3T
• iPhone X
• Nintendo Switch

Media and telephony

• Marantz Cinema 50 (AV receiver)
• HTPC running CoreELEC
• WLED controller on an ESP32 (QuinLED Dig-Uno)
• Yealink W70B (DECT base)

All in the same subnet. The printer could reach the NAS. The ESP32 running firmware I compiled myself could reach the workstation. The DECT base could reach everything.

What bothered me about it Link to heading

The obvious angle here is security, but I don’t want to make it bigger than it is. Nothing happened to me, and I live alone — there are no flatmates here with devices I don’t know about. The real problem is a different one:

I wouldn’t have noticed anything. A flat network has no place where traffic between two devices passes by. Two devices in the same subnet talk straight through the switch — the router never sees it. So if a device starts behaving oddly, I don’t find out.

And “I know my devices” is weaker than it sounds. I know the hardware. I don’t know every piece of firmware on it, and I definitely don’t know what that firmware phones home about.

Then the practical annoyances:

• The ESP32 is a tinkering board. Development builds land on it regularly. A device whose firmware I compile myself has no business sitting next to my backups.
• Guests. There was no way to hand someone Wi-Fi without handing them the whole network along with it.
• No margin while building. If the R4 is everything, then every change to the R4 is a change to everything. One typo takes out Wi-Fi, routing, DHCP and DNS all at once.
• A DECT base with no PBX. The W70B sat in the network as an island. What I actually wanted was a proper phone system with multiple trunks — and for that I first needed somewhere to run one.

The obvious fix that isn’t one Link to heading

Before the architecture, a wrong turn a lot of people take first: one SSID per device group. A “Trusted” network, an “IoT” one, a “Guest” one, each glued to a VLAN. Sounds simple, looks like it works at first — and doesn’t scale at all.

The reason is physical, not logical. Every SSID is a separate virtual access point as far as the radio is concerned. Each one sends its own beacons, roughly ten times a second, at the lowest basic rate — meaning as slowly as possible, and therefore hogging the channel for as long as possible. Each one also answers probe requests from anything passing by.

Airtime is a fixed budget everyone shares. Whatever the beacons eat isn’t available for actual data. With two SSIDs you won’t notice. With five or six you lose measurable throughput, and on a crowded 2.4 GHz channel it gets genuinely nasty. The rule of thumb from practice: no more than three SSIDs per radio band.

Then there’s the running cost. Every SSID needs its own credentials, every device has to be reconfigured when its assignment changes, and anyone who passes a password along moves the whole trust boundary with it.

Companies do it the other way round: one SSID, and the network decides per client. The device authenticates to a RADIUS server via 802.1X, and the server doesn’t just answer yes or no — it sends the VLAN assignment along with it. A phone lands in VLAN 20, a light controller in VLAN 41 — same SSID, same access point, and the device never knows. When the policy changes you change one entry on the RADIUS server, not twelve devices.

That’s what I’m rebuilding here.

Where I want to end up Link to heading

In one sentence: every device should see exactly as much network as its job requires — and not one metre more.

Concretely:

1. Split routing from switching. A dedicated firewall handles routing, DHCP, DNS and the rules. The R4 becomes a pure VLAN switch and access point. One device, one job.

2. Segment by trust, not by device type. No catch-all “IoT” VLAN that everything eventually gets dumped into. One VLAN per trust situation: whatever needs to see each other goes together, everything else doesn’t. My light controller and the HTPC have to talk, because the ambient lighting follows the picture. So they share a VLAN. The printer has no business in that conversation.

3. Automatic instead of by hand. One SSID, 802.1X, dynamic VLAN assignment via RADIUS. See above.

4. My own certificates. Internal services should do HTTPS without a browser warning. So: an internal CA that issues automatically over ACME — the same protocol Let’s Encrypt uses, just pointed inward.

5. All of it reproducible. In the end the configuration should live in code, not in my head.

The target picture Link to heading

Roughly:

• An OPNsense on dedicated hardware as router and central policy point
• The BPI-R4 behind it as VLAN switch and access point
• A Proxmox host for anything running as a VM or container
• VLAN 20 for trusted devices
• VLAN 30 for telephony
• A 40 series for everything untrusted, one VLAN per trust situation
• FreeRADIUS for 802.1X with dynamic VLAN assignment
• step-ca as an internal CA with ACME
• WireGuard for the road, so I don’t have to trust someone else’s Wi-Fi
• Central identity via Samba AD or UCS/Nubus, instead of keeping separate users in every service
• Mobile device management, so configuration and certificates don’t get carried onto each device by hand
• Visibility both ways: what’s happening inside my own network, and what’s knocking from outside

Why this is the same architecture companies build Link to heading

Looks like a lot for one flat. But it isn’t decoration and it isn’t a homelab quirk — it’s the standard shape of a corporate network, scaled down:

Same concepts, different vendor names. If you’ve got 802.1X with dynamic VLAN assignment working cleanly at home — including the devices that refuse to cooperate — you know exactly the obstacles that show up in a corporate network with three hundred endpoints. There’s just more riding on it there.

That’s also why I’m writing this up in detail: if you’re facing one of these problems at work, you’ll come away with a fairly good idea of how I work. How to reach me is on the about page.

How I’m going about it Link to heading

I’m not doing this in one go. The order is picked so that a working network exists after every single step.

The early parts are planned out; the later ones are intentions for now. Which tool I’ll use for MDM, which engine handles traffic analysis, whether it stays Samba AD or becomes UCS — I’ll decide that when I get there and know the constraints. Picking tools on spec and then forcing them into an architecture that has moved on since gets you nowhere.

What I will commit to: once each step gets concrete, I won’t just write down what I picked, but what I rejected and why. The reasons against are often more useful than the decision itself if you’re rebuilding this.

Two principles that showed up early and run through the whole series:

Always leave yourself a way back. I reflashed the R4’s SD card twice in a single day because I’d locked myself out. Since then every network change starts a timer that restores the previous config after 90 seconds unless I cancel it first. Details in part 2.

Only ever change one thing at a time. If three things are new and it doesn’t work, you know nothing. If one thing is new, you know everything.

Next up Link to heading

Part 2 covers hardware for the OPNsense box, and the question of how you rebuild a running network without taking it apart in the process.

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