Messages

I think that the options were set by default to follow the Suricata 6 behavior.

That's what I thought as well when I read the upgrade announcement, but, apparently, the app-layer.error-policy value still follows Suricata 7 behavior: Our VNC repeater connections work in IPS mode only if I manually set

Code Select Expand

app-layer:
  error-policy: ignore

in /usr/local/opnsense/service/templates/OPNsense/IDS/custom.yaml.

The planned checkbox would allow me to get rid of that customization.

I have to admit that I'm not a suricata expert. If there is a better way to "whitelist" a custom app-layer protocol to a specific port on a specific IP, I'm open to suggestions.

I just upgraded to 24.1.3_1, but I still cannot see this new checkbox, which would allow me to get rid of my current /usr/local/opnsense/service/templates/OPNsense/IDS/custom.yaml customization:

https://github.com/opnsense/core/pull/7271/commits/70dfce8d5f95a5e71da48f145e01d1ce9d22503f

Did that change not make it into 24.1.3?

OK, here we go: config.xml did *not* have opnsense-business anywhere.

I tried the upgrade process again, and, this time, I was bold and chose "y" despite the scary sounding error message about pkg being called with the wrong parameters and... it worked. First it downgraded to 22.7.11 and repeating the upgrade process eventually upgraded it to 23.1.6. :-)



Naturally, I wanted to find out *why* that scary pkg message turned up, and the root cause seems to be the following code in scripts/firmware/reboot.sh:

Code Select Expand

if [ -n "${LQUERY}" -a -n "${RQUERY}" -a \
    "$(${PKG} version -t ${LQUERY} ${RQUERY})" = "<" ]; then
echo ${RQUERY%%_*}
fi

Apparently test's -a doesn't short-circuit, so, when RQUERY is empty (due to failing to fetch a server-side file?), pkg version still displays error output. My sh skills are a bit rusty, but I see a few ways to fix that:

• Use short-circuiting tests instead: if [ -n "${LQUERY} ] && [ -n "${RQUERY}" ] && ...
• Quote the parameters: Double quotes can be nested inside $(...), so just putting double quotes around ${LQUERY} and ${RQUERY} should work.
• Suppress stderr output from pkg.

Best regards and thanks for all the great work on opnsense
Heinzi

The business edition 22.10 now has the 23.1 config of the other device?

Yes, that should be the case. The CLI shows the network configuration from the main device, so I have to assume that the import was successful.

I'll check for <type> on Friday, when I'm back at the office, and report back. Thanks!

I already have a running opnsense firewall, and I want to use a second device as cold standby. I bought one of the Deciso devices, and they arrive pre-installed with opnsense business (22.10). For compatibility reasons (I want both devices to have exactly the same configuration), I also want this device to run the community edition (just like the main device).

So far, I did the following:

• Connect on the serial console.
• Import the configuration from the main device via a USB stick with "8 Shell" and "opnsense-installer".
• Now, when I try to upgrade the device with "12) Update from console", I get the following error message:

Code Select Expand


Fetching change log information, please wait... fetch: https://pkg.opnsense.org/FreeBSD:13:amd64/22.10/sets/changelog.txz: Not Found

This will automatically fetch all available updates and apply them.

Usage: pkg version [-IPR] [-hoqvU] [-l limchar] [-L limchar] [-Cegix pattern]
                    [-r reponame] [-O origin|-n pkgname] [index]
        pkg version -t <version1> <version2>
        pkg version -T <pkgname> <pattern>

For more information see 'pkg help version'.
This update requires a reboot.

Proceed with this action? [y/N]:


Indeed, https://pkg.opnsense.org/FreeBSD:13:amd64/22.10/sets/changelog.txz does not exist.

How do I tell my device (from the CLI) to upgrade to the latest community edition?

To answer my own question:

The OPNsense Ghz small box has a APU.1D board with on-board RAM that cannot be upgraded.

I have a Deciso OPNsense Ghz small box, which has served me well over the last few years.

However, we seem to be hitting the 2GB RAM limit recently: Every now and then, suricata will crash after downloading new rule sets:

Code Select Expand

...
2021-07-31T20:10:07 /rule-updater.py[9914] download completed for https://rules.emergingthreats.net/open/suricata-4.0/emerging.rules.tar.gz
2021-07-31T20:10:29 kernel pid 4369 (suricata), jid 0, uid 0, was killed: out of swap space
...


There is no swap partition enabled (which makes sense, since the system only contains an SD card (16 GB) as permanent storage), so my first thought was to upgrade RAM. I imagine that going from 2 to 4 GB would be the easiest (= least work for me) and probably also the cheapest way to fix this. (Please do tell me if you disagree and recommend something else instead.)

So, my plan would be to (a) open up the device, (b) find out the brand and type of the mainboard, (c) check the mainboard docs for compatible RAM, (d) buy it and (e) replace the RAM.

My question to you, dear community:

• Anything wrong with this plan? Has anybody already done this successfully/unsuccessfully?
• Is the mainboard and/or supported RAM for this device documented anywhere (I did not find it in the spec section of the Deciso/applianceshop link mentioned above), so that I can skip steps a-c?

Thanks, best regards

For future readers: An example for how to set this up has been added to the opnSense/monit documentation:

https://docs.opnsense.org/manual/monit.html

Credit goes to this thread: https://forum.opnsense.org/index.php?topic=17967.0; my thanks go to FullyBorked for finding out how to do it and to mimugmail for adding it to the docs!

What he wants to know is what is the value of linking certificates to users when not enabling this feature. My 2 cents; it probably does not provide any value except for administrative purposes and the ability to enable the strict linking.

Well, the documentation of the "Strict User/CN Matching" option says:

When authenticating users, enforce a match between the Common Name of the client certificate and the username given at login.

which I would interpret such that the CN and the user name must be an exact string match. So, apparently, that's a completely different feature than the "linking certificates" of opnsense, which allows me to link arbitrary certificates and logins (irrespective of the certificate's Common Name!).

So, linking certificates and logins is only useful for administrative purposes...?

@banym: Yes, using expiring certificates is definitely useful. Unfortunately, however, I do not see how this is related to my question...

At the bottom of VPN: OpenVPN: Client Export, I can see which certificates are linked to which users.

I thought that the purpose of this was to ensure that only these combinations of certificate+user are valid, i.e. that a user can only log in with a certificate linked to them.

But it appears that I was mistaken: I just tried connecting with my personal login data and a certificate which is not linked to any user yet and... to my surprise, it just worked.

If that is not the purpose of linking certificates with users, what is the purpose?

Thanks for enlightening me
Heinzi

(Note: I know that I can configure OpenVPN to match user names and certificate CNs. That's not what my question is about. My question is about the linking between users and certificates that can be configured in System: Access: Users: (Choose user): User certificates, and which is shown in VPN: OpenVPN: Client Export.)

Using the serial console access, I was able to fix the issue. If anyone ever encounters a similar issue, this is what worked for me.

The console showed the following error during startup:

Code Select Expand

Configuring firewall.......done.
Starting PFLOG...done.
Syncing OpenVPN settings...
Fatal error: Uncaught Error: Call to undefined function openssl_x509_parse() in /usr/local/etc/inc/certs.inc:391
Stack trace:
#0 /usr/local/etc/inc/certs.inc(727): cert_get_subject_array('LS0tLS1CRUdJTiB...')
#1 /usr/local/etc/inc/plugins.inc.d/openvpn.inc(759): cert_get_cn('LS0tLS1CRUdJTiB...')
#2 /usr/local/etc/inc/plugins.inc.d/openvpn.inc(1228): openvpn_reconfigure('server', Array, false)
#3 /usr/local/etc/inc/plugins.inc(243): openvpn_configure_do(true)
#4 /usr/local/etc/rc.bootup(114): plugins_configure('vpn', true)
#5 {main}
  thrown in /usr/local/etc/inc/certs.inc on line 391
Enter full pathname of shell or RETURN for /bin/sh:

I pressed return to enter the shell and ran opnsense-update, which yielded the following output:

Code Select Expand

The following 5 package(s) will be affected (of 0 checked):

Installed packages to be REMOVED:
        openssl-1.1.1d,1

New packages to be INSTALLED:
        openssl102: 1.0.2u

Installed packages to be REINSTALLED:
        python37-3.7.6 (direct dependency changed: openssl102)
        py37-cryptography-2.6.1 (direct dependency changed: openssl102)
        cyrus-sasl-2.1.27_1 (direct dependency changed: openssl102)

Now the reason for the problem was obvious: The 20.1 version of OpenSSL was running together with the 19.7 version of OpenVPN. Apparently, the upgrade to 20.1 had only been half done, leading to mutually incompatible packages.

The fix for this was easy: Restore the system to a working 19.7 configuration with opnsense-update, then upgrade to 20.1 using the console boot menu.

Lessons learned:

• Major updates can take a long time on slow devices. Plan for a long downtime and don't be impatient!
• The OPNsense documentation recommends to perform major upgrades via VGA display or serial. Heed that advice!
• The Deciso appliances ship with a USB-to-serial null modem cable already included, which is awesome!

I just upgraded my Decisio appliance (OPNsense GHz small) from 19.7.10 to 20.1 via the Web UI. This is what happened:

1. After downloading everything, the web UI told me to wait for a reboot.
2. After half an hour, the appliance was still unavailable. This had already happened during the 19.1 -> 19.7 upgrade (see https://forum.opnsense.org/index.php?topic=13749.msg63309), so I didn't worry and power cycled the device.
3. The device was quickly back online, with some services working (NAT, WAN failover), and others not working (OpenVPN, Web UI). Yes, this means that I cannot access the web UI any more!

nmap shows that no ports are open on the LAN interface of the device. I tried another power cycle, but it didn't help.

I just ordered a null-modem cable and a USB-serial adapter to see if I can debug this issue via the serial console; both should arrive next week.

Any other hints on what I can try in the meantime?

OK, thanks for the quick reply!

I successfully set up and configured IPS in opnsense. If I try to open a TCP connection from inside my network to a host listed, e.g., in the ET botnet list, the connection is blocked and I get an alert. So far, so good.

The problem is: The alert shows up in the opnsense web UI. I don't want to regularly check the web UI for alerts. If an alert happens, I'd like to be notified (by e-mail), so that I can investigate whether this is a security incident or a false positive.

Is there some built-in functionality in opnsense to activate this kind of e-mail notification? I activated Monit, but none of the built-in service alerts seems to relate to the IPS.

Thanks and best regards