Networking · Infrastructure · Don't Make Me Think
The Network Doesn't Need Me Anymore.
There's a moment every homelab builder eventually faces. You've spent weeks — maybe months — configuring, testing, debugging. The network works. The services are up. Everything is exactly where you want it.
And then you leave the house.
And someone calls you. "The internet is down." And you're twenty minutes away, and nothing you can say over the phone is going to make sense to the person standing in front of a blinking router.
That's the problem I set out to solve. Not just building a network that works — but building one that works without me.
A network that only you can operate isn't infrastructure. It's a dependency.
The Context
This isn't a home network. It's a small ecosystem.
The property covers roughly 1,200 m². A house, an office, storage, and several rented commercial spaces — two garages, a church, an upholstery shop, and an accounting office. Over 30 devices on the network at any given time. People working. Businesses operating. Payments being processed.
When the network goes down, it's not just an inconvenience. It's a disruption to everything running on top of it. Which means the pressure to fix it — fast — falls on whoever is physically present. Not always me.
That's why "it works when I'm here" was never an acceptable answer.
The Stack
Three machines. Each with a clear role and a label.
NUC, OPNsense, and the Bypass E900 — each labeled, each with a defined role.
The hardware
OPNsense on OptiPlex 780 SFF — the firewall and router. Everything passes through here. If this is down, there's no internet — period. Label: OPN.
NUC running Pi-hole + Cloudflare Tunnel — DNS filtering and the tunnel that exposes internal services. If this is down, DNS breaks and the tunnel goes offline. Label: NUC.
Linksys E900 — Bypass router — not normally on. This is the emergency fallback when everything else fails. It sits ready, cables pre-connected, labels on every port. Label: Bypass E900.
The Physical Design
The instructions are on the hardware itself.
This is where most homelab setups stop short. The configuration is solid, but the recovery process lives only in the builder's head. That's a single point of failure — and not a technical one.
My approach: if someone needs to connect a cable in an emergency, they shouldn't have to remember anything. The label tells them where to plug it. The color confirms it. There's nothing to look up.
Two cables. Two labels. No confusion.
Two cables live next to the E900, always. One labeled "ISP" — connects to the modem. One labeled "CASA" — connects to the house network. The E900 itself has matching labels directly on the ports, telling you exactly where each cable goes.
The label is on the port. The instruction is on the label. Nothing to remember.
That's the Don't Make Me Think principle applied to physical infrastructure. The system should be operable by someone who has never touched a router — because eventually, that person will need to operate it.
The Recovery Plan
Two versions. One for anyone. One for me.
The recovery plan exists in two forms. The first is for anyone in the house — no commands, no technical knowledge required. Five steps in a visual flowchart, ending with the bypass procedure if everything else fails. The second is for me — or eventually my son, who I'm training — with the full diagnostic sequence: OPNsense console, Pi-hole, Cloudflare tunnel, ISP check.
The flowchart below is the version anyone can follow.
The Real Test
It broke. And nobody called me.
The first real test wasn't planned. A power outage took down the NUC — not gracefully. The drive was mid-write when the power cut. SQLite flagged a corruption warning on next boot.
But the network came back on its own. OPNsense booted. The NUC booted. Pi-hole restarted inside Docker. Cloudflare Tunnel re-established the connection via systemd. Everything that needed to survive a hard shutdown did — because each service was configured to start automatically, not manually.
The only thing that required intervention was the SQLite warning — and that's on my list. Everything else recovered without a single command.
A resilient network isn't one that never fails. It's one that recovers on its own — or gives anyone in the house the tools to recover it.
The Point
Build it so it doesn't need you.
The goal was never to have the most advanced network. The goal was to have one that works — consistently, predictably, and without requiring me to be physically present to keep it running.
Labels on every cable. Labels on every port. Labels on every machine. A visual recovery plan anyone can follow. Services configured to restart themselves. A bypass router sitting ready for the worst case.
None of this is complicated. All of it matters.
If your network only works when you're there — it's not finished yet.
Questions about any part of this setup? Drop them below.
This post contains Amazon affiliate links. If you purchase through them, I may earn a small commission at no extra cost to you. Every product listed here is something I personally own and use daily.
0 comments:
Post a Comment