Additional troubleshooting / possible root cause found for Snort Portscan Detection preprocessor not generating portscan alerts

September 29, 2026

Subject: Additional troubleshooting / possible root cause found for Snort Portscan Detection preprocessor not generating portscan alerts

Good day from Singapore,

Reporter: Mr. Turritopsis Dohrnii Teo En Ming

Date: 22 Sep 2026 Tuesday 7.15 pm

Country: Singapore

I performed further testing on pfSense CE 2.9.0 with Snort package 4.1.10 / Snort 2.9.20_9.

The sfPortscan preprocessor itself is correctly generated in the WAN snort.conf:

preprocessor sfportscan: \

scan_type { all } \

proto { all } \

memcap { 10000000 } \

sense_level { high } \

ignore_scanners { $HOME_NET }

Stream5 is also enabled:

track_tcp yes

track_udp yes

The generated file:

preproc_rules/preprocessor.rules

contains the sfPortscan GID 122 rules, including:

gid: 122; sid: 1 PSNG_TCP_PORTSCAN

gid: 122; sid: 5 PSNG_TCP_FILTERED_PORTSCAN

gid: 122; sid: 21 PSNG_UDP_FILTERED_PORTSCAN

However, the generated snort.conf does not define PREPROC_RULE_PATH, does not include preprocessor.rules, and does not contain config autogenerate_preprocessor_decoder_rules.

The normal rule includes are only:

include $RULE_PATH/snort.rules

include $RULE_PATH/flowbit-required.rules

include $RULE_PATH/custom.rules

I also checked those three included rule files for gid: 122, and none contained any GID 122 rules.

Controlled test

I created a test configuration and added:

var PREPROC_RULE_PATH preproc_rules

and:

include $PREPROC_RULE_PATH/preprocessor.rules

snort -T then successfully validated the configuration:

Snort successfully validated the configuration!

Snort exiting

I then stopped only the WAN Snort process, added the same two lines to the generated WAN snort.conf, and started Snort directly using the same command line normally used by pfSense,

so that pfSense would not regenerate snort.conf.

/usr/local/bin/snort -R _44907 -M -D --daq pcap --daq-mode passive --treat-drop-as-alert -l /var/log/snort/snort_igc044907 --pid-path /var/run --nolock-pidfile --no-interface-pidfile -G 44907 \

-c /usr/local/etc/snort/snort_44907_igc0/snort.conf -i igc0

After doing this, sfPortscan immediately started generating GID 122 alerts from external scans. Examples:

[122:21:1] (portscan) UDP Filtered Portscan

[122:5:1] (portscan) TCP Filtered Portscan

The same external scanner that previously generated normal Snort Nmap signature alerts but no sfPortscan alerts then generated:

[122:21:1] (portscan) UDP Filtered Portscan

Therefore, my testing suggests that sfPortscan itself is functioning, but its GID 122 rules in preproc_rules/preprocessor.rules are not being loaded by the pfSense-generated Snort configuration.

Another observation is that starting Snort normally from the pfSense GUI regenerates snort.conf and removes the manually added PREPROC_RULE_PATH and include $PREPROC_RULE_PATH/preprocessor.rules lines,

after which the workaround is lost.

I reproduced the original failure with both Max-Detect and Security IPS policies, so the problem does not appear to be specific to Max-Detect.

Could the Snort package maintainer please check whether preprocessor.rules should be included/processed when generating the interface snort.conf?

Ordinary Snort Nmap signatures were working before the workaround. That proves the failure wasn't caused by traffic failing to reach Snort. For example, I had ET SCAN NMAP OS Detection Probe alerts

while GID 122 remained completely absent.

My experiment demonstrates that loading preprocessor.rules restores GID 122 alerts; the package maintainer can determine why the generated Snort configuration isn't loading/processing those rules and what the

correct permanent fix should be.

Thank you very much.

Regards,

Mr. Turritopsis Dohrnii Teo En Ming

Republic of Singapore

22 Sep 2026 Tuesday 7.34 pm Singapore Time

REFERENCES

================

[1] https://lists.freebsd.org/archives/freebsd-amd64/2026-September/000258.html

[2] mail-archive.com - NIL

[3] https://marc.info/?l=freebsd-amd64&m=179007700292132&w=2

[4] https://lists.snort.org/pipermail/snort-users/2026-September/000905.html