Messages

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?

In my eyes it's a bug since wireguard does not need a tunnel endpoint address. My wireguard configuration does not have any configured tunnel endpoint. In the past this worked flawlessly.

During my vacation, I used my roadwarrior Wireguard VPN (Android smartphone -> Opnsense) again after a long period of inactivity. I noticed that IPv6 network traffic wasn't being routed to the internet via the tunnel. IPv4 network traffic, however, worked without any issues. I hadn't changed the configuration in ages. There were only a few Opnsense updates.

I'm currently using Opnsense version 25.7. I tried to reproduce the problem with older Opnsense and older kernel versions. The problem with IPv6 network traffic also exists in the oldest ZFS snapshot (v. 25.1.9_2). So the error must have crept in with an earlier Opnsense update, since I hadn't changed the configuration, and IPv6 in the tunnel had definitely worked in the past.

Further analysis gave the following results:

• A packet capture of the Wireguard virtual interface showed that the IPv6 network traffic from the smartphone arrived correctly at the Wireguard virtual interface, meaning it passed through the tunnel correctly.
• However, the firewall logs did not indicate that IPv6 packets were arriving. Therefore, the problem appeared to be that the IPv6 packets were not reaching the firewall.

Further analysis on the console provided more insight:

Code Select Expand

wg2: flags=10080c1<UP,RUNNING,NOARP,MULTICAST,LOWER_UP> metric 0 mtu 1420
description: My_wireguard_interface (opt15)
options=80000<LINKSTATE>
groups: wg wireguard
nd6 options=9<PERFORMNUD,IFDISABLED>

According to "ifconfig", IPv6 was disabled on the Wireguard interface. Consequently, the packets were filtered on the interface before being forwarded to the firewall. Manually removing the "IFDISABLED" flag in the "nd6 options" or manually assigning an IPv6 address to the interface (which automatically removes the flag) re-enables IPv6, and the network traffic is correctly routed to the internet again via the Wireguard tunnel.

This appears to be a bug in Opnsense, causing the interface to be incorrectly configured. If Wireguard is configured with IPv6, the flag must not be set. Accordingly, Opnsense must remove the flag from the interface if at least one of the following conditions is met:

• In the Wireguard instance configuration, the "Tunnel address" field contains at least one IPv6 address.
• The "Allowed IPs" field of at least one associated peer contains at least one IPv6 address.

In case only condition 2 meets (like in my case), the flag is set and IPv6 traffic is filtered. In my eyes this needs to be corrected in future updates.

If you use a dedicated USB stick and copy the config to the first FAT32 partition you should not run into trouble (for details see here). If you like, you can test this by starting the live system in Virtualbox in your desktop environment. Be sure to always have a recovery strategy to turn back to the old installation in case of unforeseen issues

[...]
So we are back to a mystery.

I got Gigabit throughput on that same board with OPNsense virtualised in bhyve and two network interfaces passed through. Couple of months ago was last I checked.

I have no idea what else I can do. I can test the following scenarios with reference to the thread mentioned (link). After that, I'll probably have to contact the FreeBSD community.

• Create an SPD entry for IPv6 instead of IPv4 and measure the throughput on the LAN
• Upgrade the server to IPv6 and compare the data throughput between IPv4 and IPv6

What I don't understand, however, is why others don't seem to have these problems. The board seems to be used frequently.