Messages

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