Announcing the New NetEye Extension Pack for pfSense Firewall in NetEye 4.47
With the NetEye 4.47 release, we will be extending the coverage of our NetEye Extension Packs (NEPs) by introducing a new package specifically focused on pfSense firewall monitoring, implemented through Centreon plugins.
This article explains:
When the pfSense NEP will be available
What it does and which aspects of pfSense it monitors
How it’s integrated into NetEye and Icinga Director
Availability
The new NEP for pfSense firewalls will be released and supported starting with:
NetEye: version 4.47 (and compatible later versions)
It’s distributed via the official NEP repository, alongside existing NetEye Extension Packs, and follows the standard NetEye release and support lifecycle.
Like other NEPs:
It’s installed using nep-setup
It provides pfSense‑specific Commands, Service Templates, and Service Sets in Icinga Director
It integrates with the standard NetEye SNMP / agentless host templates and variable model
What the pfSense NEP Does
The purpose of this NEP is to offer out‑of‑the‑box monitoring for pfSense firewalls using the Centreon pfSense plugin over direct SNMP, while keeping the configuration experience consistent with the rest of NetEye.
The NEP provides ready‑made monitoring for key pfSense areas, such as:
CPU and system load: Overall CPU utilization and load averages
Memory and swap: Memory and swap usage with configurable thresholds
System runtime / uptime: Operating time of the pfSense system
Interfaces: Traffic in/out and visibility on passed and blocked traffic by interface
State table: Number of entries, insertion/removal rate and search activity in the pfSense state table
All these checks are exposed via Director objects and can be enabled without having to manually deal with raw plugin parameters or custom command definitions.
How It Works in NetEye
1. Installation and Prerequisites
The pfSense NEP builds on the existing NEP and Centreon infrastructure available in NetEye 4.47, such as:
The common NEP base packages
The network and Centreon‑plugin base NEPs
Installation is done through the standard NEP workflow:
nep-setup install nep-network-pfsense-firewall
During the setup, the NEP:
Verifies and enforces the minimum required NEP dependencies
Installs the Centreon pfSense SNMP plugin from the official Centreon repository
Imports the pfSense‑related Director objects (commands, service templates, service sets)
Performs any required standard configuration and directory setup
From an operational perspective, this means:
No manual RPM handling for the pfSense Centreon plugin
No manual creation of Icinga commands or service objects for pfSense monitoring
A predictable, repeatable installation process aligned with other NEPs
2. Director Objects: pfSense‑specific Commands, Templates, Service Sets
The pfSense NEP provides a dedicated set of Director objects:
Commands: Commands encapsulate the different monitoring modes of the Centreon pfSense plugin (CPU, load, memory, swap, uptime, interfaces, state table). They are built on top of the standard NetEye Centreon SNMP command template to ensure consistent behavior.
Service Templates: Each area (for example CPU, load, memory, state table, interfaces) has its own service template. Templates define default thresholds and expose relevant parameters as Director data fields, so that warning/critical limits and filters can be adjusted per host where needed.
Service Sets: The NEP provides at least two logical groupings:
A base pfSense service set for essential firewall health monitoring (CPU, load, memory, runtime, swap)
An extras service set for more detailed visibility (interfaces and state table), which can be optionally enabled on selected firewalls
All objects follow the usual NetEye / NEP naming conventions and align with the existing SNMP / agentless templates, making it straightforward for administrators who are already familiar with NEPs.
3. Automatic Assignment via Host Templates and Variables
The pfSense NEP leverages the automatic service‑set assignment mechanism used by other NEPs, based on:
An appropriate host template for SNMP‑monitored firewalls
A small set of standardized host variables
Typical conditions include:
The host uses a network‑firewall SNMP template (for example a generic NetEye firewall SNMP host template)
The hardware vendor variable is set to "pfsense"
NEP‑specific flags such as nx_enable_nep_ss (for base service sets) or nx_enable_nep_extras (for additional checks) are enabled
When these conditions are met, the NEP’s pfSense service sets are automatically assigned to the host when configuration is deployed in Icinga.
There are also variables to:
Exclude certain service sets if they are not desired for specific hosts
selectively enable or disable extra monitoring features, such as detailed interface or state‑table checks.
This approach:
Eliminates the need to manually attach multiple pfSense services to each host
Ensures consistent pfSense monitoring across environments
Keeps the configuration modular and easy to maintain
Benefits of the pfSense NEP in NetEye 4.47
The new pfSense‑focused NEP in NetEye 4.47 offers several concrete advantages:
Native pfSense coverage: pfSense becomes a first‑class, officially covered firewall platform within NetEye’s NEP ecosystem
Standardized configuration: All pfSense checks are integrated through a unified model, reusing the same conventions and patterns as other device‑specific NEPs
Faster onboarding: Adding pfSense firewalls only requires selecting the correct host template, setting the vendor to pfSense and enabling the NEP service sets
Operational consistency: Thresholds, metrics and naming are consistent across environments, reducing misconfigurations and simplifying troubleshooting
Scalability: Automatic assignment of base and optional extra checks allows administrators to scale pfSense monitoring from a few to many firewalls with minimal effort
Did you find this article interesting? Does it match your skill set? Our customers often present us with problems that need customized solutions. In fact, we’re currently hiring for roles just like this and others here at Würth IT Italy.
ed invece talvolta sono ridondati ma se c'e un problema con il VRRP (Virtual Router Redundancy Protocol), che non e' immediatamente riconoscibile, al momento del bisogno l' elezione del Master potrebbe non funzionare. Molto interessante il set di plug-in smnp Read More
Giovedì 16.07.2009, dopo 5 ore di viaggio siamo arrivati a Scarmagno (TO), dove eravamo stati invitati ad un evento, organizzato da un nostro partner locale MCS. Durante la mattina si è parlato delle soluzioni di sicurezza della rete offerte da Read More