Five Devices in One Plastic Box

The box your internet arrives through is wearing five hats at once. It terminates the provider's connection and does the routing. It is a switch, with four ports on the back. It is a wireless access point, usually two, one radio per band. It is the firewall, which in practice means address translation and dropping anything unsolicited. And it is the DHCP server and the DNS forwarder, which is to say it decides what everything on your network is called and who answers when one of them asks a question.

The pretence holds beautifully, for years, because nobody asks any of the five to do anything in particular. Addresses get handed out, pages load, the television finds the internet, and the only maintenance anyone performs is pulling the power for ten seconds. Shipping a device that a stranger sets up in a hallway without reading anything, and that then runs untouched for a decade, is a real piece of engineering, and most of the people who sneer at it have never had to do it.

Then you ask one question.

Which device pushed two hundred gigabytes out of the house last Tuesday. Why does the printer lose its address every few weeks. Can the doorbell camera reach the file server, and if it can, how do I stop it. Which resolver is the thermostat using, and what has it been asking for. Every one of those is an ordinary question about a network, none of them can be answered by the box, and the reason has nothing to do with how fast it is.

The limit is almost never performance. The silicon in a mid-range consumer router runs a Linux kernel with a full packet filter, a real bridge, a VLAN-aware switch driver, and a capable DHCP and DNS daemon underneath it, and the interface exposes maybe a tenth of that. The capability sits there unreachable because somebody decided years ago which checkboxes the product would have.

The complaint is that consumer gear is closed, undiagnosable, and unowned. When something goes wrong you cannot see why, nothing kept a record of what happened, and the vendor's answer to every question, genuinely the only branch in the support script, is to reboot it.

A reboot that fixes a problem without explaining it has not fixed anything. It has bought you an unknown amount of time and destroyed the evidence.

Visibility goes first. The box knows which clients hold a lease right now and forgets nearly everything else when it restarts: no per-client traffic record, no DNS query log, rarely a syslog stream you can send anywhere that keeps things. Every question about last week is unanswerable, and the failure is silent. Nothing tells you the data was never collected.

Then comes segmentation, which a guest network is not. A guest network is one extra SSID plus a rule saying its clients may not reach the local subnet. Useful, and a different thing. A VLAN is a separate broadcast domain with its own address range and its own policy in both directions, which lets you say the cameras may reach the recorder, the recorder may reach nothing, and the laptop may reach both. One checkbox cannot express that shape.

Then come names and leases. Reservations run out at some count nobody documents, and you cannot hand different DHCP options to different segments, point one group at one resolver, or serve an internal name for a machine in the building. So everything goes by address, the addresses drift when something reboots in the wrong order, and you end up maintaining a hosts file by hand on four laptops.

Then comes firmware you cannot audit. By now you want to know what is running, when it was last patched, and how much longer patches will arrive. A consumer device answers the first with a version string that maps to no published changelog, the second with a date and no detail, and the third with nothing. You are running an internet-facing Linux system at the edge of your home. You cannot enumerate what is inside it.

The five roles want different placement. A radio wants to be high, central, and in open air, because that is physics and no antenna design argues with a floor joist. Routing wants to be wherever the line from the street enters the building, which is a closet, a garage, or the corner of a room chosen by whoever ran the cable in 1998. One device cannot satisfy both, so every all-in-one is sited for the cable and the coverage is whatever that leaves you.

They also want different clocks. Wireless generations turn over every few years and there is a real reason to follow them. A firewall moves on kernel and vulnerability time, which is faster and much less predictable. A five-port switch is fine for fifteen years and will outlive the house's other electronics. Fusing all three into one purchase means every upgrade is all five at once. You replace a working switch and a working firewall to get a newer radio, and you do it again in three years.

And they share a failure domain, which is the part that bites hardest at the wrong hour. A wedged wireless driver takes DHCP down with it, because both are processes on one small system whose only recovery mechanism is a power cycle. Split apart, an access point that stops responding is a wireless outage while everything on a cable keeps working, and you can go and look at the router's logs to find out which one actually failed, which is a different evening.

Separate the roles yourself. A dedicated router or firewall where the line comes in, a managed switch behind it, and access points placed where the radio wants to be. This is the option that fixes the physics, and the one a household notices first: coverage stops being an antenna problem and becomes a placement problem with a known answer. The cost is three configuration surfaces and a cable run you were hoping to avoid.

Buy one vendor's controller. One controller configures the gateway, the switches, and the access points together, and gives you the client history, the VLANs, and the per-device policy the consumer box will not. Most of the visibility for a fraction of the effort. For a lot of people, the right answer. What it costs: a small closed firmware swapped for a larger one, and where the vendor hosts the controller your topology lives on their server.

Run the open one. OPNsense or pfSense on commodity hardware, or OpenWrt on a device that supports it. This buys the most by a wide margin: real logs, packet capture, a package manager, a configuration you can read and restore from a file. It also buys you the pager. The upgrade that breaks the internet breaks it for everyone in the building while somebody is on a call.

A router is bought once and stays on the network until it dies or the provider changes something, which is a decade at least. The window in which the manufacturer ships security fixes has historically been a couple of years. It was never stated anywhere, and that is the part that matters. Updates simply stopped, no announcement was made, and the device carried on working perfectly.

An unsupported router looks exactly like a supported one, which is why nobody replaces it.

The United Kingdom closed that specific gap first. The Product Security regulations came into force on 29 April 2024 and require a manufacturer to publish a defined support period: the minimum length of time security updates will be provided, in language a non-technical reader can follow, free, without being asked for it, and without handing over personal details to see it. Once published it may be extended but not shortened.

Notice the shape of that. The rule sets no minimum length, only a duty to print one, which is a smaller-sounding change with a much larger effect, because you cannot compare products on a number that is not printed anywhere. The moment two boxes on the same shelf carry different support periods, one of them has a reason to be longer, and that is the first competitive pressure this category has ever felt on the axis that decides its useful life.

Regulation (EU) 2024/2847, in the Official Journal on 20 November 2024, goes further and sets a floor rather than a disclosure duty: vulnerability handling for at least five years, unless the product is genuinely expected to be in use for less. Its substantive obligations land later in the decade, so as I write this it is a direction of travel that a buyer cannot yet lean on, and both instruments are European. Anyone else benefits only where a manufacturer chose to run one policy worldwide.

What an expired horizon costs is not hypothetical. CVE-2023-1389, published in March 2023, is an unauthenticated command injection in a mainstream consumer router's web interface: a country parameter passed into a shell call without sanitizing, commands running as root, reachable by anything that can talk to the management page.

CISA added that one to the catalog of vulnerabilities known to be exploited on 1 May 2023, which is the formal way of saying somebody was already using it, and it got fixed. The support horizon is the answer to what happens with the next one, on a device three years past its last update and still doing its job flawlessly.

Is there anything here to segment? If everything in the building is a laptop or a phone belonging to somebody you trust, segmentation buys you nothing and the box is fine. If there are devices you would not give a password to, such as a camera, a doorbell or a thermostat, anything with a cloud account and a firmware update process you have never seen, then you have two trust levels sharing one broadcast domain. That mismatch is the best reason to leave the all-in-one.

Who answers when it breaks? Not who builds it. Who fixes it, at nine in the evening, when the person who built it is somewhere else. If the answer is nobody, the right level of complexity is whatever that person can restore from a photograph of a settings page, and every step past it is borrowed against a bad night. This question disqualifies more open-source firewalls than any technical limitation does.

What is the published support period? Ask it of every candidate, including the expensive ones, and treat the absence of an answer as an answer: a vendor who will not commit to a number in writing has told you what the number is. It is the only one of these three you can ask before spending anything, and for anyone keeping an all-in-one it is the whole decision.

For an enormous number of households the all-in-one is simply correct. Everything above is a rounding error. It works, it is cheap, its failure mode is a reboot, and its recovery path is a phone call to the provider who will send a replacement. You never have to learn what a VLAN is, and the vendor at least publishes a support number and does not go on holiday.

Recommending a separate firewall to somebody who wants working wireless is recommending a hobby and calling it a solution.

That shrinks my claim, and it should. For most people the argument only gets as far as separating the radio from everything else: buy real access points, put them where the physics wants them, and leave the provider's box doing the rest. The full split into firewall, switch, segments, and logs earns its keep when there is something specific to segment and somebody who has agreed, out loud, to answer for it.

If I could keep one recommendation from this piece it would be the access points. The firewall is the one I would give up first.

Running your own edge removes no vendor from the path. The provider still terminates the line, the access point still runs radio firmware nobody outside the manufacturer has read, and the switch is running something too.

What moves is the boundary of what you can see.

The reboot is the tell. It is the only tool the box hands you, it works often enough to be believed, and every time it works it destroys the record of what went wrong. Ten years of that is a network nobody has ever diagnosed, at the edge of the house, quietly running software older than the phone you last rebooted it from.