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

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

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

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