Messages

Jetzt wollte ich Dir ein Scrrenschot schicken, auf dem Du siehst, das hier nur Hetzner DNS zu sehen ist.
Naja, keine Ahnung warum, ob es einfach dauert oder ob der zwischenzeitliche Reboot etwas geändert hat, aber jetzt steht hier auch bei mir Hetzner DNS und Hetzer DNS (Legacy). Vielleicht wäre als Name HetznerCloud treffender. Dann ist es eindeutig, das es die Cloud API anspricht.
Egal, Eintrag ist aber da und es funktioniert auch.
Solved stimmt also ;)
Danke

Moin,

Hier steht zwar Solved davor, aber gelöst ist es ja nicht. Oder?
Selbst jetzt, im Juli 26, hat der os-DDClient 1.31_1 nur die Hetzner DNS Console im Angebot, die es mittlerweile gar nicht mehr gibt.
Ist denn eine Lösung in Aussicht? Also eine Lösung, die nicht einen eigenen DNS Server, oder ähnliche Bastelei, beinhaltet.

Grüße

Ich hatte noch ein Snapshot mit der Version 26.1.5

Den Snapshot habe ich zurück gespielt. Der hatte auch die Kernel Version 26.1.3, aber hier Lief das Update auf die 26.1.6 durch. Danach war auch der Kernel auf 26.1.6

Fehlermeldung hatte ich bei dem ersten Update eigentlich auch nicht. Wäre also interessant zu wissen, warum da noch ein alter Kernel drin war und wieso das erst jetzt, nachträglich in der Version 26.1.6 aktualisiert werden sollte.
Zumindest habe ich jetzt das Kernel Problem nicht mehr.

Ich bekomme einen Fehler, wenn ich ein Update machen möchte
Bei der Abfrage bekomme ich die Meldung:

base   26.1.3   26.1.6   upgrade   OPNsense
kernel   26.1.3   26.1.6   upgrade   OPNsense

Wenn ich dann das Update starte, kommt die Meldung unten:

***GOT REQUEST TO UPDATE***
Currently running OPNsense 26.1.6 (amd64) at Tue Apr 14 15:03:49 CEST 2026
Updating OPNsense repository catalogue...
OPNsense repository is up to date.
Updating SunnyValley repository catalogue...
Fetching meta.conf:
Fetching data.pkg:
SunnyValley repository is up to date.
All repositories are up to date.
Updating OPNsense repository catalogue...
OPNsense repository is up to date.
Updating SunnyValley repository catalogue...
Fetching meta.conf:
Fetching data.pkg:
SunnyValley repository is up to date.
All repositories are up to date.
Checking for upgrades (3 candidates): ... done
Processing candidates (3 candidates): . done
Checking integrity... done (0 conflicting)
Your packages are up to date.
Checking integrity... done (0 conflicting)
Nothing to do.
Checking all packages: .......... done
Nothing to do.
Nothing to do.
Flushing temporary package files...find: /usr/local/etc/wireguard/wg1.stat: No such file or directory
find: /usr/local/opnsense/changelog/index.json: No such file or directory
find: /usr/local/opnsense/changelog/24.7.b.txt: No such file or directory
find: /usr/local/opnsense/changelog/26.1.5.htm: No such file or directory
find: /usr/local/opnsense/changelog/25.1.7.htm: No such file or directory
find: /usr/local/opnsense/changelog/24.7.7.txt: No such file or directory
find: /usr/local/opnsense/changelog/20.7.7.txt: No such file or directory
find: /usr/local/opnsense/changelog/26.1.r1.txt: No such file or directory
find: /usr/local/opnsense/changelog/21.1.7.htm: No such file or directory
find: /usr/local/opnsense/changelog/21.7.r2.htm: No such file or directory
find: /usr/local/opnsense/changelog/25.1.9.htm: No such file or directory
find: /usr/local/opnsense/changelog/24.7.9.txt: No such file or directory
find: /usr/local/opnsense/changelog/changelog.txz.sig: No such file or directory
Starting web GUI...done.
Partial update failure detected: report this error log to OPNsense.
No further actions will be taken. Please restart the update now.
***DONE***

Bei einem Health-Check, bekomme ich die folgende Ausgabe:

***GOT REQUEST TO AUDIT HEALTH***
Currently running OPNsense 26.1.6 (amd64) at Tue Apr 14 15:10:29 CEST 2026
>>> Root file system: /dev/gpt/rootfs
>>> Check installed kernel version
Version 26.1.3 is incorrect, expected: 26.1.6
>>> Check for missing or altered kernel files
No problems detected.
>>> Check installed base version
Version 26.1.3 is incorrect, expected: 26.1.6
>>> Check for missing or altered base files
No problems detected.
>>> Check installed repositories
OPNsense (Priority: 11)
SunnyValley (Priority: 7)
>>> Check installed plugins
os-bind 1.34_2
os-chrony 1.5_3
os-debug 1.7
os-isc-dhcp 1.0_4
os-net-snmp 1.6_1
os-postfix 1.24.1
os-qemu-guest-agent 1.3
os-sensei 2.4.2
os-sensei-updater 2.0
os-sunnyvalley 1.5_2
os-telegraf 1.12.14
os-vnstat 1.3_1
>>> Check locked packages
No locks found.
>>> Check for missing package dependencies
Checking all packages: .......... done
>>> Check for missing or altered package files
Checking all packages: .......... done
>>> Check for core packages consistency
Core package "opnsense" at 26.1.6 has 68 dependencies to check.
Checking packages: ..................................................................... done
***DONE***

Unter Status sehe ich:
Type   opnsense   
Version   26.1.6


Was kann ich machen, um das System wieder sauber zu bekommen?

Es ist viel einfacher als gedacht und es geht out of the box. :D
Der RNDC Key ist genau dafür gedacht. Der muss im BIND aktiviert und auf einen Algorithmus (MD5 /SHA...) eingestellt werden. Das gleiche setzt man dann im ISC unter DynDNS ein. Sowohl der Key selbst als auch der entsprechende Algorithmus. Etwas Tricky ist der Key Name. Der ist so nicht direkt ersichtlich. Er lautet aber RNDC-Key. Das trägt man im ISC in der jeweiligen Zone unter DynDNS ein.
Wenn dann im BIND in den Primare Zonen auch der RNDC Key aktiviert ist (Transfer / Update) wird das vom ISC auch im BIND hinterlegt. Man muss dann allerdings auch die entsprechende Reverse Zone mit anlegen und auch hier den RNDC erlauben.


Kaum macht man es richtig, geht das auch. ;)

Grüße

Hallo Patrick,

Danke für deine Antwort. Auch wenn das nicht die Antwort ist, die ich mir erhofft habe.
Ist eigentlich schade, das man das, was die Komponenten eigentlich können, wegen der GUI nicht umsetzen kann.

Unbound habe ich bisher im Einsatz gehabt. Das nervt aber, durch ständige Abstürze und anderes unlogisches Verhalten. Leider sehe ich da auch die Einträge nicht, die vorhanden sind.

Gibt es denn eine Möglichkeit, bei BIND eine zusätzliche Config Datei einzubinden, ohne das die GUI von OPNSense das wieder rausschmeisst?


Grüße

Hi,

Ich suche eine Möglichkeit, den BIND Service mit ISC DHCP nutzen zu können. Sprich, die DHCP Einträge sollen auch via BIND aufgelöst werden können.
Im DHCP finde ich den DynDNS Abschnitt, der eigentlich passt. Problem ist aber, das ich die Key Einträge im BIND nicht machen kann. Da gibt es nur den RNDC Key. Laut Doku von BIND sollte das aber gehen. Problem ist dann aber, das ich die Einträge nicht per Hand machen kann und in der GUI gibt es das nicht. Trage ich das per Hand in die Config, wird das umgehend vom System wieder überschrieben. Spätestens wenn mal in der GUI mal im BIND Abschnitt was geändert hat.
Das ist also wenig Ziel führend.

In der Suche habe ich nicht wirklich was sinnvolles gefunden. Vermutlich habe ich nur die falschen Schlüsselwörter benutzt.
Ich kann mir aber nicht vorstellend as das bisher noch niemand gemacht hat. Hat jemand ein Tipp für mich?

Das RFC2136 Plugin ist prinzipiell schon gut, nur müsste ich da ja jeden Host eintragen, der sich dann aktualisiert. Das ist also nicht so ganz das richtige.


danke

Since you configured your FritzBox for IA_PD only, what are your v6 related DMZ interface settings (request prefix only etc)?

The DMZ Interface ist configured as DHCP6.
Configuration mode Basic
Prefix only and Prefix hint is active

The interface getting each time the same IP

xxxx:xxxx:xxxx:xxxx:xxxx:5054:ff:febc:b9b6/64

x = ISP IPv6

However, except for the xid error (which I'm unaware of) things look good.

Below is a screenshot of my interfaces->overview->WAN->details listing for comparison.

Thank's - my Details looks different

some more ideas:

(1) did you try restarting radvd?

yes
For now - I got the problem that the radvd crashes. To much reconfigured - I think....
I have had this problem long time ago. I hope I find again the command to rest the damon.

(2) sure not firewall / vlan related?

I think yes, but not sure any more ;)


The detail, that the Fritzbox says delegated prefix xxxx.xxxx.xxxx.xxxx/60 and opnsense says /64 with same address make me crazy

The only error, that is as error marked, inside the System - general log ist this:

/services_dhcpv6.php: The command '/usr/sbin/daemon -f -p '/var/run/dhcpleases6.pid' '/usr/local/opnsense/scripts/dhcp/prefixes.sh'' returned exit code '3', the output was 'daemon: process already running, pid: 37530'

This occurs every time I changed the config of the dhcp6 or restart the dhcpv6.
All other ist notice

I'm having a bit of trouble understanding your setup due to naming stuff. Assuming your interface named "DMZ" is your WAN interface on OPNsense,

Right, my Interface DMZ is heading to Fritzbox.

you say it only gets a /64 prefix delegated from the FritzBox to OPNsense?

I have checked this. Now I get a /64 from ISP. Is like the same as you showing in your screenshot.
Two differences -

I have configured the Fritzbox to IA_PD only
Delegated size is /60

That is the size that is configured under Interface DMZ - Prefix Delegation Size
Inside OPNSense under ISC_DHCPv6 - Interface 1 / Interface 4 i see a subnetmask of 64 bit

(2) error logs

It's very strange that there are no dhcp6c errors / warnings at all in system->Log Files->General. You should check if there are any dhcp related errors right after you reboot OPNsense.

After the last reboot I see a lot more messages from dhcp6c. Switching log level need reboot?

I see only two messages that can be a error:
unknown or unexpected DHCP6 option opt_86, len 16
XID mismatch

I think the point for me is the hint for the link local addresses. Or?

All my interfaces have got a fe80: address.
But thanks for your hint.

[broken]

(1) you get a prefix delegated large enough on DMZ

Yes, I get a /56 from ISP an delegated a /64 to DMZ Interface

(2) increase logging level of DHCP to see what actually happens (interfaces->settings->IPv6 DHCP)

On which log is that working? System? dhcp?
I don't see more output wich increase log level

(3) did anything change in the FritzBox itself? Firmware / settings? (Have seen this before breaking correct downstream delegation)

Yes, some weeks ago new firmware was coming from AVM
Not sure if this a reason but I get anymore my IPv6 delegation on OPNsense

(4) Do you have Router Advertisements enabled? Try playing with that. When enabled, there are almost no devices at all using the DCHPv6 anyway and you won't see leases.

Yes, it is active as managed
Have tried it to disable but doesn't change the behavior for DHCPv6 so far

Maybe post some screenshots of your config and / or DHCP related log stuff?

I can do that. but what you want to see?
Inside the log, systems and/or dhcp, I don't see any problems.
Last entry after restart dhcpv6 is:
Sending on Socket/8/em0/xxxx:xxxx:xxxx:a8f1::/64
listening on Socket/8/em0/xxxx:xxxx:xxxx:a8f1::/64
Sending on Socket/8/em0/xxxx:xxxx:xxxx:a8f4::/64
listening on Socket/8/em0/xxxx:xxxx:xxxx:a8f4::/64
Bound to *:547

Looks fine for me.

I tried setup DHCPv6 on OPNsense as well, but came to the conclusion DHCPv6 is broken as well!!?

the implemantion of DHPCv6 and OPNsense is tricky. I have need some days for my first setup to. But it was working like a charm for long time. I was able to give each VLAN a separate network inside the IPv6 from ISP. After each change the IPv6 for my network was changed to. That was working very well.

Hello,

I had DHCPv6 running for a while. That also worked well. A few days ago I noticed that no v6 address was being distributed. I don't have the exact cause or time.

Opnsense gets an IPv6 from the provider via Fritzbox on the interface DMZ. IF1 and IF4 track the interface DMZ and distribute a prefix ID 1 and 4 respectively.

When I noticed the problem, interface 1 and interface 4 did not get a v6 address as long as DHCPv6 was active. If I deactivated DHCPv6, the assignment of the v6 address worked. I found the entry no suitable address several times in the log.
I then deactivated DHCPv6, removed the v6 assignment from interface 1 and 4 and rebooted. Then reactivated the v6 addresses, rebooted - reactivated prefix ID for v6, reactivated DHCPv6 manual adjustment - rebooted, reactivated DHCPv6 - rebooted
;D

The current status is that both interfaces 1 and 4 now have a clean Ipv6 address with the correct prefix ID. DHCPv6 is running according to the GUI, range is available, I no longer see any errors in the log.

But - no IPv6 is being distributed. It seems as if the DHCPv6 server simply does nothing.
PID exists and according to ps the DHCPv6 is running

Does anyone have any tips?

can you explain your solution on detail? Which NAT you have had that make a problem after the update?

Das hilft nicht wirklich weiter. RADVD und DHCP sind zwei verschiedene Dinge und nicht wirklich vergleichbar.
DHCPv6 sollte funktionieren, hat es bisher auch sehr gut.