NUT Remote Access Stopped Working After Migration from CW 2.7.2 to 2.8.0-BETA

[jeffry.maynard]

Since moving to 2.8.0 I am unable to remote upsc NUT on the firewall.

Here are the config files:
/usr/local/etc/nut: more nut.conf
MODE=netserver
ALLOW_NO_DEVICE=true
export ALLOW_NO_DEVICE
export ALLOW_NOT_ALL_LISTENERS

/usr/local/etc/nut: more ups.conf
[Office]
driver=usbhid-ups
port=auto

/usr/local/etc/nut: more upsd.conf
LISTEN 10.241.1.1
LISTEN 127.0.0.1
LISTEN ::1

/usr/local/etc/nut: more upsd.conf
LISTEN 10.241.1.1
LISTEN 127.0.0.1

UPS status is functional on the firewall:

I am using a port forward:

And there is a FW rule to match:

When I attempt to connect from a remote host I timeout even though I see a stateful firewall connection:

Prior to upgrading I did not have the port forward and I just added the LISTENER statement and everything worked perfectly. Since the upgrade I have made every change I could find and nothing allows the upsc on the remote device to make the connection and pull the data.

Any assistance on this would be greatly appreciated as I monitor all of my UPS's on my main server.

[dennypage]

@jeffry-maynard You did not post sufficient information: You didn't show your pfSense NUT configuration (the NUT config files are all automatically generated by the pfSense NUT package), didn't show how you are invoking upsc, and didn't say what if any error you are receiving from upsc.

That said, I suspect that your problem is that you do not have a username/password set up in your configuration to support upsc. Look in Services / UPS / Settings / Advanced settings / Additional configuration lines for upsd.users, and add appropriate configuration.

BTW, don't just look in upsd.users and copy the admin or local-monitor username/passwords. These passwords are all automatically set to random values that change.

Also of note is that you have stuff in Advanced settings / Additional configuration lines for upsd.conf that you are not using and should remove.

[jeffry.maynard]

@dennypage
Apologies, I did not include more information:

When I run upsc office@10.241.1.1 from the remote device of 10.241.1.201 it stalls and then times out.
root@www:/etc/nut# upsc office@10.241.1.1
Error: Connection failure: Connection timed out
This is very odd to me since I see the connection being made in the firewall rules provided in the last message:

While I am not adding a username/password, I did not have one added prior to the move to 2.8 and it worked perfectly.

If I hear you correctly, your stating that I should remove the LISTEN directive in Advanced settings / Additional configuration lines for upsd.conf. Doing this made no change in the timeout issue.

I also copied the values from upsd.users from the 10.241.1.1 firewall to the remote 10.241.1.1 server and retried but that also yielded no better result.

While typing my response I did some additional checking and it appears pfSense had an issue with the ARP address of my server. Once I clear it from the table I was able to revert back to my original config which included removing the NAT port forward and adding the LISTEN 0.0.0.0 3493 to the upsd.conf section. It's not pulling properly.

[dennypage]

@jeffry-maynard said in NUT Remote Access Stopped Working After Migration from CW 2.7.2 to 2.8.0-BETA:

While I am not adding a username/password, I did not have one added prior to the move to 2.8 and it worked perfectly.

My bad. You are only reading the UPS, not logging into it or attempting to write to it. What you are doing will not require a password. Please accept my apologies.

@jeffry-maynard said in NUT Remote Access Stopped Working After Migration from CW 2.7.2 to 2.8.0-BETA:

If I hear you correctly, your stating that I should remove the LISTEN directive in Advanced settings / Additional configuration lines for upsd.conf.

You should either remove the LISTEN directive, or remove the port forward. You cannot do both. See the instructions on remote access here. I've tested the port forwarding variant with 25.03, which is very close to 2.8.0, and it works as expected.

NB: When specifying the Destination Address, either with port forwarding or with a firewall rule, you probably want to use "LAN address" rather than "This Firewall (self)". You might also want to change the Source Address to Any until you have it working.

[jeffry.maynard]

@dennypage
I added back in the listen directive and removed the port forward. Seems to work well also. Not sure why my arp table got mussed, but I guess that can happen.