Across interfaces on the same box, "no". Across interfaces on different firewalls, "yes" (provided the two firewalls have identical NIC hardware and the same interface layout). You can clone an existing interface when creating a new one. That makes the new interface identical to its parent. But this is a one-time event. They do not then auto-sync with each other going forward. You could accomplish synchronzing rules using the SID MGMT tab feature. Simply assign the same SID conf files to each interface.

@stephenw10 Thanks everyone [image: 1639246621967-snortupdated.jpg]

@bmeeks Don't get me wrong I love to talk shop it is its own language talking about firewalls with other people. Thank you for all you do. Have a great day. On Palo Alto's side you have to install certificates on the devices so it is encrypted again as it leaves the firewall to the lan side. Maybe the proxy is encrypted also.

@bmeeks lol ok, thank you very much!

@nrgia said in Suricata 6.0.3_4 Package Update Release Notes (currently for DEVEL only): @bmeeks said in Suricata 6.0.3_4 Package Update Release Notes (currently for DEVEL only): The idea for enabling this option would be to not burden the signature analysis/compare engine with needlessly testing packets the OS is probably going to discard anyway and never forward. I understand, but now I'm concerned about the following use case: If a special crafted payload is sent in order to avoid the engine, this option will help to evade Suricata. Are you sure the packets will be droped by the OS? I mean I inderstood the performance gain, but there is any reason for concern about security? I don't want to trade security for some performance gain. Just asking you're opinion here, nothing else. Thanks You are way overthinking this ... . The default forever in the package has been to "not drop invalid" (the checkbox was essentially "not checked" because it did not exist), so just leave it unchecked if you are concerned. I simply added the ability for more control over how the application is configured. And don't forget that the overwhelmingly vast majority of all traffic passing through your firewall is encrypted, so Suricata is not inspecting most payloads anyway since it can't peer into encrypted data.

@digdug3 I do have the standalone http log option disabled. I have basic logging (for http and several other ptotcols) enabled for eve output on one interface. If I disable/reduce logging on an interface, I'd expect to see a load reduction in proportion to the volume of traffic on the interface, be it suricata 5 or 6. However the interface concerned is low traffic and the proportion of http is fairly low. I'm going to play around with it next time though. Thanks.

I read the link back to AbuseIPDB posted in one of the replies in this thread. I don't really see how this fits into the general Suricata use case on pfSense. Sure Suricata can load up some IP list (providing it's in the correct format as specified for IP reputation lists), but the binary has no method of feeding anything back to the AbuseIPDB eco-system. The best you can do is scrape the text logs, but in my opinion you should not be doing all that work on your firewall. I say that because invariably such tools want to drag in all kinds of dependent packages, and each dependent package you add is a potential attack vector. You increase the attack surface of your firewall and thus reduce security. Better in my view to export the firewall and Suricata logs to an external SIEM type system, and then do your log scraping and reporting from there. That system could also report things back to AbuseIPDB. In the IT Security world I came from, your firewall has one job. And that job is keeping external traffic out (unless explicitly allowed in), and controlling what internal traffic can go where. Reporting, pretty graphs, and all that GUI fluff should be handled on an external system that is not the firewall.

@bmeeks That's strange, i've disabled: app-layer-events stream-events files since 2015 (using jflsakfja's list)

@asmirnov said in Suricata doesn't see the traffic: Sorry, I meant packets. The goal is to understand whether suricata recognizes the contents of packets, maybe I configured something wrong and it does not check I found this link describing where ERSPAN stats are captured by Suricata: https://forum.suricata.io/t/erspan-type-ii-decpasulation-processing/242. You could try enabling the stats.log feature (on the INTERFACE SETTINGS tab) to see what Suricata is seeing and logging with respect to ERSPAN.

@pfsenseuser2021 said in Snort is not working properly: I’ve read some posts about snort and vlans and I can’t understand, why the parent interface is involved. As I know on linux a vlan interface should operate like any other network interface - so I can’t understand, why suricata or snort should have problems with this configuration. I don't understand this either but that is the recommendation. I too have limited NICs on the physical host. I elimnated all vlan configuration within pfsense by virtualising it and making each vlan a member of a separate bridge on the hypervisor. That way, in pfsense, every interface is a assigned regular network adapter, albeit vtnet. Having said that, I've since encountered perfomance issues with suricata 6 (though not with v5) when running in a VM.

@bmeeks i edited the suricata.inc and restarted the service. now i do see all the ip addresses from the aliased whitelist. Thank you very much!!

Great! The change should make it into a formal package update soon. Thanks to @viktor_g for the quick fix. He knew right where to look. It would have taken me a bit longer to dig around in the function code and find the issue.

@bmeeks Thank you Sir I will install Suricata as it looks good

@darcey said in Suricata disablesid.conf and expected suricata log output: @bmeeks said in Suricata disablesid.conf and expected suricata log output: Are you positive these rules are not user-forced from some previous actions? I thought so. However I rechecked "User Forced Enabled Rules" and there were some listed there. I apologise for not double checking. I knew I had forced disabled some of the STREAM rules, but wasn't aware of the enabled's. I'd restored pfsense from backup after playing around and thought I had a clean(ish) starting point :-/ So, removing those force enabled rules eliminated many of the errors I saw in the suricata.log at startup, and the remainder I 've now successfully disabled via SID MGMNT. Thanks for your help. I now have a better understanding and the confidence to mess it up further! Glad you got it sorted out .

@steveits @bmeeks Okay, didn't know I could do a pass list. Just taught myself via clicking around how to set up an alias, and add those CIDR IP address ranges from those two VLANs I want skipped to suricata. Thanks so much!

@steveits said in Bypass filtering of a LAN device: @inline6 said in Bypass filtering of a LAN device: I should turn it off on the WAN interface entirely We only set it up on LAN for our clients. You can just stop it for a while, if you want. Otherwise you'll scan every packet twice. That is the route I will go, thank you again.

@bmeeks Now I got you, thanks for the detailed explanation. So it must have been different then I thought.