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