Why does NUT plugin need a listen address as a secondary in netclient mode?

[OPNenthu]

I'm working on setting up OPNsense as a NUT client to receive shutdown signals not from the UPS, but from a LAN-hosted NUT server.  The server is a Raspberry Pi connected to the UPS via the 'usb-hid' driver and has an IP in the 192.168.1.0/24 net (same as OPNsense).

In the 'os-nut' plugin configuration there are two places where an IP address is requested:

- General Settings -> Listen Address
- UPS Type -> Netclient

I'm clear on the latter one: this is the location of the NUT server.  The former is a little ambiguous.  Is it asking for the same listen address of the NUT server (in which case it's redundant) or is it asking where I would like to set up a NUT server to listen on in OPNsense (not what I want)?

It's not clear how to configure the plugin strictly as a client and not bind any listen interfaces in OPNsense itself.

[bartjsmit]

For security, you can restrict the NUT client to a single interface. Put the LAN IP address of OPNsense in the first field.

[OPNenthu]

Hi bartjsmit, I think I'm confused about why a listen interface is needed at all if I only want OPNsense to monitor the remote NUT server for power loss events and then trigger itself to shut down.

Maybe I'm not clear on how the NUT protocol works but their website appears to be inaccessible for several days now and I can't get to the documentation.

I was thinking that it would be possible to set up the NUT plugin as a client only and not expose any services on OPNsense (?)

[bartjsmit]

Check out the RFC https://datatracker.ietf.org/doc/rfc9271/

[OPNenthu]

Hmm...

First of all, thank you for the RFC link.  I did read through it and learned quite a bit, so I can now update my terminology as well.

Unfortunately it doesn't answer my doubt about the need for a listen interface in OPNsense for my scenario.  If OPNsense were acting as the primary then yes, no question about it.

In my desired setup, OPNsense is acting as a secondary ("slave") Management Daemon.  Therefore it will be initiating connections to the primary ("master") Attachment Daemon (a.k.a "upsd") on the remote NUT server over TCP port 3493.  The RFC indicates that the secondaries do poll for status, they are not notified, so this implies that there is no need for them to accept a connection request.  Instead, they reach out every 5 seconds (configurable) for status before making a decision to trigger a shutdown procedure on the host based on the OB ("on battery") and LB ("low battery") states.

Indeed according to one source pfSense supports this setup without needing to bind NUT to a firewall interface.  You only need to tell it where the server lives.  This jives with the examples in the RFC.

In OPNsense however, the documentation and the in-line help text in the os-nut plugin are strongly worded to suggest that enabling the NUT server in OPNsense (and giving it an IP) is required for the netclient to be able to shut down OPNsense.  That... doesn't seem right and is confusing, IMO.

You cannot view this attachment.

I noticed that if I leave the service disabled under Services->Nut->Configuration->General Settings and only enable netclient under Services->Nut->UPS Type->Netclient then I am seeing that UPS status is still populating under the Nut Diagnostics (as I'd expect).

You cannot view this attachment.
You cannot view this attachment.

I will need to test, but am I correct in assuming that this is a valid configuration in the os-nut plugin?  It seems like it should be, despite what the OPNsense documentation and help text indicate.

I hope my question is clear and I'm not obfuscating it with all of my word-salad.


TL;DR:  I don't want to expose anything on OPNsense unnecessarily nor enable it as a NUT server, but the documentation is telling me that I need to and is in conflict with my understanding of how netclient mode works on secondary management daemons.

[bartjsmit]

If you add the LAN interface, does OPNsense listen on it? I.e. telnet 3493 from the Pi or nmap if you are slightly more paranoid.

[OPNenthu]

If you add the LAN interface, does OPNsense listen on it?

No... it apparently does not.

So at the risk of asking a stupid question, what is the point of the "Listen Address" field here?  What does it actually do?

Thanks!

[OPNenthu]

Anyone please?

I had tried toggling the "Service Mode" in General Settings between netclient and standalone just to see, but in both cases there doesn't appear to be anything listening on port 3493 at OPNsense.  I'm confused as to what this interface setting does.

The OPNsense documentation says this should be the "interface ip on which the server lives."

You cannot view this attachment.

Which "server" is this referring to?  My remote RPi / NUT server, or the local NUT service on OPNsense?

[Patrick M. Hausen]

In my case I run NUT on OPNsense as the server with listen address 127.0.0.1 and voila:

Code Select Expand

root@opnsense:~ # netstat -na | grep LISTEN
[...]
tcp4       0      0 127.0.0.1.3493         *.*                    LISTEN     

I then use NAT port forwarding rules to allow access for various other systems. The firewall is (as I think) the last system that should go down, so the alert emails go out etc.

HTH,
Patrick

[OPNenthu]

That's a good point.  I was thinking to not give OPNsense the ability to control the UPS outlets and to keep those functions farther away from the network edge, but I'm probably overthinking it.

The real issue is that the USBHID driver in OPNsense apparently doesn't want to recognize my Cyberpower UPS, and I don't own the SNMP network card.  The Raspberry Pi is working well with the linux USBHID driver with some specific tweaks that I found to keep the Cyberpower from disconnecting.  It seems stable.

I'll try again to configure the os-nut plugin as a netclient only but testing it will be somewhat challenging.  I hope it should be possible to modify the shutdown command so that at least OPNsense will send an alert before powering off.