Suricata on pfSense blocking IPs on Pass List

I’ve had this off and on problem with Suricata running on pfSense where it will block IPs that exist on the pass list. I’ve researched and posted in the Netgate forums but have had limited success in permanently resolving the error. In pfSense I restart the entire Suricata service as well as each interface. I can check and see the IP is indeed in the pass list. If I (on the most recent one with the problem) run

cat /usr/local/etc/suricata/suricata_28922_igb1/passlist

Then I can see the IP in the list (it’s actually the IP/32 since that’s how it’s put it in case I need to expand the IP range). What else can I check or try? Yesterday I disabled the rule entirely so when it happened this morning it wound up disabling a whitelisted IP using a disabled rule. It just feels like there is a disconnect between pfSense and Suricata. In the Alerts page on pfSense it even has the indicators that the rule is disabled and the alerts for it suppressed.

So, I’m turning here. Where can I go on the CLI to try to understand what is happening? Thanks for any help!

pfSense uses a version of Suricata that is extended with some extra functionality. I believe the passlist you mention is one of those things. So I think the best thing to do would be to go through the pfSense support channels.

Thank you for your reply. I started top and then stopped the service through the pfSense gui. It spun for a bit but then showed that it was still running. The processes still showed in top as well. I stopped it again (also through the gui) and after a minute or so it finally showed that it stopped and all the processes cleared out of top. I then started it again (through the gui) and it hasn’t blocked again, yet. I’m not exactly sure what that indicates but it could be that telling in telling it to restart at some point it wound up starting a new process without successfully stopping the old one first.

I’m curious what troubleshooting is available through the cli to see what’s going on. How would you normally view the loaded whitelisted IPs in Suricata? I can see commands:
https://redmine.openinfosecfoundation.org/projects/suricata/wiki/Ignoring_Traffi
and
https://suricata.readthedocs.io/en/suricata-5.0.3/performance/ignoring-traffic.html
about ignoring and passing but haven’t seen where we can run a command and see all the ones already put in.

Can you post a screenshot from the pfSense GUI showing what this whitelisting looks like? I suspect it may be one of the pfSense specific extensions. Or perhaps it’s simply using a special rule file with pass rules or something.

You may be able to find what you are looking for, here:
https://forum.netgate.com/topic/154984/suricata-unwanted-blocking
The pass list is an imported alias so there isn’t anything to show on the process. This is the page you select it (we are using a custom theme so it’ll look a little different than the default if you try to compare to other things)


And if you click “View List”

In the filesystem it looks like a text file under the format of: /usr/local/etc/suricata/suricata_[ID]_[NIC]/passlist
Once it’s in there, though, you need to reload the interface for it to take the changes.

Thanks. I don’t know how pfSense (or the Suricata version they ship) turns that text file into something Suricata understands for passing traffic.

It must get loaded into Suricata when it is started. Is there a way to look at all of the IPs that are currently set to “pass” or “ignore” by the engine?

The pass list is a pfSense extension (see https://github.com/pfsense/FreeBSD-ports/blob/devel/security/suricata/files/patch-alert-pf.diff#L414), so you’ll have to ask the pfSense folks for advice on how to debug/analyze it. It’s not supported by us.

Gotcha. Thanks for the help!

Please do link back to an answer you may get, so others might learn from it :slight_smile: Thanks!

Sure thing. Right now the whole conversation is in the forum link above but when I have a final answer I will post here for posterity’s sake.

So, the belief is that there were multiple Suricata processes that were running at the time. The GUI locks on to the PID of the first process. If other processes also load then they have their own PIDs. When reloading or restarting the service or the interface it only does the it on the PID it is aware of. It seems the solution would be to:

  1. Stop the service via the GUI.
  2. Check for Suricata processes in top
  3. If they are there, run “ps-ax | grep suricata”
  4. Find the PID of the process and kill it with "kill -9 "
  5. Verify all the Suricata processes are stopped
  6. Start the service via the GUI.
  7. Verify the processes are running on the individual interfaces.

Hopefully this helps someone who comes along after me, or helps me in the future when I forget.