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.

That took me an embarrassingly long time to see clearly. 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 on top exposes maybe a tenth of that. The capability is not missing. It is unreachable, because somebody decided years ago which checkboxes the product would have.

So the complaint is not that consumer gear is underpowered. It is that it 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 first thing you want and cannot have is history. The box knows which clients hold a lease right now and forgets almost everything else when it restarts: no per-client traffic record, no DNS query log, and rarely a syslog stream you can send somewhere that keeps things. Every diagnostic question about last week is therefore unanswerable, and the failure is silent - nothing anywhere tells you the data was never collected in the first place.

Then comes segmentation, which a guest network is not. A consumer guest network is one extra SSID plus a rule saying its clients may not reach the local subnet. That is genuinely useful and it is not segmentation. A VLAN is a separate broadcast domain with its own address range and its own policy in both directions, which is what 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. Address reservations run out at some count nobody documents. You cannot hand different DHCP options to different segments, point one group of devices at one resolver and everything else at another, or serve an internal name for a machine in the building. So everything is referred to 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 this point you want to know what is actually 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 at all. You are running an internet-facing Linux system at the edge of your home and 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 wireless 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. That is a different evening.

So the axis is not cheap against expensive, or consumer against professional. It is whether the five decisions can be made independently - placed, upgraded and allowed to fail on their own schedules. The all-in-one welds five decisions of genuinely different shapes into one and hands the bundle to a vendor to schedule on your behalf.

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 rather than where the cable landed. This is the option that fixes the physics, and the one a household notices first, because coverage stops being an antenna problem and becomes a placement problem with a known answer. The cost is three configuration surfaces instead of one and a cable run you were hoping to avoid.

Buy one vendor's controller. A prosumer ecosystem where a single 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. It buys most of the visibility for a fraction of the effort, and for a lot of people it is the right answer. Be clear what it costs: you have swapped a small closed firmware for a larger one, the controller is now a dependency of your network, and where the vendor hosts it 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, and a configuration you can read, diff and restore from a file. It also buys you the pager. There is no support number, and 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, and - this is the part that matters - it was never stated anywhere. Updates simply stopped, no announcement was made, and the device carried on working perfectly. Nothing about an unsupported router looks unsupported, which is why nobody replaces one.

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 what that does and does not do. It does not require the period to be long. It requires it to be stated, 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 rather than something a buyer can 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 - a camera, a doorbell, 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 is a genuine mismatch rather than an enthusiasm, and it is the single 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. This is the only one of the three you can ask before spending anything, and for the buyers who should keep an all-in-one and simply buy a better one, it is the whole decision.

For an enormous number of households the all-in-one is simply correct, and 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. Nobody has to know what a VLAN is. Recommending a separate firewall to somebody who wants working wireless is recommending a hobby and calling it a solution.

The honest test is not technical at all. It is whether anybody else in the building can fix the network when the person who built it is away for a week. A house that depends on one person's memory of how the firewall rules are ordered has traded a vendor's opacity for a household's, and the household version is worse, because the vendor at least publishes a support number and does not go on holiday.

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 - firewall, switch, segments, 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, not the firewall.

I should be careful with the word "own". 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. That is a smaller claim than the one usually made here, and the only one I can defend - not more control in the abstract, just more of the failure landing where you can read it.

What stays with me is the reboot. 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.