Networking · Infrastructure · Monitoring

Beyond the Internet — Watching the Network.

When I first started building my homelab, I wasn't trying to create a lab at all.

I was simply solving a problem for myself. Normally, I build things because a client asks for them. This time, I was the client. Well — the direct client, not the final one.

One service became two. Two became five. Then ten. Before I realized it, the homelab had grown into something that other people relied on every day.

And that changed everything about how I needed to think about it.

Sometimes the internet isn't the problem. Sometimes the network still has work to do — and nobody knows it until someone notices that the photos aren't syncing.

The Problem

The network might still appear online while something important is broken.

A while ago, I created a simple troubleshooting guide so anyone in the house could recover the internet if it went down. That solved one problem.

But the network is much more than internet access now. Today the homelab runs photo storage, a music server, a DNS filter, a firewall, a Cloudflare Tunnel, a service launcher, and an external management system for a client. Each of these services can fail independently — and when one does, the network might still appear "online" while an important part of it is actually broken.

That's when I realized I didn't need another troubleshooting guide. I needed visibility.

The Solution

One screen. Five services. Green or red.

I wanted anyone to be able to glance at a screen and immediately know whether everything was healthy, what service was down, and whether something needed attention. No commands. No SSH. No digging through logs.

Uptime Kuma — a self-hosted monitoring tool — runs in Docker on the NUC. It checks each service every 60 seconds and shows a simple status: up or down. That's all anyone needs to see.

Uptime Kuma — 5 services monitored, all green.

Monitored services

🔥 Firewall — OPNsense · 192.168.2.1
🛡️ DNS — Pi-hole · dns.home:8080
📷 Fotos — Immich · fotos.home:2283
🎵 Music — Navidrome · music.home:4533
🔧 Taller — taller.creativelydifferentbuilds.com

The Physical Dashboard

A repurposed Samsung A51 — always on, always visible.

The monitor lives on a Samsung A51 running Fully Kiosk Browser in kiosk mode — screen always on, always showing the status of every service. It connects to Uptime Kuma over the local network at monitor.home:3001.

The goal is simple: anyone in the house — whether they understand the technical details or not — can glance at the screen and know if something needs attention. Green means everything is working. Red means something needs a look.

Samsung A51 repurposed as a physical dashboard — always on, always visible.

The Launcher

Access for the family — no technical knowledge required.

Alongside the monitor, the service launcher now includes a card for Uptime Kuma. Anyone in the house opens servicios.home:8888 from any device — phone, tablet, or PC — and has direct access to every available service. No IP addresses. No ports to remember. Just names.

The Monitor card is now in the launcher — accessible from any device on the network.

What's Next

The list keeps growing — and that's the point.

As more services come online — home automation, security cameras, a local AI assistant, a family photo album, a music library — each one gets a card in the launcher and a monitor in Uptime Kuma. The infrastructure grows, but the experience stays simple.

Eventually, I'd like to build a guest access system — a QR code menu with curated services for visitors. A pre-selected family photo album. A shared music library. Maybe a local AI assistant. Content that's safe to share, easy to access, and requires nothing more than scanning a code.

That's still an idea. But the infrastructure to support it is already here.

Quick Setup Guide

Get Uptime Kuma running in under 5 minutes.

Requirements: Docker installed on any always-on machine

1. Run the container

docker run -d \
  --name uptime-kuma \
  --restart unless-stopped \
  -p 3001:3001 \
  -v uptime-kuma:/app/data \
  louislam/uptime-kuma:1

2. Open the dashboard

Go to http://[your-server-ip]:3001 and create your admin account.

3. Add a monitor

Click + Add New Monitor → Type: HTTP(s) → enter the URL of your service → set interval to 60 seconds → Save. If the service uses a self-signed certificate, enable Ignore TLS/SSL error.

4. Add a local DNS record (optional)

In Pi-hole → Local DNS Records → add monitor.home pointing to your server IP. Now anyone on the network can open it by name.

There are many detailed guides out there for setting up Uptime Kuma — this is just the version that worked for me. If you run into something specific or need help getting it running in your setup, drop a comment below.

Real World Update

The internet was working. The photo service wasn't.

This is exactly why I built this. The internet was up. The network was running. But Immich — the photo service — went down, and the monitor caught it immediately with a timestamp.

The reason: photos don't have a permanent server yet. Immich runs on my main workstation, and when I shut it down for the night, the service goes with it. That's a known limitation — one that will be resolved when the services move to a dedicated always-on machine. For now, the monitor makes that limitation visible instead of invisible.

As soon as the workstation came back online, Immich recovered automatically. The monitor logged the downtime, the duration, and the recovery — without me having to check anything manually.

Immich down at 22:43 — timeout of 48000ms. Back up at 22:44 when the workstation came online. The monitor is in Spanish because my wife and kids are native Spanish speakers — the system should work for everyone in the house.

That's the point of visibility. Not to prevent every failure — but to know exactly when it happened, how long it lasted, and when it recovered. Without asking me.

The Honest State

It works perfectly. It looks like a work in progress.

Right now, the A51 is literally thrown on my desk — and it looks exactly like that. Next to the Fire Tablet running MacroDeck, the setup works perfectly but doesn't look intentional. Because it isn't yet.

"If a cluttered desk is a sign of a cluttered mind, of what, then, is an empty desk a sign of?"

— Albert Einstein

I've read that quote many times. And I agree with it — I don't want an empty desk. I want one that looks organized and functional. One that doesn't make a visitor wonder what happened here.

The plan is to mount both the A51 and the Fire Tablet on the wall with permanent connections to the PC. Everything within reach, nothing in the way. The desk stays as the workspace — the wall becomes the command surface.

That's the next project. Unless my mind takes a different route first — which, if you've read this blog, you already know is a real possibility.

The Point

A well-monitored network is one that anyone can trust.

The internet might be fine. But the network has more work to do. And now, anyone in the house can see exactly how it's doing — without asking me.

Green means everything is working. That's all anyone needs to know.

What are you monitoring in your homelab? Drop it 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.

Read More

Networking · Infrastructure · Design

If It Only Works for Me, It Doesn't Work.

When I started this blog, it was simply an excuse to write.

A place to document ideas, experiments, and the occasional lesson learned after breaking something.

My homelab started the same way. It began as a technical challenge. I wanted more control over my own infrastructure. More privacy. More ownership over the services I used every day.

At first, everything was built for one person. Me. I knew every IP address. Every port. Every password. Every service had its own bookmark, its own shortcut, its own way of being accessed.

That worked — but only for me.

If every new application requires me to explain "go to this IP address, on this port" — I haven't built a useful system. I've built a puzzle.

The Realization

This infrastructure isn't just mine.

My wife uses it. My children use it. Guests will eventually use parts of it. And hopefully, years from now, they'll use services I haven't even deployed yet.

If every new application requires me to explain "go to this IP address, on this port, using this browser" — then I haven't built a useful system. I've built a puzzle.

Don't Make Me Think

The best systems don't ask users to remember.

One idea has been influencing my thinking for years: Don't Make Me Think. Steve Krug wrote about it in the context of web design, but I believe the principle applies almost everywhere. The best systems don't ask users to remember. They don't require explanations. They simply make the right thing obvious.

I realized my homelab deserved the same treatment.

The Solution

Names instead of numbers.

Instead of asking people to remember addresses like 192.168.2.114:8080 or 192.168.2.20:2283, I configured local DNS records in Pi-hole so every service now has a name:

Local DNS records

firewall.home
dns.home
nas.home
fotos.home
music.home
servicios.home

Pi-hole Local DNS — 6 registros activos, nombres en vez de IPs.

Nobody has to remember where a service lives. Only what it does.

The Launcher

A starting point for everyone in the house.

I built a launcher that lives on any device in the house — a simple page that shows only what's relevant to each person. Not because they need access to everything. Quite the opposite.

The goal isn't to expose every service. The goal is to make the available ones effortless to find. No documentation. No explanations. No technical knowledge required.

It runs on the NUC — the machine that's always on — served by a simple Nginx container. Any device on the network opens servicios.home:8888 and sees it immediately.

Servicios activos y planificados — cada uno con nombre, no con IP.

El launcher abierto en el Pixel — accesible desde cualquier dispositivo en la red.

The Philosophy

This may seem like a small change. Philosophically, it changes everything.

The infrastructure stops feeling like a collection of servers and starts feeling like a product. One designed for people instead of administrators.

Eventually I want to add much more — a local AI assistant, a family wiki, a digital library, internal tools, automation. The list keeps growing. But I've learned something important: every new service should become easier to discover, not harder. Adding functionality should never increase complexity.

External access is a completely different problem. That requires authentication, permissions, reverse proxies, VPNs, and much stricter security. I'll write about that separately.

Inside my network, my philosophy is simple: if someone has permission to use a service, they shouldn't have to think about how to reach it. They should simply open it.

The Point

A well-designed system disappears.

The funny thing is that this has very little to do with servers. It's really about design. A well-designed system disappears. People stop thinking about how to use it and simply use it.

That's the kind of infrastructure I want to build. Not one that impresses me. One that quietly works for everyone else.

If someone has permission to use a service, they shouldn't have to think about how to reach it. They should simply open it.

How do you handle service discovery in your homelab? Drop it 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.

Read More

Don't Make Me Think — Network Edition

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.

Recovery flowchart — no commands version

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.

Read More

Parenting · Gaming · Local Multiplayer

I Gave My Son Access to Gaming. Not to the Internet.

I've been close to video games for as long as I can remember.

I didn't start early — I was around ten when I first played. But from that moment, something clicked. Not an escape from reality, not at that age. More like a door that opened to a different way of thinking.

Strategy games taught me to think several steps ahead. Role-playing games taught me patience and decision-making. Puzzle games rewired how I approach problems. Every genre had something to offer — not just entertainment, but a way of training the mind without it feeling like training.

I carried that with me. And now that I'm a father, I see those benefits clearly. I've watched what games did for me, and I want that for my kids.

But the game has changed. Literally.

Everything became online. Everything became free-to-play. And with that shift came something nobody warned us about: the internet brought the whole world into the room with your child.

Today's multiplayer games are designed to capture attention indefinitely. They're built around engagement loops, microtransactions, and social pressure. And beyond the design — there's the environment. The toxicity. The strangers. The people your child assumes are other kids their age, because why wouldn't they be?

That assumption is exactly where the danger lives.

I know this firsthand. Not as a theory. I've lived the consequences of what happens when a child connects to the wrong person online — and I had to involve the police to resolve it. I won't go into details. But that experience changed how I think about internet access for my kids permanently.

Roblox is blocked in my home at every level — DNS and firewall rules combined. That's not a random decision. It came from a real incident, with real consequences, that I will not let repeat itself.

The Infrastructure Side

Having your own infrastructure changes everything.

I have a firewall. I have a DNS resolver I control. I have the ability to segment devices, set rules by MAC address, and define exactly what any device on this network can and cannot reach.

His computer is on the network. But it's not on the same network as everyone else. He has access to what I know is safe for him. What he doesn't have is an open door to the internet at large — unfiltered, unmonitored, unrestricted.

How it works technically

His device is assigned to a separate network segment via OPNsense. Pi-hole handles DNS filtering at the network level — specific platforms are blocked at every entry point, DNS and firewall rules combined. No workaround from the device side is possible without going through the firewall first.

The games he plays run locally — no cloud dependency, no account required, no server in another country deciding what content he sees. Everything stays inside the network I control.

And inside those boundaries, I've given him more freedom than most kids his age have.

The Games

He plays modern games. Games his friends are playing.

I watch him play Subnautica and I see something I didn't expect. He doesn't just explore. He manages tension. The game generates a specific kind of fear — the deep ocean, the unknown, something just out of sight — and instead of shutting down, he builds. He creates bases, he plans routes, he finds ways to protect himself from things he hasn't encountered yet.

Then I watch him play Hollow Knight. That game asks something different from him. It asks him to remember. Routes. Events. Techniques. It asks him to fail, repeatedly, against the same boss — and to come back each time with a slightly better understanding of what went wrong. That's not just gaming. That's a feedback loop that most adults struggle to maintain in real life.

And then there's Minecraft. Where he builds things that exist only in his mind first, and then in the game. No instructions. No blueprint. Just imagination and patience.

Every time he beats a difficult boss — every time he earns something through effort and repetition — he learns something that no participation trophy ever taught anyone: that results require work. That dedication has a payoff.

The Session

Four kids. One screen. Four controllers. No internet required.

I organized a gaming session with his friends at home. Kids from school. Kids he actually knows, kids whose parents I know. No online strangers. No headsets talking to accounts from other countries. Just kids in the same room, in front of the same screen.

Four Xbox controllers connected via USB to the PC. One TV. All four playing together.

Same room. Same screen. Real people.

The game library for the session: Brawlhalla, Street Fighter V, Scott Pilgrim vs The World, and Marvel Cosmic Invasion. The competitive options were available — but they chose to prioritize games where all four could play together at the same time. That decision was intuitive and social, not technical. Nobody sat out. Nobody watched while the others played.

They laughed. They argued. They ran around the room between rounds. They came back and played more.

What they played

Screenshots are shown to give you a sense of each game — not photos from the session itself. I was too busy making sure they had a good time to stop and document everything.

Street Fighter V

Competitive. Face to face. The classic of "you vs me on the same couch."

Scott Pilgrim vs The World

Beat 'em up cooperative — all four moving toward the same goal. Nobody left out.

Brawlhalla

Platform fighter. Up to 4 players. Chaotic, fast, and loud.

Marvel Cosmic Invasion

Cooperative beat 'em up. Marvel characters, same couch, same mission.

I was there the whole time. Not hovering — present. Watching. I didn't take more photos because I was busy living the moment and monitoring the session. That's a different kind of supervision than a parental control app. I know what they played. I know what they saw. I know what they experienced together.

That bond — the gestures, the expressions, the laughter in the same room — is something no online game can replicate. A headset and a chat window is not the same as sitting next to someone and watching their face when they lose.

The Point

I'm not closing the door to gaming. I'm opening it — carefully, deliberately, on my terms.

I'm not against online gaming forever. But I am against it right now, at this age, without the maturity to navigate what comes with it.

Right now, he plays in the real world. With real people. And that's exactly where I want him.

One day he'll have full access. One day he'll make his own decisions about what he plays and who he plays with. That day will come.

But it's not today.

Today, he plays. He learns. He has fun. He just doesn't do it with strangers. And I sleep better because of it.

How do you handle gaming at home with your kids? Drop your thoughts 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.

Read More

When One Problem Turns Into Two

The calm before...

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 mentioned here is something I personally own and use.

I'd enjoyed almost a month of absolute peace. My OPNsense firewall was working flawlessly, without a single outage. It was performing so well that, to be honest, I'd fallen into that dangerous state of complacency where you don't even check the logs or the connection. You simply assume everything will be fine forever.

Until this morning.

At 7:01 AM, I sat down at my computer ready to start the workday and was met with the worst possible screen: No connection.

At first, nothing made sense. The infrastructure had been stable for weeks. The OptiPlex running OPNsense was powered on. The NUC was powered on. Physical links? At first glance, all good. Everything looked normal. But the network clearly wasn't.

I couldn't reach the OPNsense dashboard. Nothing.

The problem...

Since the business relies heavily on network connectivity, I couldn't allow extended downtime, so I started troubleshooting fast.

First step: connect directly to the ISP, bypassing everything. That worked — I had internet. So the ISP itself was fine. The problem was somewhere in my own infrastructure.

Then came the first rabbit hole.

My main PC, connected to the ISP directly over Wi-Fi, had no internet either — connected, but nothing loading. I dug into it and found the cause: DNS was still pointing to Pi-hole, on a network segment that didn't exist in this configuration. Switched everything to automatic DHCP and DNS, and that PC came back online.

Good. One thing fixed. But the real problem — OPNsense unreachable — was still there.

So I activated the bypass plan: an old Linksys E900, pre-configured to take over DHCP for the whole office in exactly this kind of scenario. I connected it between the ISP and the internal network.

Except it had the same DNS problem. Configured to hand out Pi-hole's address as DNS to every client. Same fix: switched it to public DNS. Bypass online. Core systems back up.

The proof

And here's the part that actually matters most to me: it worked. Not "worked in theory" — worked under real pressure, on a real morning, with a real firewall down. I'd built this bypass months ago for exactly this scenario, and today was the first time it actually had to do its job. It did. That's not a small thing. That's the difference between a stressful morning and a lost day.

Relief — for about ten minutes.

The partial failure

Because the network was still only partially healthy.

Maria's PC, on the second switch, still had no connection through the network — though it kept working because it was also connected directly to the ISP over Wi-Fi as a fallback.

The access points weren't responding either.

That uncertainty was stressful. When everything is down, the problem is clear. When half the network works and half doesn't, every assumption becomes questionable.

And the whole time, one thought kept nagging at me: what happens if a customer walks in right now? Odoo runs on this network, and without it, the store can't operate the way it needs to.

Luck was on my side, oddly. Nobody walked in until 11am. That gave me a window to work without the pressure of a customer standing there — but it was also its own kind of pressure, a clock running in the background the whole time. Peace and pressure, at the same time.

I checked Pi-hole on the NUC directly, worried it had crashed and was the common thread. It was fine — active, healthy, full history of queries. Not the culprit. Crossed that off the list.

The fix

With the bypass holding the network up, I had a window — and the OptiPlex was already down for diagnosis anyway. So I decided to act on something I'd suspected for a while.

The OptiPlex's LAN interface was running on a USB Ethernet adapter. This wasn't the first time a USB NIC had given me trouble — when I first set up OPNsense on the NUC, before moving it to the OptiPlex, a USB NIC was the exact thing that failed on me back then too. Apparently that's a known weak point for USB network adapters under sustained load. Fine for temporary setups. Not for a firewall running 24/7.

I had a dual-port Intel PCIe NIC sitting ready. Took the OptiPlex apart, installed it, reassigned the interfaces from the console — WAN stayed on the onboard port, LAN and a future OPT/DMZ port moved to the new card. Brought OPNsense back up.

LAN came back clean. WAN picked up a real IP from the ISP again, not the bypass's.

I felt relief. Found the root cause. Or so I thought.

The second failure

Because the access points were still offline. Maria's PC still couldn't reach anything through the LAN.

That made no sense. I'd just fixed the actual hardware problem on the firewall. So why was half the network still acting like nothing happened?

That's when the frustration really kicked in.

Back to troubleshooting. DHCP leases. IP configurations. Pings that came back as "destination unreachable" from addresses that shouldn't exist. Manual IPs versus automatic ones. Everything seemed to check out individually, and none of it explained the access points being completely dark.

Mental fatigue sets in fast on mornings like this. Your brain starts looking for a complicated answer, because surely something this stubborn has to be complicated.

The resolution

I stepped back, took a breath, and decided to forget the theories. Check every physical connection manually. One cable at a time.

That's when I found it.

While moving the OptiPlex earlier to install the new NIC, I had accidentally knocked loose the UTP cable connecting the first switch to the second switch — the one feeding the access points, the cameras, and Maria's desk.

I had unintentionally created a second problem while fixing the first one.

I just stared at the cable. Then I laughed. Because that's IT sometimes. You fix one issue, and in the process of fixing it, you cause another.

Reconnected the cable. Instantly, everything came back. Access points online. Maria's PC online. Full network restored.

After a long, stressful morning, the network was finally healthy again.

What I Learned Today

1. Bypass plans are essential — and proving they work matters

Having a physical bypass kept the business running while I troubleshot the real problem. Without it, the entire office would have gone down for hours.

But more than that: this was the first time that bypass had to perform for real, outside of a test. It worked. There's a particular kind of relief in seeing a contingency plan you built months ago actually do its job under pressure — it's no longer theoretical, it's proven.

2. Avoid USB NICs for critical systems

This is the second time a USB Ethernet adapter has failed me on a firewall — once on the NUC, now on the OptiPlex. Fine for temporary use. Not for production infrastructure. Dedicated PCIe NICs, especially Intel-based ones, are the right call.

3. Troubleshooting can create new problems

This one stung. Not every issue you see belongs to the original failure. Sometimes, during diagnosis — or while physically moving hardware to fix one thing — you unintentionally introduce a second problem. That can completely distort your understanding of what's actually happening.

Final thought

Today's outage taught me something simple:

The first problem was hardware.

The second problem was a cable, knocked loose by my own hands while fixing the first.

Both mattered. Both taught me something.

Read More

Network Security Group Services and Emergency Plan

 Post #017 — Network Infrastructure

Network Security,
Groups / Services.

30+ Devices. No Control. Here's How That Changed.

Pi-hole dashboard — 32 active clients · 14.4% of all DNS queries blocked

A few weeks ago I had 30+ devices on a single flat network. Everything could see everything. The router was handing out IPs without knowing who was who, and I had zero visibility into what was actually happening on the network. It worked — until it didn't feel right anymore.

This isn't a post about blocking YouTube or locking down guest WiFi. This is about something simpler and more important: knowing what's on your network, giving each group of devices exactly the access it needs, and nothing more. Once OPNsense was back online and stable, this was the next step.

---

The Numbers Right Now.

CURRENT STATE

32 Active Devices On the network right now. All mapped, all assigned to a group.

14.4% DNS Blocked Of all DNS queries on the network. Blocked before they leave.

5 Security Groups Each with its own ruleset. Assigned by MAC address.

---

Groups and Segmentation.

WHO GETS WHAT

Every device gets classified by role. Not by who uses it — by how it should behave on the network. That's the key distinction. A family member's phone gets assigned to a group based on what level of access makes sense for that device, not based on who they are.

The groups are assigned by MAC address in Pi-hole. MAC addresses don't change, so the policy follows the device regardless of what IP it gets assigned. Right now the network has five active groups:

Employees Work-focused access. Office machines, productivity tools, stable connectivity. Full LAN access Adult content blocked Timed internet access	Visitors Internet only. Isolated from internal devices, servers, and storage. Internet access only No LAN access APK installs blocked
Kids Parental controls, content filtering, screen time limits, controlled gaming access. Adult content blocked App install control Timed access	Grandpa Custom protection profile. Aggressive ad blocking, restricted installs. Its own thing. App whitelist only APK domains blocked Extra protection active
Gaming / TVs Media and gaming devices. Ad blocking active, no install restrictions. These devices consume content — they don't install software. Full internet access Ad blocking via Pi-hole APK sideloading blocked

---

The Grandpa Rule.

NOT PUNISHMENT — CONTAINMENT

This one deserves its own explanation because it's not obvious from the outside.

The phone is on its own policy. The issue isn't browsing habits or anything personal. The issue is that certain device types are magnets for bad APK installs — fake app stores, ads that look like download buttons, links in messages that lead somewhere unexpected. An older user on an Android device with no restrictions is a real risk. Not because of intent. Because the attack surface is wide open.

The ad appears. The link resolves to nothing. Pi-hole blocks the APK download domains at the DNS level — the install never starts. No error message. No friction. The phone works normally for everything else.

This is the part most people don't think about when setting up a home network. The threat isn't always external. Sometimes it's a trusted user on a device that doesn't know how to protect itself.

---

Pi-hole — Network-Wide Ad Blocking.

NO EXTENSIONS. NO INSTALLS. NO PER-DEVICE CONFIGURATION.

Pi-hole runs on the NUC at 192.168.2.114. Every device on the network uses it as its DNS resolver — configured once in OPNsense, applied everywhere automatically. Smart TVs, phones, tablets, game consoles. None of them need anything installed.

After the first week: 32 active clients, 14.4% of all DNS queries blocked. That number will move as I tune the blocklists and add group-specific rules. The baseline is already there.

Pi-hole — 117,055 total queries · 16,877 blocked · 84,231 domains on lists

Why DNS-level blocking matters: Pi-hole blocks the request before it leaves the network. The device never connects to the ad server. This works on every device without touching the device itself — including TVs and consoles that have no browser extension support.

---

The OptiPlex Incident.

THE SIGNAL

In the middle of all this, the OptiPlex started to smell. Not smoke — not catastrophic. But that specific warm-electronics smell that means something is running hotter than it should. The capacitors, maybe. Thermal paste on a 15-year-old machine that's now doing real work 24/7.

I didn't panic. I documented it and started planning. If OPNsense goes down, the network goes with it. And that means the businesses go with it. That wasn't acceptable.

---

The Emergency Router Kit.

WHAT DIDN'T EXIST BEFORE

That's why the emergency router kit exists. A TP-Link E900 — small, cheap, fast — pre-configured and sitting in the rack. Not plugged in. Waiting.

The E900 is already configured with the same network range, same DHCP, and DNS pointing to Pi-hole on the NUC. The NUC runs independently — Pi-hole doesn't care which router is handling DHCP, as long as the DNS queries keep coming.

# E900 — Emergency Config
Network     192.168.2.x
Gateway     192.168.2.6
DHCP Range  192.168.2.100 – 192.168.2.149
DNS         192.168.2.114 <- Pi-hole (NUC)
Status      Pre-configured. Ready.

Failover Procedure — Estimated Time: 2–3 min
Step 01	Unplug the OptiPlex from the switch.
Step 02	Plug in the E900 to the same port.
Step 03	Wait 2–3 minutes for DHCP leases to renew.
Done	Network is back. Pi-hole is still running. Businesses continue.

Pi-hole runs on the NUC, independent of OPNsense. If the firewall goes down, the DNS blocker keeps working. The two services are decoupled by design.

---

This Is a Living System.

WHERE THIS GOES NEXT

What I have right now is a baseline. The groups exist, the MAC assignments are in place, Pi-hole is logging everything. But the rules are going to evolve — as I learn more about how each group actually uses the network, as new devices come in, as I identify patterns in the query log that need addressing.

Security isn't a configuration you set once. It's an ongoing process of observation and adjustment. The infrastructure is there to support that process — not replace it.

Next phase: OPNsense firewall rules between VLANs, WireGuard for remote access, and the WD EX2 coming back online with its own access policy. The foundation is built. Now it gets layered.

---

Hardware in This Post.

WHAT I'M ACTUALLY USING

• TP-Link E900 — Emergency failover router. Pre-configured, same network, same DNS. 2-minute swap if OPNsense goes down.
• Intel NUC D34010WYKH — Running Pi-hole 24/7. 8GB RAM, compact, low power draw, independent of the firewall.
• Multicolor Network Cables — Black for LAN, white for WAN, red for the emergency kit. Color-coded from day one.

---

---

Related Posts

• My Network Has No Firewall Right Now. Here's Why That's Temporary. — Post #008
• Got the Firewall Running Again. — Post #011
• OPNsense Back Online. — Post #014
• A 2014 Mini PC. Two Services. Zero Monthly Fees. — Post #013

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.

Read More