Successfully monitoring a UPS connected to a Synology RS?



  • I would like to have pfSense monitor the Cyberpower UPS connected (via usb) to my Synology RS815+. The Synology is able to act as a UPS Server, and I have another Synology backup unit connected to it via the LAN as a slave.

    If I connect the Cyperpower usb to my pfSense box it recognizes it and reports fine FYI

    I have googled and found reports of it working (see below) but I can't get it to work on my side. Anyone have this working?

    
    (Jan 2014)
    
    UPS Monitoring: Remote NUT UPS
    
    Remote NUT UPS Settings
    -----------------------
    Remote NUT UPS Name: ups (or put whatever you want to call it)
    Remote NUT UPS Address: Put IP of synology here
    Remote NUT UPS User: monuser
    Remote NUT UPS Password: secret
    
    (monuser/secret is the monitor master account that is configured by default in the Synology inside of the /usr/syno/etc/ups/upsd.users file).
    


  • I've set it up as above with mouser/secret and I am seeing the following in pfSense logs:

    Sep 25 13:34:56	upsmon	87654	Poll UPS [ups@192.168.2.20] failed - Access denied
    Sep 25 13:34:51	upsmon	87654	Poll UPS [ups@192.168.2.20] failed - Access denied
    Sep 25 13:34:46	upsmon	87654	Poll UPS [ups@192.168.2.20] failed - Access denied
    Sep 25 13:34:41	upsmon	87654	Poll UPS [ups@192.168.2.20] failed - Access denied
    Sep 25 13:34:35	upsmon	87654	Poll UPS [ups@192.168.2.20] failed - Access denied
    Sep 25 13:34:30	upsmon	87654	Poll UPS [ups@192.168.2.20] failed - Access denied
    Sep 25 13:34:25	upsmon	87654	Poll UPS [ups@192.168.2.20] failed - Access denied
    

    So it appears it is trying to connect at least. I've confirmed the ups name is 'ups' and the user/pass is correct in the Sinology's upsd.conf file



  • The Synology units are pretty limited/restricting in their NUT configuration. You often have to manually edit the configuration to do anything outside of the Synology world. The good news is that the config is not often overwritten.

    The configuration files are in /usr/syno/etc/ups. The configuration for the remote user goes in upsd.users and would look something like this:

    [remoteuser]
            password = uwebncyel88
            upsmon slave
    
    

    Note that this is a slave, not a master. The values you choose for "remoteuser" and "uwebncyel88" are what you enter as username and password in the pfSense remote NUT configuration.

    While you are there, you should change the default password that Synology puts in for the master in upsd.users and upsmon.conf. They put a single user in as a master, with a known to the world password, which means that it's trivial to trigger a remote unauthorized shutdown of the entire cluster.



  • OK the user I was using was the default master. I'll create a new user as a slave and try that. I'll change the default master passed as well. Thanks



  • Well that successfully caused the Synology RS to not recognize the UPS anymore. I removed the added user and reset the monuser password back to default and finally after an hour got it to work again.



  • The user and password settings don't have any effect on the driver (usbhid-ups) recognizing the UPS.

    If you have a syntax error in upsd.users, this can prevent upsd from starting, but that's about it. I'd have to test to see how this manifests itself in the Synology ui.

    Can you say more about what you saw?



  • I suspect that the default user/pass is used in other locations/.conf files and changing its password in upsd.users caused probs. I started poking around and noticed the default user/pass listed in at least one of the other .conf files.

    Pretty sure I didn't have any syntax errors, I set it like this:

    
    [monuser]
            password = zdfbgdfgsdf
            upsmon master
    
    [remoteuser]
            password = sdcsfewrfgwdv
            upsmon slave
    
    

    After I updated the user/pass to the [remoteuser] in pfSense the log generated "connection refused" entries. (I'm not at home at the moment to copy/paste the exact data).

    Thanks for your help btw..



  • I'll have to connect a UPS to my Synology to test. Tomorrow night.

    Did the remote access work?



  • Not sure what you mean by "Did the remote access work?". pfSense was trying to connect to the SynologyRS but the logs said "connection refused". I do have it's IP (192.168.1.1) set in the "allowed access IP's" on the SynologyRS UPS prefs.

    I have a second Synology (411j) connecting as a UPS slave to the SynologyRS and it works perfectly with no configuration needed BTW.



  • I mean did pfSense remote access work with user "remoteuser" and password "sdcsfewrfgwdv"?



  • The person that did the NUT plugin for Synology either didn't have a good understanding of NUT, or was totally focused on keeping Synology's support costs to zero. Their remote access depends upon every node using master mode which is very bad from a NUT point of view. There should be only one upsmon in master mode, the rest should be in slave mode. Also the use of a globally known password for a remote master is horrible from a security pov. The good news is that they let you edit the files, so you can fix it after the fact.

    @AR15USR:

    I have a second Synology (411j) connecting as a UPS slave to the SynologyRS and it works perfectly with no configuration needed BTW.



  • @dennypage:

    I mean did pfSense remote access work with user "remoteuser" and password "sdcsfewrfgwdv"?

    No it didn't. Logs said "connection refused" but I think this was due to the SynologyRS not being connected to the UPS as soon as I modified the default user password in upsd.users.

    I will try again tonight with only adding the [remoteuser] and not changing the default user password at all.



  • So, mixture of good news and bad news.

    Bad news first: There is a change of behavior, which I assume is part of DSM 6.0. The change is that upsmon.conf is rewritten on each system boot. Even though upsd.users continues to not be rewritten each time, this still means that you can no longer change the default username/password of monuser/secret. Serious bummer.

    On to the good news: Synology no longer requires master for remote monitoring. This applies to both locally hosted UPS units and remote hosted units. What this means is that you can host the UPS on pfSesnse with monuser/secret declared as a slave, and the Synology will happily connect to it even though Synology is attempting to say it's a master. You can also host the UPS on the Synology, and use it as a remote connection for pfSense. If you host the UPS on the Synology, you can either add a user to upsd.users as discussed above, or you can use the default monuser/secret.

    Regardless of the username/password, if you host on the Synology, you need explicitly list the IP address of pfSense in the list of permitted remote hosts in the Synology (Control Panel -> Hardware & Power -> UPS). This may have been why you were getting permission denied previously.

    Given a choice, I would host the UPS on pfSense and use remote connections on the Synology units. If you want to do this, you will need to enable remote access as described in this post.

    For the remote user, you will need to use this in order to match the expectations of the Synology:

    [monuser]
     password = secret
     upsmon slave
    
    

    However if you want to host on one of the Synology units, that will work as well.

    Hope this helps.



  • Thanks dennypage for taking the time to look into this, much appreciated.

    I did have the pfSense IP added into the allowable IPs on the Synology unit from the start. I'll give it another go tonight and report back..



  • OK I've set it up as I understand it based on your post. Not working. Here's my settings:

    UPS is connected to the Synology unit.

    Setting screenshots are below.
    SS1 = Synology unit ups.users
    SS2 = Synology UPS Settings
    SS3 = pfSense settings
    SS4 = pfSense log










  • Can you post the MONITOR line from /usr/local/etc/nut/upsmon.conf on the pfSense box please? And the MONITOR lines from /usr/syno/etc/ups on both Synology boxes please?



  • Sure:

    pfSense:
    No MONITOR line, is commented out. Also the upmon.conf is called "upsmon.conf.sample"

    Synology 1 (has the UPS plugged in to this one):
    MONITOR ups@localhost 1 monuser secret master

    Synology 2
    MONITOR ups@192.168.2.20 1 monuser secret slave



  • Hmm…. if there is no /usr/local/etc/nut/upsmon.conf it means that NUT is not actually configured and enabled. I'm at a loss to explain how there are upsmon error messages in the log when there is no upsmon configuration file.

    Can you check a couple version things please?

    pkg info | grep -i nut
    pkg which /usr/local/etc/nut/upsmon.conf.sample
    

    Following that, please go to Services / UPS / Settings and press the save button. Then check contents of /usr/local/etc/nut/upsmon.conf.

    @AR15USR:

    pfSense:
    No MONITOR line, is commented out. Also the upmon.conf is called "upsmon.conf.sample"



  • OK I had a thought, at the time I checked on the pfSense upsilon.conf I had the NUT package disabled because it wasn't working. Turned it back on and now there was a upsmon.conf file there. Here is its contents:

    MONITOR ups@192.168.2.20 1 monuser secret slave
    SHUTDOWNCMD "/sbin/shutdown -p +0"
    POWERDOWNFLAG /etc/killpower
    

    Here are the other outputs:

    /root: pkg info | grep -i nut
    nut-2.7.4_1                    Network UPS Tools
    pfSense-pkg-nut-2.7.4_2        Network UPS Tools
    
    
    : pkg which /usr/local/etc/nut/upsmon.conf
    /usr/local/etc/nut/upsmon.conf was not found in the database
    [2.3.2-RELEASE][admin@Yukon.lan]/usr/local/etc/nut: ls
    cmdvartab            nut.conf.sample      upsd.conf.sample     upsmon.conf          upssched.conf.sample
    driver.list          ups.conf.sample      upsd.users.sample    upsmon.conf.sample
    

    That result seems not right? I did ls so you could see it right there



  • @AR15USR:

    OK I had a thought, at the time I checked on the pfSense upsilon.conf I had the NUT package disabled because it wasn't working. Turned it back on and now there was a upsmon.conf file there. Here is its contents:

    MONITOR ups@192.168.2.20 1 monuser secret slave
    SHUTDOWNCMD "/sbin/shutdown -p +0"
    POWERDOWNFLAG /etc/killpower
    

    Okay, that makes much more sense.

    @AR15USR:

    : pkg which /usr/local/etc/nut/upsmon.conf
    /usr/local/etc/nut/upsmon.conf was not found in the database
    [2.3.2-RELEASE][admin@Yukon.lan]/usr/local/etc/nut: ls
    cmdvartab            nut.conf.sample      upsd.conf.sample     upsmon.conf          upssched.conf.sample
    driver.list          ups.conf.sample      upsd.users.sample    upsmon.conf.sample
    

    That result seems not right? I did ls so you could see it right there

    I was asking for pkg which on "/usr/local/etc/nut/upsmon.conf.sample". The sample config file should be owned by nut-2.7.4 or nut-2.7.4_1. The file "/usr/local/etc/nut/upsmon.conf" is generated by the configuration and is not owned by any package.

    Anyway, the remote access configuration matches the remote access configuration of the slave Synology unit. About the only thing left is that IP address of the pfSense box isn't what the master Synology box thinks it is. Or perhaps there is some a bug again in the Synology NUT configuration for remote clients. Btw, you are running DSM 6, yes?

    Two things you can try:

    1. On the master Synology, delete each permitted device and save. Disable remote the network UPS server and save. Re-enable the remote network UPS server and save. Re-add each (slave Synology and pfSense) IP address to the Synology permitted devices and save. If you have multiple local network addresses for pfSense, add them all. This is simple and easy, and I would do this first.

    2. On the master Synology, log in as root and run

    tcpdump -n port 3493
    

    You should begin seeing traffic from the slave Synology.

    On the pfSense box, log in as root and run

    /usr/local/etc/rc.d/nut.sh restart
    

    You should see upsmon on pfSense connect to upsd on the Synology.

    If you want to listen in on the conversation you can run tcpdump with the -A option

    tcpdump -n -A port 3493
    

    There will be a number of things that don't print, but you should be able to follow the gist of the conversation.



  • OK got it sorted out and it is working now. Much thanks for your help.

    I did both of your suggestions below. #1 didn't make a difference.

    #2, When running "tcpdump -n -A port 3493" I saw this:

    09:38:33.744802 IP 192.168.2.20.3493 > 192.168.2.1.61499: Flags [FP.], seq 19:37, ack 22, win 114, options [nop,nop,TS val 268312 ecr 1101366621], length 18
    E..FC\@.@.q............;y.O..3.....r.......
    ....A..]ERR ACCESS-DENIED
    
    

    This shows the pfSense box being denied from 192.168.2.1, I was using its actual IP of 192.168.1.1. As soon as I entered the 192.168.2.1 IP into the allowed devices on the Synology unit it worked instantly. I'm guessing it has to do with the Gateway, the Synology is on LAN 2.1 instead of 1.1.

    Anyhow big thanks for all your help, much appreciated.

    Not sure if you are still interested, but here is the output for the users.conf.sample anyhow:

    /root: pkg which /usr/local/etc/nut/upsmon.conf.sample
    /usr/local/etc/nut/upsmon.conf.sample was installed by package nut-2.7.4_1
    


  • No problem. Glad you got it working.



  • I have a similar setup working thanks to this thread and some others.

    Question though, with my Synology the master as soon as it goes on battery pfsense shuts down immediately. Is there an option I can use on upsmon to make it wait until low battery reached?



  • The master side (Synology) controls all the signals, including low battery and forced shutdown. There is no way to override these from the slave side (pfSense). There is a pull down in the Synology config that says whether to initiate shutdown immediately or wait for low battery. This is the only control available to my knowledge.



  • Note that even if there were a way to override the fsd signal on the slave, it would be a bad idea because the signal generally indicates that the master is about to instruct the UPS to turn the load off.


Log in to reply