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

Eight Hours a Day, Constant Pain. A $50 Cushion Fixed What My Chair Couldn't.

---

Eight Hours a Day, Constant Pain. A $50 Cushion Fixed What My Chair Couldn't.

THE PROBLEM

A while ago, I made what I thought was a great purchase: a gaming chair. It looked good, felt modern, and honestly, the price was hard to ignore. Like many people who work long hours at a desk, I thought a gaming chair would be more comfortable than a regular office chair.

I was wrong.

I work around 8 hours a day sitting at a desk, and over time, I started having intense pain in my tailbone. At first, I blamed my posture. I kept changing how I sat, trying to sit properly, but nothing really worked. Then the discomfort became constant.

I started adding random cushions to the chair, hoping that would help. It worked a little, but the pain was still there, especially after long work sessions. Eventually, I began researching tailbone pain and sitting for long periods. That's when I realized something important: sometimes the problem isn't you — it's the chair.

I thought my posture was the problem. The chair was making everything worse.

So I switched back to my old, boring office chair. Surprisingly, the pain immediately got better.

---

A Cushion Made for the Exact Problem I Had

THE FIX

That's when I decided to try a cushion specifically designed for coccyx and tailbone pain. I bought the TushGuard Seat Cushion, and honestly, I noticed a difference pretty quickly. There's something incredibly relieving about using a product made for the exact problem you're facing.

The pressure relief was noticeable, especially during long sitting sessions. It wasn't magic overnight, but after regular use, the improvement became clear.

TushGuard Seat Cushion — XX-Large · Amazon's Choice · 28,000+ reviews

To be fair, it wasn't just the cushion.

A few things worked together:

• Switching away from the gaming chair
• Improving my posture
• Taking breaks every 45 minutes
• Using proper support for my tailbone
• Being more aware of how long I sit without a break

All of that together made a huge difference.

---

6'0". 270 lbs. Still Holding Up.

DURABILITY

For context: I'm not exactly lightweight. I'm 6'0" and around 270 lbs, so durability mattered to me. Some cushions compress and lose their shape after a few weeks. So far, this one has held up very well over the last couple of months — no noticeable flattening, no shifting during use.

At this point, I'm seriously thinking about investing in a proper ergonomic chair while continuing to use the cushion long-term. The two aren't mutually exclusive — if anything, the cushion taught me how much seat support actually matters before committing to a chair purchase.

---

If You Sit All Day and Your Back Hurts — Don't Ignore It.

IS IT WORTH IT?

This isn't for everyone. If your chair already fits you well and you don't have tailbone or coccyx pain, you probably don't need this. But if you spend most of your day sitting and the discomfort is constant — don't keep blaming your posture before you've looked at your setup.

Sometimes small changes — especially the right support — can completely change how your body feels by the end of the day. Your back and tailbone will thank you.

• TushGuard Seat Cushion — XX-Large · coccyx & sciatica relief · memory foam

---

This Build Isn't Finished.

WHAT'S NEXT

That's the thing about building your own system — it's never really done. Here's what's coming:

• Network security — 30+ devices, finally under control. Groups, Pi-hole, and the emergency router kit.
• Building a desk from scratch — a closed, ventilated cabinet for the homelab, surge protection, and an ergonomic setup designed specifically for long work sessions.
• Home Assistant — smart plugs, door notifications, and automation that actually makes sense"

Each of those is a post. I'll document the process — what worked, what didn't, what I'd do differently. If you're building something similar, follow along.

---

Questions about the setup? Drop them below. I built this without a guide — figured it out piece by piece over time. Happy to help you figure it out.

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

Post #016 — Cable Management

Making the Infrastructure Disappear.
My Wife Was Right About the Cables.

When the homelab becomes part of the office — and the office has to look like it

---

The process actually started well. At least, it did at first. The original plan was simple: reorganize the networking equipment, reroute the cables properly, clean up the desk, and make the firewall setup look less like a temporary arrangement held up by stress and zip ties. Then my wife got involved. Somehow, the project shifted from "rewiring the office" to "redesigning the entrance wall to the office." Now we're installing decorative PVC wall panels. Honestly, she's right.

Once the decorative panels came into play, the entire cable layout changed. Since the wall needs to look clean, the cables can't run openly behind the equipment anymore. Everything must fit neatly into floor cable channels and follow the room's design instead of just the shortest technical route. This project has grown beyond the original homelab idea. Suddenly, the network infrastructure isn't just a functional piece hiding in the corner. It has to blend in with the space. It must look intentional.

---

When the plan changes

I want to clarify something important: even though the decorative changes weren't the main focus, they quickly became more important than the homelab itself. At the end of the day, this isn't a dedicated server room. It's part of our home. While I can live with exposed switches, visible cables, temporary hardware stacks, and chaotic infrastructure for testing, most people—especially wives—prefer walls that don't look like a small ISP exploded inside the office. That perspective likely keeps projects like this grounded. The homelab matters. The infrastructure matters. The redundancy plans matter. But the space still has to feel livable when the cables blend into the background and the computers are no longer the main focus.

It has to blend in with the space.
It must look intentional.

If this project can work well as part of the network infrastructure and still look clean and inviting enough for clients, that's a win-win. I believe that. As this homelab grows, I see more clearly that it can't exist separately from the real world. It's not tucked away in a garage or a dedicated server rack, far from daily life. It's part of the office. It belongs to the workspace. It shapes the experience people have when they walk in. So yes, the technical side is important. Reliability is key. Cable management is essential. Redundancy and recovery plans are crucial. But presentation matters too. If someone enters the office and the first thing they see is exposed wiring, piles of temporary equipment, and chaotic infrastructure, then no matter how technically impressive the setup is, the space will still feel unfinished.

Honestly, I think my wife realized that faster than I did. What started as cleaning up the network became something more balanced. It's now infrastructure that not only works but also blends in with the space instead of clashing with it. The decorative PVC panels, hidden cable channels, and cleaner routing don't directly improve network performance. But they do enhance the environment. If the final result is a space where the infrastructure quietly does its job in the background while the office feels calm, organized, and welcoming to clients, then the project becomes more than just a homelab. It becomes part of the workspace itself.

---

What the process revealed

After a lot of cutting, routing, measuring, and rewiring, I realized something almost funny: most of the old cable paths weren't reusable. The decorative wall panels changed everything. Some cables needed to be rerouted through floor cable channels, others required new lengths entirely, and little by little, the project became less about "organizing cables" and more about rebuilding the entire flow of the office infrastructure around the room itself.

And honestly? It didn't fully turn out the way I originally imagined. At least not yet. What this process made painfully clear is that achieving that incredibly clean, organized, almost invisible setup requires more than just cable ties and patience. It needs furniture designed specifically for infrastructure — something like a dedicated ventilated cabinet or locked networking closet where everything can live intentionally instead of simply being hidden nearby. Because right now, if I'm honest, part of the process feels like I relocated the chaos instead of completely eliminating it.

But at the same time, there is visible progress. Behind my desk, there are no longer loose blue Ethernet cables bouncing around everywhere. The setup looks more structured, more deliberate, and more mature. Even the placement of the main workstation will probably change now that the room itself has a different visual flow.

---

She was right

And this is where I have to admit something important: my wife was right. She had a much better eye for the space than I did. The office entrance now feels cleaner, calmer, and more intentional. There aren't cables crossing the floor anymore. The infrastructure fades into the background instead of demanding attention when someone walks in. And that changes the feeling of the room completely. Clients notice those things. Maybe not consciously. But they feel them. And at the end of the day, clients are the reason projects like this are even possible. Without clients, there is no business. Without business, there is no budget for homelabs, servers, upgrades, networking equipment, or infrastructure experiments. So making the office feel professional matters just as much as making the network reliable.

Ironically, one of my favorite parts of this entire process turned out to be something very simple. At one point, all the services were completely shut down. The network was effectively offline while everything was being moved into its new position. Equipment disassembled. Cables removed. Hardware relocated.

And then: reconnect everything. Power it back on. Wait. And it all came back online exactly the way it was supposed to. No panic. No emergency recovery. No unexpected failures. Just infrastructure quietly returning to life.

And honestly, that moment gave me more peace of mind than any benchmark, dashboard, or speed test possibly could. Because I think that's one of the real successes of this entire project: not that the network became more complex, but that it became understandable, recoverable, and stable enough to survive being taken apart and rebuilt without everything collapsing around it.

---

The infrastructure didn't disappear.
It just stopped demanding attention.
That's the goal.

---

Related Posts

• Stability Is Not the Same as Health. — Post #015
• OPNsense Back Online. — Post #014

Read More

Post #015 — A Personal Note

Stability Is Not the Same as Health.

A reflection on the things we stop paying attention to once they start working

---

There's a pattern I keep running into, and it doesn't just show up in technology.

It shows up in relationships. In routines. In the infrastructure around us — the physical kind and the human kind. The pattern is this: the moment something starts working reliably, we stop paying attention to it. We stop asking questions. We stop checking. We just use it and move on.

And for a while, that's fine. Most things hold up quietly for a long time without needing anything from us.

Until something changes.

---

The Illusion of Stability

When I started building this homelab — documenting it, writing about it, sharing what I was learning in real time — I kept running into the same discovery over and over again.

The problem was never where I assumed it was.

I would spend hours troubleshooting the new thing I just deployed, convinced that my changes had broken something. And then I would find it: a weak electrical connection in a terminal that had been there for years. A port on the ISP equipment that hadn't functioned properly in months, maybe longer. A cable termination that looked fine but wasn't.

The new system didn't create the problem.
It revealed the problem that was already there.

That distinction changed how I think about failure. When something breaks after a change, the instinct is to blame the change. Revert it. Undo it. Get back to the state that was "working." But working and healthy are not the same thing. A system can appear perfectly stable right up until the moment it isn't — not because something new arrived, but because the hidden fragility finally had something to react to.

---

The Things We Stop Noticing

I think about this beyond technology too.

How many things in daily life are we just getting by with — not because they're actually healthy, but because nothing has disrupted them yet? Routines that haven't been examined in years. Relationships that coast on familiarity. Equipment, habits, assumptions — all of them holding up quietly, all of them accumulating invisible wear.

We don't check on the things that seem fine. We reserve our attention for what's visibly broken. And so the hidden problems compound in the background, patient and unannounced, until something new comes along and suddenly everything falls apart at once.

It looks like the new thing caused it. It didn't. It just changed the conditions enough that the old fragility finally showed.

---

What Maintenance Actually Means

Working systems still need maintenance. Not because they're broken — because they won't stay healthy on their own.

That's the lesson I keep relearning. Not in a dramatic way. In the quiet, unglamorous way of cleaning dust out of a machine that's been running for years. Of checking a cable connection that nobody has touched since it was first plugged in. Of asking whether something that appears to be working is actually healthy, or just hasn't been disrupted yet.

There's a difference. And the difference only becomes obvious under pressure.

The best time to check on something
is before it gives you a reason to.

I set an alarm for 4 AM to fix a network that nobody knew was fragile. By 6 AM it was done. By 8 AM people were working without interruption, without a single complaint, without any awareness that anything had changed at all.

That's what good maintenance looks like from the outside: nothing. Total invisibility. The work disappears, and life continues.

But I know what it took. And I think that's worth writing down — not as a technical document, but as a reminder to myself.

---

The Real Culprit

In the end, what failed was a terminal. A weak electrical connection. Possibly something as simple as dirty contacts inside a port that hadn't been used in years.

Not the firewall. Not the configuration. Not the new hardware I introduced. The old infrastructure that had been quietly degrading while everything around it seemed fine.

Tiny things. The kind of things nobody thinks about while everything seems to be running smoothly. The kind of things that only become visible when you slow down, disconnect from the pressure, and actually look.

I'm starting to think that's the real skill this project is teaching me. Not the commands. Not the configuration files. Not the hardware.

The discipline of paying attention to the things that appear to be fine.

---

Sometimes things aren't healthy.
They're just getting by quietly
until something changes around them.

---

Related Posts

• OPNsense Back Online. — https://creativelydifferentbuilds.blogspot.com/2026/05/opnsense-back-online.html
• The NUC Wasn't the Problem. The Power Strip Was. — https://creativelydifferentbuilds.blogspot.com/2026/05/the-nuc-wasnt-problem-power-strip-was.html

Read More

 Post #014 — Network Infrastructure

OPNsense Back Online.

What Failed, Why It Was Harder Than It Should Have Been, and What I Have Now That I Didn't Before

The firewall is back. The network is under control. And the actual culprit turned out to be something embarrassingly simple — which is exactly why it took so long to find.

This post documents what happened during the failed first deployment, why isolating the real problem was harder than it sounds, and what the network looks like now that OPNsense is running properly.

---

Why This Was Hard to Diagnose.

THE CONTEXT

Troubleshooting a network while people are actively using it is a completely different kind of challenge. Every change you make has immediate consequences. Every minute without internet is someone's phone not loading, a payment terminal going offline, a business interruption.

This property runs two active businesses across approximately 1,250 m². During working hours, the network isn't an experiment — it's infrastructure. That means real changes, failovers, and diagnostics have to happen under pressure, quickly, with no margin to methodically isolate one variable at a time.

What looked like a complex firewall misconfiguration turned out to be three separate, unrelated problems that happened to surface at the same time — making the behavior appear random when it wasn't.

---

Three Problems. One Chaotic Result.

WHAT ACTUALLY FAILED

01

ISP Hardware

Two of the four LAN ports on the ISP equipment were not functioning correctly — likely dirty contacts from years of disuse. Moving to a working port fixed the instability immediately.

02

Faulty RJ45

A weak electrical connection on one of the terminations. Not visually obvious. Causing intermittent drops that looked like configuration failures.

03

DHCP Conflict

Multiple devices competing for IP assignments during the transition. Not a hardware failure — a logical conflict that cleared once the other two issues were resolved.

None of these would have been catastrophic on their own. Together, layered on top of each other, they produced behavior that appeared completely random. That's the part that cost time — not the fix, but the diagnosis.

OPNsense wasn't the problem. It never was.

---

4 AM.

THE PART NOBODY SEES

There's only one window where this kind of work is possible: before anyone wakes up.

I set my alarm for 4 AM. Not because I had to — because it was the only time the network belonged entirely to me. No businesses open. No phones ringing. No one waiting for a page to load or a payment to process. Just silence, a terminal, and enough time to do the work properly.

I moved cables. I isolated variables. I replaced a termination. I verified every connection before committing to the next one. I did the deploy cleanly, without pressure, without anyone watching.

By 6 AM, everything was behind t
he firewall.

Nobody noticed. There were no calls, no complaints, no questions. People arrived, opened their devices, and used the network exactly the same way they always had. The day ran normally. The businesses ran normally.

That's what a successful infrastructure change looks like from the outside: nothing. Total invisibility. The work disappears into the background and life continues without interruption.

That's also the part that never shows up in documentation. The alarm at 4 AM. The decision to sacrifice sleep in order to have the calm conditions the work actually requires. The two hours of focused, uninterrupted effort that made the next eight hours completely uneventful for everyone else.

I'm starting to understand that this is what real infrastructure work looks like. Not the deploy — the conditions you create to do it right.

---

The Part I Didn't Expect.

THE REAL LESSON

I checked hardware I assumed was fine. I cleaned dust out of equipment that had been running ignored for years. I checked contacts, verified cabling, confirmed power. All of this before touching a single configuration file in OPNsense.

The assumption was that the new system broke what was already working. That's the instinct — blame the change. But the network wasn't as healthy as it appeared. It was stable enough that nobody noticed the weaknesses underneath. The moment I started making structural changes, those weaknesses surfaced all at once.

The new system doesn't always create the problem. Sometimes it reveals the problem that was already there.

In the end, what failed was a terminal. A weak electrical connection. Possibly something as simple as dirty contacts inside a port that hadn't been used in years. Tiny things. The kind of things nobody thinks about while everything seems to be running smoothly.

---

What the Network Looks Like Now.

CURRENT STATE

ISP Equipment → OPNsense (OptiPlex) → Switch
↓                                             ↓
All 30+ devices NUC · NAS · IMPERFECT

OPNsense sits between the ISP equipment and the rest of the network. Everything passes through it. DHCP is managed internally — every device that matters has a static mapping by MAC address. No more guessing IPs. No more blind reboots.

---

The Backup Plan.

WHAT DIDN'T EXIST BEFORE

Before this deployment, there was no documented recovery procedure. If the network went down, the path forward was improvised each time. That's gone now.

Emergency Network Recovery — Estimated Time: 15–20 min

~2 min

Disconnect OPNsense from the network. Plug a device directly into the ISP equipment.

~3 min

Verify internet access is restored. Confirm the ISP port is functional.

~5 min

Reconnect devices directly to switch. Network is operational at ISP level without firewall.

~10 min

Diagnose OPNsense separately, without pressure, without anyone waiting for internet access.

That plan didn't exist before. Having it changes the stakes entirely. The firewall going down is no longer an emergency — it's a maintenance window.

---

What's Next.

HONEST STATUS

The network is stable. The firewall is running. The NUC has a permanent IP. The NAS has a permanent IP. IMPERFECT has a permanent IP.

The next phase is Home Assistant — a dedicated machine for automation, smart plugs, NFC access, and door sensors. That project requires its own post. For now, the infrastructure foundation is finally in place.

Working systems still need maintenance. Especially before adding something new to the mix. Because stability can be misleading — sometimes things aren't healthy, they're just getting by quietly until something changes around them.

That realization is worth more than the deployment itself.

---

Related Posts

• My Network Has No Firewall Right Now. Here's Why That's Temporary. — Post #008
• Got the Firewall Running Again. — Post #011
• 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

Post #013 — Homelab

A 2014 Mini PC. Two Services. Zero Monthly Fees.

Self-Hosting Immich and Jellyfin on an Intel NUC

This started as a practical decision. I had an Intel NUC from 2014 sitting on a shelf — stress-tested, cleaned, and confirmed working. I had a NAS full of movies and family photos. And I had two services on my list that I kept putting off: a self-hosted photo library and a local media server.

The NUC became the host. The only real question was whether an 8GB i3 machine from over a decade ago could handle both without falling apart.

It can.

---

What This Covers.

THE SHORT VERSION

This isn't a step-by-step tutorial. What I want to document here is the sequence — the order things need to happen in — and the honest friction that came with it. If you've been curious about self-hosting but assumed it required deep Linux knowledge, this might change your mind.

The rhythm is simple:

01

Ubuntu Server 24.04 LTS

Minimal install. No GUI. Just SSH access and a command line. The install itself took less than 15 minutes — bootable USB, follow the prompts, done.

02

Docker

One command installs the entire Docker engine. From this point forward, every service runs in its own container. No conflicts, no dependency hell.

curl -fsSL https://get.docker.com | sudo sh

03

NAS Mount via CIFS

The movies and photos live on the WD EX2 NAS. Rather than copy everything to the NUC, I mounted the NAS shares directly. The NUC reads from the NAS in real time.

04

docker-compose.yml

One file. Five containers. Jellyfin, Immich server, Immich machine learning, Redis, and PostgreSQL — all defined together, all starting with a single command.

docker compose up -d

05

fstab — Persistent Mounts

Without this step, the NAS mounts disappear on every reboot. Adding two lines to /etc/fstab makes them permanent. The NUC mounts the shares automatically every time it boots.

06

OPNsense Static DHCP

The NUC needs a fixed IP. Not on the NUC itself — in the router. OPNsense assigns the same IP every time based on the MAC address. No configuration changes needed on the server side.

---

Two Services, One Machine.

WHAT'S RUNNING

Jellyfin 192.168.2.114:8096 Local media server. Movies and series stream from the NAS through the NUC to any device on the network. No subscription. No account required.

Immich 192.168.2.114:2283 Self-hosted photo library. Automatic backup from phones, face recognition, map view, timeline — everything a cloud service offers, running locally.

---

The Part Nobody Mentions.

HONEST STATUS

The services work. But at the time of this deployment, OPNsense wasn't stable yet — it was the next item on the list, not the current one. That created a specific problem worth documenting.

Without a firewall managing DHCP, the NUC's IP address isn't guaranteed. Every restart is a question mark. The bookmark you saved yesterday might point nowhere today.

The deliberate choice: I could have set a static IP directly on the NUC — it's a few lines in a config file. But that would have created a conflict the moment OPNsense came online and started managing the network. The plan was already in motion. Hardcoding the IP on the machine would have meant undoing it later. So I didn't.

Instead, the NUC runs on DHCP. When the IP changes — which it does, occasionally — I find it the way a headless server should be found: through the network, not by plugging in a monitor.

That's where SSH earns its place. Once you know the new IP from the router's lease table, you're back in. No keyboard. No screen. No interruption to the services themselves — they keep running regardless.

This is also where my situation diverges from a simple home setup. This property spans ~1,250 m², runs two active businesses, and has over 30 devices on the network across multiple access points. The ISP equipment is locked down — no admin access, no app, no lease table. There's no way to check what IP was assigned without a dedicated firewall in the loop.

If your setup is simpler — one router, a handful of devices, and access to the admin panel — this friction probably doesn't apply to you. Most home routers let you assign a fixed IP from the app in under a minute. But if you're operating at scale without a firewall, you're flying blind in exactly the way I was.

OPNsense is the next post. That's where the IP becomes permanent and the network becomes visible.

---

Does a 2014 Machine Handle It?

THE HONEST ANSWER

Yes — with reasonable expectations. The NUC runs both services simultaneously without breaking a sweat during normal use. Streaming a movie while Immich indexes photos in the background? No problem.

Where you feel the age is in Immich's machine learning pipeline. Face recognition and smart search require real processing. On first run, with hundreds of photos to analyze, it takes time. Not hours — but long enough that you notice it's working.

For a household media server and photo library, an 8GB NUC from 2014 is more than enough.

docker ps
immich_server — Up 20 hours (healthy)
jellyfin — Up 20 hours (healthy)
immich_ml — Up 20 hours (healthy)
immich_postgres — Up 20 hours
immich_redis — Up 20 hours

It boots, mounts the NAS, starts the containers, and disappears into the background. That's exactly what a server should do.

---

What's Next.

HONEST STATUS

The NUC is running. The services are stable. The next phase involves Home Assistant on a dedicated OptiPlex — which opens the door to smart plugs, NFC automation, door sensors, and on-demand wake for the NAS.

That's a separate post. For now, the media server is live, the photos are organized, and the monthly subscription cost for both is zero.

The fear of Linux was bigger than Linux itself. The installation was straightforward. The commands were learnable. The part that's genuinely hard isn't the server — it's the network.

---

Related Posts

• The NUC Wasn't the Problem. The Power Strip Was. — Post #010
• Got the Firewall Running Again. — Post #011
• Undust the EX2 — Bringing My NAS Back to Life — Post #012

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

Networking · Post #013

Turning Off the Firewall

May 2026  ·  Creatively Different Builds  ·  ~6 min read

Today felt like a loss.

What I thought would be a simple task — changing two cables — turned into three hours of network chaos. Phones started ringing, people lost internet access, and I found myself battling cables, switches, Wi-Fi access points, and OPNsense all afternoon.

My first mistake was changing the Wi-Fi APs from the 192.168.1.x range to 192.168.2.x. I needed access to the APs for configuration, but OPNsense quickly took over every connected device in its DHCP leases. Everything looked connected — but there was no internet.

Then I moved on to cable swapping.

The room looked like a battlefield.

I went from point to point trying to isolate the issue. After about 30 minutes, I had already reverted most of the setup back to its original state but still had no internet. Eventually I realized the OPNsense configuration was conflicting with the DHCP assignments. I had to connect directly to each AP in three different locations just to regain access and manually restore the IP settings.

Later, after examining the hardware, I found another problem: one of the RJ45 terminals was faulty.

The blue pair pulled out of the connector. The whole afternoon, hiding here.

That was when the hard truth hit me:

I'm not ready for deployment yet. And honestly — that's okay.

The Decision

I'm fully aware of what I'm exposing myself to by running the network unprotected for now. But I have to be honest about where things stood before: even without a firewall, the network is already in better shape than it was before I started taking control of it. It used to be disorganized, with no clear structure. Now it's more aligned, more documented, more understood — it just has to wait thirty days to be put fully in order.

That's the trade-off I'm accepting consciously, not by accident.

This experience revealed weak points I would rather discover now than during a full production rollout. I'm still not fully confident in the OptiPlex's generic PSU running 24/7. This setup will also need the ISP modem in bridge mode — and rushing that change while the hardware is uncertain is the wrong order of operations.

OPNsense console — "Host is down".

The Plan Forward

Instead of improvising my way out, I stopped and built an actual recovery strategy. That alone made today worthwhile.

The decision is deliberate: OPNsense stays out of production until the new hardware arrives. Not as a retreat — as sequencing. The new OEM power supply and the new network card are already on the way. The moment they land, the order of operations is fixed and non-negotiable: install the reliable PSU, install the dual NIC, validate stability under real load for several days, and only then file the ISP ticket to request bridge mode.

And there's a safety net underneath all of it. If, once everything is in place, configuration problems show up again the way they did today, the E900 is pre-configured to step in and handle NAT and DHCP — keeping the network alive while I troubleshoot OPNsense without pressure. The firewall going down should never again mean the house and the business go down with it.

Because today proved something important: a network isn't truly stable because it works. It's stable because you know what happens when it breaks.

Next 30 days — stabilize, don't push

→ OPNsense stays out of full production — waiting on the new PSU and NIC, on purpose

→ Keep the network in its current stable configuration — ISP through the switch, OPNsense inline only where reliable

→ Maintain a physical fallback cable to the main workstation, so a single cable change restores access if the firewall host dies

→ Build a second OptiPlex as a standby OPNsense — mirrored config, its own reliable PSU, pre-armed and powered off

→ Pre-configure the E900 as an emergency NAT/DHCP fallback, ready to take over if configuration problems return

→ Automate config backups to the NAS, with an external copy to avoid a circular dependency during recovery

→ Buy a proper cable tester, so a faulty termination is never an invisible variable again

When the hardware arrives — the fixed sequence

→ Install the OEM PSU in the primary OptiPlex

→ Install the dual-NIC configuration for the final architecture

→ Validate stability under real-world load for several days

→ Only then file the ISP ticket and move the modem into bridge mode — with the E900 standing by as the NAT fallback if anything goes wrong

Not before. The order is the whole point.

What Today Taught Me

Today was frustrating, exhausting, and humbling.

But it was also one of the most valuable days this project has had so far. Because networking isn't just about making things work under ideal conditions. It's about creating systems that survive mistakes, recover from failure, and stay understandable under pressure.

Every issue today pointed to something significant: documentation matters, recovery paths matter, hardware reliability matters. And confidence doesn't come from improvisation — it comes from preparation.

So no — this wasn't a failure.

It was a test run.

And next time, I'll be ready.

networking opnsense homelab firewall lessons-learned build-in-public

Creatively Different Builds  ·  creativelydifferentbuilds.blogspot.com

Read More