Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 48 replies
  • Subscribers 7 subscribers
  • Views 107965 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

HowTo: Monitoring RED Device State with Nagios

quasar3c279
Hi folks,

in normal Site2Site VPN setups you could monitor the tunnel state by pinging the remote end of the vpn. If it doesn't respond it's down! [;)] With the REDs being a local interface on the ASG it's no longer possible to check the tunnel state with ping.

We wrote a nagiosplugin which checks the link state of a given RED ID and returns OK when online and CRITICAL when offline. There are also some other values we report, on-/offline time and IP were it is connected from.

I'll give you a short description how to setup the plugin, expecting that you've got a running nagios environment:

1. Copy the check_asg_red_state.pl to your nagios plugn directory (normally /usr/local/nagios/libexec) and make it executable

2. Create a new check_command looking like this: 
# 'check_' command definition

	define command{

		command_name check_asg_red_state

		command_line $USER1$/check_asg_red_state.pl -H $HOSTADDRESS$ -R $ARG1$

	}

3. You need to gennerate a key pair for the nagios user in order to use the passwordless authentication with the host. This can be done by running 
ssh-keygen -t rsa -N ""

as nagios user or 
su - nagios -c 'ssh-keygen -t rsa -N "" '

4. Install your public key on your Astaro for passwordless login of loginuser.

5. Now you can test your setup: 

nagios@debian:/usr/local/nagios/libexec$ ./check_asl_red_state.pl -H my.firewall.net -R A300001234567890

RED STATE OK - RED connected from 1.2.3.4, uptime 22h 15min | Uptime=1335min;;


Now you can start adding the REDs to your nagios configuration.

There maybe BUGs, please let me know if you found something unusual or if it doesn't work.

I hope this is helpful for other people, if you have questions feel free to ask!

Regards,
Cobotec GmbH

Mario Techel

Version 1.1:
- minor bugfixes, changed default value for StrictHostKeyChecking to no


This thread was automatically locked due to age.
check_asg_red_state_v1.1.zip
  • 0
    Hi firebear,

    No you don't need to install any extra software on the utm. 
    The only thing that you must do is to allowed your monitoring server to connect via ssh.

    So the support on the utm is still active.

    Regards
  • 0 in reply to daniel4
    Hi Daniel,

    thanks for the support.
    Do you know why I don't get a correct uptime?

    Ed
  • 0
    Hello
    my key-files seem to be not working.
    I generated them after I did su - nagios using

     ssh-keygen -t rsa -N ""


    I get a timeout from the plugin. If I try to use ssh loginuser@ as nagios nothing happens. the id_rsa file resides in /usr/local/nagios/.ssh

    I did a cat id_rsa.pub and pasted the output to the loginuser-keys in the UTM webgui.

    What's the matter here? [:D]
  • 0 in reply to IngoPohlschneider
    Hello chas0rde,

    can you confirm that you have added the monitoring host to the allowed network.

    Please test the ssh login from the nagios user with only the firewall IP. 
    #> ssh fw-ip

    Then you should get a prompt witch asks you for a username. If this didn't happened you must do some more checks.

    It the ssh service on the default port?
    Can you connect or get a login prompt from a different host? 
    Maybe local firewall on the monitoring server?
  • 0 in reply to daniel4

    It the ssh service on the default port?


    After I read this I suddenly realized [:P]
    Some genius changed the port for some reason 

    As I see it there is no parameter to use any other port than the default port [:(]

    That would be nice
  • 0
    Hello
    check itself works after I hardcoded the port used by us. 

    After that I altered the Perl script to have an optional parameter -p (default: 22) to supply the port. Find the updated version attached.

    Still I get some errors with that script (see screenshots attached):
     - uptime is wrong
     - Last connect is shown as uptime

    If I see it right the uptime is derived from the file-age of the log file.
    I guess (at least in v9.1) the timestamp gets updated since the last successful PING is written to the file. Therefore the uptime is always 0 min (or the creation-date of the file for down devices)

    I didn't know how to fix that on the quick since I am not a perl wizard [;)]

    Any ideas or help is appreciated [:)]
    Although I think Sophos should enable SNMP-Queries for this kind of information

    Best regards
  • 0 in reply to IngoPohlschneider
    Hi chas0rde,

    please try this version. 
    I've changed some minor things, including a alternative port option.

    Yes the uptime calculation is currently not correct in the current utm version.
    If i find a new way i'll post an update here.
    RED check.zip
  • 0
    Hey
    thanks for the reply. Nice of you to add the port-feature (as well) + your bug fixes.

    If you like you could add it to some kind of a repository so that everyone could contribute if interested [[[:)]]]

    Thanks anyways [[[:)]]] I hope the uptime-monitoring will be fixed too + downtime-monitoring would also be nice [[[:)]]]
    So one could tell branches since when they have been offline once they call in [;)]

    best regards
    chaser
  • 0 in reply to IngoPohlschneider
    So I have this running on nagios 4.0.2 with Sophos UTM 9.106-17.

    When I run the plugin, I get

    "Can't locate Nagios/Plugin.pm in @INC at /usr/local/nagios/libexec/check_asg_red_state.pl line 64.

    Did something change in nagios or did I make a booboo?

    Resolved:  Turns out I was missing a file...
    Installed the perl-Nagios-Plugin from rpmforge and we get past line 64.

    Now a new problem, I'm getting:
    Argument "" isn't numeric in numeric gt (>) at /usr/local/nagios/libexec/check_asg_red_state.pl line 151.
    RED STATE CRITICAL - unable to connect to firewall or file not found

    line 151:
    if ($cmd_get_version > 9.1){

    I also notice I can ssh into the UTM from the nagios box if I use loginuser@astaro and a password, but if I try to just use public key, it fails authentication.

    Any suggestions?

    Resolved:  I guess renaming the rsa key was enough to drop it in a non-default location.  Set up a generic rsa key with no name and session connects.
Unfiltered HTML