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











On Tuesday, 22 September 2026 at 12:32 PM, Turritopsis Dohrnii Teo En Ming <teo.en.ming@protonmail.com> wrote:

> Subject: [Bug Report] Snort IDS/IPS Portscan Preprocessor Cannot Detect Any Port Scans in pfSense CE 2.9.0 Firewall
>
> Good day from Singapore,
>
> Reporter: Mr. Turritopsis Dohrnii Teo En Ming
> Date: 22 Sep 2026 Tuesday
> Country: Singapore
>
> I had activated Max-Detect IPS Policy with Portscan Detection enabled on 21 Sep 2026 Monday at 10.17 PM.
>
> This is what I have done.
>
> 1. Configure WAN Snort as detection-only
>
> Go to:
>
> Services → Snort → Snort Interfaces → WAN → WAN Settings
>
> Set:
>
> Enable: checked
> Interface: WAN
> Send Alerts to System Logs: checked if you want the alerts in /var/log/system.log
> Block Offenders: UNCHECKED
> If your version presents an Inline IPS option: UNCHECKED
>
> This is the critical part for your requirement of "without blocking anything." Netgate documents that Block Offenders causes Snort to insert
> firewall blocks for hosts generating alerts, while the default is disabled. Inline inspection is also separate and is not required for
> IDS-only monitoring.
>
> In other words, you can use the Max-Detect IPS policy without actually using Snort to block traffic. Here "IPS Policy" describes the rule policy;
> it does not by itself mean that pfSense must block matching traffic.
>
> 2. Use the Max-Detect policy
>
> Go to:
>
> WAN Categories → Snort Subscriber IPS Policy Selection
>
> Set:
>
> Use IPS Policy: ✓
> IPS Policy Selection: Max-Detect
>
> Then Save.
>
> Max-Detect is specifically intended to enable the broadest detection coverage. Snort describes Maximum Detection as including Security,
> Balanced and Connectivity policy rules plus additional active rules, with increased false-positive/performance costs.
>
> Your pfSense interface also exposes Max-Detect as an available policy, as shown in your screenshot. Netgate's current interface documentation
> describes Max-Detect as the policy intended to detect as much as possible.
>
> Don't manually select every Snort Subscriber category
>
> Once Use IPS Policy is enabled, let Max-Detect determine the Snort Subscriber rule selection. pfSense documentation says selecting a policy
> disables manual selection of those Snort categories.
>
> You can still have other rulesets such as Emerging Threats if you've configured them separately.
>
> 3. Enable the required preprocessors
>
> This turned out to be particularly important on your installation.
>
> Go to:
>
> WAN Preprocs
>
> Keep the normal/default preprocessors enabled, and specifically make sure:
>
> Modbus preprocessor = ENABLED
>
> and:
>
> DNP3 preprocessor = ENABLED
>
> We discovered why this matters.
>
> Initially Max-Detect failed with:
>
> Unknown rule option: 'modbus_func'
>
> After you enabled Modbus, Snort proceeded further.
>
> It then failed on:
>
> Unknown rule option: 'dnp3_ind'
>
> After you enabled DNP3, you reported that Max-Detect finally started successfully.
>
> So on your installation I would leave both Modbus and DNP3 enabled while using Max-Detect.
>
> Do not disable them simply because you don't operate Modbus or DNP3 equipment. In this case their importance is that Max-Detect has
> enabled rules containing keywords implemented by those preprocessors.
>
> 4. Configure Portscan Detection
>
> Still under:
>
> Services → Snort → Snort Interfaces → WAN → WAN Preprocs → Portscan Detection
>
> Use the settings you showed in your screenshot:
>
> Enable: ✓
> Protocol: all
> Scan Type: all
> Sensitivity: high
> Memory Cap: 10000000
>
> Ignore Scanners: [blank]
> Ignore Scanned: [blank]
>
> Those are suitable for your test.
>
> With Protocol = all, sfPortscan monitors TCP, UDP, ICMP and IP scanning. With Scan Type = all, it covers portscans, portsweeps,
> decoy scans and distributed portscans. Snort's sfPortscan documentation confirms these options.
>
> Your previous startup log also proved that Snort generated:
>
> Portscan Detection Config:
> Detect Protocols: TCP UDP ICMP IP
> Detect Scan Type: portscan portsweep decoy_portscan distributed_portscan
> Sensitivity Level: High/Experimental
>
> So the GUI settings are making it into Snort correctly.
>
> Keep Ignore Scanners blank
>
> Your GUI says its default is $HOME_NET.
>
> That's appropriate for your particular test because your Nmap scanner is external in Tokyo, while the pfSense WAN being tested is in Singapore.
>
> Don't put your Tokyo scanner's public IP into Ignore Scanners, because that would explicitly tell sfPortscan not to alert on scans originating
> from it. Snort documents ignore_scanners as suppressing scan alerts for specified source addresses.
>
> 5. Make sure Stream5 remains enabled
>
> This is important.
>
> Snort's own sfPortscan documentation states that Stream5 is required for sfPortscan, particularly to determine direction for connectionless
> protocols such as UDP.
>
> Your previous Snort startup log showed TCP and UDP session tracking active, so I would not change the Stream settings.
>
> 6. Save and perform a full Snort restart
>
> After changing preprocessors, don't depend solely on a configuration reload.
>
> Stop WAN Snort and start it again from:
>
> Services → Snort → Snort Interfaces
>
> This is preferable because Snort documents that some dynamic preprocessor changes require a restart rather than merely a reload.
>
> Wait until the WAN Snort icon shows it is running.
>
> There is no need to reboot the entire pfSense firewall every time.
>
> 7. Confirm Max-Detect really loaded
>
> Because you have system logging enabled, check:
>
> tail -100 /var/log/system.log
>
> You should not see:
>
> FATAL ERROR
>
> For a more direct check:
>
> grep -i "FATAL ERROR" /var/log/system.log
>
> And:
>
> ps auxww | grep '[s]nort'
>
> The important distinction is that the GUI configuration being saved does not necessarily prove Snort successfully loaded the entire Max-Detect
> ruleset. The running Snort process does.
>
> 8. Verify the generated preprocessors
>
> For Modbus:
>
> grep -n -i 'preprocessor.*modbus' /usr/local/etc/snort/snort_44907_igc0/snort.conf
>
> For DNP3:
>
> grep -n -i 'preprocessor.*dnp3' /usr/local/etc/snort/snort_44907_igc0/snort.conf
>
> For sfPortscan:
>
> grep -n -i 'sfportscan' /usr/local/etc/snort/snort_44907_igc0/snort.conf
>
> Do not manually edit this generated snort.conf. Use these commands only to verify what pfSense generated.
>
> 9. Test from Tokyo
>
> For a straightforward TCP SYN portscan test from your Tokyo system:
>
> sudo nmap -Pn -sS -p 1-10000 -vvv <your-Singapore-public-IP>
>
> You can also deliberately slow or speed the scan later, but first use a conventional scan so we're testing the basic configuration.
>
> On pfSense:
>
> tail -f /var/log/system.log
>
> Then perform the scan.
>
> You can subsequently search:
>
> grep -i "portscan" /var/log/system.log
>
> and:
>
> grep -i "scan" /var/log/system.log | tail -100
>
> Also check:
>
> Services → Snort → Alerts
>
> 10. Your Nmap signature detection is already proven to work
>
> This part is important because it separates the remaining sfPortscan question from the rest of Snort.
>
> Your previous log already contained repeated alerts such as:
>
> ET SCAN NMAP OS Detection Probe
>
> and:
>
> ET SCAN Potential SSH Scan
>
> from your external scanner to the Singapore WAN.
>
> Therefore Snort is seeing the Nmap traffic and ordinary Snort scan signatures are detecting it.
>
> The outstanding question is narrower: why the sfPortscan preprocessor itself isn't producing the expected portscan event.
>
> 11. Make absolutely sure Snort cannot block anything
>
> For the configuration you want, I would use:
>
> WAN Snort
> │
> ┌─────────┴──────────┐
> │ │
> Max-Detect Preprocessors
> │ │
> Lots of rules sfPortscan = ON
> Modbus = ON
> DNP3 = ON
> │ │
> └─────────┬──────────┘
> │
> ALERT
> │
> system.log
> │
> ▼
> No Snort blocking
>
> The key WAN Settings should therefore be:
>
> | Setting | Your configuration |
> | ------------------------- | -------------------------- |
> | Snort | **Enabled** |
> | IPS Policy | **Max-Detect** |
> | Portscan Detection | **Enabled** |
> | Protocol | **All** |
> | Scan Type | **All** |
> | Sensitivity | **High** |
> | Modbus preprocessor | **Enabled** |
> | DNP3 preprocessor | **Enabled** |
> | Send alerts to system log | **Enabled** |
> | **Block Offenders** | **Disabled** |
> | **Inline IPS** | **Disabled**, if presented |
> | Ignore Scanners | **Blank/default** |
> | Ignore Scanned | **Blank** |
>
> Netgate specifically recommends starting Snort with blocking disabled because more aggressive policies can generate false positives.
>
> One caution about Max-Detect
>
> Max-Detect is deliberately aggressive. Snort says Maximum Detection is primarily intended for testing and isn't optimized for performance;
> false positives are expected.
>
> That actually fits what you're trying to do if your objective is maximum visibility rather than blocking. Leaving blocking off means you can
> observe what Max-Detect finds without Snort automatically cutting off hosts.
>
> And based on what we've already discovered on your firewall, I would not enable every remaining preprocessor indiscriminately. Modbus and DNP3
> were specifically demonstrated to be required by rules Max-Detect selected. If Snort now starts cleanly with Max-Detect, leave the other
> preprocessor settings alone unless another rule dependency or your traffic requires them.
>
> ===================================================================================================================================
>
> Important Information:
>
> pfSense CE firewall version: 2.9.0
>
> Snort package version: 4.1.10
>
> Snort version: 2.9.20_9
>
> ===================================================================================================================================
>
> My Snort signatures/rules have already been proven to work. When I run nmap scans from Tokyo against my pfSense WAN interface in Singapore,
> many of the following Snort alerts were generated:
>
> ET SCAN NMAP OS Detection Probe
>
> ET SCAN Potential SSH Scan
>
> However, port scan detection simply don't work. I think it is a bug.
>
> Please help me to get it working.
>
> Thank you.
>
> Regards,
>
> Mr. Turritopsis Dohrnii Teo En Ming
> Singapore
> 22 Sep 2026 Tuesday 12.26 pm Singapore Time
>
>
>
>
>
_______________________________________________
Snort-users mailing list
Snort-users@lists.snort.org
Go to this URL to change user options or unsubscribe:
https://lists.snort.org/mailman/listinfo/snort-users

To unsubscribe, send an email to:
snort-users-leave@lists.snort.org

Please visit http://blog.snort.org to stay current on all the latest Snort news!

Please follow these rules: https://snort.org/faq/what-is-the-mailing-list-etiquette