Messages

A further workaround solution could be switching to DH group 31 when using OpenSSL flavor. Prerequisite is that the other endpoint must support this group.

I'll test this with my configuration next week.

Github ticket see here (#6068).

It looks your USB NIC has a Realtek chipset. Unfortunately, FreeBSD (backend of Opensense) has not a good support for USB NICs. I am facing the same problem with my realtek USB NIC connecting my network printer to the Opnsense. After reconnecting the cable you need to reset the USB device manually and reassign its IP address.

At the console you can use the following command to breathe new life into your USB NIC:

Code Select Expand


root@opnsense-host:~ # usbconfig -d [i]<device id>[/i] reset && sleep 1 && ifconfig ue0 [i]<IP address>[/i] up


where <device id> can be retrieved with the following command (first string token of line representing your USB NIC (without colon)), and the IP address is its originally configured IPv4 address and netmask (e.g. 10.1.0.1/24).

Code Select Expand


root@opnsense-host:~ # usbconfig


I had similar issues after updating my Opnsense to the version 22.7.x short time ago. Before doing this I switched from LibreSSL to OpensSSL due to the fact that LibreSSL is deprecated (link). Update went fine after a few approaches. But I didn't notice the issues with multiple isolated Child_SAs per IPsec connection. I started some research beginning with with the log error message "unable to install inbound and outbound IPsec SA (SAD) in kernel". Maybe at the other endpoint there will only be a message "no proposal chosen" depending on which endpoint started the negotiation.

Result is, that this is an issue with OpenSSL. Switching back to LibreSSL solved this issue. But, due to the discontinuation of LibreSSL this can only be a short term solution. The detailed problem is, that the key derive function in OpenSSL 1.1.x has not enough buffer space to handle modp8192. The key derive function fails with an error code and the IKE daemon is unable to negotiate additional phases 2.

I see the following resolutions:

• Switch back from OpenSSL 1.1.x back to LibreSSL (only a short term solution, because it will break again if LibreSSL is dropped in next major release)
• Reduce the key derive configuration for all phases 2 from modp8192 to a lower one (e.g. modp4096 should be fine and is still treated as secure by the security community and BSI the next time (subject to change))
• Switch to OpenSSL 3.0.5 or higher (Unfortunately, OpenSSL 3.x branch is still not available for productive FreeBSD). It would be glad if somebody can backport the small patch for increasing the buffer size of the HKDF function)

References:

• https://github.com/strongswan/strongswan/issues/1255
• https://github.com/openssl/openssl/commit/20c2876f24d0ccf9581ace08c7882d544d2588ea
• https://www.openssl.org/docs/man1.1.1/man3/EVP_PKEY_CTX_add1_hkdf_info.html

Today, I tried to upgrade the Opnsense again. Before starting I proactively disabled the new dd-client in the web gui. Everything went fine including the latest update to version 22.7.2.

Now, I need to check how to investigate the dd-client script in conjunction with my configuration without breaking the installation again.

Have you tried disabling ddclient? I believe editing the /etc/rc.conf.d/ddclient file will allow you to disable the service.

I tried disabling DDNS by modifying the config during runtime. I know, this is not the best idea but followed this way because I did not know how to disable the service on the CLI. So, I'll give your hint a try. Thanks.

Without trying to sound like a completely unsympathetic person, and I ask with respect, how do you propose that anyone, including the devs to replicate your specific hardware/configuration mix?

I think we misunderstood each other. It's almost impossible that any other can replicate my problem on the current level of information. But that's not my intention. I'd like to debug the issue myself and asked for hints how to control certain parameters via the CLI (e.g. interactive standalone execution of ddns scripts (line-by-line), disabling services, reloading specific services etc.).

I've never seen my OPN installations trying to "call home", i.e. to collect metrics, so there might (or not) be numbers available of the number of upgrades, but going by the forums posts, I make a guess that there are hundreds or more successful upgrades of those versions; so it doesn't seem (to me) like a widespread problem and more pertaining to a specific configuration.

It's in the nature of things. The fewer of these have a problem, the more help is required from the person concerned. BTW, nowadays there is a lot of software calling home or having some kind of telemetry included.This is often a plague and can also induce risks. So, I am happy that Opnsense does not have such things included.

Back to the current issue. Are you able to ctrl+c to finish booting? If so, then get to the UI to disable the dynamic dns as a test, and console to gather system logs? I can see if you're remoting in and only ssh is available, this would be an unlikely scenario.

Unfortunately, ctrl+c only terminates the script and drops me to the shell. This means Opnsense is incompletely started and does not offer the gui. But internet access via shell is available after adding a public DNS to /etc/resolv.conf. I guess I can debug and investigate the issue by temporarily disabling DDNS services and execute them standalone. But I don't know how to achieve this on the command line. I'll try the first hint given by @WN1X

Thanks for your reply. In my eyes a complete reinstallation should only be the last resort. Before the update all files were intact (health audit). So, it looks like there is bug in version 22.7 which lead to enter a dead lock state during the boot process. To improve overall software quality such hints on bugs should be investigated.

I tried in that direction by disabling the service via command line. Unfortunately, there is no command line reference existing how control the firewall (e.g. install/uninstall/enable/disable services). Instead, I tried editing the config file using "vi" and restarting all services. No luck.

In the stuck state the web gui is not accessible because either not started or blocked by the incomplete setup of firewall rules.

Do you know about a command line reference of CLI based opnsense tools?

Thanks

Does nobody has an idea how I can debug this issue? Currently, I am not able to keep the firewall up to date and patch any security issues :'(.

Maybe one of the developers can give hints how to execute the boot scripts separately or step-by-step. Further hints besides the ones mentioned are appreciated.

Thanks.

Hi all,

yesterday I started to upgrade my Opnsense from 21.1.10 to 22.7.2. The upgrade process to 22.7.0 went fine till reboot. After rebooting the sense never came up and the console showed that booting was stuck at "Configuring dynamic DNS clients..."

I further updated to version 27.7.2, but the same issue still exists.

After the system was stuck I got the console after pressing Ctrl-C, so I could manually update to the latest version and start the text based opnsense-shell. Using the latter, restarting all services did not change anything. I also tried disabling DDNS by modifying the config.xml, but no chance.

Has anybody noticed a similar issue or has an idea how to debug?

[Instead, Mobile IPsec fails:]

It appears that OPNsense incorrectly requires the client certificate to be installed inside OPNsense. This should NOT be required. If OPNsense has a server certificate issued from an external CA, and, a copy installed of that external CA (just the public cert, no private key), then OPNsense should be able to correctly verify the authenticity of the remote Mobile IPsec client presented client certificate.

Instead, Mobile IPsec fails:
[...]

You're are partly right. It depends on configured trust anchor for client authentication. Strongswan itself can handle both (Leaf certificate and CAs). But, there are several bugs in Opnsense's IPsec implementation. Maybe, you've triggered one of them. Unfortunately, fixing them does not seem to have high priority.

There are already some bug reports in Github (Link). So, don't trust what is configured in the web gui and have a look into strongswan's config file (/usr/local/etc/ipsec.conf).

Feel free to (re-)open bug reports in Github.

It looks like the CDCE mode of  the Realtek NIC doesn't work either since Opnsense 22.1.10. Does anybody observed the same issue?

Besser ist, wenn Du schrittweise vorgehst. Für den Zugriff vom mobilen Endgerät über IPsec ins Internet benötigst Du:

• Einen IPsec-Tunnel (Phase 2), welcher Netzwerkverkehr ins gesamte IPv4-Netz überträgt (mobiles IPv4-Netz <-> 0.0.0.0/0)
• Eine NAT-Regel, welche Dein mobiles IPv4-Netz in die WAN-IPv4 übersetzt (hast Du bereits gemacht, wähle als NAT-Target aber besser "Interface address")
• Eine Firewall-Regel, welche auf der IPsec-Schnittstelle eingehenden Verkehr vom mobilen IPv4-Netz ins Internet zulässt

Dann sollte es klappen. Über die Firewall-Regel(n) definierst Du zukünftig, zu welchen Zielnetzen der Verkehr Deiner mobilen Endgeräte geroutet wird.

Ich nehme mal an, dass der Internetzugriff vom Roadwarrior VPN ausschliesslich über NAT geregelt werden muss, da kann ich ja keine zusätzliche Phase2-Route einfügen.

Doch, genau das ist zu tun:

• Du musst für den Roadwarrior entsprechende Phase2-Einträge auf der Opnsense machen.
• Die S2S benötigen ebenfalls entsprechende Phase2-Einträge auf der Opnsense und am anderen Endpunkt.
• Korrespondierende Firewalleinträge für die netzübergreifende Kommunikation der IPSec-Verbindungen auf der Opnsense erstellen
• Gegebenenfalls an den S2S-Gegenstellen noch die Firewall anpassen und die Endgeräte mit einer korrespondierenden Route zum Roadwarrior-Netz versorgen

NAT benötigst Du für die reine IPSec-Kommunikation nicht, sondern nur falls der Roadwarrior über das VPN auf das Internet zugreifen soll