Thread/Matter, Router Rules, and Firewalls

Configuration
1

thought it would be helpful to explain what works for network configuration related to Thread. Specifically we saw Eve devices which is an early adopter of Thread and Matter behave erratically within HA but solid to Apple.

The focus of this discussion is limited to getting your Matter devices to work reliably on a local subnet if you are having problems.

The Theory

Matter is a relatively high level device interoperability protocol that can work over Thread which is a lower level IPv6-based protocol largely using mDNS which is itself based on UDP. Matter can also work over WiFi and therefore IPv6 and mDNS as well.

For Thread, a border router is used to communicate with Thread devices and anything else on your network like HA. A Thread border router may be an AppleTV, and Apple HomePod, a SkyConnect device, Google devices, or any anything implementing the Thread border router protocol. You may have more than one Thread border router and these can talk to other Thread border routers.

A border router may use or support services in a dual stack network that are IPv4 in addition to supporting the IPv6 Thread/Matter network (for example supplying a means for some app on the IPv4 network to control a Thread device through the border router). The communication here isn’t direct of course between IPv4 app and Thread device.

The network requirements

HA documentation states that the HA instance and the border router must be on the same subnet/VLAN. The underlying mDNS traffic is ‘link-local’ which means it is not routable between subnets/VLANs.

Thread devices themselves like Eve Window/Door set up their own communication IPv6 network using the Thread border router radio and then the border router communicates over your LAN or subnet to HA. On the network Thread resolves to mDNS and mDNS broadcast for service discovery.

So aside from HA and the Thread border router being on its subnet what needs to happen?

Your Eve/Thread devices may still be unreliable if mDNS traffic cannot operate within a single subnet. Some routers, especially custom managed routers, may not allow link-local traffic without some rules. In addition, a host firewall (i.e, HA host for example) may block mDNS or not allow traffic on the required ports.

Thread/mDNS traffic on the Ethernet/WiFi network is normally IPv6 that uses mDNS port 5353 and Matter uses 5540 for its service multicast. mDNS over IPv6 uses the multicast address ff02::fb.

In addition HA is known to use mDNS over IPv4 multicast address 224.0.0.251. This traffic may be related HA may broadcasting over IPv4 for the ‘Matter over WiFi’ case but there maybe another reason unrelated to Matter.

Router Traffic

So let’s look at this mDNS traffic from a network router’s perspective and then the HA firewall.

First, the router must allow mDNS traffic on the local subnet in which HA, the border router and the Thread devices reside. Some routers may allow this traffic by default. Some may have a check box to allow mDNS traffic, or if you manage your own router you need to have rules in place for the subnet where HA and the border router reside.

As an example, the following rules would suffice for a pfsense router firewall if the IOT subnet/VLAN was where the HA, border router, and Thread devices reside:

IOT_Rules
IOT_Rules1152×269 41.2 KB

In this case the following alias’ definitions are in place for the first three rules:
Source Addresses:

  1. VLAN69_IOT net = the local subnet interface network, i.e., any device address (IPv4 or IPv6) on this subnet as the source address, i.e., those assigned by DHCP/RA/SLAAC.
  2. link_local_IPv6 = fe80::/10 (link-local), fd00::/8 (ULA) as the source address
  3. link_local_IPv4 = 169.254.0.0/16 (also known as APIPA/self-assigned as source address; disabled if you don’t allow IPv4 self-assigned addresses as this is an edge case for brain dead devices).

mDNS_broadcastScope as the following IPv6 and IPv4 destination addresses

  • ff02::fb (IPv6 mDNS broadcast, typically Thread or any other IPv6 mDNS implementation)
  • 224.0.0.251 (IPv4 relates to HA mDNS broadcast for things like IPP)

mdns_Port = 5353, 5540 (mDNS port and Matter operational discovery port)

Note that these rules only address traffic on this subnet, not traffic entering the subnet/VLAN because the traffic is link-local by definition.

The second two rules relate specifcally to Apple HomeKit and HA, not Thread or matter although your border router may also require this traffic.
UnprivilegedPorts = 1024:65535

HA Firewall

Aside from those router rules, the HA host firewall on your HA instance or Host/HA network must allow that local mDNS/Matter traffic in addition to its own limited subset of unprivileged ports like 8123 TPC as well.

Limitations

Does all of this mean that you can’t seperate your IOT devices from your trusted network where HA would otherwise reside? One answer is it seems useful to put untrusted devices, non-Thread devices, on a separate network or VLAN from HA. The rub is that Thread is link-local and therefore the HA/Border Router restriction to one network segment is pertinent.

As far as I know there is no such limitation with Matter over WiFi if the devices are not simply using link-local IPv6 addresses. But that may be an implementation detail.

9 Likes
2

Does this apply to IPV4 WiFi-based Matter devices as well?

I just picked up a Nest Thermostat now that Matter in HA supports it and was able to get it to work on my main LAN (where my HA Yellow is). But when I try to move that same thermostat over to my IOT subnet, the original pairing stops working, and I’m unable to successfully re-pair the device.

I have firewall rules to allow traffic between my IOT subnet and my Home Assistant instance, and mDNS reflector is set up. Typically mDNS discovery works fine between the two subnets (for example, my HA instance (from my LAN subnet) can find all of my ESPHome devices (on my IOT subnet)).

Seems like it should be possible to put IPV4 Matter devices on separate subnets assuming mDNS can work across the subnets, and the proper routing rules are in place. Does that seem right to you?

Edit: I wonder if perhaps the phone also needs to be properly routed for things to work properly. So possibly the sequence is:

  • Configure firewall rules for the phone, device, and HA to all talk to eachother across subnets
  • Connect phone to IOT network
  • Connect device to IOT network
  • Add matter device from phone
3

Your sequence is what I figured out to be necessary as well. Kinda bummed cause I like to keep my servers and my devices separated and well… now I gotta make an exception :smiley:

4

So it worked for you if you temporarily opened the two networks to add the device, and then closed them back off? I haven’t gotten to trying this yet

5

lol, I’ll let you know by the end of today! I just tried absolutely every other combination to try and make it work and this is the last one and the longest one, cause my networks were all over the place cause I never transferred things over to my new switch :smiley:

Today, I will be finishing that project and subsequently finally making my last attempt to get this damned thermostat to connect to home assistant.

6

sorry, I didn’t understand your question. No, I never got it to work by just opening up the networks. I had to rearrange my networks from a multiple switch situation to a single switch situation (due to offputting completing an upgrade like a true procrastinator) so that I could put home assistant in the same vlan as my IoT devices. I tend to keep my servers separate from my devices, but have tested and figured out that you can not in no way, put home assistant and at least the thermostat on separate networks. Even after pairing the devices. — I did not test as deep as to try the tbr in both subnets as well, so that’s something someone can try to see if maybe ha+tbr in one vlan and thermostat in another, if that works, who knows? Seems like a lot of work for not much reward :slight_smile:

I can however confirm, contrary to what I found elsewhere, cutting off the internet is indeed perfectly fine and everything still works.

7

What do you mean with VLAN69_IOT net? An fd00::/8 Matter IPv6 address? And what do you mean with an address assigned by DNS? Did you mean DHCP or RA? There is no such thing as “Matter over WiFi/IPv4)”, because Matter only works over IPv6, However the services over IPv6 can be advertised using IPv4 mDNS or IPv4 DNS. It is not required of a Matter device to support IPv4 though for (m)DNS.

8

Sorry didn’t see your response. Thanks, yes addresses are of course supplied by DHCP/RA, that was a typo (I’ll fix that bit).

And yes Matter is only IPv6.

IPv4 in the firewall rule is not related to Matter, that traffic is related to things like IPP (Printer) on mDNS or anything else HA is communicating with through IPv4 .

The rule for allowing ‘VLANXX_IOT net’ source traffic to broadcast on 5353, etc. is related to any traffic, Matter or not. Matter would only be broadcasting in the IPv6 space.

9

But does it mean any router/ access point would be compatible ?

I am running agaisnt an issue with Eve peripherals (doors,sensors,switch,energy,etc), when using for example a TP-Link Archer C80 the connectivity check fails on my android device.
But using a google Nest wifi Pro solve the issue.

In such scenario how can I implement the rules ?

10

What check is failing…is the Android failing to connect to HA or the Eve device is failing when you try to connect it via Matter in the Android app?

The newer Eve windw/door sensors are Thread and need a border router like an Apple HomePod or 2nd gen 4K Apple TV or Nest compatiable border router. Some of the Eve devices are not upgraded to Matter when you buy them and require the Eve app to upgrade them to Matter before use with HA.

In general most WiFi routers do not need any additional configuration (your router is IPv6 capable). The rules above were implemented on a custom router configuration for pfsense…most routers will already be set up properly and as long as HA and the border router are on the same network it should just work.

11

-In my test scenario i use the Eve energy si tje border router thing is not it.

  • in the App it fails at “check for connectivity” after it as generated the matter IDs, etc… i wil try to make a screenshot.
  • the devices can be connected when I am using the google nest pro wifi as a wifi router for my phone. Any other router fails.

I am using skyconnect, not using the google nest pro thread antennas.

I need to use another wifi router than the google nest pro (for other reasons outisde of this scope)

12

If you’re using sky connect as your border router, you should have the multi-protocol firmware installed (it will say multi-protocol in device add-in configuration instead of just Zigbee), and you’ll would need both the HA “Thread” integration and HA Matter add-in too. Can you see Sky Connect set up as multi protocol and identified as your “preferred Thread network” within HA?

13

And you absolutely should not.
They even stated as such on the matter stream last week.

DO NOT use the Sky Connect for Matter over Thread while also running Zigbee on it. That is the plan eventually - but right now it is simply not stable enough to do that.

14

so there you have it…buy something cheap that works as a border router but not necessarily a WiFi router if that is your constraint. It’s a shame really they’ve been pitching that SkyConnect thing for a while, I bought one, tried it, and threw it in a drawer.

15

The Sky Connect works fine - IF you are running the Thread ONLY firmware on it.

1 Like
16

@yodiyossarian
Like I said earlier , it is working with the google nest pro wifi configuration.

But not any other router, so it is not a skyconnect / zigbee multi protocole thing fault.

  • +I did the test with the sonoff zbdongle-e flashed with OTN 2.4.0 and still same result
  • +tested with beta frmware on android phone
  • +tested beta firmware on matter server 5.0.4
  • +tested on 2nd raspberry pi 4 4go
  • +tested on 2nd microSD card

→ If you are un-happy with multiprotocole you can always roll back to original firmware with zigbee : Home Assistant SkyConnect

Please read carefully, my issue is not related to skyconnect (working flawlessly BTW with Multiprotocol on google nest pro wifi) but network issue.

Yes i do see the multiprotocol configured correctly on HA.

Could any one on this forum tell me what configuration he his running on a TP-Link router ?

17

@mobile.andrew.jones

+Tested with and without Thread only firmware
+tested on sonoff zbdongle-e

sames network issues

18

My question is about : How do you map the configuration you gave us on top (for PfSense) on any other TP-Link router equiped also with it’s firewall.

I have options such as IGMP/ICMP Snooping V2 or V3, I have the NAT Firewall open, IPV6 setup, IPV6 DHCP.

As i am new to IPV6 my question is network related.

19

Pierre, I understand you believe the issue may be related to Ipv6.

When you tested on the Nest Pro you may have been utilizing the Nest built-in Thread Border Router (not sky-connect) and that’s why it worked in that scenario. Without the Nest you may not have a working Thread Border Router on the network in which the Eve and HA are operating.

The TP-link may not have a Thread border router feature and the Sonos is not a Thread border router either AFAIK. That’s why we keep asking about the sky-connect. There is an apparently an open issue with sky-connect (see issues on GitHub) multi protocol so it’s good that you were able to revert sky-connect to just the Thread stack.

20

I saw that peoples had issues with this yes.

image
image785×614 24.9 KB

As you can see I am not in that case scenario as the nest thread antennas are not in my preferred network + i did not activate the smartphone credentials.

I believe it may be related to the Eve devices being too network restrictive.