The mechanical answer to how to install snort on pfSense is four clicks in the package manager. The useful answer is everything after that: which rule feeds to enable, which interface to inspect, and whether to block in Legacy Mode or Inline IPS Mode. Check the installed engine version separately from the GUI package version before choosing rule feeds.
Know which Snort you are getting
The GUI package and the Snort engine are separate components. Record both versions from the installed package list and check the engine’s supported rule feeds before enabling them. A GUI package version is not evidence that the engine has moved to the same major version.
Snort publishes engine lifecycle notices. Check them against the installed binary rather than relying on an older walkthrough’s version numbers.
So install Snort when you specifically want it, usually for OpenAppID application detection. For the alternative, read Snort versus Suricata on pfSense; Netgate’s documentation notes the two share enough design that most Snort instructions carry across. Install one, not both on the same interface.
Install the package and open the GUI
Go to System > Package Manager > Available Packages, search for snort, and click Install. The configuration interface then appears at Services > Snort. Nothing is inspecting traffic yet: a fresh install has no rules and no interfaces assigned, and sits idle until you do both.
Enable rule feeds on the Global Settings tab
The setup documentation lists five rule sources, one of which comes in two tiers:
| Rule set | Cost | Notes |
|---|---|---|
| Snort VRT, registered | Free, snort.org registration | Released to registered users after 30 days or more |
| Snort VRT, subscriber | Paid | Twice-weekly updates, sometimes more frequent |
| Snort GPLv2 Community | Free | Already included in a paid VRT subscription |
| Emerging Threats Open | Free | Broad general-purpose coverage |
| Emerging Threats Pro | Paid | Near-daily updates |
| OpenAppID | Free | Open detectors for layer 7 application identification |
For a home or lab firewall, Emerging Threats Open plus the Snort GPLv2 Community rules is the sensible free start. Registering at snort.org gets you an oinkcode, which goes in the subscriber-code box here and unlocks the registered VRT feed. Do not enable the Community rules alongside a paid VRT subscription; the paid feed already contains them.
Set Update Interval here too. The documentation calls every 12 hours a good choice, with a start time defaulting to just past midnight.
Then use the Updates tab and click Update Rules. The updater compares MD5 hashes between local and vendor copies and downloads only what differs; a FORCE button bypasses that check. The tab shows the hash and file timestamp, so it doubles as proof your oinkcode works.
Assign an interface
On the Snort Interfaces tab, add an interface. WAN and LAN differ, and the difference is NAT.
On WAN, Snort sees traffic before inbound NAT translation, so alerts carry real public source addresses, plus every bit of internet noise your firewall was going to drop anyway. On LAN it sees post-translation private addresses, so an alert names the internal 192.168.0.0/24 host that actually did something, which is far more actionable when the problem is a machine of your own.
Each interface spawns its own Snort process with its own copy of the rules in memory, so two interfaces is roughly double the RAM footprint. Use the pfSense hardware sizing calculator to plan inspection alongside the rest of your workload, and check the hardware requirements reference before adding memory-intensive rule sets.
Legacy Mode versus Inline IPS Mode
This is the decision that catches people out. The two modes fail in opposite directions.
Legacy Mode is the default: an IDS with a bolt-on blocker. A custom output plugin takes a copy of every alert, extracts the IP addresses, screens them against your Pass List, and inserts the survivors into a pf table called snort2c. A hidden firewall rule, absent from the GUI but present in /tmp/rules.debug, blocks anything in that table. The consequence is blunt: as the package author describes it, every alert becomes a block unless a Pass List entry covers it. One false positive on your ISP’s resolver and you have cut yourself off.
Inline IPS Mode routes packets through a netmap pipe between the NIC driver and the network stack, so Snort drops the packet rather than blocklisting a host afterwards. Two hard constraints. Inline operation depends on netmap support in the installed FreeBSD driver and package combination; check the current package guidance for the actual NIC before enabling it. And every vendor rule ships with an action of ALERT, so enabling Inline IPS Mode without rewriting rule actions to DROP gives you exactly zero blocks. That is the source of most “my IPS does nothing” threads.
The per-interface settings live on the Interface Settings tab. Block Offenders turns blocking on. Which IP to Block takes SOURCE, DESTINATION or BOTH, with BOTH as the recommended default. Kill States clears existing state-table entries for a blocked address, and the documentation says it should generally be enabled, because without it an established connection survives the block.
Leave Block Offenders unchecked for the first week. Run pure IDS, read the Alerts tab, and build Pass List and Suppress List entries for the rules that fire on your own normal traffic. Keep console or another recovery path available and account for required management traffic in the pass policy.
Verify before you call it done
Confirm that the service is running, the intended rules loaded, and ordinary traffic reaches the selected interface. The following commands inspect local package, process and blocking-table state.
From a shell on the firewall:
pkg info | grep -i snort
ps -ax | grep snort
grep snort2c /tmp/rules.debug
pfctl -t snort2c -T show
Line one confirms the package and binary versions. Line two should show one process per configured interface; a missing process means Snort died on startup, usually on a bad rule or a memory ceiling. Line three confirms the hidden block rule exists; line four lists what is currently blocked, the first place to look when something breaks after you enable Block Offenders. Clear a bad block with pfctl -t snort2c -T delete <ip>, then add the Suppress List entry or it returns.
For your own network, compare an ordinary file transfer across the inspected path before and after enabling inspection, while watching CPU. Deep packet inspection on a single-threaded engine is the most common reason a box that used to route at line rate suddenly does not.
Common mistakes
Enabling Block Offenders on day one and blocklisting your own DNS resolver. Running Snort and Suricata on one interface, paying twice for identical alerts. Switching to Inline IPS Mode on a NIC with no netmap support, or leaving every rule at ALERT and wondering why nothing drops. Inspecting WAN when the question is which internal host is misbehaving.
Related across the network
- OPNsense Suricata IDS/IPS: Installation and Tuning Guide — opnsenselab.com