Messages

I can see from the source code that CVE-2023-42325 can't affect OPNsense because that code doesn't exist in OPNsense. However, CVE-2023-42327 and CVE-2023-42326 are a bit less clear looking at the source code.

Is OPNsense affected by CVE-2023-42327 or CVE-2023-42326?

Is this a bug in the migration process?

Yes.

https://github.com/opnsense/core/issues/6550

i think native config uses bool for this field

No.

https://github.com/opnsense/core/commit/01922175549b3db79b20c9fb1ec19cc52c784b15

I have observed this same bug again in a recent update. First, please apologise for the snark: you are wrong about which format of boolean the native config uses.

You can verify that older stock installs of OPNsense from the official ISO did indeed use "on" rather than "1" for the Unbound configuration that I am talking about. These are changes that occur when the choices about Unbound are made during the initial wizard. If you start with "OPNsense-21.1-OpenSSL-dvd-amd64.iso.bz2" from this location:
https://mirror.wdc1.us.leaseweb.net/opnsense/releases/21.1/

Perform a plain vanilla install and then during the install wizard choose the DNSSEC configuration settings. Then take a look at the diff of the config.xml. You will see the the "on" booleans that are causing this bug. Here is a screenshot or two.

On the most recent update an error "Unbound Migration failed" was in the update logs. This may have started with an earlier upgrade, but I am just noticing the error because it stands out. The error message says to check log for details. Here is what is shown in the log.

Code Select Expand

[ERROR] Model OPNsense\Unbound\Unbound can't be saved, skip ( OPNsense\Phalcon\Filter\Validation\Exception: [OPNsense\Unbound\Unbound:advanced.dnssecstripped] value should be a boolean (0,1){on}
[ERROR] [OPNsense\Unbound\Unbound:advanced.dnssecstripped] value should be a boolean (0,1){on}

Here is the exact text of the error in the update log:

Code Select Expand

>>> Invoking update script 'refresh'
*** OPNsense\Unbound\Unbound Migration failed, check log for details

I can see exactly what to fix: change the entry in the config XML from "on" to "1" and then the scripts should work. However, I hesitate to fix this manually when there are probably many others with the same problem.

Is this a bug in the migration process?

I've made code contributions to the wireguard plugin in the past. I'm definitely willing to see how to fix this. I just wanted to check in here and discuss before going forward.

The problem is that if one had the os-wireguard plugin installed before this update, after the update, there is a new plugin named os-wireguard-go that is not installed. However, on the dashboard, there is a red stopped entry in the services pane. This indicates a problem. However, from what I gather in the discussion so far, this is not a problem, and the user should manually have that entry in the pane ignored.

Should that dashboard pane entry just be part of the os-wireguard-go plugin only and not appear at all if the os-wireguard plugin is installed alone?

Question about default behavior:

Setting the widget in the services dashboard to be ignored is definitely a solution to this issue. However, the widget should be installed and uninstalled with the wireguard-go plugin, correct?

Checking the instance that I just upgraded: os-wireguard-go is not installed and os-wireguard is.

Shouldn't the dashboard widget follow the particular plugins that are installed rather than needing a user to disable/ignore the widget manually?

Perhaps this is actually a bug?

Thanks so much. That is exactly what I was looking for.

If an update requires a restart, is there a way to schedule the process to occur at a particular time in the future? And another situation: even without an involved update, is there a way to schedule a restart?

I have searched the documentation and the forums here and didn't see anything that stood out that would answer this question.

Bummer - oh well. Thanks for the quick response.

Is it possible to make DHCP changes over the API? I have looked the API documentation up and down and I don't see any endpoints that pretain to the DHCPv4 service. My goal is to check existing leases and then convert one of them to static.

What API endpoint is used to configure DHCPv4 service?

And the rest of the answer to the first question: strings like "WireGuard (Group) net" and "OPT1 net" are from the descriptions and are used in the GUI to display these nets. To refer to these same entities in the API, the string to use is found in the "Name" field in the alias listings. They are listed as type "Internal (automatic)". So, the following are the translation for the two I listed with my question:

"OPT1 net" -> "__opt1_network"
"WireGuard (Group) net" -> "__wireguard_network"

and so on. As for the second question: meh. It's probably by design and is just cosmetic so it doesn't matter if it displays the correct information.

I figured out part of the answer to the first question:

"WireGuard (Group)" when referring to it via API is called "wireguard". I'm not sure if any other plugins work in the same way, but the string that the API needs is found in the config.xml section for the interface in the "if" field:

<if>wireguard</if>

I am trying to create firewall rules via API. I am able to create rules using CIDR, but the system aliases like "OPT1 net" or "WireGuard (Group)" or "WireGuard (Group) net" in the source_net or destination_net fields in the POST'ed JSON. Also, I'm unable to refer to the interface "WireGuard (Group)" in the interface field.

Are these strings usable in the API at all?

On a side note, when the rule is created (using CIDR and interface ID), and you look in the web console listing of "Automatically generated rules", the created rule appears to be wide open with "*" in every column on that view. However, when editing that same rule as listed under "Automation -> Filter", everything looks correct.

Is the web UI not able to display the details of the rule correctly? Or is showing all "*" in each column by design and the expected way for the rule to be displayed?

If anyone runs into this installer bug, here is a specific workaround until the problem can be fixed.

1. Login to the OPNsense web console.
2. Navigate to the "Interfaces" menu.
3. Select "Assignments".
4. In the pane that appears on the right, click "Save".

Also, here is the Github issue for the bug:

https://github.com/opnsense/core/issues/5768