HomeLink L2 — extending your home network

When a routed tunnel is not enough — Matter, discovery, and the three faults that look like a broken VPN but are not.

Updated 26 August 2026 networkingtroubleshootinghomelink

HomeLink L2 does not connect two networks. It extends yours: the hosted Home Assistant becomes a member of your home LAN, on the same broadcast domain as the bulbs, speakers and Thread border router. Discovery and Matter then behave as they would on a machine plugged into your switch.

A routed tunnel (L3) is enough for anything that already has an address — ESPHome, MQTT, Bluetooth proxies. Broadcasts are designed never to leave your LAN, so they never arrive. That is the protocol working, not a slow link. See when devices are not discovered.

Before it is switched on

L2 is set up deliberately, not by default. It installs a small always-on box on your LAN and moves the LAN address onto a bridge. That is the whole configuration, and it is also every trap.

Set it up is the how-to, including why the rollback, the boot unit and the watchdog are shaped the way they are. This page is what it looks like when something is already wrong.

It arms an automatic rollback first. If the box becomes unreachable, it undoes itself without anyone visiting the house. Do not reboot it, and do not "fix" the network, while that rollback is armed — silence is what restores it.

When it goes wrong

These are faults we have seen on a live house, with the tunnel looking healthy the whole time. Tell support which signature you have; include that IPv4 discovery works if it does.

Slow on a fast line

L2 bridges your LAN into a VXLAN that rides inside WireGuard. On a box whose default route is that bridge, lowering the tunnel MTU lowers the bridge, which then fragments the tunnel's own packets. There is no stable value — each attempt ratchets down. At the default 1420, every WireGuard packet was being fragmented on egress. Measured on a 300/300 line: 4.3 Mbps.

The fix is a route-specific MTU for the tunnel endpoint, stating that the host's own packets leave by the physical NIC at 1500. Same line, same defaults: 296 Mbps. We set this; it is not something to tune in Home Assistant.

A guest NIC left at 1500 on this path silently black-holes large frames. A bridge does not fragment and sends no ICMP. Ours sits at 1370.

Ping works, copies do not

Pinning the tunnel MTU only governs what the tunnel endpoint itself sends. A phone on your LAN still negotiates MSS from its own 1500-byte MTU and hands the house box segments too big for the tunnel. Correcting that relies on an ICMP that consumer routers frequently drop. The flow does not fail — it stalls.

Every router path we ship now clamps MSS to the path, so we no longer depend on that ICMP. That includes the Windows helper, which until recently did not size the tunnel at all. If a large transfer still crawls after that, it is a different fault; tell support.

Fine until something rebooted

Three faults sat on the first L2 house box for days, and none of them could fire while the interfaces stayed up. A reboot for the first time since the work began brought the LAN back and left the hosted VM with no link home.

They shared a shape, not a cause:

• The change and its effect were separated by a reboot (a tunnel MTU of 1260 is below IPv6's minimum of 1280; the kernel removes IPv6 from the interface, wg-quick reports "No such device" for a device that is there, and tears the whole VPN down — IPv4 included).
• Each error message pointed away from its cause.
• Each failed into the same-looking state: the house looks fine, the hosted VM has no house LAN, and from outside it is indistinguishable from a broken tunnel.

A deliberate reboot belongs in the setup, as a tested step, before the box is handed over. A change that has not survived a reboot has not been tested, however long it has appeared to work.

The house box also has a watchdog. netplan still owns the physical NIC, and on a carrier event it will take it out of the bridge while the machine is running. Arguing over ownership has to be won on every host, forever; the watchdog repairs the specific failure in about 80 seconds instead.

Matter still missing

A healthy IPv4 test proves nothing about IPv6. Bridged IPv6 was being dropped by the datacentre firewall while IPv4 mDNS worked perfectly — devices appeared, then went unavailable the moment anything tried to reach them. Multicast snooping on the bridge black-holed IPv6 toward the tunnel the same way, and flooding both ends was the fix that actually worked.

Home Assistant also picks a NIC per service. With two interfaces it can advertise Matter onto the management network (a segment containing only our infrastructure) while the house LAN full of real devices goes unused. L2 servers keep both NICs; the house one is primary and the management one has no gateway, so it stops competing. Management still works because forwarded traffic is masqueraded onto the management subnet — the guest replies to something on its own LAN and never consults a default route.

If IPv6 is flowing and Matter still asks for a border router, the next question is not about the tunnel. Appearing in the Thread panel is not the same as Home Assistant holding the Thread credentials, and on Android that message is usually about the phone rather than the server. Work through adding a Matter-over-Thread device, which separates the four failures that all look like a missing border router.

Be careful with short packet captures here. A 60-second window that shows no _meshcop._udp looks like a border router advertising nothing, and once sent us chasing a fault that did not exist — services do not rebroadcast continuously once cached.

The longer write-up of the wrong turns is Four megabits on a three-hundred line, part two of a three-part series that starts with the bulb that caused all of this.