So You've Decided to Become Your Home's IT Department

Thu, 11 Jun 2026 00:00:00 +0000

Nobody hired me. There was no interview, no offer letter, no salary negotiation. One day I installed a NAS, and somewhere between the third Docker container and the first VLAN, I had silently become the Head of IT of a small but extremely demanding organization: my home.

The job comes with everything a real IT department has, except the parts that make it survivable. There is a helpdesk (it’s me), a security operations center (also me), a change advisory board (me, talking to myself in the shower), and an escalation path (me, but more stressed). There is also a user base with a zero-tolerance SLA, whose entire ticketing system consists of one sentence: “the WiFi doesn’t work.”

Today I want to share two recent incidents from this prestigious career. Both are entirely self-inflicted. Both taught me something. Neither was the WiFi’s fault, although you can guess what the tickets said.

Incident 1: My security system arrested my security system

I run Frigate as my NVR, with a handful of Tapo cameras streaming RTSP over a dedicated camera VLAN. I’ve written about this setup before, it works great. The whole stack is deployed via Komodo, my GitOps control plane, so updating a service is a one-click “pull and restart.”

On the firewall side, my OPNsense box runs CrowdSec, an intrusion prevention system that watches traffic and bans IPs that behave suspiciously. It does an excellent job of dispatching the endless parade of bots knocking on the WAN side, and it acts as a nice layer of protection for my self-hosted websites. I was very proud of it. Remember that, it matters for what comes next.

One evening, I open Frigate and every single camera says “No frames received.” All of them. At the same time.

Now, one camera down is a camera problem. All cameras down is a me problem. So I started digging, in the order any seasoned home IT professional would: blame the cameras, blame the switch, blame the NAS, blame Frigate, restart things at random, and only then, look at actual evidence.

The evidence was in the OPNsense firewall logs. There it was, a rule quietly dropping hundreds of connection attempts from my NAS toward the cameras on port 554, the RTSP port. The rule’s name? “CrowdSec (IPv4) out.”

Here is what had happened, in the dry language of a post-mortem:

Komodo did a routine pull-and-restart of the Frigate stack.
On startup, Frigate’s ffmpeg processes all tried to reconnect to every camera at once, and retried aggressively when the streams weren’t instantly back. Roughly 770 connection attempts to port 554 in a short burst.
CrowdSec looked at this flood of connection attempts and concluded, quite reasonably, that an attack was in progress.
CrowdSec banned the cameras. Not the machine doing the hammering: the machines being hammered. It looked at a mugging and arrested the victims.

My intrusion prevention system had decided my security cameras were the threat and thrown them in jail. The cameras had done nothing. They were sitting quietly on their VLAN, minding their own business, when my NVR started knocking on their door a few hundred times a minute. The guard had handcuffed the witnesses.

The fix took one line on the firewall, once per camera:

cscli decisions delete --ip <camera IP>

followed by the step I should have done on day one: whitelisting my own LAN subnets so CrowdSec focuses its zeal on the actual internet, where the actual attackers are.

In a real company, this is the moment where the security team and the infrastructure team have a tense meeting with a slide titled “Lessons Learned.” In my company, both teams are me, so I just sighed in two different tones.

Epilogue: once bitten, twice wrong

Two days later, one camera dropped off Frigate again. Armed with my hard-won experience, I knew exactly what this was. CrowdSec. Again. The overzealous guard had struck once more. I went straight to the firewall, ready to deliver justice.

The firewall logs showed zero dropped packets. The ARP table showed the camera wasn’t even on the network. It had simply… gone offline. A power cycle of the camera fixed it in thirty seconds.

This is the other trap of being your own IT department: after your first dramatic incident, every new symptom looks like the last root cause. The previous outage doesn’t just cost you an evening, it installs a bias in your head, free of charge, forever.

Incident 2: The automation server that politely refused every IP address in the house

Second story. I run n8n, a workflow automation tool, in a small container on my Proxmox cluster. It triages my email, files notes, does glue work I’d otherwise do by hand. It is, ironically, supposed to save me time. It had been running flawlessly for six days. Remember the cameras? Same energy.

The first symptom arrived through the usual enterprise-grade monitoring channel: people in the house reporting that the WiFi was acting up. Devices that were already online were fine, but anything new (a phone waking from sleep, a laptop coming home) just would not connect. The general “internet feels haunted” vibe that users report as, you guessed it, “the WiFi doesn’t work.”

The WiFi was innocent. The radios were radioing. The problem was one layer up: new devices couldn’t get an IP address anymore, because there were, technically speaking, no IP addresses left.

A quick search suggested a known compatibility issue between my DHCP server (Kea, on the OPNsense firewall) and WireGuard. The internet was confident. The internet was also wrong, which is worth remembering: when you are the entire IT department, your only coworker is a search engine, and that coworker has strong opinions and zero accountability.

The lease table, on the firewall at 192.168.1.1, told the real story. Of the 253 usable addresses in the pool, 224 were marked DECLINED. Not in use. Not expired. Declined, as in: the server had offered them to someone, and that someone had said “no thanks, this one’s taken.” Two hundred and twenty-four times in a row.

Here is the loop that one single machine had been running, one address every ten seconds or so, for 75 minutes straight:

Ask for an IP address.
Receive an offer.
Probe the network to check the address is actually free (a responsible, standards-compliant thing to do).
Hear its own probe echoed back by a confused virtual bridge, and conclude the address is taken.
DECLINE the address, which the server then quarantines for 24 hours.
Go back to step 1, with the next address.

It worked its way through the entire pool like that, politely refusing every single IP address in the house and getting each one locked away for the day. By 12:21 the server’s log said it all: allocation failed, subnet empty. Devices holding an existing lease never noticed a thing. Anything new got silence. (Which looks like DNS being down. Which looks like the WiFi. Which is what the ticket said.)

All that remained was finding who. The lease table only had a MAC address with a Proxmox vendor prefix, so I went hunting through all 49 VMs and containers in the cluster. The culprit: container 152. The n8n machine. My automation server. The machine whose entire job is doing things for me had spent its lunch break doing this to me.

The fix had two parts: bulk-delete the 224 quarantined leases on the DHCP server and restart it, then restart the n8n container so its network plumbing got rebuilt. And here the story delivered its best plot twist: n8n refused to start. Why? Its disk was full. Why was its disk full? Because it had spent 75 minutes writing log lines about every IP address it was declining. The machine had documented its own rampage so thoroughly that it bricked itself with the paperwork. The arsonist died of smoke inhalation. One disk resize later, it booted, took an address, kept it, and went back to sorting my email like nothing had happened.

Final thoughts

So, does any of this stop me? Not even a little.

The learning is part of the fun. That’s the whole deal with running your own infrastructure: every incident is stressful for an hour and fascinating forever. A cloud camera that stops working is a mystery you’ll never solve. My cameras stopped working and I got a detective story with firewall logs, wrongly accused cameras, and a confession. My IP addresses vanished and I got a whodunit with a MAC address for a fingerprint and a lineup of 49 virtual machines.

Sure, it gets a bit stressful in the moment. There are people waiting on that WiFi, and the person who broke it, statistically speaking, is me. But the moment the cause finally clicks into place, when the weird symptom, the misleading theory, and the innocent-looking log line suddenly snap into one coherent story, that feeling is hard to beat. You don’t get it from things that just work, and you definitely don’t get it from things that break somewhere you’re not allowed to look.

The helpdesk remains open. The tickets remain “the WiFi doesn’t work.” And the Head of IT remains, despite everything, happily unfired.

DHCP | Antoine Weill--Duflos

So You've Decided to Become Your Home's IT Department

Incident 1: My security system arrested my security system

Epilogue: once bitten, twice wrong

Incident 2: The automation server that politely refused every IP address in the house

Final thoughts