montoring remote appliances over the net without outside IP'

[yogurt_21]

Hello all I'm new to the forums but have been lurking for the better part of a year.

I work for a company that sends appliances to our clients for our product. Based on our clientelle, not all of them will be able to supply an expernal IP for the appliance so we are searching for other methods of monitoring them and being able to login and make changes/updates to them.

I am certaintly able to monitor the appliuances we do have external access to via cacti but I'm looking for a decent way to monitor say 1000 applainces spread out all over the U.S. behind firewalls on seperate networks.

each appliance is running centos 5 (varies from 5.2-5.4) so currently we are simply taking one of our larger internal appliances and using it to monitor the others.

I'd welcome any reocmnedations on the best way to go about this.

[Linegod]

Off the top of my head I would try using ssh/scp with no passphrase to transfer specific stats to your central collector, then write a script to parse the text file for each host.

[yogurt_21]

are you talking about using a trap with specific settings or are you talking about an actual snmp push to a central collector using an ssh/scp connection?

if there is an option for force snmp data to be sent to an external IP, we have a larger prtg that can accept and monitor snmp traffic.

I just haven't found anything that'll let me do that.

[Linegod]

I was talking about just setting up a script on the client that gathers the information, and send it over ssh/scp as a plain text file. You then create a script on the central box to read these values. From the collectors point of view, no snmp is involved. As a note, using snmptrap to send the values would be far more complicated, as you would have to create custom scripts to gather the information from your trap collector daemon.

Another method would be to have the client device create an SSH Tunnel for SNMP back to your central controller, and bind on a specific port - each client would have a client specific port, 5001 for the first client, 5002 for the second, etc, etc. You could then just collect from 127.0.0.1, specifying the client port as the SNMP port.

[yogurt_21]

so if I were to want interface stats I could set up a script to gather the data and save it in a file and then run a cron job to send it with a wput type command to the remote controller, then simply run a cron job on the remote host for the parser?

as for the other option would the tunnel have to be setup after installation at the client location or could it be setup before as long as the appliance was preconfigured with all the IP information?

[Linegod]

so if I were to want interface stats I could set up a script to gather the data and save it in a file and then run a cron job to send it with a wput type command to the remote controller, then simply run a cron job on the remote host for the parser?

Yes, but instead of a 'wput', use an 'scp'.

as for the other option would the tunnel have to be setup after installation at the client location or could it be setup before as long as the appliance was preconfigured with all the IP information?

It could be set up prior. I would just throw it in inittab, but you could create an initscript service as well.

The reason that I am pushing ssh/scp, is that since the client device IP is unknown, you have to accept input from _any_ host. To control who is sending you information, only allow keyed ssh connections. Some other security considerations would have to taken into account, but that would be the first step.

[yogurt_21]

thanks for the help, I'll look into both and see which is more feasible for our deployment. it's really sounding like option 1 is the simplest but I'm not sure how well either will scale, trial and error I guess.

[yogurt_21]

just wanted to give an update, ssh tuneling with the specific ports per client seems to be working, thanks again !

the scripts did work as well but the tunnel is faster to setup and when we're back tracking on clients who already have an appliance on site, shorter is better.

[Linegod]

Glad to hear it.

The SSH Tunnel should be more reliable as well, and easier to troubleshoot.

[yogurt_21]

alright now that I have a working solution is there a way to add in a password to the tunnel when it runs?

I want to be able to add it to /etc/rc.local so that the tunnel starts at boot.

also if I didn't want to put my cacti server on an external could I setup another server and run the tunnels to that instead

ie client hosts tunnels port 161 to port 5001 on external appliance, cacti server reads snmp data form exteral IP of the appliance on port 5001.

alos if you could recomend the most efficient tunnel, some seem slower than others.

right now I'm using something similar to

ssh -R 5001:localhost:161 sourceuser@remotehost

running it from the client box (as I can't use the normal forwarding from our external box to the client box's internal IP)

[Linegod]

Use ssh-keys to have it log in automagically.

Try disabling/enabling compression (dependant on type of connection) and change the encryption type - can't remember the default encryption for most openssh installs, but it is probably overkill for your requirements.

As for creating an separate aggregation server, this more complex, and is going to depend on what facilities you have available, and to be honest, is leaning towards network design.

[victoria19]

I think it is time for you to have a separate IP. If you have that, you can monitor all the appliances in remote areas. Also, you have to contact someone who can do the script to put them all together.


appliances

[TheWitness]

Using push, you can scale to well over 10k appliances.

TheWitness