Monitoring pfSense with Nagios XI or Core Using SSH Series

This walkthrough will guide you through the process of monitoring your pfSense using SSH and Nagios. Though this was originally written with Nagios XI in mind, recent additions to this walkthrough have made the process far easier for those configuring it on Nagios Core. FWIW, the scripts could also be used with NRPE without issue, although I discuss why SSH is my preferred route below. The end of part 3 has an example Nagios XI service config file as well as example services.cfg and commands.cfg files for Nagios Core . This process is based on very sound practices and I can say that I used it to monitor numerous pfSense firewalls for several years with zero issues. Not to mention, once you understand the process it is trivial to replicate the configuration to additional firewalls. At some point, I might make this methodology a pfSense package to assist with the install and versioning if there is enough interest.

Changelog
15Dec2017 – Originally posted
9May2018 – Added uptime and CPU temperature check as well as a Nagios Core example
11May2018 – Modified the check_pf_mem plugin
1June2018 – Added Nagios Core services.cfg and commands.cfg examples
29Oct2018 – check_ping changed to check_icmp
7Jan2019 – added info about ‘username is reserved’ error
16Apr2020 – added info about limiting sudo commands
6Apr2022 – Added check_pf_gw_status (contributed by Manuel Gayer)

Why SSH When There’s NRPE and SNMP?

Quite honestly, I’ve never been a huge fan of NRPE or SNMP. By default, NRPE uses ADH (anonymous Diffie Hellman) and it’s a little messy dealing with certs if you want to make it secure IMO. I admittedly haven’t tried the pfSense NRPE package recently, but years ago the service would frequently require a restart, i.e. false positives. I also tried SNMP monitoring because I was quite familiar using it for network equipment monitoring, but 1) I found it difficult to get what I needed and 2) the OIDs ended up being a bit of a moving target. On top of that, SSH is built into pfSense!

As you see above, I like monitoring the holy heck out of my firewalls so I know exactly what’s happening whether in real-time or via historical data <- fantastic for data correlation. I’ll continue adding more checks over time including more security-focused ones, but if you have any you’d like to see just give me a holler and I’ll look at adding them. Better yet, write the script and I’ll acknowledge your work! 😉

I’ve broken this guide down to 3 parts. You can click on any one of the links to go to that section. Note: I suggest going in order and *not* skipping anything. If you receive any errors, please double-check your work and make sure you followed the steps outlined here.

Part 1: Setting up password-less SSH (below)
Part 2: Downloading and testing the checks
Part 3: Configuring the checks on Nagios

Monitoring pfSense with Nagios Using SSH – part 1 – Setting up password-less SSH

Enable SSH on pfSense

First and foremost, you need to enable SSH on your pfSense box if you haven’t already. From the web GUI, go to System -> Advanced and put a checkmark in the box to ‘Enable Secure Shell.’ Hit save!

Creating the SSH keys on Nagios

From the command line on the Nagios system, type in the following as the nagios user. Hint: If you are logged in as root, just run ‘su – nagios’ to make the switch.

$ ssh-keygen -t ed25519

Hit enter a few times to accept the defaults. If all goes well, the new keys will get created in the /home/nagios/.ssh directory. Now we are looking for the public key to copy/paste. Display that key using the cat command below.

$ cat /home/nagios/.ssh/id_ed25519.pub
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIBinKKG0cGsC9rtsD1Ty4Q9fCed1bjUGMazNCTKgJAjT nagios@localhost.localdomain

Don’t close that window just yet! We’ll need it here in a bit! It’s also worth noting that you can copy this same public key to multiple pfSense firewalls (or other Linux, Unix, or BSD systems) that you want to monitor and you don’t need a separate one for each of them.

Creating the Nagios user on pfSense

Now we need to go over to the pfSense web GUI and create the Nagios user. FWIW, the password doesn’t matter because we won’t use it to log in… Just make it something ridiculously long that you can copy/paste twice. Also, note the ‘Authorized SSH Keys’ is identical to the one from the previous step. Don’t forget to click save after filling in the highlighted information.

If you receive an error “That username is reserved by the system” then you previously (or currently) installed the pfSense NRPE package. Even if you remove the NRPE package, it does *not* remove the FreeBSD-level user. Either a) use a different username throughout the guide or b) remove the user via the command line via the rmuser command.

Install and configure the sudo package

Before you get out of the pfSense web GUI, you need to install one other package. As you would when installing any pfSense package, go to System -> Package Manager and click on Available Packages. Type in ‘sudo’ and click install on the only package that shows up. Click ‘Confirm’ and you should be ready to go.

After the sudo package is installed, go to System -> sudo. Click on add and change the user dropdown to Nagios, place a checkmark in the “no password” section and then type ‘ALL’ in the command list as shown below. Click Save. Note: Verify your sudo settings and especially the ‘no password’ checkbox remain after clicking Save!

Note: I would not make limit the command list as discussed here until you have determined everything is working. However, you might consider coming back to this section once you understand exactly which scripts you use in your environment. Instead of ‘ALL’ as seen above, you would limit the command list to only the monitoring scripts that require sudo access. For example, you would add the 2 commands in place of ALL.

/usr/local/libexec/nagios/check_pf_ipsec_tunnel, /usr/local/libexec/nagios/check_pf_state_table

Testing it

Next, go back to your Nagios command line and test to ensure you can log in. Don’t forget that you need to be the ‘nagios’ user! The very first time you’ll get asked a question about continuing your connection as seen below. Type in ‘yes’ and hit enter. If all goes well, you will end up at a command line on the pfSense box (last line in it).

[nagios@localhost ~]$ ssh nagios@192.168.11.1
The authenticity of host '192.168.11.1 (192.168.11.1)' can't be established.
ED25519 key fingerprint is SHA256:QIWv1m3iAfsPu/mqP1XhonpElGxDPEy5ggjRc6fQeew.
ED25519 key fingerprint is MD5:5b:92:18:de:18:65:e9:71:06:12:d5:b1:cb:cb:fd:78.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.11.1' (ED25519) to the list of known hosts.
 [2.3.4-RELEASE][nagios@pf.localdomain]/home/nagios:

If you exit out of the firewall shell with Control-D and then re-connect, you’ll see this login dialog isn’t quite as messy.

[nagios@localhost ~]$ ssh nagios@192.168.11.1
 [2.3.4-RELEASE][nagios@pf.localdomain]/home/nagios:

So we’re now able to login from the Nagios box, but what good does that do otherwise? Now that we have a secure connection between the systems, we can download and eventually run any check command we want using the SSH proxy on Nagios XI or the check_by_ssh on Nagios Core.

Go to Part 2: Downloading and testing the checks