The reason why I keep asking about network question is that i have read this article :
that explain exactly the issue I have but for a Ubiquiti accesspoint.
I do not have one on my hand (yet) hence I need to run the configuration on tp-links routers for now.
I have been able to fix the issue by following the guide here :
By using the console on chrome + a bluetooth dongle (BLE4.0) I am able to add matter devices without any router.
Pierre, thanks for sharing that solution. So the issue for you was not the network per se.
Iām curious what type of mobile device failed the paring for you. There was some comments in that link you sent that iOS could not pair with SkyConnect due to lack of credentials interoperability.
Pairing Matter/Thread devices using iOS with Apple Thread Border Routers like AppleTV obviously works. I am surprised that there were some comments that Android pairing did not work with Sky Connect.
Well, the pairing was working with google nest pro but not with any other routers.
I personnaly believe it is network issue, as a config is working and an other not when only the network topology changeā¦
Also when i monitor the traffic with Wireshark there is absolutly no mdns patternā¦
My android is Samsung S20FE 5G , ONE UI V5.1 and Android V13.
Pairing with an iPad was not succesfull either. As i got the message āthread border router not detectedā
but was correcly configured on HA (and visible)
You may very well be right Pierre.
Sounds like there is an open issue where if one uses Android Thread/Matter expects a Google border router like your Nest Pro. IOS may only work with Apple border router. https://github.com/home-assistant/core/issues/103257#issuecomment-1791636173
Odd though that you donāt see any mDNS traffic at all from HA. I only saw this situation when I had installed HA manually inside Debian as a supervised install with a blocking firewall. Once I opened the appropriate ports mDNS could pass. HA OS when installed in its entirety or in a VM is already properly configured with Avahi to route across internal docker containers and the HA firewall so mDNS passing to the host adapter works out of the box.
Have you checked if IGMP snooping is on in the main router??? There was some conjecture that snooping is problematic for mDNS. https://forum.mikrotik.com/viewtopic.php?t=134004
As you probably know Itās worth noting that the first Eve Thread fabric connection is occurring over Bluetooth with UDP and control happens over TCP after that.
Only a guess, but If the cred exchange canāt happen (the reason an apple TBR + android device would be an issue or vice versa) I doubt it ever gets to ths point where it even needs to reach out. Thus no mDNS. Again only a theory but would be my first guess in that scenario.
Yeah, I guess one could install an add-on like printer IPP and should then see that mDNS traffic as HA would try to reach the printer services
Just to confirm, this canāt be solved with any amount of firewall rule configuration, mDNS proxying, or other proxying between vlans?
I can only assume this limitation exists due to HA itself and its use as f the toolkit. Iām totally speculating. This white paper indicates that the border router MAY stub the Thread network to ULA or even global IPv6 and provide routing accordingly.
If the TBR did stub the mesh to something routable, understood IPv6 RA messages, and technology like Avahi were used to repeat mDNS broadcasts it would seemingly be possible to cross subnets between HA and the Border Router/device mesh.
Iām going to experiment a bit more. If you know of anyone who has success Iād love to hear about it.
I have not been able to get any configuration working that involved devices on different VLANs. This may be because Iām using Opnsenseās UDP Broadcast Relay addon which doesnāt support IPv6 (is there an IPv6-capable alternative?)
The device that is setting up (commissioning?) the Matter device needs to be on the same network as the border router, and, at least in Androidās case, needs to be connected to the internet, otherwise it fails during the āgenerating Matter credentials stepā. I have no idea why it needs to connect to the internet to generate credentials.
I had a lot of trouble because of these requirements, I had to poke holes in the firewall for my phone to access the internet from the local-only network, and allowed it to access a DNS server on another network because the local-only net has DNS access control lists that only allow local DNS. Quite a pain.
I also had trouble using just the Skyconnect as the border router, I wasnāt able to add anything beyond my first device for some reason. I wiped everything and got a Nest Hub, which also needs internet for its initial setup, but then I restricted it to local-only. While using the Nest border router, devices were constantly going offline and I hated life. I ended up moving the Home Assistant instance to the local only network (which was its own ordeal, and I still donāt like that itās there), enabled IPv6, joined the Skyconnect to the Google PAN, and somehow eventually got the bright idea to unplug the Nest Hub and rely solely on the Skyconnect. Everything has been stable ever since.
Iāve learned more than I ever wanted to know about a protocol that was sold to me as simple and would ājust workā. Well, it may just work for the average person, but I, unfortunately, had a complex network, and your post helped me get to a final state that doesnāt involve repeatedly banging my head against the wall.
How did you input fe80::/10 and fd00::/8 as aliases in pfSense? Whenever I do I get an error of āIPv6 subnets are not supported in host aliasesā.
Create the type alias Network instead of Host. Port is the other type. HTH
Thanks for sharing! Why are those firewall rules needed when all the traffic is on the same subnet and in a single LAN? In my world, the traffic is switched L2 within the LAN and will not pass the firewall. Or can the FW kill multicast/broadcast traffic that is local on an interface?
In pfSense, do you create the rules on the IOT interface or are they Floating rules?
Hello @ Videonissen, yes within a single subnet/broadast domain, no rules would normally be required. The rules I refer to are not firewall rules but rather policy rules that include rules where inter-VLAN traffic is involved, for instance Avahi mDNS where traffic is crossing subnets.
mDNS is used to find services and then TCP/UDP is used to invoke those services. If all your traffic is within a single subnet/L2 the default functionality is sufficient and traffic should ordinarily pass within the subnet. If you have Matter devices on different subnets then these rules may be required to allow Avahi to forward mDNS to pass.
In all current cases as of this writing the border router (Thread intermediary) and HA need to be on the same subnet. If all of your Matter devices are also on that subnet then youāre in business.
It is possible to have devices, e.g., Matter devices, on different subnets than HA when using Avahi. In this case, those router policy rules can apply to allow this traffic to cross subnets (again nothing to do with the WAN firewall).
Lutron devices are a good example of a Matter device that can cross a subnet because they are not Thread but rather Matter over Ethernet/WiFi. Eve devices are a good example of a Thread device where the Border Router and HA need to be on the same Subnet.
Also local firewalls, e.g., an HA container, would need to allow this traffic. My experience is that the VM HA host does allow this traffic but if youāre using a user configured Debian host with a firewall to run HA you may need to allow this traffic within the Debian firewall.
The bottom line is if your devices are working donāt do anything extra. If not, then log the traffic whether on pfsense or your Linux host and allow that traffic as required.
Okay, then I get it. However, if you have two subnets/VLANs (IoT & LAN), do you not need to configure the above FW rules as well for the LAN?
If youāre like a lot of folks you have a mix of IOT devices, some of which may be Matter/WiFi, some may be Matter/Thread, while some devices are integrated with HA via proprietary protocols that still use mDNS for zero-conf discovery.
If you put all of your devices, Thread Border Router(s), and HA on the IoT subnet then nothing further may be required with regard to mDNS unless your router is not allowing your mDNS broadcasts to work within a single subnet. If something isnāt working in this single subnet scenario check the router logs and allow traffic as needed on ports 5353 or 5540.
Where you have HA, Border Routers, and all devices on the same subnet you would create standard rules to allow access from LAN to HA and perhaps to your border routers if your phone or Apple Home is referencing these devices from LAN. These are rules you probably already have in place if you are acessing IoT devices from LAN.
If you have elected to keep HA and your Border Routers on LAN while Matter/Wifi and proprietary zero-conf devices are kept on the IoT subnet then you will need rules for mDNS/Broadcast that go along with something like Avahi replicating this mDNS traffic across subnets. You might configure your network this way to limit the IoT subnet devices from accessing the Internet. In this case you might need mDNS rules to be on both subnets unless your router is allowing this traffic by default as part of the Avahi configuration.
In this second scenario where IoT is hosting all the non-Thread devices I would join these devices to the network by setting my mobile device temporarily to the WiFi access point associated with IoT until the device is joined to that subnet or specifying IoT in the initial proprietary paring process and then have my phone rejoin the trusted LAN once the device is onboarded.
