The Netgate team did some throughput testing some time back shortly after the Inline IPS Mode option was added to the Snort package. I no longer have the emails we swapped, but if I recall correctly there was about a 100 MBits/sec penalty with Snort running with a moderate rule set. This was likely on one of their higher-end appliances (but bare metal, so not apples-to-apples when comparing to virtualized). One thing that also matters is the type of traffic in the throughput test. Small packets versus large packets, for example. I'm talking about the payload size when I say "small" and "large". Every packet has a certain amount of CPU overhead in order to get processed. That overhead stays pretty constant no matter if the packet is a 64-byte icmp-request, or if it is a full-frame 1500-byte TCP packet. The overhead I'm talking about is wrapped up in pulling the packet off the wire and copying it into kernel memory for processing. But when looking at throughput, most all speed tests are just measuring total bits or bytes received over some unit of time (typically per second). As an example, about 42 1500-byte packets will deliver the same amount of "data" per second as 1000 64-byte icmp-reply packets. Obviously the CPU is going to be doing a lot more work over the same time interval to process 1000 packets as compared to only 42. The true measure of throughput is pps (packets per second). This removes the "packet size" variable from the equation. So one thing some throughput tests do is mix up the composition of packets in the test data stream. They generate a mix of small, medium, and maximum payload packets in an attempt to more closely mimic real world traffic. So my point with the long description above is that you should not assign too much importance to the results of a speed test. Instead, examine the real day-to-day performance of your network. Do things seem to still work at the same speed? Do web sites still load at the same rate? Are users complaining about speed slowdowns? An IDS/IPS will slow down your packet processing by some amount. That's just unavoidable, because you have added a large amount of extra work for the CPU to do. It has to pull the packets into the IDS/IPS, analyze them by comparing each packet to all of the signatures, and then make a go/no go decision for the packet. The CPU cycles expended doing that have to come from somewhere.

To expand a bit upon the answer provided by @Gertjan. Packages for pfSense are compiled against a specific FreeBSD kernel version. And because FreeBSD is the underlying operating system for pfSense, that ties the version of pfSense to a specific branch of FreeBSD. So, in turn, packages are also tied to a specific FreeBSD version branch. You can't install a package compiled on and for FreeBSD 12 on a FreeBSD 11 kernel (and vice-versa). Doing so will break things due to the different versions of shared libraries. So the version of pfSense installed on your firewall determines which "branch" of the pfSense packages repository your firewall looks at to see if new package versions are available. So if your firewall is not running the most recent version of pfSense, you won't necessarily see the most recent version of the packages listed. But there are some exceptions to that, especially when a new pfSense version is posted. To prevent breaking things, never upgrade or install a new package when a pfSense update is showing (for example, when the Dashboard check shows a newer version of pfSense is available). Always update pfSense to the most current version before installing or upgrading any packages.

Found what appears to be a solution for this issue. Not 100% sure why it happens, though. What little bit I found on Google suggests is may just be a peculiarity with FreeBSD and exactly how sockets are addressed. The problem resolved in my test virtual machine when I changed the IPv6 gateway from "Automatic" to "None". I have IPv6 disabled on the WAN interface of the VM I was testing with. You can try checking the setting on your firewall to see if changing it helps you. The setting is under SYSTEM > ROUTING from the pfSense menu. Here is a screenshot: [image: 1633635455590-pfsense_default_gateways.png] The default value for the IPVv6 gateway was initially set for "Automatic", and that resulted in the SC_ERR_LIBNET_WRITE_FAILED error. Changing the value to "None" in the drop-down selector eliminated the error for me. As I said, on this firewall the IPv6 address for the WAN is configured for "None".

@beachbum2021 How did you solve the problem ?

@dule said in Snort 4.1.4_3 -- Snort Inline mode crashes WAN interfaces: @bmeeks Thank you for your responses. I turned off Inline mode and looks like firewall works good. I faced one more problem with IPSec for mobile client but I managed to fix it. What do you think should I leave offloads disabled or should I revert that configuration and enable offloads once again? [image: 1633507592316-1d320990-26e7-49e0-aa11-8942dd583131-image-resized.png] I'm not sure that I need it anymore since I'll keep using legacy mode? I do not know how these offloads work in depth so probably thats the reason I'm confused When using either of the two IDS/IPS packages, whether with Inline IPS Mode or with Legacy Blocking Mode, you should leave all hardware offloads disabled. With today's highspeed CPUs, there is very little impact from letting the software stack handle those chores. The problem with hardware offloading being enabled is that the NIC then sends "weird" and somewhat non-standard packets through. And those weird packets can trip up and fool the IDS/IPS. Some forms of hardware offloading can also result in packets completely bypassing the IDS/IPS engine altogether, thus those packets are not even inspected by the engine.

@jasonau as bmeeks says, the eve json log lines are usually too long for the default freebsd syslog (because of its adherence to RFC5424). That restriction cannot be changed without recompiling. You can instead write the eve logs to file, and forward that to your logstash instance using syslog-ng (pfsense package). In suricata settings, set log eve json to file. For the elastic side, you might be interested in the pfelk project which includes a logstash pipeline configuration and templates for suricata.

Yes, that is a common PHP error when attempting to load and read very large log files. PHP must load the entire file contents into memory, then stream that memory data out to your browser. There is a limited amount of system memory allocated to the PHP process, thus when it tries to open a very large file it will exhaust the memory reserved for PHP processes. You can view the file from the CLI using something like the vi editor, or you can use various forms of sftp to connect and grab the file. One of my favorite tools for this kind of stuff is WinSCP.

@le_bleu said in Suricata blocks internal IP despite beeing on the passlist AND no alerts in logs: @bmeeks The setting "Remove Blocked Hosts Interval" is set to "1hour" but suricata is configure in INLINE mode so the setting is not use if I understand well. My suricata configuration runs well since at least 6month without issue. The ALERTS tab is not empty I can see some log of past 24Hours but when trafic is block nothing is listed about this block. Oh, well you used the word "block" so I assumed you were using Legacy Mode. You are correct the BLOCKS tab is irrelevant when using Inline IPS Mode. And so is the "Remove Blocked Hosts Interval" setting. There is an issue, I believe, in the Suricata binary itself where it can drop traffic without logging an alert for it. Seems I remember seeing a bug report on the Suricata Redmine site about that. Hopefully that will be addressed in the upcoming 7.0 Suricata release set for later this year.

@xm4rcell0x said in Snort-3 release: @bmeeks another dumb question (sorry that's only an hobby....and i have to thanks you and this forum for all I know ) You say hardware VLAN tagging... But I don't think I have enabled it. I only have vlans configured into pfSense's interfaces tab...that's only a "software VLAN tagging" right? Some NICs have the feature and enable it by default. Here is a link to some pfSense documentation about that: https://docs.netgate.com/pfsense/en/latest/vlan/index.html. And here is a post from the forum discussing how to disable it on igb cards: https://forum.netgate.com/topic/158898/disable-hardware-level-vlan-filtering-on-igb-network-card. One thing to be aware of, though, is that the NIC driver name in FreeBSD is sort of generic in that the driver may cover a number of slightly different variations of the same basic hardware. Not all igb cards are absolutely identical.

@nicesub said in Suricata modifying rules: @bmeeks Thank you for your reply. Given that I run my Suricata on Hyper-V server I was wondering how Inline mode would work given its hardware/driver requirements? That virtual NIC is not supported for native-mode netmap, so Inline IPS is not possible. You should instead use the Legacy Blocking Mode and choose to enable the "Block on DROP Only" option, then proceed configuring rules as you would if you were using Inline IPS Mode.

@sysadmin_on_call I am using pcap length of 1522

@wmarnold1 said in Teams client use of STUN blocks MicroSoft ~ Supressed?: I read somewhere that pfSense on BSD doesn't understand the distinction between ALERT and DROP records, so, it blocks both. I like considering Emerging Threats, for the most part Let me set the record straight there. I think some information has gotten a bit confused as it moved around the web ... . IDS/IPS "blocking" is handled by either the Snort or Suricata add-on package when using pfSense. Each package offers two quite distinct blocking modes: Legacy Blocking Mode and Inline IPS Mode. There is quite a long Sticky Post at the top of this sub-forum describing the Inline IPS Mode for Snort. As part of that description, the post goes into the differences between Legacy Mode and Inline IPS Mode blocking. Here is a link: https://forum.netgate.com/topic/143812/snort-package-4-0-inline-ips-mode-introduction-and-configuration-instructions. When using Snort with Inline IPS Mode, you most certainly can mix and match rule actions such as ALERT and DROP. Rules with the ALERT action will only generate alert log entries and not block any traffic. Rules with the DROP action will generate alert log entries AND drop the offending packet(s) -- in effect "blocking" that traffic. When using Snort in Legacy Mode Blocking, any alert results in a block because the custom blocking module will insert the IP addresses pulled from alerts into the pf (packet filter) table snort2c. And any IP address inserted into that table is blocked by the firewall using a built-in hidden rule created by pfSense at boot up. Suricata works pretty much the same way, but it does offer one other option with Legacy Mode Blocking. It offers the option to "block on DROP only". That means only rules whose action is DROP will result in the IP addresses getting inserted into the snort2c table for blocking (Suricata uses the same built-in table that Snort uses).

@cool_corona said in Suricata Inline vs legacy performance.: Inline performance [image: 1632280060926-5518cada-5472-4088-8cae-3f837598e668-billede.png] Legacy performance [image: 1632280441403-8fe30928-fd59-4250-b7cd-517a3c2ea920-billede.png] Significant difference in performance!! Way back, there were no images. There was only text : Like [image: 1632296020793-c94ea720-e2cd-435a-a578-8e4d7e6222b0-image.png] Image => Words => answer ! edit : click on the image.

@gertjan @bmeeks Thanks. I reduced the value to half size from default and I will grab using SFTP. cheers

Thanks to those who've offered real help. It wasn't that difficult once I understood the issues. It turns out I was just enabling too many of the rules, and thus getting shut down. In the end, I found a site that had explanations of the key groups to block, and all is well. I'm surprised there are so few well described "how tos" for non networking guys, but there you have it.

@umm12 said in anomaly traffic detection in suricata: how i can use and configure suricata as Anomaly Traffic Detection IDS/IPS? The problem is there no standard anomaly traffic... what might be anomaly traffic to you might also be okay traffic for me. In other words, you have to define anomaly traffic for your network as the network administrator. So, I'll share this thread that has helped me and others setting up Suricata with a warning that it's a very long thread: https://forum.netgate.com/topic/70170/taming-the-beasts-aka-suricata-blueprint?_=1632087648731 Good Luck.

Thanks for adding the Netmap thread parameter on the latest release, I can confirm that I'm still limited to 1Gbps with auto, putting 2 fixes the bandwidth issue

@mikej47 said in SNORT gone after Pfsense update: @bmeeks that is great news. I can just upgrade to that version and the patch is built in. What is Pfsense + ? How do I get the + version? pfSense+ is the new name for the old "Factory Edition" of pfSense that comes on Netgate appliances. When you upgrade to the latest 21.05.1 version, pfSense+ is what that will be.

You will need to change the port (where specified) in the individual rules you have enabled. Using a modifysid.conf file on the SID MGMT tab is the best way to do this. The SID MGMT feature uses Perl regex. There are some examples of the syntax in the various *-sample.conf files included on the tab. There is no pre-defined RDP Port variable in the standard configuration. You could certainly define one, but still you would need to modify the appropriate rules in order to have them reference it.