How your server is kept apart from others

Each Home Assistant is its own virtual machine, and now its own network stack as well. What used to keep tenants apart was a firewall rule on a shared bridge — real, working, and the wrong failure mode. Here is what replaced it, and how we check it rather than assert it.

Updated 28 August 2026 networkingsecurityisolation

Your Home Assistant is a separate virtual machine: own disk, own kernel, own network identity. Hardware is shared with other tenants the way it is on any reputable host. The interesting question is whether those machines can reach each other. They should not.

Until recently they sat on one shared bridge, in one flat subnet, and what kept them apart was a firewall rule dropping traffic from that bridge back to itself. That rule was real — it dropped thousands of packets — but it was a configuration rather than a separate network stack, and a configuration can be rebuilt without it. One firewall reload did exactly that and took four servers offline; isolation survived only because a duplicate rule happened to be sitting somewhere nobody knew was load-bearing.

As of 28 August 2026 each server has its own network namespace — its own routing table, its own bridge, its own interfaces — and the shared bridge has been retired: it has no ports left on it. Being on separate stacks is not by itself the whole answer, and we would rather say so than imply more: the host still has one connection into each tenant, so it could route between them, and what stops it is a firewall table with a default of drop. That table is deliberately not the general-purpose firewall, because the general-purpose one is the thing that got rebuilt without its rules.

The difference that matters is the failure mode. If that table goes missing, tenants lose their connection to us — loudly, immediately, visibly. It cannot fail in the direction of quietly joining them together.

The short version of the security page still applies: we do not say "virtually separated", and we do not say a firewall is no longer involved. The replacement still has a host-side filter. That is a virtue — inbound traffic to a shared public IP always lands on the host, so something has to refuse to forward it between tenants.

Why the current rule is the wrong failure mode

Three things the rule depends on, all found the same week:

1. A kernel switch. Bridged frames only reach the firewall because bridge-nf-call-iptables is on. Set it to off — a tempting "fix" when bridged traffic is being filtered unexpectedly — and the DROP never sees the traffic. Isolation vanishes and nothing looks broken.
2. Rules surviving a reload. A ufw reload rebuilt its chains from file and silently discarded every runtime-inserted rule, taking all four hosted VMs off the network at once. Isolation held only because a second copy of the DROP happened to live in FORWARD as well.
3. Something restoring them at boot. The host firewall save file is written and never replayed. Every rule there is runtime-only, surviving on the machine not having rebooted.

None of these fail loudly. A tenant would not notice gaining reachability to another tenant, and neither would we. Silent loss of isolation is the one failure mode a multi-tenant host must not have.

Overlapping home subnets are already handled: three customers currently use 192.168.1.0/24, each in its own routing table selected by the VM's source address. A VM with no matching rule reaches no house at all.

What we measured and rejected

Separate bridges, policy routing, and VRFs were measured on this host. They are not the destination.

Per-VM bridges, still in the host's network stack. Removes layer-2 adjacency — no shared broadcast domain, no ARP spoofing. Does not isolate at layer-3. The host holds a connected route to every tenant and will forward between them unless a FORWARD rule says no. Better than today (the rule no longer depends on bridged-frame filtering), not strong.

Per-VM routing rules plus a blackhole. Fails open: lose the rule and the lookup lands in the main table, which has every tenant. That is the current HomeLink mechanism, and the same failure mode.

A VRF per VM. Measured, and it needs more than a VRF. Connected routes are confined, but a lookup miss falls through to the main table and lands on the shared bridge. An unreachable default closes that — until internet egress re-opens it, at which point a leaked default sends everything unmatched to the WAN, other tenants included. Upstream drops private address space; isolation that relies on someone else's router is not isolation. The leak cannot be designed out of a VRF; it can only be configured around.

What tipped it

Against VRF specifically — which works, on this host — the gains are two, and the second is the one that decides it:

1. The main-table fallthrough cannot exist. A VRF has to be configured out of leaking; a namespace has nothing to leak into.
2. HomeLink's source-based routing disappears. Overlapping customer LANs currently need a rule that must move in lockstep with any address change or the customer silently loses their house LAN. Inside a per-VM namespace those are ordinary routes in an ordinary table. That deletes a live class of bug rather than mitigating it.

If only (1) were on offer, VRF would be the better trade: namespaces make every diagnostic one command further away, at the moment someone is under pressure. (2) is what tips it.

The shape: each VM gets its own network namespace. The guest's bridge, taps and HomeLink live inside it. The host holds the WAN, the port forwards, and one veth per tenant — and will not forward between those veths. A table that ufw cannot rebuild, with policy drop, closes the remaining hairpin. An empty table takes tenants offline (loud) rather than joining them (silent).

If the hook that moves a VM's network into its namespace fails, the VM comes up with no uplink. That is a new failure mode, and it is the right trade: loud, not silent.

What must still be true

We write these as tests rather than trusting a review. Isolation is probed from a tenant's position, not by confirming a rule exists. It must hold with bridged-frame filtering off, after a firewall reload, and for IPv6 as well as IPv4.

A dedicated machine per tenant is stronger still. That is a product tier, not this change. This is the strongest design that still shares a hypervisor.

Where this actually stands. Every server running today is on its own stack, the production one included, and the isolation probe passes from inside each of them. Two things are honestly still in progress: the code that puts a newly created server straight onto this design is written and tested but has not yet built one, and there is one host in this account, so none of it is proven across a fleet.

A dedicated machine per tenant remains stronger than any of this. That is a product tier, not this change.

The longer write-up of the measurements is Isolation that fails closed. The dated security account, including what we cannot yet claim, is Security and privacy.