pfSense and OPNsense
What NODE64 checks on a firewall – and what it explicitly does not.
Prepared, not supported #
This page describes a state that is prepared: the checks are built and the agent has been measured on FreeBSD 15.1. It has not yet been tried on a real pfSense or OPNsense installation. As long as that is the case, this page does not say "supported".
How the agent gets there #
Both systems are FreeBSD. The NODE64 agent has been built for FreeBSD since phase 22 – statically, without libraries from the target system. It is placed as a program and started through an rc.d script.
Deliberately no package and no plugin. Netgate states about third-party package repositories on pfSense that using them is unsupported and carries a significant risk of breaking the installation – up to systems that no longer boot. A tool meant to check a system's security must not endanger that system. For OPNsense a plugin would be possible but would have to be accepted into the project and maintained there; the agent does not need the web interface at all.
What follows from this: after a firmware upgrade the program may be gone. The installation script can simply be run again. If it is not, the heartbeat stops and the device visibly falls to "offline" in the dashboard – it does not disappear silently.
What is read #
The entire configuration of both systems lives in one file: /conf/config.xml. The agent reads it and evaluates it in place.
Nothing from that file leaves the device. It contains every user's password, IPsec keys, WireGuard private keys, certificates including their private part, RADIUS and LDAP credentials. What is transmitted is exclusively numbers and yes/no answers: "three rules without a description", "UPnP is on", "one IPsec tunnel uses an outdated algorithm". No excerpt, no rule name, no address.
Two tests secure this. The first feeds a configuration full of invented secrets and checks that none of them appears in the collected values. The second is stricter: it requires every collected value to be a number – so nothing can slip through that nobody thought of when writing the test.
What is checked #
| Area | Checks |
|---|---|
| Access | web interface on the WAN side, HTTP instead of HTTPS, SSH from outside, admin account still active |
| Rule set | "any to any" rules, rules without a description, rules without logging |
| NAT | port forward without a source restriction, UPnP enabled |
| Services | DNS resolver open to the outside, time service open to the outside, SNMP with a default community |
| VPN | IPsec with outdated algorithms, OpenVPN without a TLS key, OpenVPN with weak encryption |
| Operations | no remote log destination, no automatic backup |
What is NOT checked #
- The Linux check catalogue does not apply there. On a firewall
/etc/rc.confis nearly empty, services are generated by the web interface, and updates run through the firmware. The ordinary catalogue would report rows of things that are correct on a firewall. Every one of the other 300+ checks is explicitly excluded from firewalls. - Nothing is changed. NODE64 reads, evaluates and reports. No rule is created, none disabled, no service restarted.
- No checking from outside. Whether a port is really open is answered by the configuration – not by a scan. A tool that probes your own firewall from outside would be something else.