I set out to write about the writing room’s physical layer. The argument was clean. Everything I have built, the databases that hold my series canon, the memory the AI queries, the servers the whole operation runs on, sits on a network. I had spent a year preaching data classification at the software layer and never once looked at the wire. So I would look at the wire.
I had a source for what I would find. My own planning doc, written six days earlier, said the network was flat: one address space, no segmentation, thirty-plus IoT devices sharing a broadcast domain with the box that holds my canon and my health data. I wrote fifteen hundred words on that premise. It was a clean draft. It was also wrong, and the thing that caught it was the one rule I will not shut up about.
Read the source. Never your memory of it.
The Doc Was Confident, and the Doc Was Wrong
Before I shipped, I opened the actual firewall and read the ruleset. Not my notes about the firewall. The firewall.
The network was not flat. The wireless IoT was already segmented, sitting on its own interfaces behind the firewall, with rules that block it from reaching the box I had spent a draft worrying about. I had done the exact thing my article was about to accuse me of skipping. My own documentation had not merely gotten it wrong. It had gotten it wrong with confidence, complete with a paragraph explaining why segmenting the IoT was impossible on my current gear. A wrong answer that arrives with a reason is the most dangerous kind, because the reason is what makes you stop checking.
That is the whole failure mode in one move. I trusted a summary of the system instead of the system. The summary had drifted. The system had not.
What the Wire Actually Said
Here is the receipt, because a claim about a firewall that does not show the rules is just one more summary.
Two separate interfaces carry the wireless IoT, each on its own subnet, neither of them the network where the canon lives. On the first, the rules read in order: let the IoT reach the name server on the main box for DNS, let it reach the home-automation controller, then block everything else from the IoT to the trusted network, then let it out to the internet. First match wins, so anything from a smart plug to my canon database that is not a DNS lookup hits the block and dies there.
The second interface is simpler still. Block to the trusted network, allow to the internet, no exceptions.
That is classification enforced at the wire. Not in the application, not in a policy document, in the packet filter. The exact thing my draft claimed I had failed to do, sitting right there in the ruleset, doing its job while I wrote an article about my own negligence.
The Map Is Not the Network
This is not a networking lesson. It is the writing-room lesson in a firewall costume.
The entire reason my writing room runs on a synthesis database instead of a pile of notes is that memory drifts. The AI remembers a character detail one way, the profile says another, and the database is the source while the memory is the summary. When they disagree, the summary loses. I built that discipline into the fiction on purpose. Then I walked over to my own infrastructure and did the precise thing the discipline exists to prevent. I read my notes about the network and reported them as the network.
Documentation drifts the same way memory does. The moment you write a system down, the note starts aging and the system keeps moving. Six days was enough. The doc said flat because flat was true at some earlier point, or because the person writing it reasoned about what the gear could do instead of reading what it was doing. That person was me. Either way, the map and the territory disagreed, and I trusted the map, because the map was in my own handwriting.
The Current State, Now That I Have Read It
Reading the source did not just spare me an embarrassment. It handed me an accurate map, which is what reading the source usually does. Here is the network I actually have.
The edge is a rented cable gateway feeding an aging pfSense firewall. Behind it is one flat trusted network. On it: the NAS that holds the canon, the memory the AI queries, and now the DHCP and DNS for the whole house, plus both office machines, the printer, and whatever IoT is hardwired to the wall. Off the firewall hang two separate IoT segments, each on its own interface, each walled off from the trusted side, served by an old single-band access point that predates most of the gear it protects. Two unmanaged gigabit switches tie it together.
That is a more segmented network than my own doc believed, and a more fragile one than I would build today. The segmentation is real, but it is hand-built and riding on gear that is aging out from under it. The firewall cannot upgrade itself. The access point can tag exactly one wireless network to a segment, which is the only reason an ancient AP is still doing IoT duty at all.
The residual exposure is narrower and more specific than the flat-everything problem I had invented. The wired IoT still shares the trusted network with the NAS. And the two IoT segments each keep a door open to the trusted side, one for DNS and one for the home-automation controller. That controller is inside. A compromised sensor does not reach my canon, but it reaches the automation box, and the automation box is on the trusted network. That is the kind of edge you only find by reading the rules instead of trusting a summary that says segmented, done.
Why UniFi
So why UniFi, and why now, if nothing is on fire.
Start with why upgrade at all. My planning doc gave three reasons, and reading the firewall deleted one of them: the flat-IoT emergency was never real. Two survive. The firewall is a maintainability dead end, an SG-1100 that runs out of memory and kills its own major upgrade on a gigabyte of RAM that cannot be expanded. Correct rules today, and no clean way to carry them forward tomorrow.
The other survivor is capability I already paid for. The NAS and both office machines have 10G network cards throttled to a gigabit by the switches in front of them. The fast hardware sits idle because the cheap gear between it and everything else cannot keep up. Neither the firewall nor the stranded 10G is a fire. Both are real.
Why UniFi specifically, over staying on pfSense or bolting separate boxes together. Because a network one person maintains is worth consolidating, not maximizing. UniFi puts the gateway, the switching, and the Wi-Fi under one controller that the gateway hosts itself. No separate management box, no hand-tuned integration to babysit.
The parts do specific jobs. The gateway carries the 10G uplink, built-in PoE, and an intrusion-detection engine. The managed switch unstrands the 10G on the NAS and the PCs and powers the access point. The new access point tags each wireless network to its own segment, which turns my hand-built IoT interfaces into managed segmentation that can grow instead of a clever thing I have to remember I did.
The honest tradeoff: pfSense is more open and more flexible, and I am giving that up. UniFi is a walled garden. For a network one person maintains next to a full-time job and a novel series, walled and integrated beats open and aging. I am not buying it to fix a breach. I am buying it because the firewall is on a clock and the fast hardware is asleep, and that is reason enough without inventing a crisis to justify the receipt.
Read the Firewall
I am the CISSP who wrote a security article about his own network and got the topology wrong. In my defense, I had a source. The source was me, six days ago, confident and wrong.
The writing room has a physical layer, and it has a lesson that does not care whether you are checking a character’s age or a packet filter. The map is not the network. I read my notes, and my notes lied. Then I read the firewall, and the firewall had been telling the truth the whole time. I just had to stop reading about it and read it.
You may also like: - The Architecture Underneath the Writing Room - Not All Data Is Created Equal - When the AI Service Dog Loses the Plot