Messages

1

24.7 Production Series / What is present advice about OpenSSH/SSH/SSHD cve-2024-6387

« on: July 01, 2024, 06:15:10 pm »

https://www.qualys.com/2024/07/01/cve-2024-6387/regresshion.txt

(Claimed regression of CVE-2006-5051)
( https://www.freebsd.org/security/advisories/FreeBSD-SA-24:04.openssh.asc )

Assuming there will be a patched sshd in a new OPNSense hotfix/release, what is the present best advice for people running sshd?

sshd.config alter "LoginGraceTime" to "0" (unlimited) then bounce sshd service or some other step?

Thanks!

2

Hardware and Performance / Re: Intel Atom P5000 / P5322 Support

« on: November 16, 2023, 07:13:37 am »

Sorry to resurrect a 5 month old thread, but the content I wanted to provide seemed worth the discomfort of bringing back an old thread:

I too had a A3SPI-8C-LN6PF based motherboard which didn't work with HBSD 14 or FreeBSD 14 several months back.

(It worked fine with many new Linux based systems at the time.)

SuperMicro has not yet updated this to show FreeBSD 14 seems to work on it, but this is what SuperMicro claimed was supported when the motherboards were made and no FreeBSD support listed at all:

https://www.supermicro.com/support/resources/OS/Parker_Ridge_Intel_Atom_C5000.cfm

However, I recently re-tested with Hardened BSD 14 (latest) and it worked for me.
I also included a full buildworld, buildkernel and install both with CPU arch optimizations in /etc/make.conf for the cpu. (The Atom CPU Type was tremont)

If Hardened BSD 14 (based on FreeBSD 14) works now with this motherboard, that implies FreeBSD 14 will probably work now for the same class of motherboards.

According to https://www.freebsd.org/releases/14.0R/schedule/ FreeBSD 14 release annoucement was planned for yesterday, but maybe isn't quite ready.

Issuing a "uname -K" on an OPNSense system which is still on 23.7.7_3 (not yet upgraded to 23.7.8_1) and I see:
1302001

This puts OPNSense squarely in the middle of some variation of FreeBSD or related version 13.x kernel.

According to https://opnsense.org/about/road-map/ , as of right now, the plans for OPNSense 24.1.x is January 2024, but it does not indicate a move to 14 will be included. OPNSense 23.7.x is reported earlier in the doc as being based on FreeBSD 13.2.

If OPNSense installer does not yet work on your motherboard, maybe wait until OPNSense is based on a *BSD version 14 installer or later.

Hopefully this will help you or others looking to get this class of motherboard to work with OPNSense.

Good luck!

3

22.7 Legacy Series / "live view" results do not persist on screen: they disappear from view

« on: December 22, 2022, 05:50:21 pm »

Is there a way to have "live view" (Firewall -> Log files -> Live view) setup with a filter (example:  "interface_name=YOUR_NAME" and "action!=pass" and "src!=255.255.255.255" and "dst!=255.255.255.255")

and then show the results and have them persist on the page?

The behaviour I am seeing right now is not like earlier releases of OPNSense...

Now, a collection of matched to the filter appear in the browser, then in 0.2 seconds to 5 seconds disappear. Later other matches appear, then disappear. I've had to resort to "control-a , control-c" to copy the results when I see them, so I can paste them into a text editor, so I can read them.

At one time (maybe 1 year ago), matches to filter would appear on page an not disappear. Each match would appear in order, one row after the next until max allowed rows were found, then stop, and not disappear unless we selected the "refresh" option/button.

Thanks!

4

22.1 Legacy Series / Re: Persistent NIC ordering/naming basedon MAC address(es)

« on: May 25, 2022, 05:01:51 pm »

Thanks :-)
It has reliably worked with every upgrade since it was installed.
We even had a NIC fail. I edited the config while the server was up, commented out the MAC addresses from the failed card, put in the new MAC addresses for the replacement, shut down, replaced NIC, rebooted, worked.

5

22.1 Legacy Series / Re: NUT does not detect UPS connected via USB

« on: April 29, 2022, 11:06:11 am »

The UPS is "Numeric Digital 800 plus"
It is on the list here: https://networkupstools.org/ddl/NUMERIC/Digital_800_Plus.html

That page example shows:
ups.productid : 5161
ups.vendorid : 0665

What does your UPS actually use and tell you over USB? (If you don't know, and/or don't know how to find out , suggestions on how to find out posted below: I don't know your skill level. I'm not trying to be insulting. I try to write things to be consumable by a greater audience than an individual. Maybe people other than you can benefit. :-)

I'm using the blazer_usb driver and that driver replaces the older/previous megatec driver, and it is using the megatec Q1 protocol.

As mentioned, the UPS is detected when I run the blazer_usb driver manually as the root user (with the -u root option).

I've also tried the newer QX driver (nutdrv_qx), with the same results.

When working to diagnose other UPS serial (old fashioned RS232/DB9) and USB issues, I encountered a case like this...

Running debug options for a USB "driver" to UPS resulting in success/partial-success when running as root from the command line.

For me, the "problem" was with devd device permissions for the added USB device.
My device didn't match the devd DB for supported UPS, so it didn't change mode or permissions for the added USB device.

Using Linux "lsusb -vv |less" or FreeBSD "usbconfig dump_all_desc | less" , find the USB device for your UPS in the output, then locate that USB device's "idVendor" and "idProduct"

Take these hexadecimal values (after the 0x) you found when interrogating your UPS over USB and look in your OPNSense devd nut config file to compare/evaluate:
/usr/local/etc/devd/nut-usb.conf

See if you can find a supported device that uses those values for "idVendor" and "idProduct"
If there are none, even if your UPS is supported, devd is probably not altering the device permissions to allow non-root access to talk to the added USB , UPS device.

One route which I suggest not doing and relying upon long-term, if this is the problem, is adding an entry to the file similar to the others, but matching your vendorID and productID, then reloading devd or rebooting, then seeing if the "/dev/" device gets the desired ownership/permissions so that non-root can talk to it.

It might be a good step toward diagnosing the issue, but isn't really supportable, as the next update of the package that owns that file, and you will have to re-apply changes. Additionally, integrity checks for files owned by packages which have changes could issue alarms about the config file not matching the vendor installed file.

In my case, I was lucky: a firmware upgrade of my UPS having this problem (supported model, but vendorID and product/device ID not listed in the file) resolved the issue. After UPS Firmware upgrade and "reboot of the UPS with the new firmware" it appeared again on USB using a supported vendorID and product/device ID, allowing the default devd rules included with nut services to work with my UPS.

Assuming your UPS uses the samples from the URL provided:
ups.productid : 5161
ups.vendorid : 0665

Checking /usr/local/etc/devd/nut-usb.conf on my present 22.1.X (April 29, 2022) install shows me

#  Belkin F6C1200-UNV  - blazer_usb
notify 100 {
        match "system"          "USB";
        match "subsystem"       "DEVICE";
        match "type"            "ATTACH";
        match "vendor"          "0x0665";
        match "product"         "0x5161";
        action "chgrp uucp /dev/$cdev; chmod g+rw /dev/$cdev";
};

If the text you have above is accurate, then check your nut devd config for:
   0.017996     - VendorID: 06da
   0.018020     - ProductID: 0003

Do you find this in your devd config?
#  Mustek Powermust  - blazer_usb
notify 100 {
        match "system"          "USB";
        match "subsystem"       "DEVICE";
        match "type"            "ATTACH";
        match "vendor"          "0x06da";
        match "product"         "0x0003";
        action "chgrp uucp /dev/$cdev; chmod g+rw /dev/$cdev";
};


Is devd working for you on your system?
 # /etc/rc.d/devd status
 Try reloading devd:
 # /etc/rc.d/devd reload
 or maybe:
 # /etc/rc.d/devd restart
 or if not an option, a reboot will surely reload devd with the nut devd usb config.
 Then unplug the USB cable to the UPS and plug it back in. Are the /dev/* device permissions and ownership now "right" for non-root access?
Does your USB device use these same VendorID and ProductID provided above in 2 examples?
Can you confirm the ownership (user:group) and mode match the expected settings from your file when detected?
 From your text:
   0.000983     Checking device (06DA/0003) (/dev/usb//dev/ugen0.3)
 # ls -l /dev/usb//dev/ugen0.3
 What are the ownership and permissions for that device (assuming same for your USB to UPS)?
Is more than one "/dev/*/ file added for your USB based UPS, and are you using one /dev/* file to talk to your UPS while the nut software is using another?
If your VendorID and ProductID do not match this, do they appear in this devd config file from nut anywhere else?

If your UPS is supported but has different VendorID/ProductID, it would probably be a good idea to see if the latest nut (source) includes your UPS in the devd rules, and if not, then submit it to the nut maintainers to get it added.

Other things to consider:
 If you have been running tests as root, check to see if you have accidentally created directories, or files which the nut service running as non-root can no longer read from or write to.
 Did the debug process accidentally remove a dedicated lockfile directory the non-root service needs to run correctly?
 Were any changes made to the non-root user (/etc/passwd) or groups (/etc/group) that could break the non-root nut users access?
 Are you trying to use special kernel hardening security features not supported by stock OPNSense such as MAC, or sysctl customizations for securelevel, etc.?

I hope this provides you with enough ideas to find a solution and then post what you did to solve this problem.

6

22.1 Legacy Series / Re: OPNSense, UPS, Nut, USBHID-Driver

« on: April 14, 2022, 01:19:31 am »

That makes sense. Mods, feel free to move this thread with setting up Nut with USBHID to UPS and the other thread on setting up Nut with SNMPv1 or SNMPv3 to UPS to the other forum.

Thanks!

7

22.1 Legacy Series / OPNSense, UPS, Nut, USBHID-Driver

« on: April 13, 2022, 11:13:31 am »

How I setup OPNSense to use NUT to talk to my UPS over USB...

You may remember my string of posts showing an example setup for using Nut with the SNMP driver to talk either SNMPv1 or SNMPv3 through nut to a UPS which supports those, here:
https://forum.opnsense.org/index.php?topic=27776.0

Since I was unable to get Nut to communicate over AES encyrpted session with SNMPv3 (even though snmpwalk was able to talk AES to the UPS) I switched over to trying to have Nut connect over USB using the Nut "USBHID-Driver"

Getting Nut installed is the same:
In order to support SNMP-Driver, on OPNSense, login to the web interface.

System -> Firmware -> Plugins:

Now, right frame, choose to "+" install "os-nut":

Refresh web page after install, Scroll down to "Services" and check for:
Services -> Nut -> Configuration

In the right-frame, specify your Desired IP address for nut service, and name the UPS configuration to use.
To avoid problems, try using a name without any white-spaces, and limit the name to alpha-numerics with underscore, hyphen, and periods.

Enable Nut: X
Service Mode: NetClient
Name: NameForYourUPSWithoutSpaces
Listen Address: YOUR_IPv4_OR_IPv6_Address_For_NUT_Service_Here
[Apply] (choose apply)

To setup use for the Nut "USBHID-Driver" some information to help you:

Use your preferred OS of choice to connect to the USB port of your UPS, and try to identiy the 4 hexadecimal-digit code for "VendorID" along with the 4 hexadecimal-digit code for "ProductID".

Sometimes UPS have multiple USB ports, and each have different purposes. Make sure to check your product manual to determine which USB port is used for signalling status of the UPS and connect to it.

With many Linux distributions, you have "lsusb" as root to show you all of these.

An example of the format for output of these devices might be:
Bus [0-9]{3} Device [0-9]{3}: ID [0-9a-f]{4}:[0-9a-f]{4} SOME_DESCRIPTION_OF_ITEM_HERE

The 3 digit integer following "Bus" refers to which USB "Bus" identified where is is connected.
The 3 digit integer following "Device" refers to which USB "Slot" on a shared USB "Bus" is connected.
These tend to be unreliable if selected to identify your UPS, as they can change assignments each boot, or when BIOS/Firmware is upgraded, or features are enabled/disabled in BIOS/Setup.

The 2 groups of 4 hexadecimal-digits separated by a Colon ":" are the items of interest here.
The Second item of interest is the string that follows, which in this example is "SOME_DESCRIPTION_OF_ITEM_HERE"

You can probably identify your UPS using the "SOME_DESCRIPTION_OF_ITEM_HERE" string provided, but it can change with firmware upgrades, so isn't as reliable as using the "VendorID" and "ProcuctID" but it is better than trying to use the USB Device/Bus.

The 4 hexadecimal-digits to the left of the colon refer to "VendorID" while the 4 hexadecimal-digits to the right refer to a "ProductID" : The product ID can sometimes change when firmware is upgraded, but the VendorID tends to not change very much.

Another item you can use to try to help the Nut "USBHID-Driver" identify your UPS is your UPS's Serial Number, if it is presented over USB as an identifier.

From FreeBSD (like what OPNSense is using right now) you can try:
"usbconfig dump_all_desc | less"

Look through the list, and then if you can find your device described in a line which is left-justified with no spaces to the left something like:

ugen[0-9].[0-9]: <NAME_OR_DESCRIPTION_OF_UPS_OR_MODEL_OF_UPS> at usbus[0-9], cfg=[0-9] md=[.]* spd=FULL (12Mbps) pwr=ON (10mA)

Then look below that for these lines of data if present:
...
  idVendor = 0x[0-9a-f]{1,4}
...
  idProduct = 0x[0-9a-f]{1,4}
...
  iSerialNumber = 0x[0-9a-f]{1,4}  <SOME_SERIAL_NUMBER>
...

Copy the 4 hexadecimal values you see for your UPS "idVendor" after the "0x" somewhere.
 (Let's assume your devices vendorID is "abcd")
Copy the 4 hexadecimal values you see for your UPS "idProduct" after the "0x" somewhere.
 (Let's assume your devices productID is "0123")
Copy the sting for "iSerialNumber" contained within the "<" and ">" but not including the "<"or ">"
 (Let's assume your devices serial number is "0a1b2c3d4f-0000"

On OPNSense web interface, visit:
Services -> Nut -> Configuration

On the right, you should see "Services: Nut: Configuration" with the "General Settings" you filled out with your data above, and applied.

There should what looks like a "tab" to the right of "General Settings" called "UPS Type"
The "UPS Type" tab should have a down-triangle to the right.
Click on that down-triangle and you should see a drop-down menu with choices of drivers.
Visit each driver and make sure that any drivers other than the "UBSHID-driver" are NOT enabled. If they are enabled, disable and choose apply for each that is enabled.

Next, visit "UPS Type" down-triangle , drop-down menu: USBHID-Driver and add data:
Enable: X
Extra Arguments:

In this "Extra arguments" you will want to make some decisions on how to identify your USB Device:
 Use VendorID and ProductID (or)
 Use Serial Number (or)
 Use VendorID and ProductID and Serial Number

From above, we assumed
your device's vendorID was "abcd")
your device's productID was "0123")
Your device's serial number was "0a1b2c3d4f-0000"
(Your VendorID, ProductID and Serial number will almost certainly be different)

Add what you want to the Extra arguments like:
vendorid=abcd
productid=0123
serial=0a1b2c3d4f-0000

A required "extra argument" is "port" which for USB can be auto:
port=auto

An Optional Extra argument is a description for the UPS, and maybe choose a name/model of your UPS without spaces and add it:
desc=ModelX_UPS

Final list of extra arguments:
port=auto
desc=ModelX_UPS
vendorid=abcd
productid=0123
serial=0a1b2c3d4f-0000

(The values you would use would be different)

Then you choose to apply:
[Apply]

Is it working?

A word of warning: if this does not work, your web interface can become slow and sluggish, requiring you to try to resolve these changed from the command-line.
If you are confident that won't be a problem, visit:
Services -> Nut -> Diagnostics

If you are NOT feeling confident, then before you visit "Diagnostics" maybe see if your DeviceID and ProductID are claimed as supported with your install of nut and its USBHID-Driver. A good place to check?
/usr/local/etc/devd/nut-usb.conf
Review that file, and see if you can find any mention of you device with an entry that contains BOTH the VendorID and ProductID you found reported by your UPS when asking for it over USB.
If it is listed, that should raise your confidence.
If not listed, then it is a bit of a gamble.

When you visit the "Diagnostics" pages, if your device is supported, and the USB cable works, and the USB Interface on your UPS and system are working, and the device you specified matches your UPS, then within 3 seconds you should see information appear to the right once you visit the "Services -> Nut -> Diagnostics" page.

If you do not, you can try tests from the command line as root.
Recall the name you assigned your UPS on the "General Settings" screen under Services -> Nut -> Configuration

If you called it "NameForYourUPSWithoutSpaces" then that is the name to use here:
/usr/local/libexec/nut/usbhid-ups -DDDDDDDDDDDDDDD -a NameForYourUPSWithoutSpaces -u root

If that "works" you should see super-detailed information where your OPNSense Nut service "usbhid-driver" tries to talk to the USB device you identified in the "UPS Type" tab under the "USBHID-Driver" using the "Extra Arguments"

Errors and problems described when running this may help you to identify the problem.

Here is an example of bad news for you:
...
   0.015875     This VENDORNAME device (baad:f00d) is not (or perhaps not yet) supported by usbhid-ups. Please make sure you have an up-to-date version of NUT. If this does not fix the problem, try running the driver with the '-x productid=0004' option. Please report your results to the NUT user's mailing list <nut-upsuser@lists.alioth.debian.org>.
   0.015877     Device does not match - skipping
...

("baad:f00d" is an example of a 4-hexadecimal digit for "VendorID" with a colon then a 4-hexadecimal digit for "ProductID" which would be replaced with the VendorID and ProductID for your UPS.)

It probably means your device is not yet supported.

In one case, I found that upgrading the UPS Firmware and then *rebooting* the UPS (taking all outlets offline, unplugging UPS, then pressing power button to turn off UPS for moving, then plugging it back in, pressing the power button, then re-enabling all of the outlets) caused the "ProductID" to change, and suddenly be supported. This is an uncommon and should not be *expected* but it worth trying.

If you found problems with this procedure and have suggestions, please post replies to help other people have an easier time than you did.

Useful links:
 * https://networkupstools.org/docs/man/usbhid-ups.html : man page on web with mentions for supported hardware for this driver and descriptions for many "Extra Arguments" not used in this example.

I hope this helps you. Good luck!

8

22.1 Legacy Series / Re: CVE-2018-25032 , zlib,

« on: April 13, 2022, 09:57:33 am »

Notes for "22.1.5" include:
"
...
Due to popular demand the user experience for the revamped VLAN handling was improved in several areas. Also incuded are a larger Unbound MVC rework and DNS system route apply changes from one single spot. Last but not least the zlib vulnerability was fixed in FreeBSD amongst others.
...
src: zlib compression out-of-bounds write[9]
...
"
It looks like 22.1.5 notes say this CVE was addressed. Thanks!

9

22.1 Legacy Series / Re: OENVPN / Issue with external script "could not execute external program"

« on: April 09, 2022, 06:22:38 pm »

Here is an example. Review what is done here before you use it. Try to understand it.

New file:
/usr/local/etc/inc/plugins.inc.d/openvpn/ovpn_setup_cso_wrapper.sh
=8<=============cut below here===============
#!/bin/sh
#

# Wrapper script example to call original and "my" scripts, too:

# Some variables to maybe use later:
myARGV="$@"
myScriptName="$0"
PATH="/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/root/bin"
export PATH
myScriptBaseN=`basename "${myScriptName}" | tr -d '[[:space:]]'`
myPID="$$"
myTick=`date '+%s'`
myTmpFile=`mktemp /tmp/${myScriptBaseN}.${myTick}.${myPID}.XXXXXXXXXXXXXXX`

echo "Starting wrapper script: " >> ${myTmpFile}
date  >> ${myTmpFile}

# Do you want to see the environment you are provided when called?
# Uncomment these and review the logged tmp file after this script is called:
#echo "BEGIN:My local environment when called:"
#set >> ${myTmpFile}
#echo "END:My local environment when called."

# Now, order doesn't really matter to me, but may matter to you. Call your scripts before the default or after?
# Here is an example default script to call based on what you showed before:

echo "Calling 'ovpn_setup_cso.php' with args passed: '${myARGV}'"  >> ${myTmpFile}

/usr/local/etc/inc/plugins.inc.d/openvpn/ovpn_setup_cso.php $myARGV >> ${myTmpFile} 2>&1
myES1="$?"

date  >> ${myTmpFile}
echo "Call to ovpn_setup_cso.php' resulted in exit status of '${myES1}'" >> ${myTmpFile}
echo "An exit status of zero '0' implies no errors encountered." >> ${myTmpFile}
echo "Non-zero implies error encountered."  >> ${myTmpFile}

# Now maybe you have scripts to call
date  >> ${myTmpFile}
echo "Now calling YOUR_SCRIPT_NAME" >> ${myTmpFile}
/path/to/your/script $myARGV >> ${myTmpFile} 2>&1
myES2="$?"

date  >> ${myTmpFile}
echo "Call to YOUR SCRIPT' resulted in exit status of '${myES2}'" >> ${myTmpFile}
echo "An exit status of zero '0' implies no errors encountered." >> ${myTmpFile}
echo "Non-zero implies error encountered."  >> ${myTmpFile}

# Repeat as needed

# Your choice on how to exit. You could save the exist status of the original script
#  and exit with that value here, or always exist with happy exit status:

#exit $myES1
exit 0

=8<=============cut above here===============

chmod 755 /usr/local/etc/inc/plugins.inc.d/openvpn/ovpn_setup_cso_wrapper.sh
chown SOMEUSER:SOMEGROUP /usr/local/etc/inc/plugins.inc.d/openvpn/ovpn_setup_cso_wrapper.sh
(
The chown needs to be a user or group or both which the service calling the wrapper script would have access. or example, if openvpn is running as user "openvpn" group "openvpn" which is not a member of any other group, then the "chown" command can be to have the user and/or the group be the owner. Example:
chown openvpn:openvpn /usr/local/etc/inc/plugins.inc.d/openvpn/ovpn_setup_cso_wrapper.sh
)

Once you understand the script and alter it, call the script to see if you introduced any errors, or failed to address addition of content for your customizations and look for errors.
Check out the resulting file it creates, each time it is called:
ls -lt /tmp/YourScriptBaseName* | head
choose one and review it.

Writing scripts can help you automate steps and diagnose bugs. Even if you do not use this, it could help you to understand what is being done, and then adapt it as needed for other purposes.

You will notice it is a bit verbose with what it logs, and logs to a new file each call. This is meant for debugging. In the final form, you would likely want to have your script send its logged output to systlog (see command "logger" man page instead of directing all output to a temp file)

This script is for illustrating a ways to use a wrapper script which can be be called instead of the "real" (original) and then call the original as well as do other work to try to debug issues, or overload the calling of other scripts with the calling of one script. I take no responsibility in how you use it.

Good luckl

10

22.1 Legacy Series / Re: OENVPN / Issue with external script "could not execute external program"

« on: April 04, 2022, 11:09:53 pm »

I do not see your script handling any arguments passed to it, then passing those arguments to each of the scripts it is calling.

Next, I do not see any PATH setting and export in your script. It is often a good idea for these kinds of scripts to set a PATH environmental variable and export it.

PATH isn't needed if you use the absolute path to each binary and confirm they don't change with upgrades.

Next, you should consider some debugging like adding:

date >> /tmp/client-conenct-script-called 2>&1

so that when it is actually run, if the date command can be found in your PATH or a full path to the date command is used, the STDOUT and STDERR are both dumped to the test temp file /tmp/client-conenct-script-called

All of these to see if your script is even being called.

Another point of debugging?
Try adding:
set > /tmp/lient-conenct-script-set_env.`date '+%s'`

maybe you can see what environmental variables actually in memory when your script is called before taking actions to act on variable that may or may not be in memory.

From the above, you should be able to gather enough debugging information to alter your script after you confirm it is being called.

11

22.1 Legacy Series / Re: OPNSense, UPS, Nut, SNMP-Driver, SNMPv1 or SNMPv3

« on: April 03, 2022, 04:57:08 pm »

Once you have everything working as you want, you should consider revisiting settings to better secure your configuration:
If you have SNMPv3 working and don't need SNMPv1, why not disabled SNMPv1?
If you know the hosts which will be talking to your SNMPv3 service, why not restrict access to just the hosts?
If you enabled multiple users to test AES and DES, why not disable the accounts which you are not using?


If you decide to experiment with adding support for AES after DES is working, and your web iterface becomes super slugglish immediately after enabling AES and then choosing Services -> Nut -> Diagnostics, you may need to get a shell on your server to change settings, then re-visit the web interfaces and re-save the previous DES settings:

To save you time if you need to do this...
On the OPNSense box, using your favorite editor, alter this file:
/usr/local/etc/nut/ups.conf

Change:
privProtocol=AES
to
privProtocol=DES

Restart the service:
/usr/local/etc/rc.d/nut restart

Now, go back to your web service and things should be less sluggish. Re-visit the Services -> Nut -> Configuration, choose the "UPS Type" down-arrow to get the drop-down menu, and then locate and choose "SNMP-Driver"

The right frame should show you the settings you expect and likely won't match what you put in the file. Whatever the result, make sure that the configuration does not include "privProtocol=AES" and then make sure it DOES include "privProtocol=DES"

Then choose "Apply"

12

22.1 Legacy Series / Re: OPNSense, UPS, Nut, SNMP-Driver, SNMPv1 or SNMPv3

« on: April 03, 2022, 04:40:31 pm »

As for support of AES with Nut...
There appears to be either a bug in the present Nut which is being used, or a problem in how it is being built for the package.

On another "stock" FreeBSD box, and on a HardenedBSD box (latest 13, then default stable/master, did buildworld, kernel, install), I tested getting a copy of "ports" (latest git repo main) and then configure, build and install nut from ports.

As first pass, it seemed like maybe the issue was that maybe support for crypto libs was missing, so I tried building against OpenSSL (latest) but that didn't work, so I tried building against NSS, but that didn't resolve AES support. Last, I took the "kitchen sink" approach and enabled all the non-conflicting features to see if any of those resolved this issue with being broken for AES, but nope.

Each time I used a configured user that used AES for privacy (encryption) an attempt to start with it resulted in:

No supported device detected
Driver failed to start (exit status=1)
/usr/local/etc/rc.d/nut: WARNING: failed precmd routine for nut

If I edited the configuration and JUST change "AES" to "DES" and specified the UPS SNMP user that used DES instead of AES, then it worked.

Using "snmpwalk" to connect with the same args allowed the aes user to use AES, and the DES user to use DES.

I've not found the problem with AES support yet, and I will probably be re-tasked to abandon SNMP, and try for USB cable based support. (My boss re-tasked me with getting USB support to work with Nut on OPNSense using the USBHID-Driver. Details of that process are here: https://forum.opnsense.org/index.php?topic=27936.msg135580#msg135580 )

Hopefully some part of the above process and issue will help one or more of you save time when setting this up on your network.

Thanks for reading!

13

22.1 Legacy Series / Re: OPNSense, UPS, Nut, SNMP-Driver, SNMPv1 or SNMPv3

« on: April 03, 2022, 04:23:02 pm »

Once you have it working for SNMPv1, you can try for SNMPv3.

Again, from the "SNMP-Driver" page, you make sure it is enabled:

• Enable
  
  For "Extra Arguments" you remove "snmp_version=1" and remove "community=public" but keep the "port" value.
  
  Then we need to add more:
  snmp_version=v3  (this is required as of this writing as the default is v1 unless otherwise specified)
  authProtocol=SHA (as of this writing, I was able to test "None" and "MD5" and "SHA" (SHA1) which all worked, only if the SNMP service on the UPS network device supported these.)
  secLevel=authPriv (authPriv means you want an authentication process and an encryption process. Other choices are: noAuthNoPriv (default) , authNoPriv or authPriv : Each specify requirements for auth and/or encryption)
  snmp_retries=5 (optional: included to show it is available)
  snmp_timeout=2 (optional: included to show it is available)
  pollfreq=30 (optional: included to show it is available)
  privProtocol=DES (according to Nut docs and binary query, it supports either DES or AES, but trying to use AES as of April 3, 2022 results in failure and problems. On the same box, using "snmpwalk" with aes works fine against the same device and https://networkupstools.org/docs/man/snmp-ups.html claims that DES, AES, AES192, and AES256 are all supported by their source, but can vary depending on how the binary is built.)
  authPassword=WhateverYouSpecifiedAsYourPassword
  privPassword=WhateverYouSpecifiedAsYourEncryptionPassphrase
  secName=TheProfileUsernameYourSetupOnYourSNMP_DeviceForYourUPS
  
  Example:
  
  
  Then choose "Apply".
  
  Now, to see if it is working, visit:
  Services -> Nut -> Diagnostics
  
  If it is working, you should (in less than 10 seconds) see a collection of data which looks a lot like what you see when you snmpwalk a device: a bunch of MIB-like names with associated values:
  
  
  

14

22.1 Legacy Series / Re: OPNSense, UPS, Nut, SNMP-Driver, SNMPv1 or SNMPv3

« on: April 03, 2022, 04:09:26 pm »

For SNMP-Driver, page, you choose:

• Enable

HINT: to avoid problems, review your list of available drivers for nut, and visit each one. You should only enable ONE AT A TIME. Please disable any other nut drivers and apply that change for each when testing SNMP, or you may risk problems. After you have everything working for SNMP, then you can experiment with other drivers being concurrent with the SNMP-driver.

For "Extra Arguments" the minimum to include are:
port=Your_SNMP_Server_IP_Address:SNMP_PORT_NUMBER

The "SNMP_PORT NUMBER" (161) is optional, so you could just specify:
port=Your_SNMP_Server_IP_Address

Next, you need to specify the "Community" which is like a username. For the previous examples using a Schneider Electric network management card, I create a community for SNMPv1 called "public" with read-only access, so I use that same name "public" for my community name here:
community=public

The included item "snmp_version" is not required as of this writing, but I've included it here to be explicit:
snmp_version=v1


Then choose "Apply".

Now, to see if it is working, visit:
Services -> Nut -> Diagnostics

If it is working, you should (in less than 10 seconds) see a collection of data which looks a lot like what you see when you snmpwalk a device: a bunch of MIB-like names with associated values:

15

22.1 Legacy Series / Re: OPNSense, UPS, Nut, SNMP-Driver, SNMPv1 or SNMPv3

« on: April 03, 2022, 03:59:37 pm »

Now that the UPS Network services support SNMPv1 and SNMPv3, we can first walk through enabling the simpler and less secure SNMPv1 and once that is working, try to setup SNMPv3.

Services -> Nut -> Configuration:


The default page drops you in a view of the "General Settings" Tab.
Choose to

• Enable this

Set Service Mode to "netclient"
Specify a name for your UPS, but avoid whitepaces. Maybe start with just alpha-numerics, underscore, hyphen and periods.
Specify the IP address you want to use for OPNSent nut service with your UPS network service with SNMPv1 and/or SNMPv3 support.

Locate the "down-arrow" in the tab for "UPS Type" and select it to reveal a drop-down menu:

Select "SNMP-Driver" in the drop-down menu.

New page which allows you to configure the SNMP-Driver for either SNMPv1 or SNMPv3
Example for SNMPv1:


Example for SNMPv3: