Got the Firewall running again.

 

OPNsense Is Back. It Wasn't Easy.

WHERE IT STARTED

The firewall has been offline for months.

No content filters. No kids schedule. No employee limits. No visibility into what's on the network. Just an ISP router doing the bare minimum while I waited for the right hardware and the right moment to fix it.

Today was that moment. And it didn't go smoothly.

This post documents everything — the hardware decisions, the installation failures, the IP conflict that nobody warns you about, and what it took to get OPNsense running on a machine that came from a trash pile.







The Hardware.

WHAT I'M WORKING WITH

The machine is a Dell OptiPlex 780 SFF. It came from a friend who manages IT for a local company — pulled from service during an asset upgrade, stripped of its drive and PSU, and headed for physical destruction. I took four of them.

This one gets OPNsense.

The specs are modest by today's standards — Core i3 second generation, 8GB DDR3 — but a firewall doesn't need processing power. It needs reliability, low power consumption, and enough RAM to handle routing tables and firewall rules. The OptiPlex checks all three.

What it was missing:

  • PSU — the original was stripped before disposal. The OptiPlex 780 uses a non-standard Dell connector, but the board accepts a standard ATX PSU with a simple adapter. I bought a generic ATX unit and connected it externally — not elegant, but functional.
  • Storage — no drive at all. This is where the Hitachi comes in.












The Drive.

CHOOSING THE RIGHT STORAGE

I had two drives available: a Kingston SSD 120GB and a Hitachi HDD 160GB. Before committing either one to OPNsense, both went through CrystalDiskInfo.

The Kingston had already been cloned to a Samsung NVMe for another machine. That freed it up — but the Hitachi needed vetting first.

The Hitachi results:

  • Health Status: Good
  • Reallocated Sectors: 0
  • Current Pending Sectors: 0
  • Uncorrectable Sectors: 0
  • Power On Hours: 5,078 — less than 6 months of continuous use

A mechanical drive running OPNsense isn't ideal — but this one is clean. OPNsense writes logs and state tables, not sustained random I/O. A healthy HDD handles that without issue. The Kingston SSD goes to the NUC instead, where read speed actually matters.






The PSU Connection.

MAKING IT WORK

The OptiPlex 780 SFF uses a proprietary Dell power connector — not standard ATX. The board has a 6-pin connector where a standard ATX 24-pin would normally go.

The solution is a Dell-to-ATX adapter cable. One end plugs into the board's power header, the other accepts a standard ATX connector from any generic PSU. The PSU sits outside the chassis — not the cleanest install, but it works and it's stable.

The chassis stays open for now. A custom bracket to mount the PSU properly is a future project — once I have a 3D printer.







The Board.

WHAT'S INSIDE

With the PSU connected and the chassis open, the board is fully visible. This is a machine that was designed to run in an office environment for years — and it shows. Solid capacitors, clean layout, nothing suspicious.

The thermal paste on the CPU was old but not as bad as the NUC. Replaced it anyway. Cleaned the fan. Applied contact cleaner to the ports.







Step 1 — Creating the Installation USB.

PREPARING THE MEDIA

OPNsense is distributed as a compressed disk image — not an ISO. The file is OPNsense-26.1.2-vga-amd64.img.bz2. The vga variant is correct for machines with a standard VGA output, which the OptiPlex 780 has.

Rufus handles the decompression automatically. The setup:

  • USB drive: Kingston DataTraveler 14GB
  • Image: OPNsense-26.1.2-vga-amd64.img.bz2
  • Partition scheme: GPT
  • Rufus detects it as a compressed bootable disk image and writes it directly

Rufus confirms the write by showing four FreeBSD partitions on the USB: EFI system partition, FreeBSD boot, FreeBSD swap, and FreeBSD UFS. That's exactly what OPNsense needs.


Step 2 — First Boot.

IT WORKS — FROM THE USB

Boot from USB on the OptiPlex: press F12 at startup, select the Kingston USB from the boot menu, and OPNsense loads in live mode directly from the USB drive.

The system comes up with two interfaces detected:

  • LAN (em0) → 192.168.1.1/24 — the onboard Ethernet port
  • WAN (ue0) → no IP — the USB Ethernet adapter

The system is running in live mode. To make this permanent, it needs to be installed on the Hitachi. Login with root / opnsense, then select option 8 (Shell) and run:

opnsense-installer




Step 3 — The Partitioning Loop.

WHERE IT WENT WRONG

Select Install (UFS). Select the Hitachi as the target disk. Accept the recommended 8GB swap partition.

Then this:

Partitioning error. An installation step has been aborted. Would you like to restart the installation or exit the installer?

Restart. Same error. Restart again. Same error.

The Hitachi had old partition tables that the installer couldn't overwrite. The drive was showing as r0w0e0 — read-only, write-zero, exclusive-zero. The installer wasn't failing to install OPNsense. It was failing to claim the disk.

Exit to shell. Identify the disk:

geom disk list

Two disks visible: ada0 — Hitachi 149GB, and da0 — Kingston DataTraveler 14GB (the USB). The Hitachi is ada0.

First attempt — wipe the first 10MB to destroy the partition tables:

dd if=/dev/zero of=/dev/ada0 bs=1M count=10

10MB written successfully. Back to the installer. Same error.

The dd cleared the data but the GPT partition table header still existed in the disk's metadata. The fix:

gpart create -s gpt ada0

Output: ada0 created.

Back to the installer. This time it worked.

The lesson: if the OPNsense installer fails with a partitioning error on a used drive, don't just wipe the data. You need to create a fresh GPT partition table with gpart before the installer can take ownership of the disk.







Step 4 — Installation.

FINALLY

Install (UFS). Hitachi selected. 8GB swap accepted. The installer clones the live system from the USB to the Hitachi.

A mechanical drive is slower than a USB stick for sequential writes. This takes a few minutes. When it finishes, remove the USB and reboot.





Step 5 — The IP Conflict.

THE PROBLEM NOBODY MENTIONS

OPNsense boots from the Hitachi. LAN comes up at 192.168.1.1/24. Standard default. Connect a cable, open a browser, go to https://192.168.1.1.

Nothing.

The problem: my ISP router also uses 192.168.1.1 as its gateway address. Two devices claiming the same IP on the same network is a direct conflict — neither one responds correctly, DHCP breaks, and routing fails silently.

This is the default OPNsense configuration conflicting with the most common ISP router subnet. If your ISP uses 192.168.1.x — and most do — you cannot use OPNsense's default LAN IP without a conflict. You have to change one or the other before the network makes any sense.

The solution: change OPNsense LAN to a different subnet entirely. I chose 192.168.2.x, reserving 192.168.1.x for the existing network and future ISP bridge mode migration.

From the console, option 2 (Set interface IP address), select LAN, set to 192.168.2.1/24:





Step 6 — First Access to the Dashboard.

FINALLY IN THE UI

With OPNsense LAN at 192.168.2.1 and IMPERFECT connected directly via the USB Ethernet adapter, the dashboard loads.

Interface assignments confirmed:

  • LAN → em0 (onboard Ethernet)
  • WAN → ue0 (USB Ethernet adapter)








Step 7 — DHCP and Static Mapping.

FIRST DEVICE ON THE NEW NETWORK

Services → Dnsmasq DNS & DHCP → General:

  • Enable: ✅
  • Interface: LAN
  • DHCP authoritative: ✅

DHCP range: 192.168.2.60 to 192.168.2.200. The lower IPs stay reserved for static mappings — APs, servers, anything that needs a fixed address.

Static mapping for IMPERFECT:

  • Hostname: IMPERFECT
  • MAC: 30:C5:99:7*:**:**
  • IP: 192.168.2.20

IMPERFECT releases and renews its DHCP lease. Gets 192.168.2.20. Dashboard accessible from the main workstation.






Step 8 — Reboot Test.

DOES IT SURVIVE?

Power → Reboot from the dashboard. USB disconnected. The OptiPlex boots from the Hitachi on its own.

LAN comes up at 192.168.2.1. DHCP serving. IMPERFECT gets its IP. Dashboard loads.

The installation survives a cold reboot without the USB. OPNsense is running from the Hitachi exactly as intended.



The Current State.

HONEST STATUS

The firewall is protecting one machine. The OptiPlex sits on the desk with the PSU hanging outside the chassis — not pretty, not clean, but running 24/7 without complaint for a week straight. A few reboots to test stability, one power-down to move it to its current spot. That's it.

It's not where it's going to live permanently. This is a temporary position until the next piece of hardware arrives and everything gets its final home. Could be weeks, could be a couple of months. For now, it works — and that's what matters.


One week of real production use. No crashes, no drops, no surprises. The hardware is proving itself.

What's Next.

THE NEXT FEW DAYS

A second switch goes in — the NUC and the NAS connect to it, and a few services start coming online. More on that in a separate post.

The bigger move is getting OPNsense in front of the entire network. Right now I'm missing MacroDeck, Moonlight, and Odoo — all three depend on IMPERFECT being reachable across the network, and that path currently goes through the ISP router, not the firewall. That needs to change in the next few days.

The plan is already staged. The cables are ready. The APs are next.




What This Actually Took.

THE REAL SUMMARY

I rescued some hardware from a trash pile. I have a generic ATX PSU, a 160GB mechanical drive with a clean SMART report, and a USB Ethernet adapter. Total cost: under $40.

There's a reason this build looks the way it does.

Right now, I can't buy everything brand new and run this on perfect hardware. It's not about being cheap, and it's definitely not a minimalist aesthetic. If I could, I'd gladly build this with newer equipment. But I needed the protection and the services now, not someday when my budget finally catches up.

After years around technology, you end up collecting pieces along the way. You get old hardware that survived moves, forgotten boxes, and abandoned projects. These things still work. Giving them a second life makes more sense to me than letting them sit on a shelf and decay.

There's another reason behind this setup, too.

I've already tried the subscription route. I've used cloud services, managed platforms, and software that makes you feel like your data belongs to you right until you stop paying. I learned how quickly years of information can vanish when it all depends on someone else's system.

After that, my view on technology changed.

So this setup exists for a reason.

It isn't elegant. It isn't modern. It definitely won't end up in a showcase full of perfect homelabs and spotless racks. But it has something I missed for a long time: it feels like mine.

I know exactly what's running, where it's running, and why. When something breaks, I don't wait for a support ticket or an automated reply. I open the machine, check the logs, get my hands dirty, and fix it.

Maybe it looks improvised from the outside. But to me, it feels familiar. It reminds me of a time when technology was something you could understand, repair, and keep alive with patience instead of subscriptions.

The hardware is set up. The software is running. The firewall is back, even if only partially. And for now, that's enough.


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.


RELATED POSTS

  • My Network Has No Firewall Right Now. Here's Why That's Temporary. — Post #009
  • The NUC Wasn't the Problem. The Power Strip Was. — Post #010

Comments

Popular posts from this blog

From Fear to Control: What Self-Hosting Gave Me

When One Problem Turns Into Two

Google Photos Was Free. Until It Wasn't. Here's My Setup Now.