"Recent posts
#1
General Discussion / Re: How do IPv6 Router Adverti...
Last post by OPNenthu - Today at 02:32:25 AMThis 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?
Would you be able to achieve the same with a firewall rule in an IoT VLAN?
#2
General Discussion / Re: How do IPv6 Router Adverti...
Last post by barney - Today at 01:59:55 AMThanks 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:
To add a matter device directoy to OpenHab I:
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:
The MDNS response contained:
The way I read this is that:
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:
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
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
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
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 Advertisments
The Dirigera periodically emits an RA which updates the routing table on my test R-Pi within VLAN40:
Code Select
$ 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
#3
26.1, 26,4 Series / Re: This makes me want to cry!...
Last post by OPNenthu - Today at 12:30:21 AMAnother thing to be mindful of-
After you've checked & fixed the hardware clock issues and made sure to replace the battery, keep in mind that NTP will still fail to sync if the system time is significantly behind the real time (I think by 1000 seconds or more).
To get NTP working in OPNsense you need to make sure to set the system time close to the actual wall clock time and then restart the NTP service. You can use the FreeBSD 'date' command to do this.
I found this out the hard way on my Protectli that had a weak battery and NTP wouldn't sync after a power outage.
(Side note: the 'coreboot' UEFI on Protectli is very stripped down and at present doesn't have a method to set the system time, unlike the AMI BIOS, so it's left as a runtime activity for the user to set the clock. A good CMOS battery is important.)
After you've checked & fixed the hardware clock issues and made sure to replace the battery, keep in mind that NTP will still fail to sync if the system time is significantly behind the real time (I think by 1000 seconds or more).
To get NTP working in OPNsense you need to make sure to set the system time close to the actual wall clock time and then restart the NTP service. You can use the FreeBSD 'date' command to do this.
I found this out the hard way on my Protectli that had a weak battery and NTP wouldn't sync after a power outage.
(Side note: the 'coreboot' UEFI on Protectli is very stripped down and at present doesn't have a method to set the system time, unlike the AMI BIOS, so it's left as a runtime activity for the user to set the clock. A good CMOS battery is important.)
#4
26.1, 26,4 Series / Thin disk / ZFS / Unmap?
Last post by ThyOnlySandman - Today at 12:28:46 AMLast week I setup a new ESXi VM template to move from UFS to ZFS and upgrade to 26.1.
I ran several ZFS unmap tests inflating thin VMDK with large ISO and deleting.
zpool set autotrim=on zroot
System didn't appear to auto trim / unmap within ~30 min.
But running - zpool trim zroot - manual trim worked. VMDK shrunk to very close to exact used space So was happy and proceeded to swap over to new ZFS VM template.
Only been weekend since deployed and now reviewing today VMDK is 47GB yet Opnsense reports only 5GB used?
I've since ran manual trim again but it only shrunk VMDK ~1GB. There is no way this much data has ever been written other than some internal ZFS function.
Is ZFS scrub or compression screwing with thin provisioning unmap / zero space?
I'm at a loss what FreeBSD + ZFS + VMFS thin disk is doing - Any suggestions appreciated.
Thin disk is 80GB
# df -h
Filesystem Size Used Avail Capacity Mounted on
zroot/ROOT/default 69G 5.0G 64G 7% /
devfs 1.0K 0B 1.0K 0% /dev
/dev/gpt/efiboot0 260M 1.3M 259M 1% /boot/efi
zroot/var/mail 64G 160K 64G 0% /var/mail
zroot/var/log 64G 31M 64G 0% /var/log
zroot/usr/src 64G 96K 64G 0% /usr/src
zroot/tmp 64G 206M 64G 0% /tmp
zroot 64G 96K 64G 0% /zroot
zroot/usr/ports 64G 96K 64G 0% /usr/ports
zroot/var/audit 64G 96K 64G 0% /var/audit
zroot/home 64G 96K 64G 0% /home
zroot/var/crash 64G 96K 64G 0% /var/crash
zroot/var/tmp 64G 388K 64G 0% /var/tmp
devfs 1.0K 0B 1.0K 0% /var/unbound/dev
/usr/local/lib/python3.13 69G 5.0G 64G 7% /var/unbound/usr/local/lib/python3.13
/lib 69G 5.0G 64G 7% /var/unbound/lib
/dev/md43 484M 48K 445M 0% /usr/local/zenarmor/output/active/temp
fdescfs 1.0K 0B 1.0K 0% /dev/fd
procfs 8.0K 0B 8.0K 0% /proc
tmpfs 100M 24K 100M 0% /usr/local/zenarmor/run/tracefs
# zpool status
pool: zroot
state: ONLINE
config:
NAME STATE READ WRITE CKSUM
zroot ONLINE 0 0 0
da0p4 ONLINE 0 0 0
errors: No known data errors
Edit: Reviewing backup logs the fresh VM template VMDK was 14GB prior to few GB of Zenarmor / NTOPNG data accumulated over weekend.
VMDK has grown around ~29GB beyond what it should be in around 3 days.
I ran several ZFS unmap tests inflating thin VMDK with large ISO and deleting.
zpool set autotrim=on zroot
System didn't appear to auto trim / unmap within ~30 min.
But running - zpool trim zroot - manual trim worked. VMDK shrunk to very close to exact used space So was happy and proceeded to swap over to new ZFS VM template.
Only been weekend since deployed and now reviewing today VMDK is 47GB yet Opnsense reports only 5GB used?
I've since ran manual trim again but it only shrunk VMDK ~1GB. There is no way this much data has ever been written other than some internal ZFS function.
Is ZFS scrub or compression screwing with thin provisioning unmap / zero space?
I'm at a loss what FreeBSD + ZFS + VMFS thin disk is doing - Any suggestions appreciated.
Thin disk is 80GB
# df -h
Filesystem Size Used Avail Capacity Mounted on
zroot/ROOT/default 69G 5.0G 64G 7% /
devfs 1.0K 0B 1.0K 0% /dev
/dev/gpt/efiboot0 260M 1.3M 259M 1% /boot/efi
zroot/var/mail 64G 160K 64G 0% /var/mail
zroot/var/log 64G 31M 64G 0% /var/log
zroot/usr/src 64G 96K 64G 0% /usr/src
zroot/tmp 64G 206M 64G 0% /tmp
zroot 64G 96K 64G 0% /zroot
zroot/usr/ports 64G 96K 64G 0% /usr/ports
zroot/var/audit 64G 96K 64G 0% /var/audit
zroot/home 64G 96K 64G 0% /home
zroot/var/crash 64G 96K 64G 0% /var/crash
zroot/var/tmp 64G 388K 64G 0% /var/tmp
devfs 1.0K 0B 1.0K 0% /var/unbound/dev
/usr/local/lib/python3.13 69G 5.0G 64G 7% /var/unbound/usr/local/lib/python3.13
/lib 69G 5.0G 64G 7% /var/unbound/lib
/dev/md43 484M 48K 445M 0% /usr/local/zenarmor/output/active/temp
fdescfs 1.0K 0B 1.0K 0% /dev/fd
procfs 8.0K 0B 8.0K 0% /proc
tmpfs 100M 24K 100M 0% /usr/local/zenarmor/run/tracefs
# zpool status
pool: zroot
state: ONLINE
config:
NAME STATE READ WRITE CKSUM
zroot ONLINE 0 0 0
da0p4 ONLINE 0 0 0
errors: No known data errors
Edit: Reviewing backup logs the fresh VM template VMDK was 14GB prior to few GB of Zenarmor / NTOPNG data accumulated over weekend.
VMDK has grown around ~29GB beyond what it should be in around 3 days.
#5
German - Deutsch / Re: IPv6 PD hinter FritzBox nu...
Last post by Maurice - Today at 12:28:01 AMWas meinst Du mit "Interface eintragen"?
Services: Router Advertisements
Falls es dort einen Eintrag für das FRITZBOXWAN-Interface gibt, diesen löschen.
Falls nicht, dann:
Interfaces: [FRITZBOXWAN]
IPv6 Configuration Type auf Static IPv6 stellen (und eine Dummy-Adresse eintragen, z. B. 2001:db8::1/64).
Nun wieder zu Services: Router Advertisements und den Eintrag für das FRITZBOXWAN-Interface löschen.
Wenn Du schon dabei bist: Prüfen, dass weder Kea noch ISC noch Dnsmasq auf dem FRITZBOXWAN-Interface aktiv sind.
Abschließend das FRITZBOXWAN-Interface wieder auf DHCPv6 umstellen.
Eventuell wurde opt10 / vtnet4 früher mal anderweitig verwendet und bei der Umwidmung zum WAN-Interface wurde dann radvd (und ggfs. weitere Dienste) nicht korrekt deaktiviert. Und rtsold + radvd auf dem selben Interface geht quasi zwangsläufig schief.
Grüße
Maurice
Services: Router Advertisements
Falls es dort einen Eintrag für das FRITZBOXWAN-Interface gibt, diesen löschen.
Falls nicht, dann:
Interfaces: [FRITZBOXWAN]
IPv6 Configuration Type auf Static IPv6 stellen (und eine Dummy-Adresse eintragen, z. B. 2001:db8::1/64).
Nun wieder zu Services: Router Advertisements und den Eintrag für das FRITZBOXWAN-Interface löschen.
Wenn Du schon dabei bist: Prüfen, dass weder Kea noch ISC noch Dnsmasq auf dem FRITZBOXWAN-Interface aktiv sind.
Abschließend das FRITZBOXWAN-Interface wieder auf DHCPv6 umstellen.
Eventuell wurde opt10 / vtnet4 früher mal anderweitig verwendet und bei der Umwidmung zum WAN-Interface wurde dann radvd (und ggfs. weitere Dienste) nicht korrekt deaktiviert. Und rtsold + radvd auf dem selben Interface geht quasi zwangsläufig schief.
Grüße
Maurice
#6
General Discussion / Re: How do IPv6 Router Adverti...
Last post by OPNenthu - Today at 12:09:14 AMQuote from: mooh on April 20, 2026, 03:44:07 PMMaybe a quick intro to Matter over Thread will help.Good post, @mooh. Thanks!
#7
General Discussion / Re: No IP from DuckDNS and Ded...
Last post by OPNenthu - Today at 12:06:04 AMQuote from: Cobra on April 20, 2026, 02:37:43 PMHow should I configure the rules and interface?
Just the WAN interface is needed, so that OPNsense has an internet connection.
The firewall itself is the one making the DDNS requests so there are no rules needed for that, unless you have enabled the "Disable force gateway" option in Firewall->Settings->Advanced for some reason.
#8
26.1, 26,4 Series / Re: Having SSL for all home ne...
Last post by nero355 - Today at 12:03:16 AMQuote from: bookie56 on April 20, 2026, 08:04:00 PMHave you any other suggestions that are supported in Palemoon?I don't use such software so I guess have a look around @ https://addons.palemoon.org/extensions/ ??
Search for example : https://addons.palemoon.org/search/?terms=password
You could also try : https://addons.mozilla.org/en-US/firefox/addon/bitwarden-password-manager/
Some Mozilla Firefox Extensions/Add-Ons also work in Pale Moon if they are the NPAPI variant!
Good luck! :)
#9
26.1, 26,4 Series / Re: [Solved] Enforcing DNS thr...
Last post by nero355 - April 20, 2026, 11:55:36 PMQuote from: TarteTatin on April 20, 2026, 07:08:22 PMYou're right, I did not see the "invert destination" option. Now I did check it and specified my firewall.COOL! :)
Thanks to you, I had a better look at it!
#10
General Discussion / Re: Newcomer with a quick requ...
Last post by Patrick M. Hausen - April 20, 2026, 11:49:21 PMCreate the VLANs on each of the physical interfaces. Create one bridge for each VLAN. Only supported way in FreeBSD.
