Messages

Tja, geht nicht... :-(

[...]

Da die kurze Netztrennung nichts gebracht hat, empfehle ich Dir – wie unter #1 gesagt – einen Paketmitschnitt zu machen. Dann siehst Du, was in Bezug auf IPv6 los ist bzw. nicht funktioniert. Alles andere is ein herumstochern im Nebel. Es ist ja auch nicht ausgeschlossen, dass der Fehler möglicherweise beim ISP liegt.

Mein Aufbau:
Deutsche Glasfaser -> FritzBox -> OPNSense

Einen solchen Aufbau hatte ich in der Vergangenheit mit Vodafone und Kabelmodem. Bereitstellung eines IPv6-Präfix und IP-Adresse hatte immer problemlos funktioniert. Dieses Szenario sollte also grundsätzlich funktionieren. Aktuell betreibe ich die Opnsense direkt am Anschluss der Deutschen Glasfaser. Das funktioniert einwandfrei (abgesehen davon, dass IPv6 nach dem Start bis zu 15 Minuten dauert, bis es funktioniert -> eigensinnige Philosophie der DG).

OPNSense fordert von der FritzBox ein 60er Prefix an (den Rest benötigt die Fritzbox für ihre Netze).
Ich habe DHCPv6 auf dem WAN sowie dem LAN, Gast, IoT Interface eingestellt.

Wie Maurice schon geschrieben hatte, sollte auf dem WAN kein radvd laufen. Aber warum hast Du abgesehen vom WAN die anderen Schnittstellen auf DHCPv6 konfiguriert? Du möchtest doch nur vom Präfix abgeleitete Subnetze (/64) auf die internen Schnittstellen verteilen, oder?

Nach einem Neustart bekommt der WAN-Port eine IPv6 Adresse, die anderen bekommen keine (ich vermute, ich bekomme kein Prefix von der FritzBox).
Drücke ich auf Interface->Overview bei WAN-Interface auf Refresh (mehrfach, 2-3 mal), dann bekommen die die Interfaces eine IPv6.

[...]
Nur das 2-3 fache Drücken des Refresh-Buttons auf der GUI bringt irgendwann die IPv6.
Das Problem ist reproduzierbar!

Prüfe mal über die Konsole, ob die Opnsense ein Präfix und IP-Adresse erhalten hat. Wie sieht die Ausgabe der folgenden Befehle aus?

Code Select Expand

# ifctl -6pi <wan interface>
# ifconfig <wan interface>


Ich betreibe meine Opnsense auch direkt am DG-Anschluss. Ich hatte mit Updates der Opnsense in dieser Hinsicht bisher nie Probleme gehabt. Die Option ,,Use IPv4 connectivity" gibt es nur für PPPoE-Verbindungen. Dies hat bei der DG keine Relevanz.

Was steht unter Interfaces -> Overview -> (WAN-Interface)?


Du kannst zunächst folgendes probieren:

• Nimm mal das Glasfasermodem für kurze Zeit vom Stromnetz und warte nach Wiederherstellung der Stromversorgung ca. 15 Minuten. Prüfe dann, ob die WAN-Schnittstelle IPv6-Adresse und -Präfix erhält
• Falls Punkt 1 nicht hilft. Trenne die Ethernet-Verbindung zum ONT und starte einen Paketmitschnitt auf der WAN-Schnittstelle (Protocol: IPv6, Count: 3000). Schließe dass Ethernetkabel dann wieder an und lasse den Mitschnitt für ca. 15-20 Minuten mitlaufen.

I've been using Opnsense for a long time now and I have to say it's a truly excellent product. Many thanks to the developers and the community for making this project a reality and ensuring its continued existence.

Donation done.

For renewing a IPsec S2S connection I tried to clone the connection (just in case if something goes wrong).

But cloning of the IPsec connection in Opnsense 25.7.4 fails with the following error message. The new connection is partially created (Local/Remote authentication and children are missing).

PHP-Error:

Code Select Expand

[07-Oct-2025 17:55:13 Europe/Berlin] OPNsense\Base\ValidationException: [OPNsense\IPsec\Swanctl:locals.local.0977c3df-a3e1-4fd7-bc3a-9675c163c8c2.connection] Option not in list.{21ff4ad2-57d4-417b-8ee7-b3efd5c1327a}
[OPNsense\IPsec\Swanctl:remotes.remote.6bee0d82-f55d-40a9-8ba4-88706e84772b.connection] Option not in list.{21ff4ad2-57d4-417b-8ee7-b3efd5c1327a}
[OPNsense\IPsec\Swanctl:children.child.865d0565-290a-4d9a-9e38-761797b9f123.connection] Option not in list.{21ff4ad2-57d4-417b-8ee7-b3efd5c1327a}
[OPNsense\IPsec\Swanctl:children.child.eb152ed1-c641-4b72-9883-b0ac8014f658.connection] Option not in list.{21ff4ad2-57d4-417b-8ee7-b3efd5c1327a}
[OPNsense\IPsec\Swanctl:children.child.ad84fad2-87f9-44ed-9c5f-0303a535e563.connection] Option not in list.{21ff4ad2-57d4-417b-8ee7-b3efd5c1327a}
[OPNsense\IPsec\Swanctl:children.child.4ed1a40b-d996-4b33-b1ad-3f2c20b404dd.connection] Option not in list.{21ff4ad2-57d4-417b-8ee7-b3efd5c1327a}
 in /usr/local/opnsense/mvc/app/models/OPNsense/Base/BaseModel.php:802
Stack trace:
#0 /usr/local/opnsense/mvc/app/controllers/OPNsense/Base/ApiMutableModelControllerBase.php(319): OPNsense\Base\BaseModel->serializeToConfig(false, false)
#1 /usr/local/opnsense/mvc/app/controllers/OPNsense/IPsec/Api/ConnectionsController.php(127): OPNsense\Base\ApiMutableModelControllerBase->save()
#2 /usr/local/opnsense/mvc/app/library/OPNsense/Mvc/Dispatcher.php(166): OPNsense\IPsec\Api\ConnectionsController->setConnectionAction()
#3 /usr/local/opnsense/mvc/app/library/OPNsense/Mvc/Router.php(156): OPNsense\Mvc\Dispatcher->dispatch(Object(OPNsense\Mvc\Request), Object(OPNsense\Mvc\Response), Object(OPNsense\Mvc\Session))
#4 /usr/local/opnsense/mvc/app/library/OPNsense/Mvc/Router.php(139): OPNsense\Mvc\Router->performRequest(Object(OPNsense\Mvc\Dispatcher))
#5 /usr/local/opnsense/www/api.php(36): OPNsense\Mvc\Router->routeRequest('/api/ipsec/conn...', Array)
#6 {main}
Does anybody know what exactly went wrong?

Und wie genau? DUID-LL? Weißt Du das sicher?

Ja, das weiß ich sicher, sonst würde ich es hier ja nicht schreiben. Ich hatte es in der Vergangenheit über einen Paketmitschnitt ermittelt, da ich die DUID in der Konfigurationsdatei nicht finden konnte.

AVM verwendet DUID-LL:

• DUID type: 0x0003
• Hardware type: 0x0001
• Link layer address: xxxxxxxxxxxx

Details siehe RFC8415.

MAC klonen hilft nicht wirklich, weil für IPv6 eine DUID genutzt wird - mir ist es nie gelungen, herauszubekommen, wie die Fritzbox diese bildet oder sie auszulesen.

Die Fritzbox generiert die IPv6-DUID aus der MAC-Adresse. Daher ist eine Speicherung der DUID in der Konfigurationsdatei nicht notwendig.

Moin zusammen,

ich möchte ein kurzes Update geben: Ich hatte gestern noch ein Gespräch mit der DG, die mir bestätigte, dass mein Anschluss "gestört" sei.

In #1 hast Du alles richtig gemacht, sieht ähnlich zu meiner Konfiguration aus. Der Kundensupport hat jedoch noch sehr viel Luft nach oben. Ich bekomme regelmäßig zu hören, dass mein Anschluss gestört sei. Anschließend versanden die Tickets regelmäßig oder werden ohne Rückmeldung geschlossen.

An meinem Anschluss habe ich aktuell das Problem, dass die Gegenstelle "Router solicits" einfach ignoriert. Daher dauert es an meinem Anschluss nach dem Neustart der Opnsense bis zu 15 Minuten, bis sie ein IPv6-Präfix zugewiesen bekommt. Aktuell kann ich damit eher leben, als mich wieder mit dem 1st-Level-Support rumzuärgern, welcher von Technik keinen blassen Schimmer hat.

No, powerd wasn't the problem. I tried many configurations without success. In retrospect, it looks to me like a timing issue in the FreeBSD kernel, which is probably causing problems with the default ACPI configuration of the UEFI firmware.

All good things come to those who wait.

Half a year ago, I conducted further tests with Opnsense, PFsense, FreeBSD (vanilla), and Linux. Both Opnsense and PFsense had the same data throughput issue, while FreeBSD and Linux did not. I couldn't really determine the cause. As a last resort, I've now turned my attention to the UEFI firmware configuration.

Bingo! In the UEFI firmware of the "Supermicro A2SDi-4C-HLN4F" motherboard, there is an option called "ACPI 3.0 T-States." Disabling this option restores almost full throughput. I couldn't find any information about current versions of FreeBSD supporting ACPI 3.0 T-States. Since the issue didn't occur with the vanilla version of FreeBSD, but did occur with both open-source firewalls, it's difficult to prove whether this option is the cause or just a symptom.

So if anyone has similar problems, they should keep an eye on this or similar power management options.


Edit: The above option was already present and enabled in the first BIOS version when I purchased the motherboard in 2017. Unless there were any changes to the ACPI tables during that time, the bug may have been introduced or triggered with a later version of FreeBSD.

The silence in the GitHub plugin repo regarding the issue disagrees with your blanket statement, but I'm not here to challenge you on a local issue that may persist.

The reason for this is likely that the GitHub issue doesn't reflect the observations I started the thread with. While the GitHub entry discusses an unclean shutdown, this thread is about startup problems with the proxy. The root cause may be the same. Since the problem I observed wasn't always reproducible, root cause analysis wasn't easy either. The current observation (checked recently) is that the Squid proxy sporadically crashes with a segfault, but restarts automatically. The previously mentioned command "squid -k parse" also ends with a segfault.

Personally, I don't like the fact that people come and complain about issues but once they are gone do not bother to give useful feedback. It is what it is, though.

Calm down, with posts like these, the community forum is sure to be successful in the long run. There can be countless reasons why someone stops responding to a thread. In the past, at least one of them was that the email notification wasn't working reliably.

Right - https://github.com/opnsense/core/issues/9021

I was surprised that the GitHub issue was closed. I can't tell from the ticket content that the bug has been fixed. Does anyone have any further information?

No, the issue of "segmentation fault" still persists in Opnsense 25.7.1. In case squid crashes it will automatically be restarted. So, despite the log entries I never observed any interruptions of the squid service anymore.

[...]
I'd also like to change the MAC on all internal parent interfaces as a security measure against applications leaking firewall OUI / manufacturer info to the outside.
[...]

Why do you think changing the MAC address improves security? Of course, the original MAC address reveals the manufacturer of the network card or motherboard, but only to devices on the same Layer 2 network segment. MAC addresses are not transmitted across routers.

For a long time, I used a custom, locally managed MAC address for the WAN interface to avoid problems with my ISP if my hardware changed. This configuration worked perfectly for many years and with several different ISPs, until a few weeks ago.

What happened? My ISP, Deutsche Glasfaser, was conducting maintenance work in our area. During this exact time, the internet connection went down overnight. Absolutely no communication was possible; the remote end simply didn't respond to any of the sent Ethernet frames. It was a tedious process to resolve the issue, especially because the non-technical support provided conflicting and incorrect information :-(.

After a thorough technical investigation, I discovered that the ISP was using similar MAC addresses for its own infrastructure after completing maintenance. Apparently, the ISP allocated the MAC address range, which also included my custom address, and applied an inbound filter for the CPE to prevent MAC address collisions. After updating the MAC address for the WAN interface, everything worked again.

I just updated from Opnsense version 25.7 to 25.7.1 and noticed that the IPsec VPN on my smartphone is no longer working. The IPsec widget in the dashboard shows "no phase 1 configured", while everything looks fine in the configuration section.

On the console, the "swanctl --list-conns" command confirms that no connections are configured. It seems as if Opnsense is forgetting to derive a correct IPsec configuration from its global configuration file.

After switching back to the previous Opnsense version (v.25.7), everything is working fine again. Has anyone observed a similar issue?