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.

@valir "No"...you need to configure it, enable rulesets, etc. There is a wizard that runs when adding an interface (suggest adding LAN, as WAN will look at packets that will end up being blocked by the firewall). There is a choice to block or not...suggest not blocking for a while and watching the Alerts tab to see what will be blocked. Also, it may be best to start in the default Legacy mode as there are a variety of small issues with Inline mode for instance depending on the NICs. You may want to add your IP to a Pass list so you're not blocked.

I assume you mean when you specify a complete IP address with the mask. If specifying a complete individual IP, the mask is not required, so just drop it and use the x.x.x.x variation. If you want to pass the entire subnet, then use x.x.x.0/24, and that should work.