[Bug Report] Snort IDS/IPS Portscan Preprocessor Cannot Detect Any Port Scans in pfSense CE 2.9.0 Firewall
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
REFERENCES
=============
[1] https://lists.freebsd.org/archives/freebsd-amd64/2026-September/000257.html
[2] mail-archive.com - NIL
[3] https://marc.info/?l=freebsd-amd64&m=179005127168258&w=2
[4] https://lists.snort.org/pipermail/snort-users/2026-September/000904.html
[5] mail-archive.com - NIL
[6] https://marc.info/?l=snort-users&m=179009017706411&w=2
[8] https://redmine.pfsense.org/issues/17120
[9] https://lists.snort.org/pipermail/snort-devel/2026-September/000231.html
[10] mail-archive.com - NIL
[11] https://marc.info/?l=snort-devel&m=179008926605522&w=2
Comments
Post a Comment