Matter/Thread Commissioning Fails on Proxmox VM (HAOS) with ZBT-2 — Address Unreachable After PASE

Configuration Matter/Thread
, ,
1

Matter/Thread Commissioning Fails on Proxmox VM (HAOS) with ZBT-2 — Address Unreachable After PASE

Category: Matter/Thread
HA Version: 2026.6.1
HAOS Version: 17.3
Supervisor: 2026.05.1
Matter Server: 8.5.0
OTBR Addon: 3.0.1
Thread Radio: Nabu Casa ZBT-2 (USB, passed through to HAOS VM)
Thread Network: MyHome67, channel 15
Installation: HAOS as VM on Proxmox VE 9.2.3 (Lenovo ThinkCentre M920q)
Network: UniFi UDM SE, VLAN1 (192.168.1.x)

Summary

Matter-over-Thread commissioning fails via two different paths depending on the method used:

  • iPhone Companion app ("Add Matter Device"): Gets to "Setting Up" and stalls indefinitely. Nothing appears in Matter Server logs — the commission attempt never reaches the Matter Server at all.
  • HA web UI + BLE proxy (manual code entry): PASE completes successfully, device joins Thread mesh and gets ULA addresses, but the Matter Server then fails with "Address unreachable" for all Thread ULA addresses.

The Thread network is healthy, OTBR reports BBR Primary, but the Matter Server cannot reach newly commissioned devices via their Thread ULA addresses. Commissioning only succeeded briefly when an Apple Border Router (HomePod Mini or Apple TV) was the Thread leader — but this is limited to 4 devices due to Apple's secondary fabric limit, making it unworkable for a full deployment.

Hardware/Software Stack

  • Proxmox host: Lenovo ThinkCentre M920q, Proxmox VE 9.2.3
  • HAOS VM: qemux86-64, HAOS 17.3, HA Core 2026.6.1
  • Thread radio: Nabu Casa ZBT-2 USB stick, passed through to HAOS VM via USB quirk 303a:831a:gki
  • OTBR backbone interface: enp6s18 (configured in OTBR addon)
  • Apple Thread BRs: 2x Apple TV 4K + 4x HomePod Mini + 1x HomePod (normally on, ch25 Apple network)
  • Zigbee: SLZB-MR2 on Z2M channel 20 (separate, not related)
  • BLE proxy: SMLIGHT SLZB-06M running ESPHome BLE proxy (connected to Matter Server)

Background / History

This setup previously worked on bare metal HAOS with an SLZB-MR2 as OTBR on Thread channel 25. After migrating to Proxmox VM (~2 months ago), existing Matter devices continued working but commissioning new devices was intermittent — in hindsight this may have been working only when Apple BRs were active as leader.

Last week the following changes were made which triggered the current situation:

  • Switched from SLZB-MR2 to ZBT-2 as OTBR
  • Changed Thread channel from 25 to 15 (channel 25 was congested; channel 15 was chosen to reduce WiFi overlap)
  • Not all devices followed the channel change immediately, causing mesh fragmentation
  • Multiple backup restores were attempted, resulting in a mixed ch25/ch15 state
  • Eventually settled on ch15 with ZBT-2, but commissioning has not worked since

The SLZB-MR2 was also tried as OTBR on ch15 with identical commissioning failures, ruling out the ZBT-2 hardware as the sole cause.

  • Thread network forms correctly, OTBR becomes leader on channel 15
  • ot-ctl bbr state → Primary
  • ot-ctl state → leader
  • OTBR REST API reachable at 192.168.1.31:8081
  • BLE proxy connects successfully ([ble0] BLE proxy handshake complete) — however the BLE proxy connection is intermittent; it stops working after a period of time and requires an OTBR or Matter Server restart to reconnect. This makes repeated commissioning attempts difficult to coordinate.
  • PASE completes successfully — device joins Thread mesh and gets ULA addresses
  • OTBR logs confirm device registers as child with correct ULA address
  • BorderRouting sends correct RAs advertising fda0:6c81:cc96::/64 on enp6s18
  • BBR initializes: [NOTE]-BBA-----: BackboneAgent: Backbone Router becomes Primary!
  • Both OTBR and Matter Server addons have host_network: true
  • All iptables/ip6tables FORWARD chains: ACCEPT
  • OTBR firewall chains (OTBR_FORWARD_INGRESS, OTBR_FORWARD_EGRESS): ACCEPT all
  • IPv6 forwarding enabled globally (/proc/sys/net/ipv6/conf/all/forwarding = 1)
  • Matter Server correctly receives Thread dataset from OTBR via Supervisor (confirmed by Set config key threadDataset to <redacted> in logs)

What Fails

iPhone Companion App

Initiating "Add Matter Device" from the HA iOS Companion app results in the phone showing "Setting Up" indefinitely. Nothing appears in the Matter Server logs — no commission_with_code command is ever received. The failure appears to happen before the Matter Server is even contacted, possibly at the iOS commission sheet level when it tries to find a border router.

BLE Proxy Commissioning (HA web UI, manual code entry)

This path gets further. The Matter Server receives the commission request, discovers the device via BLE proxy, PASE completes, and the device joins Thread with ULA addresses. However the Matter Server then cannot reach the device:

CommissioningClient  Operational address for undefined set to udp://[fda0:6c81:cc96:0:56d2:5874:f3df:913]:5540
WARN  Commission~onnection Address udp://[fda0:6c81:cc96:0:56d2:5874:f3df:913]:5540 unreachable

Meanwhile OTBR debug logs confirm the device did join Thread and register its address as a child:

Mle-----------: Child 0x0001 IPv6 address[2]=fda0:6c81:cc96:0:d15f:e088:b415:eba

Note: After multiple failed attempts the Matter Server accumulates stale peer addresses and tries them all. Cleared by wiping /data/server-2-134b but the routing failure persists regardless.

Routing Investigation

IPv6 routes on HAOS VM host:

fda0:6c81:cc96::/64    dev wpan0    proto kernel  metric 64
fda0:6c81:cc96:ffff::/96  dev wpan0  metric 65535

The Thread ULA prefix only routes via wpan0. There is no route for fda0:6c81:cc96::/64 on enp6s18.

Manually adding the route does not fix commissioning:

ip -6 route add fda0:6c81:cc96::/64 dev enp6s18 metric 10

ping6 from HAOS host during live commissioning:

  • ping6 -I enp6s18 <thread-ula> → fails
  • ping6 -I wpan0 <thread-ula> → no response during active commissioning

DUA registration:

No BBA, DUA, or MLR entries appear in OTBR debug logs during commissioning attempts. Devices never register their Domain Unicast Addresses with the BBR.

OTBR/Matter Server Supervisor linking:

This was found to be broken initially — the OTBR integration in HA was stale (showed generic "OpenThread Border Router" instead of "Home Assistant Connect ZBT-2"). Deleting and re-adding the integration fixed the Supervisor injection of threadDataset into the Matter Server. However commissioning still fails after this fix.

Key Finding

OpenThread appears to be a userspace network stack. Traffic to Thread ULA addresses doesn't flow through the kernel's normal routing via wpan0 — it goes through otbr-agent's internal proxy. The kernel route on wpan0 is misleading and doesn't actually allow arbitrary processes to reach Thread devices.

The Matter Server needs to reach Thread devices through OTBR's backbone proxy, not directly via the kernel routing table. On native HAOS hardware (Green, RPi) this presumably works because everything shares the same network namespace in a way that allows this proxying. On a Proxmox VM, something in the container/VM network stack prevents this from working.

Things Already Tried

  • USB quirk 303a:831a:gki applied to ZBT-2
  • ZBT-2 moved off powered USB hub to direct rear USB 2.0 port
  • TREL disabled (ot-ctl trel disable) — eliminates multi-AIL detection but doesn't fix commissioning
  • OTBR firewall disabled in config
  • NAT64 enabled in config
  • Full Matter Server data wipe (/data/server-2-134b deleted)
  • OTBR integration deleted and re-added (fixed threadDataset injection)
  • Proxmox ebtables checked — only drops ICMPv6 RAs, not data traffic
  • iptables -P FORWARD ACCEPT on both Proxmox host and HAOS VM
  • ip6tables -P FORWARD ACCEPT on both
  • Manual IPv6 route addition for Thread prefix on enp6s18
  • OTBR addon restart multiple times
  • Matter Server addon restart multiple times
  • Full HAOS VM reboot
  • Both BLE proxy commissioning and iPhone Companion app commissioning attempted
  • Apple Border Routers powered off to eliminate PBBR competition
  • OTBR log level set to debug — confirmed BBA initializes but no DUA registrations occur

Questions

  1. On a Proxmox VM setup, how is the Matter Server supposed to reach Thread ULA addresses? Does it go through the kernel routing table or through OTBR's userspace proxy?

  2. Is there a known working configuration for Matter-over-Thread on HAOS in a Proxmox VM with ZBT-2?

  3. Should DUA registrations appear in OTBR debug logs when a device is commissioned? If so, why would they be absent even when BBR is Primary?

  4. Is there a way to verify whether the Matter Server's UDP packets are actually being sent and reaching wpan0, given that tcpdump is not available in the HAOS shell?

  5. Has anyone successfully commissioned Matter-over-Thread devices on Proxmox VM + HAOS + ZBT-2 without Apple Border Routers involved?

Related Issues / References

2

I have run that setup for a long time and it just works out of the box, if you have IPv6 enabled and do not spread any device related to Matter over multiple VLANs.

3

Thanks Wally, that was an oversight by Claude ai who I've been working with for four days trying to diagnose and fix my issues. I did read it, but obviously not thoroughly enough. What I meant to say was:

Has anyone successfully commissioned Matter-over-Thread devices on Proxmox VM + HAOS + ZBT-2 with Apple Border Routers also present on the network?

Do you have any IPv6 restrictions on the Proxmox host itself, such as sysctl ipv6 disable or ebtables rules? And does your router (mine is a UDM SE) send IPv6 RAs to VLAN1?

The other thing i'll mention is that the other PAN ID's when scanning using the OTBR Join section within the UI is neighbor Thread Networks - my devices are on 0xC5EA.

image
image874×569 16.5 KB

4

SOLVED: The root cause was net.ipv6.conf.all.disable_ipv6=1 in /etc/sysctl.d/99-proxmox.conf on the Proxmox host. This completely disabled IPv6 on all bridges including vmbr0/vmbr1, preventing the HAOS VM from passing IPv6 traffic needed for Matter/Thread operational commissioning after PASE. Removing these sysctl settings and re-enabling IPv6 on the Proxmox host immediately fixed commissioning.

5

Good to hear you found the solution. :slight_smile:

1 Like
6

Just want to verify something....I've seen another community thread where the BLE Proxy was failing unless the ESP was using the latest ESPressif framework (6.0.1). May I ask which version you used?

7

SLZB-06M running ESPHome 2024.9.2 (firmware 1.51). However this turned out not to be the root cause in my case — the fix was re-enabling IPv6 on the Proxmox host bridges (removing disable_ipv6=1 sysctl settings). BLE proxy was intermittently connecting but Matter commissioning was failing at the operational address stage due to IPv6 being disabled.