Messages

Just after updating to 26.4_6 the security audit produces a list of 7 vulnerabilities with CVE. Is this the new normal now that AI is searching for them?

This is not meant to discredit the OPNsense maintainers, just a general question. I just want to be prepared for a time when running a firewall with known vulnerabilities is the new normal.

"Request prefix only" ist eine Einstellung des DHCPv6-Clients und nicht PPP-spezifisch. Es geht nur darum, ob der dhcp6c auch IA_NA anfragt.
Bei der Telekom ist es völlig egal, ob man diese Option setzt oder nicht, denn per DHCPv6 bekommt man dort ausschließlich ein Präfix (IA_PD), keine Adresse (IA_NA). Für die Konfiguration der WAN-Adresse wird dort wie gesagt SLAAC verwendet.

Ich höre Deine Worte, aber bei meiner OPNsense hat "Request prefix only" am Telekom Anschluss für Privatkunden, aber sonst gleicher Konfiguration wie der TO, genau die Auswirkung eben keine GUA zu bekommen, respektive eine zu bekommen, wenn nicht gesetzt. Könnte natürlich am Privat- vs Geschäftkundenanschluss liegen.

Und die EUI-64 ist auch von der MAC des Interfaces abgeleitet, über die die PPPoE Verbindung läuft.

Ich glaube der spannende Teil ist die Sache mit der GUA während "nur Präfix" + DHCPv6 für das WAN aktiviert sind. Das passt nicht zusammen. Das WAN Interface sollte eine Adresse der Art "fe80::<EUI-64>%pppoe0/64" haben.

Ist bei den Routern mal von statischer IPv6 Konfig auf DHCPv6 umgestellt worden? Kann da was durcheinander gegangen sein?

Ich bin mir nicht ganz sicher warum auf dem WAN Interface überhaupt eine GUA auftaucht. In der Konfiguration steht doch "nur Präfix anfordern".

Wenn sich die IPv6 ändert, brechen dann auch Verbindungen ab?

Deutsche Telekom usually hands out a static public address for your router plus a prefix. The public address is not from the prefix range. Maybe you can show how exactly the WAN interface is configured?

Upps, falsche Sprache: Die Telekom gibt normalerweise öffentliche Adressen für den Router aus und ein Präfix für. Dies Routeradresse ist nicht aus dem Präfix. Vielleicht zeigst Du mal die geneue Konfiguration des WAN Interface?

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?

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.

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.

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.

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.

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?

Upgrading from 25.10.2_12, I came across this bit in the log:

Code Select Expand

69/196] Extracting os-OPNBEcore-1.8: .......... done
/bin/sh: /usr/local/opnsense/scripts/firmware/register.php: not found
pkg-static: DEINSTALL script failed
/bin/sh: /usr/local/sbin/pluginctl: not found
/bin/sh: /usr/local/opnsense/scripts/firmware/register.php: not found
pkg-static: POST-INSTALL script failedWhat went wrong? Auditing the system doesn't indicate any problem. Full log file attached.

Not every plugin is for everyone — install what fits your needs. 🙂

I didn't mean to belittle your effort. In fact, I appreciate every effort to improve OPNsense.

I just not sure what the size of the target audience for all this host discovery stuff is, yours and the new component of OPNsense. If I want to know what's going on on my network, I ask it directly via SNMP or an all-in-one solution like Unifi or Omada. Only small, unmanaged networks don't already provide that functionality. How many are there using OPNsense?

I would like to see this software rolled into one plugin together with the device discovery service added to OPNsense recently. There's some overlap in functionality.

Then again, unless the information is accumulated over a multi-layer network, i.e. across routers, I could just as well query the network management software for it. I can see how filtering MACs into FW Aliases can be useful if one manages networks on the basis of MAC addresses, but I don't.

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

Hatte früher auch mal ne Fritzbox mit Pyur mit ner anderen *Sense dahinter. Da hat das Präfix auch immer auf sich warten lassen.

Kommte bei Dir das Präfix auch ohne Refresh irgendwann?

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.