DEV Community

Nguyen Dong
Nguyen Dong

Posted on

A single pfSense block never becomes a Wazuh alert. Here is why, measured.

#wazuh #pfsense #security

You point pfSense at Wazuh, the logs arrive, and the dashboard stays empty. Most people assume the integration is broken. On Wazuh 4.14.7 it usually is not: there are two separate reasons, and one of them is by design.

We sent pfSense filterlog lines over UDP syslog to a Wazuh 4.14.7 manager container and read archives.log and alerts.json.

Reason 1: rule 87701 carries no_log

The stock pfSense rules live in ruleset/rules/0540-pfsense_rules.xml:

Rule Level Matches Becomes an alert?
87700 0 any filterlog event decoded as pf no (level 0)
87701 5 action = block no: it has <options>no_log</options>
87702 10 18 × 87701 from one source IP within 45 s yes

The comment above 87701 says: "We don't log firewall events, because they go to their own log file." Pass events stop at 87700.

What we measured:

  • One block line over UDP 514: it reached archives.log; alerts.json stayed empty.
  • 18 block lines from one address within the window: the 18th came back as 87702, level 10.

So a working integration shows nothing until one address is blocked 18 times in 45 seconds.

One trap while testing: wazuh-logtest prints "Alert to be generated" for 87701 anyway. Logtest does not apply no_log. Check alerts.json, not logtest.

Reason 2: RFC 5424 lines match no decoder

pfSense can log in BSD (RFC 3164) or RFC 5424 format. The stock decoder is keyed on <program_name>filterlog</program_name>, which Wazuh's pre-decoder reads from a BSD-style header. Over UDP on 4.14.7:

Line sent Decoder
Oct 2 15:00:01 pfSense filterlog[12345]: 5,,,1000000103,igb1,match,block,… pf: srcip, dstip, action read
2026-10-02T15:00:01.123456+07:00 pfSense.home.arpa filterlog[12345]: … pf: read
<134>1 2026-10-02T15:00:01.123456+07:00 pfSense.home.arpa filterlog 12345 - - … No decoder matched

With RFC 5424, archives.log even shows the manager's own host name instead of the firewall's: the header was never parsed.

The fix

  1. Send BSD format. In pfSense, Status → System Logs → Settings, set the log message format to BSD (RFC 3164).
  2. Decide which blocks you want as alerts. To alert on every block, overwrite 87701 without no_log in /var/ossec/etc/rules/local_rules.xml: 
<group name="local,pfsense,">
  <rule id="87701" level="5" overwrite="yes">
    <if_sid>87700</if_sid>
    <action>block</action>
    <description>pfSense firewall drop event.</description>
    <group>firewall_block,pci_dss_1.4,gpg13_4.12,hipaa_164.312.a.1,nist_800_53_SC.7,tsc_CC6.7,tsc_CC6.8,</group>
  </rule>
</group>
Enter fullscreen mode Exit fullscreen mode

On 4.14.7 this loaded with no warnings, and the same single block line that produced nothing produced one 87701 alert. An internet-facing firewall blocks a lot, so many people prefer a narrower child rule (one interface, one port) and leave 87701 alone.

Limits

Measured on a Wazuh 4.14.7 manager container, with syslog over UDP from 127.0.0.1 and in wazuh-logtest. We did not run a pfSense box: the lines were written in the filterlog format for one IPv4 TCP block and one pass. Not measured: IPv6, other pfSense programs, OPNsense, other Wazuh versions.

Full note with the one-minute checks: https://atkvn.com/fix-pfsense-logs-not-showing-in-wazuh.html

Dong Nguyen, ATK New Technology. We check and fix Wazuh rules for people who run it.

Top comments (0)