Bridges go offline / fail to pair across VLANs after enabling native HA Matter Server & OTBR

[BorjaIglesias]

Hi everyone,

I've been successfully using matterhub to expose my Home Assistant entities to Google Home. However, I recently enabled the official Matter Server and Open Thread Border Router (OTBR) add-ons in HA to connect native Matter over Thread devices directly. Since then, my matterhub integration has broken.

Environment:

• Home Assistant running on Proxmox.
• UniFi Network heavily segmented with VLANs (HA is on HomeLab VLAN 10; Google Home hubs are on Multimedia/IoT VLANs 30/40).
• UniFi mDNS Reflector is enabled and was working perfectly before.
• IPv6 ULA (fdXX::/64) is properly configured across all involved VLANs.

Symptoms:

• All previously working matterhub devices in Google Home are now offline.
• If I try to commission a new matterhub bridge while my phone is on the Google Home VLAN, the discovery fails entirely.
• If I move my phone to the same VLAN as HA (HomeLab), the commissioning succeeds, but the devices immediately fall into an "Offline" state in the Google Home app.

Troubleshooting:

1. Port Clash Ruled Out: I suspected a UDP port collision on 5540 between HA's native Matter Server and matterhub. However, changing the matterhub bridges to use ports 5541, 5542, etc., does not fix the offline issue.
2. mDNS / Interface Poisoning: Doing a packet capture on the UniFi gateway shows traffic crossing, but it seems Google Home cannot establish the final IPv6 route. I strongly suspect that when OTBR is enabled, it creates new network interfaces (like wpan0) and messes with the host's IPv6 routing table.

Is it possible that matterhub gets confused by the new OTBR interfaces and starts broadcasting its Link-Local address (fe80::) or the Thread subnet address via mDNS, instead of the routable ULA (fd10::) of the main host? Since fe80:: is not routable across VLANs, Google Home would fail to connect after the initial handshake.

Is this a known issue when running native OTBR alongside matterhub in a segmented network?
Is there a workaround to force matterhub to bind to a specific network interface or explicitly advertise the routable ULA address instead of picking the default/wrong one?

Any insights would be greatly appreciated!

[RiDDiX]

Enabling OTBR adds a Thread interface (wpan0) with a non-routable fd:: address. Without a pinned interface, matterhub advertises on all of them, so Google Home can grab the wrong address and the devices go offline.

Pin it to your LAN interface and restart:

mdns_network_interface: eth0

(use your actual LAN interface name). That keeps the advertisement on the routable fd10:: only.

mdns_strip_global_ipv6 will not help, the Thread address is a ULA, not global. And if discovery from the Google VLAN still fails, that is your mDNS reflector not carrying the records across, not matterhub.

Next alpha warns you about this in the log too.