Messages

Isn'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.

Wouldn'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.

[The mdns-bridge running on OPNsense reflects that message from VLAN 40 to VLAN 20.]

This 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.

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.

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.

Do 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,

[I]

If 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. 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.

I shouldn't have assumed how your environment is.

No problem - I appreciate you taking the time help.

[is]

By 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?

if 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.

Don'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:

Code (json) Select Expand

{
  "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 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.

[and all the matter devices connected through it]

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.)

Would 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.

[More Details]

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 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:

Code Select Expand

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:

Code Select Expand

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:3fcc
The 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 Advertisments

The Dirigera periodically emits an RA which updates the routing table on my test R-Pi within VLAN40:

Code Select Expand

$ 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 medium
That 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

[Update: Ignore all this - completely off on the wrong track...]

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:

The 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,

Thanks for taking the time to look at this.

Is 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?

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 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...