
Monitoring pfSense with Nagios Using SSH – part 1
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

Dallas Haselhorst has worked as an IT and information security consultant for over 20 years. During that time, he has owned his own businesses and worked with companies in numerous industries. Dallas holds several industry certifications and when not working or tinkering in tech, he may be found attempting to mold his daughters into card carrying nerds and organizing BSidesKC.
16 thoughts on “Monitoring pfSense with Nagios Using SSH – part 1”
Hello I would add one thing.
You need to enable SSH on the pfsense box…
In part 1, there is a very brief statement about enabling SSH. I didn’t spend a lot of time on it because most sysadmins enable SSH on their box shortly after install. If I need to further clarify how to enable it, just let me know and I’ll make some modifications. Thanks for the feedback!
hello thank you so much for your work, I followed your instruction but yet I cant manage to log in to pfsense box using ssh from Nagios unless I enter the password for the user we created,
any help please on that and I’d be thankfull
Thanks for the feedback! A majority of the time, this is caused by creating the key on the wrong account. The other issue I’ve run into is the need for an extra carriage return after copying/pasting the key into the “Authorized SSH Keys” box. Let me know what you figure out!
will I edit the /etc/ssh/sshd_config and I enabled the publickeyauthentication and now I can connect using public key but as root and when I try to do so as nagios user I got a “permission denied (publickey)” so any help on the, and thank you in advance.
That specifically is an issue with who created the key… Make sure you are logged in as the nagios user on the Nagios system when you run the ssh-keygen command.
Dallas, for those of us in home testing systems that don’t use a full setup like Nagios, what do you recommend for external monitoring of pfsense logs (I primarily use it with pfBdev and snort, both loaded up and across multiple subnets). Been gravitating towards a splunk setup, but before going up the learning curve would interested to get a sense on direction.
Nagios is performing uptime and additional resource monitoring in the way I use it here. If you are interested in logs (and traditional SIEM functions), there are tons of options so you can play with them at home. I’m a fan of Security Onion, but it is so much more than a log collector so it requires some additional horsepower. Kiwi, Splunk, and LogRhythm all have freemium versions that would be a great way to play around in the space too.
Hello, thanks for this article.
I’m trying to manage IPSEC tunnel with NRPE on Nagios but it failed everytime.
I think I do not put the right options in pfSense and maybe Nagios too. It works locally on pfSense.
In nagios i have this :(check_nrpe_script_2!5666!check_pf_ipsec_tunnel!myIP)
In pfSense i have this on extra options :
(-e myip)
Any idea ??
Thank you in advance for your help.
Hey Florent! Thanks for stopping by! I believe your last variable will likely need to be ‘-e myIP’ or ‘-e!myIP’ if I remember NRPE correctly. For example, either ‘check_nrpe_script_2!5666!check_pf_ipsec_tunnel!-e myIP’ or ‘check_nrpe_script_2!5666!check_pf_ipsec_tunnel!-e!myIP’. Also keep in mind that checking the VPN requires root privileges so you will need to use ‘sudo’ on your command. Just for my own curiosity, please let me know what format works. Thanks and best of luck!
Thank you for your quick answer!
I tried both and thought about adding sudo, but without success for the moment. For information the error is as follows: CRITICAL – IPSEC VPN tunnel not found: MyIP
I checked the tunnel is well established on the pfsense.
I keep looking and keep you informed.
Sounds great! Best of luck!
Hi Dallas,
Thanks for your excellent plugin, I’m finding it really useful. Just wondering if you had a script that checks when bandwidth has reached a specified threshold over a specified period of time?
Or even a script that comes close to doing this that I can play with. I’ve tried a few scripts I’ve found on the internet, but no luck running them on FreeBSD.
Hey Ricky! Someone asked about this awhile back and I answered the question in the comments on part 2 of the guide. Long story short is I don’t have anything because I found running ping commands to/from can help identify saturated links in a roundabout way. However, if you decide to travel down that path, I would suggest using iftop (below). With a little scripting, you could bring the data back into Nagios rather easily and even graph it. I think this would be extremely useful and if you write it, let me know as I would love to add it to the plugins. Take care!
: sudo pkg install iftop
: sudo iftop -t -s 1 -n -N -i em1
——————————————————————————————–
Total send rate: 60.1KB 60.1KB 60.1KB
Total receive rate: 996B 996B 996B
Total send and receive rate: 61.1KB 61.1KB 61.1KB
——————————————————————————————–
Hi Dallas,
thanks for the excellent guide. To improve security I suggest shrinking the sudo command list of the nagios user only to the necessary monitoring commands.
Hey Seb! Not a bad suggestion and one I’ve considered as well. My reason for not baking the change into the guide originally was that if someone is on the system as that user, a) you’re in big trouble and b) they can already modify the other sudo scripts unless you restrict their permissions too. All that said, a brief discussion should be included… I’ll make mention of it in the guide and let the readers choose their own path. Thanks!