I'm trying to add some matter devices to my setup with devices on an IoT VLAN (40) and the OpenHab controller on a separate VLAN (20), but a router advertisement broadcast on VLAN 40 does not appear to make it to VLAN 20.
I'm trying to understand which piece of the IPv6 puzzle is responsible for passing this RA between VLANs, and what I need to do to get it working.
Some more info... I have the following set up:
OPNsense on a PC Engines apu4d4
Ubiquiti Pro Max 16 PoE switch
R-Pi (Raspbian Trixie) running OpenHab on VLAN 20
R-Pi (Raspbian Trixie) for testing on VLAN 40
IKEA Dirigera on VLAN 40
- VLANs are defined in OPNsense and mirrored with the same VLAN tags in the switch configuration.
- All the devices are hard wired (no WiFi) to the switch, with the OPNsense port in trunk mode assigned to the default Ubiquiti VLAN and the other ports in access mode assigned to their relative VLANs (20 for OpenHab, 40 for Dirigera and test R-Pi).
- When the Dirigera sends out an RA it turns up on the test R-Pi on the same VLAN but not on the OpenHab R-Pi on a different VLAN.
- My ISP does not have IPv6 so I have created a static /56 ULA and assigned :20/64 and :40/64 subnets to the VLANs. WAN, LAN and other VLANs are set to IPv6: None.
- I've enabled Services > Router Advertisements on both VLAN 20 and 40 interfaces, using Unmanaged mode.
- I'm running a FreeBSD port of dennypage/mdns-bridge (https://github.com/dennypage/mdns-bridge) on the server, although I can achieve the same results with the IoT config available on the Ubiquiti switch.
- I have no DHCPv6 running - seems like SLAAC should be sufficient for what I'm doing.
- Matter devices are already connected to the Dirigera and I can access them using that as a bridge, but I'm trying to add them directly to OpenHab.
- I have a firewall rule allowing all ICMPv6 in to the VLAN interfaces to access anywhere - I can tighten this up when its working. All blocks are logged and I cannot see any relevant packets being blocked.
When I try to add a new matter device from the IoT VLAN to the OpenHab server it all seems to go fine up to the point where OpenHab tries to talk to the device. Tracing the network comms:
- The Dirigera publishes an RA.
- The test R-Pi on the same VLAN receives this, and adds an entry to its routing table.
- OpenHab does not receive the RA.
- When OpenHab tries to contact the device from the mDNS it has no route, and fails.
So if anyone could tell me the last bit of this puzzle I'm missing I'd be really grateful - taken me quite a while to get to here but it seems so close now...
Quote from: barney on April 20, 2026, 03:01:31 AMI'm trying to understand which piece of the IPv6 puzzle is responsible for passing this RA between VLANs
Hi @barney. RAs are not meant to pass between VLANs, normally. That is considered a serious leak and means you no longer have L2 boundaries. Is there a reason why you are trying to keep the hub on a separate VLAN? It naturally wants to be on the same segment in order to form a mesh.
Thanks for taking the time to look at this.
QuoteIs there a reason why you are trying to keep the hub on a separate VLAN?
It just seemed to be a common / recommended set up, although I admit this level of network architecture is new to me, and I may have a tendancy to over-engineer things some times...
I can see how
uncontrolled boundaries could be a problem, but isn't the idea to have separate VLANs with
controlled routes between them? That's what I set up in my IPv4 world:
- VLAN 10: 192.168.10.0/24 - Full Access - laptops, phones etc.
- can access the outside world
- can access the server on 20.16
- can access the rest of VLAN 20/30 for testing, although I turn these firewall rules off when not being used
- VLAN 20: 192.168.20.0/24 - General internal only things
- no outbound access to the internet
- fixed server at 192.168.20.16, running OpenHab, Lyrion Music Server etc
- firewall rule to let 192.168.20.16 access VLAN 30 to get camera footage
- bunch of R-Pi LMS players
- some other stuff
- VLAN 30: 192.168.30.0/24 - Cameras
- no outbound access to the internet or any other subnet
So the server on 20.16 is the main thing running 24/7, and has defined firewall rules to let it access other stuff like the cameras on VLAN 30.
When I started adding smart devices it seemed to make sense to create a new VLAN for them, so I:
- created VLAN 40 and stuck the Dirigera on that
- linked up a bunch of devices using that as a hub
- added a new firewall rule to let the OpenHab server access the Dirigera
All good - I still have no IPv6 anywhere (the Dirigera has one but that's not anywhere in my set up) and OpenHab only has to talk to the Dirigera which acts as a hub for the matter devices beyond it, and the thread/matter mesh network is all in VLAN 40.
I could have left it there (and maybe I should have!), but sometimes when the Dirigera restarts it tends to lose stuff and I have to set it up again, so I wanted to use that only for onboarding the matter devices then talk to them directly from the OpenHab server, which started my long road into IPv6...
I could put OpenHab on a separate server inside VLAN 40, but I'd prefer not to run a separate server just for that if I don't need to. Also, it would mean I'd need to allow routes between VLAN 30 and 40 which are currently isolated, or just merge 30 and 40 in to one.
Is the security risk with RAs that if you allow them between subnets you are allowing a rouge device to set up any route it likes? Would a solution to be to examine the specific RA and add a fixed route from OpenHab to VLAN 40, assuming the Dirigera routing stuff is permanent and does not change?
Update: Ignore all this - completely off on the wrong track...Ah - think I've had a light-bulb moment... and I was trying to solve the wrong problem.
Internet search for Dirigera has a lot of stuff like:
QuoteThe IKEA Dirigera hub acting as a rogue Thread Border Router (OTBR) and advertising its own Unique Local Address (ULA) prefix instead of using the network-assigned IPv6 prefix is a known, significant issue when integrating it into existing Matter networks.
So the question is not: "how do I get from my network to the Dirigera thread network", but: "why is the Dirigera creating its own network and not using the ULA provided".
Which I guess is not an OPNsense issue any more, so I'll follow up on that front instead.
Again, thanks for taking the time to look - I think my IPv6 knowledge has gone from "almost nothing" to "not very much", which is a definite improvement!
Cheers,
Quote from: barney on April 20, 2026, 04:37:40 AMisn't the idea to have separate VLANs with controlled routes between them?
Certainly, but I think some concepts are getting mixed up. For instance, you probably have DHCP in your IPv4 networks set up so that clients get their IPs only from the "server" on their own network. Clients in VLAN 20 don't get IPs from the DHCP pool in VLAN 30.
Similarly, you don't want a router (in this case that Dirigera hub is acting as an IPv6 router) handing out IPs from its own subnet to clients in a different subnet. That's what would happen if the RAs crossed over. The RA would contain the prefix of the router's network (VLAN 40) and that prefix would get configured onto the clients in VLAN 20. That would put them effectively on the same network and bypass routing/firewalling (if it even works).
To be honest I don't know how these smart home devices work (I don't own any) but I assume that they want to be on a network together and possibly the hub is providing internet access for the connected matter devices (?). I'm not sure how that works- do they have IPs on the OPNsense network at all, or do they connect wirelessly only to the hub?
In either case, personally, I'd treat them all as "IoT" things and keep them in a VLAN together. That way they would all talk to each other freely and do what they need to do, but they could not access my private network. I would be able to access them, however, from a more privileged network using firewall rules.
Maybe I'm oversimplifying because I'm thinking of these devices as typical clients...
Maybe a quick intro to Matter over Thread will help.
In its most basic form, a Thread network works by having a so-called "Border-Router" create that network (think WiFi AP). All devices - including the border-router - added to that network use IPv6 link-local addresses to communicate. The Thread network has nothing to do with the networks on your router / firewall. IPv6 is only used because of SLAAC, not to connect it to your other networks.
Communication between devices on the Thread network and your own networks is provided by the border-router. It must be connected to one of your networks so that it can be discovered via Bonjour. Use mDNS if required. The border-router will forward Matter messages between your networks and the devices on the Thread network. Although the border-router is called a router, it actually does the forwarding on the application layer, not layer 3. That's how communication with Matter over Thread IPv6 devices works just fine, even if the border-router is connected to an IPv4 ethernet connection only.
The Dirigera Hub is a border-router. So, just put the Dirigera Hub in your IoT network and make sure the computers, phones, tablets, etc you use for home automation can communicate with the border-router.
Quote from: mooh on April 20, 2026, 03:44:07 PMMaybe a quick intro to Matter over Thread will help.
All devices - including the border-router - added to that network use IPv6 link-local addresses to communicate.
Although the border-router is called a router, it actually does the forwarding on the application layer, not layer 3.
That's how communication with Matter over Thread IPv6 devices works just fine, even if the border-router is connected to an IPv4 ethernet connection only.
Thank you for the above, because I could have sworn reading the same thing about these devices in the past!
So it's like I thought :
Dump them all in your IoT VLAN and let them have fun there!
No special IPv6 stuff needed :)
Quote from: mooh on April 20, 2026, 03:44:07 PMMaybe a quick intro to Matter over Thread will help.
Good post, @mooh. Thanks!
Thanks everyone.
I got it to work, and the short answer is I configured a gateway / route / firewall rules in OPNsense:
Gateway:
Name: Dirigera
Interface: VLAN40
Address: fdb4:66c9:5838:40:6aec:8aff:fe0d:c1fe
Route:
Network: fd2c:d79a:65f9:1::/64
Gateway: Dirigera
fdb4:66c9:5838 is my static ULA prefix
fdb4:66c9:5838:20 is the local /64 prefix for VLAN 20
fdb4:66c9:5838:40 is the local /64 prefix for VLAN 40
fdb4:66c9:5838:40:6aec:8aff:fe0d:c1fe is the Dirigera
fd2c:d79a:65f9:1 is the thread ML-EID network - internal thread network behind the Dirigera
As well as the comments here, this article on Thread IPv6 addressing (https://openthread.io/guides/thread-primer/ipv6-addressing) helped.
More Details The starting point was:
- Dirigera is running with a bunch of devices connected to it.
- IKEA Smart Home app on my phone can connect to Dirigera and see all the devices.
- Dirigera is added to OpenHab as a matter:controller.
- Dirigera is on VLAN40 (IoT) and OpenHab on VLAN20.
- mDNS-bridge is running on OPNsense actoss VLAN20 / VLAN40.
To add a matter device directoy to OpenHab I:
- Go in to the Smart Home app and put it in pairing mode - this gives me a pairing code.
- Go in to the Dirigera controller in OpenHab and add a device - enter the pairing code.
Originally this process failed with an "unable to locate the device" message. After adding the gateway / route it works.
Tracing the network traffic on the OpenHab box I saw the following:
fe80::20d:b9ff:fe57:27c9 ff02::fb MDNS 418 Standard query response 0x0000 TXT...
fdb4:66c9:5838:20:2ecf:67ff:fe51:99e6 fd2c:d79a:65f9:1:cd4:13fb:7251:3fcc WireGuard 163 Transport Data, receiver=0x047FB532, counter=11556339582847249375, datalen=69
fdb4:66c9:5838:20::1 fdb4:66c9:5838:20:2ecf:67ff:fe51:99e6 ICMPv6 211 Destination Unreachable (No route to destination)The MDNS response contained:
Answers
...
F8470964ED4A3E53._matterc._udp.local: type SRV, class IN, cache flush, priority 0, weight 0, port 5540, target BA6ED07031FF8186.local
BA6ED07031FF8186.local: type AAAA, class IN, cache flush, addr fd2c:d79a:65f9:1:cd4:13fb:7251:3fccThe way I read this is that:
- Putting the device into pairing mode causes it to broadcast an MDNS response on VLAN40.
- The MDNS message says "I have a device in commissioning mode at fd2c:d79a:65f9:1:cd4:13fb:7251:3fcc".
- The MDNS bridge passes this on to VLAN20, where OpenHab picks it up.
- OpenHab tries to talk directly to that device to add it using the pairing code.
- It fails as it does not know how to get to fd2c:d79a:65f9:1.
Adding the gateway / route fixes the last step, and everything is good.
Router AdvertismentsThe Dirigera periodically emits an RA which updates the routing table on my test R-Pi within VLAN40:
$ ip -6 route
fd2c:d79a:65f9:1::/64 via fe80::6593:10a4:85c9:9edb dev eth0 proto ra metric 100 pref medium
fdb4:66c9:5838:40::/64 dev eth0 proto ra metric 100 pref medium
fe80::/64 dev eth0 proto kernel metric 1024 pref medium
fe80::/64 dev eth0.20 proto kernel metric 1024 pref medium
default via fe80::20d:b9ff:fe57:27c9 dev eth0 proto ra metric 100 pref mediumThat is the message I was expecting to get to VLAN20 to also update the routing table there, but I can see how allowing automatic routing across VLANs could be a problem. Also, as it routes via a link-local address it probably wouldn't work even if the packet did get there.
So manually configuring the gateway / route / firewall rules makes it obvious where the cross-VLAN communications are going.
Cheers
This might come in useful in the future. Just so I understand: the problem this solves for you is that it isolates the Thread hub (the Dirigera) to a VLAN where you can disable internet access?
Would you be able to achieve the same with a firewall rule in an IoT VLAN?
Yep - sort of...
It isolates the Thread Border Router (Dirigera)
and all the matter devices connected through it to a VLAN where I can prevent both internet access and also access to any other VLANs (general internal, cameras etc.)
QuoteWould you be able to achieve the same with a firewall rule in an IoT VLAN?
I'm not sure. I could restrict access to the Dirigera itself as it has a known IP, but I'm not sure if I could restrict access to the thread devices behind it. The RA that the Dirigera broadcasts to its VLAN adds a direct route to all devices on the ML-EID (thread network) so I'm not sure if those packets still go via the router or not, and so could be intercepted by the firewall.
As it currently stands, all I have are three firewall rules:
- IPv4 access from OpenHab to Dirigera itself.
- IPv6 access from OpenHab to the ML-EID network (fd2c:d79a:65f9:1::/64)
- mDNS between VLAN20 and VLAN40
All other access to/from VLAN40 is blocked by default except for some common DNS / NTP etc stuff, although I'm still analysing the logs and may need some reverse access from the ML-EID network back to the OpenHab server.
There's only one concern I have and it may be a nothing-burger, but I'll mention it anyway for discussion.
Based on what @mooh wrote the default for these devices is that they use link-local addresses, which limits their access to what the hub provides them from its own uplink to the IOT network. That is easy enough to firewall because all you would have to do is block the hub and everything downstream of it is also walled off.
By necessity of your design, since you split the hub off to a separate VLAN, it now needs to advertise ULAs downstream because LL addresses are not routable. The issue now is, if you're not careful, you could potentially open a hole whereby the connected matter devices gain network access via some ULA route. You've weakened the default security which you then need to mitigate with your own routing/rules.
All fine and good if you understand what you're doing, but I wouldn't recommend it for family & friends. IMO, it's cleaner and safer to put the thread hub / border router on the IoT net. Give it a static IP or add its MAC to an alias. Then if you really must constrain it and its downstream devices to the IOT network and nothing else (not even internet), a rule like this could do:
Interface: IOT
Quick: <checked>
Action: Block
Direction: In
Protocol: any
Source: { dirigera }
Dest: !IOT_net
Now they are not able to get beyond the IOT network, but your controllers on other VLANs can still get to them (if their rules permit).
Quote from: OPNenthu on April 21, 2026, 05:56:09 AMBased on what @mooh wrote the default for these devices is that they use link-local addresses, which limits their access to what the hub provides them from its own uplink to the IOT network. That is easy enough to firewall because all you would have to do is block the hub and everything downstream of it is also walled off.
ey are not able to get beyond the IOT network, but your controllers on other VLANs can still get to them (if their rules permit).
Exactly. Don't worry about the thread devices. They only know the thread network and can't get out. Any traffic between the thread network and the rest of the world is via the border-router. The fact that the thread network uses link-local IPv6 addressing is entirely irrelevant for your LAN design.
Of course, these are just the basics. In real life, it can get more complex quickly:
- You'll probably want more than 1 border-router.
- Matter devices are also available as WiFi or Ethernet devices. They should be on the same L2 network as the border-routers, i.e. your IoT network.
- One of the recent revisions of Matter introduced a feature to allow Matter devices to communicate with the world. Although still only via border-routers - I think -, it breaks the notion of strict locality that is/was one of the highlights of Matter to me.
Quote from: OPNenthu on April 21, 2026, 05:56:09 AMBy necessity of your design, since you split the hub off to a separate VLAN
Not sure what you mean here - the Dirigera
is on the IoT VLAN?
Quote from: OPNenthu on April 21, 2026, 05:56:09 AMif you really must constrain it and its downstream devices to the IOT network
I don't generally 'constrain' anything directly. I log the default block rules and only create specific allow rules to pass the things I need. The only block rules I generally have are to intercept-and-not-log noisy clients before they get to the default block rule and get logged.
Also, just to note, the block rule you suggest would only capture traffic from the Dirigera itself, not from the thread devices behind it.
Quote from: mooh on April 21, 2026, 02:44:35 PMDon't worry about the thread devices. They only know the thread network and can't get out.
...
One of the recent revisions of Matter introduced a feature to allow Matter devices to communicate with the world.
I think I must be using the latter... all of the matter devices in the thread network have a ULA IPv6 address that is routeable across the network (Dirigera supports Matter 1.4 if that makes a difference) - this is the address that is published in the mDNS message.
e.g. The Air Sensor has this:
{
"productName": "ALPSTUGA air quality monitor",
"hardwareAddress": "c2be2a915b99fd5c",
"iPv4Addresses": [],
"iPv6Addresses": [
"fde60a8291c018d8000000fffe002c00",
"fd2cd79a65f90001a09ba0cb1f92985d",
"fde60a8291c018d8d392333ab2732096",
"fe80000000000000c0be2a915b99fd5c"
]
}It has a link local fe80.. address and not sure what the fde6.. addresses are (Routing Locator (https://openthread.io/guides/thread-primer/ipv6-addressing#routing-locator-rloc) maybe?), but the fd2c.. address is the one advertised in the mDNS message which OpenHab uses to control the devices - looks to me like the Mesh-Local EID that the OpenThread doco says "Does not change as the topology changes / Should be used by applications".
Anyway, it's all working as I wanted now: OpenHab can commission / control the matter devices and nothing on the IoT VLAN can start outbound connections other than to the OpenHab server (although I can see them trying to phone home and being blocked in the firewall logs). Just needed the gateway / static route and a firewall alias for the thread network (fd2c:d79a:65f9:1::/64) to write a couple of allow rules.
Appreciate you both taking the time to look at this.
Quote from: barney on April 22, 2026, 03:39:44 AMNot sure what you mean here - the Dirigera is on the IoT VLAN?
I didn't notice that. I'm sorry.
Quote from: barney on April 22, 2026, 03:39:44 AMI don't generally 'constrain' anything directly. I log the default block rules and only create specific allow rules to pass the things I need. The only block rules I generally have are to intercept-and-not-log noisy clients before they get to the default block rule and get logged.
Understood. In my environment all the local interfaces get internet access by default (I use a group level rule to allow egress), and for IoT that's just as well because they all need internet access. I wouldn't try to block the Dirigera from the internet in the first place, but if I had to, I would need an interface level block specifically for that device. Though I acknowledge that such a block can be circumvented with a spoofed MAC or a self-configured IP, so maybe not a great example. :)
I shouldn't have assumed how your environment is.
Quote from: barney on April 22, 2026, 03:39:44 AMAlso, just to note, the block rule you suggest would only capture traffic from the Dirigera itself, not from the thread devices behind it.
I'd like to understand this better. If the Dirigera has no internet access, how can devices behind it have internet? I assumed it's proxying their traffic but maybe I don't understand something.
Thank you, @barney.
QuoteIf the Dirigera has no internet access, how can devices behind it have internet?
Neither the Dirigera nor any of the devices behind have internet access (see note below) - all of my monitoring / automation is local using openHAB (https://www.openhab.org). If I want to access stuff remotely I can VPN in to my openHAB server and control it via that.
Note: I did need to allow the Dirigera internet access when first commissioning it as it wanted to check / download the latest firmware before letting me do anything. I'll also open that up again if later firmware is released. If specific device firmware updates are release I may need to allow the devices internet access at that time.
I have no real problem with connecting stuff to the cloud if they need it, but as a general approach I just don't let anything out unless
I want it to - not because the manufacturer wants it! If I do ever get a device that really does require cloud access then I'll create a rule to let that out.
QuoteI shouldn't have assumed how your environment is.
No problem - I appreciate you taking the time help.
Quote from: barney on April 22, 2026, 03:39:44 AMI think I must be using the latter... all of the matter devices in the thread network have a ULA IPv6 address that is routeable across the network (Dirigera supports Matter 1.4 if that makes a difference) - this is the address that is published in the mDNS message.
Very interesting. Looks like I have some reading to do, especially why there are multiple ULAs per device. Anyway, ULAs are not globally routable, just like link-local addresses. So my basic point is still true. These devices cannot reach the internet without some sort of proxy and none of your local networks without routing support.
Do you happen to have multiple thread networks in your home?
I just performed a little experiment setting up a new Matter over Thread border router and added 2 devices to it. The router was connected to a WiFi network, too. The border router created a unique local prefix for the Thread network and another one for WiFi. It did route between the two. It also got a GUA and an IPv4 address on the WiFi interface.
So, my statement that Thread uses link-local addresses is wrong. It uses ULAs.
I may have another look into this later.
Quote from: mooh on April 22, 2026, 01:39:45 PMULAs are not globally routable, just like link-local addresses. So my basic point is still true. These devices cannot reach the internet without some sort of proxy and none of your local networks without routing support.
Yep, exactly - that was the point of my initial post. The RA the Dirigera publishes makes these devices routable within the VLAN but I needed to reach them from a server on a separate VLAN. My initial thought was to reuse the same RA, but adding a manual gateway / route seems a much better option.
Quote from: mooh on April 22, 2026, 01:39:45 PMDo you happen to have multiple thread networks in your home?
Nope, not yet. I've only just started with Thread so only have a few devices. If I expand on those I'm most likely going to put a Thread-enabled GPO or two in each room, which should establish a pretty solid mesh but it's still just extending the same network not creating a new one.
Cheers,
Quote from: barney on April 23, 2026, 01:32:21 AMThe RA the Dirigera publishes makes these devices routable within the VLAN but I needed to reach them from a server on a separate VLAN.
This is where I don't understand what you're looking for. Devices not on one of the IPv6 networks that the border router announces can still use Matter as long as they can communicate with the border router via other means.
At my home, I have an IPv4 only network for IoT stuff which is blocked from all other local networks. That's where my border routers live. Everyone in my home has their own dedicated network. mDNS is used to announce the border router to other networks. My Mac uses IPv4 over Ethernet to communicate with the border router. Actually, I can use all my Matter over Thread devices from anywhere in the world as long as I can connect to the border router.
If you want to use IPv6 in networks where you don't see the RA messages, you may try NDP proxy. There's a section in the OPNsense manual on its usage but it only shows how to use IPv6 on a local network if you don't have prefix delegation.
Quote from: mooh on April 23, 2026, 01:41:32 PMThis is where I don't understand what you're looking for.
I'm not looking for anything any more - my stuff is all working. I'm continuing the discussion trying to answer questions and maybe explain my setup in case it helps anyone else in the future, and happy to keep doing that if it is useful.
As I understand the situation I have 3 separate networks involved:
- VLAN 20 - fdb4:66c9:5838:20::/64 - containing the OpenHab server.
- VLAN 40 - fdb4:66c9:5838:40::/64 - containing the Dirigera TBR and other direct ethernet / WiFi IoT Devices.
- Thread - fd2c:d79a:65f9:1::/64 - Thread Mesh-Local network containing the Matter devices.
These are all separate networks and require L3 routing for traffic to move between them.
The communications I need to happen are:
- Discovery (3 -> 1): devices on the Thread network need to be discoverable from the OpenHab server.
- Control (1 -> 3): The OpenHab server needs to send messages to the devices on the Thread network.
For the Discovery stage:
- The Thread device registers itself with the Dirigera TBR.
- The Dirigera broadcasts an mDNS message, which includes the Mesh-Local IPv6 address of the device.
- The mdns-bridge running on OPNsense reflects that message from VLAN 40 to VLAN 20.
- The OpenHab server gets the mDNS message and registers a device with its Mesh-Local IPv6 address.
For the Control stage:
- The OpenHab server sends a message to the device's Mesh-Local IPv6 address.
- The OPNsense gateway / static route sends this to the Dirigera TBR.
- The Dirigera TBR routes this to the end device.
So the two highlighted steps (Discovery 3, Control 2) are the ones I needed to add.
If my OpenHab server itself was in VLAN 40 then I would not need anything extra - the Router Advertisement the Dirigera publishes would suffice (Note: this is an assumption - I've not tried putting OpenHab on the IoT VLAN so don't know for sure).
When I initially asked this question my thinking was that I needed to get the RA published on VLAN 40 across to VLAN 20 somehow and that would complete the route for the control messages. However, creating the gateway / static route was the actual solution, and it is all working exactly how I want it now.
Final note is that the IKEA Dirigera operates both as a Matter Bridge and as a Thread Border Router. I am only using it as a TBR. If you are using it as a Matter Bridge then the OpenHab server only ever needs to talk to the Dirigera - never directly to the devices on the Thread network.
Thanks for explaining this again. It never occurred to me that you want to bypass the matter bridge feature of the Dirigera hub. That's why I was pointing out that you only need to connect to the border router (implying the matter bridging).
Assuming I finally understand the setup: Isn't this a multi-admin setup having the Dirigera and OpenHAB server controlling the Thread devices in parallel? This may have a negative impact on the battery life of any devices due to the additional communication. Wouldn't it be much easier to just add a Thread radio to the OpenHAB server and drop the Dirigera Hub, also removing the dependency of the OPNsense routing on the ULA prefixes used by the Dirigera hub?
Quote from: mooh on April 27, 2026, 04:22:34 PMIsn't this a multi-admin setup having the Dirigera and OpenHAB server controlling the Thread devices in parallel?
Technically yes, but I only use the IKEA Smart Home App to connect new devices into the Thread network. Once they are connected I only ever monitor / control them from OpenHab via the TBR. They are still there in the phone app but I never use that, so in practice there is only a single control channel in use.
Quote from: mooh on April 27, 2026, 04:22:34 PMWouldn't it be much easier to just add a Thread radio to the OpenHAB server and drop the Dirigera Hub
I need the Dirigera / IKEA Smart Hope App to handle all the Bluetooth / security handshakes when adding a new device. After that, yes, any generic TBR would work, but as the Dirigera also provides that I don't need anything else right now. If my network grows then I may add a second TBR for redundancy, but haven't got to the point where I need that yet.