Suricata 6.0.10_1 Update for pfSense Plus 23.01 - Release Notes
-
An update for the Suricata package has been posted for the pfSense Plus 23.01 RELEASE branch. This latest update contains two important fixes. One improves the performance of the Pass List logic, and the other change improves Inline IPS Mode performance with the netmap device.
Pass List Improvements:
For quite some time there have been two different Pass Lists used by Suricata when operating in Legacy Blocking Mode. This mode uses a custom output plugin compiled into the binary and used exclusively on pfSense. Pass Lists are text files containing IP addresses and/or networks that should never be blocked by the plugin. One of the Pass Lists used by the plugin is the one configured by the user. This can be either a default list generated by the system or a custom list provided by the user and created on the PASS LIST tab. The other Pass List is actually hidden from view and is generated automatically by the custom output plugin at runtime. This internal list is populated with all the interface IP addresses (using a /32 mask) present on the firewall. These interface addresses are obtained by calling into the operating system and iterating the configured interfaces. Additionally, once Suricata starts, an independent internal thread is launched which subscribes to a kernel routing socket and listens continuously for updates to any interface IP advertised by the OS kernel. In this manner the internal hidden interface IP pass list is automatically updated as firewall interfaces change. You can see this interface IP address monitoring thread log its actions in thesuricata.log
for the Suricata interface (viewable under the LOGS VIEW tab by selecting an interface and then thesuricata.log
entry).In the past, this internal interface monitoring thread and the user-supplied Pass List were both adding firewall interface IPs to the Radix Tree structure that stores, and then looks up later, IP addresses and networks. This duplicating of entries was a potential trouble spot in the Radix Tree. Additionally, when adding user-supplied IP addresses and networks, no test was done to see if the entry being added duplicated an existing entry (or was covered by an existing entry). This behavior risked causing issues in the Radix Tree when later looking up an IP address to see if it was covered by the Pass List. So, the Pass List logic in the custom output plugin has been altered a bit to address these potential trouble spots. As a result of the changes, you will notice that firewall interface IP addresses (those /32 values) are no longer pulled into the user-supplied pass list. Instead, those are pulled into the internal list by the interface IP monitoring thread. Another visible change shows up in the
suricata.log
. Now, when parsing a user-supplied Pass List, if an entry read from the list either already exists in the Radix Tree or lies within a previously added subnet in the Radix Tree, that entry is not added since it would represent a duplicate entry. A summary of the Pass List processing is printed in thesuricata.log
if you want to check out the results. Remember that a Pass List is only used with Legacy Blocking Mode. Inline IPS Mode does not need, and thus does not generate nor use, a Pass List.Inline IPS Mode Improvements:
Inline IPS Mode uses the netmap kernel device to implement the ability to selectively drop packets. This mode uses netmap to establish a sort of pipe between the physical NIC driver and the kernel's network stack (also called the host stack). Suricata's analysis engine sits in the middle of that pipe. It reads packets from one end of the pipe, analyzes them, and then either forwards them on to the other end of the pipe or drops them if the packet triggered a DROP rule. Dropped packets are considered as "blocked". In IPS mode, two netmap pipes are created. One receives from the NIC and transmits to the host stack, and the other receives from the host stack and transmits to the NIC. The host stack end of a netmap connection is denoted by appending a caret ( '^' ) to the interface name. So a typical interface pair would beem0
andemo^
. The two netmap connections created for IPS mode would look like this assumingem0
was the chosen interface:em0 --> em0^ em0 <-- em0^
Suricata offers three threading run modes, but only two are useful for production use. The
single
thread mode is really only for development and testing purposes. The two modes used in production operation areautofp
andworkers
. The default mode on pfSense has beenautofp
since Suricata was first added as a package. However, some time back the ability to choose either of the three available run modes was added to the INTERFACE SETTINGS tab in the Performance and Detection Engine Settings section. See the example below.Details on the available run modes and their corresponding threading models can be found here: https://suricata.readthedocs.io/en/suricata-6.0.0/performance/runmodes.html. For Inline IPS Mode operation, the
workers
run mode is likely to offer the highest throughput performance. But feel free to experiment to see which offers better performance with your particular setup. The efficiency gain ofworkers
really shines when your hardware or virtual NIC exposes multiple TX/RX queues. But if your NIC only exposes a single pair of TX/RX queues, then it may be a toss-up which mode offers the best throughput performance. You can examine the output in thedmesg.boot
log in/var/log
on the firewall to see the configuration seen and logged by netmap. Here is an example fromdmesg.boot
pulled off one of my pfSense virtual machines using thevmx
virtual NIC:vmx0: netmap queues/slots: TX 4/512, RX 4/512
This indicates the adapter is exposing four TX and four RX queues with 512 slots in each queue. The slots are data buffers on the netmap ring. Queues map to netmap rings, so for this
vmx
virtual adaptor netmap will create four TX rings and four RX rings (as four TX/RX ring pairs) with each ring containing 512 slots to hold the packet data.But from the same firewall using a different interface with the
em
virtual NIC driver, notice only a single queue pair is exposed resulting in netmap creating only a single TX/RX ring pair (with the rings having 1024 slots for data):em1: netmap queues/slots: TX 1/1024, RX 1/1024
Some high performance hardware NICs may have eight or even more TX/RX queues. Higher queue counts translate into greater potential throughput. Suricata, when using netmap IPS mode with run mode
workers
, will launch a distinct processing thread for each exposed NIC queue. This maximizes performance. So, if you are using Inline IPS Mode with Suricata, experiment with changing the Run Mode setting on the INTERFACE SETTINGS tab to see if you gain throughput increases. Remember to save after making a change to the Run Mode, and then restart Suricata on the interface so it will recognize the change. Run Mode changes are NOT dynamic! The run mode is set at daemon startup only.Potential Startup Failure:
If, after updating to the latest 6.0.10 version of the Suricata binary you find that Suricata fails to start, examine thesuricata.log
for the interface looking for any lines similar to this:21/2/2023 -- 20:14:32 - <Error> -- [ERRCODE: SC_ERR_MEM_ALLOC(1)] - failed to setup/expand stream session pool. Expand stream.memcap?
This error indicates you need to expand the TCP Stream Memcap value on the FLOW/STREAM tab for the interface. The default is 128 MB, but that may not be enough when using high thread counts with multiple CPU cores. Try 256 MB, then keep increasing in 32 or 64 MB chunks until Suricata starts successfully. If your firewall is really tight on free RAM, you can try increasing the value from 128 MB in 32 MB chunks until you get to the minimum amount required.
-
-
-
One issue I found yesterday.
Given the user updates the Suricata package from 6.0.8 to 6.0.10_1.
And the configuration is migrated to the new version for 2 interfaces WAN and LAN.
Then the user is presented with 2 WAN interfaces.Also the user cannot change one of the interfaces back to LAN.
Hope this helps.
-
@nrgia said in Suricata 6.0.10_1 Update for pfSense Plus 23.01 - Release Notes:
Also the user cannot change one of the interfaces back to LAN.
Is the instance actually running on the WAN, or did the text in the Description field on the INTERFACE SETTINGS tab just change? If the latter, you should be table to type LAN in the textbox and save the update.
I never saw this behavior in my testing, but I seem to recall one user reporting it during the 2.7 DEVEL snapshot testing. I think his fixed itself with a reboot of the firewall.
-
@bmeeks Both interfaces were down before the update request. The WAN configuration was duplicated to a duplicated WAN, and the configuration for the LAN was not displayed in the Settings menu. And yes in the settings menu it shows 2x WANs both as naming and the configuration.
I will try with a reboot after a few hours and let you know, I'm using the connection for the moment.
-
@nrgia said in Suricata 6.0.10_1 Update for pfSense Plus 23.01 - Release Notes:
@bmeeks Both interfaces were down before the update request. The WAN configuration was duplicated to a duplicated WAN, and the configuration for the LAN was not displayed in the Settings menu. And yes in the settings menu it shows 2x WANs both as naming and the configuration.
I will try with a reboot after a few hours and let you know, I'm using the connection for the moment.
Why were the interfaces down? How did the firewall connect to Netgate servers to pull down the update? Just trying to figure out the scenario for reproducing the problem.
And if it is working okay now, how did you fix it? Or do you mean it's running without Suricata on the interfaces?
P.S. -- you might also try simply removing the Suricata package and then reinstalling it. Now that I think more about it, that may be what the user did that had the problem during the DEVEL snapshot testing.
-
@bmeeks Sorry, I meant I disabled Suricata on both interfaces before starting the update process.
Also i removed Suricata package and reinstalled it.
-
@nrgia said in Suricata 6.0.10_1 Update for pfSense Plus 23.01 - Release Notes:
@bmeeks Sorry, I meant I disabled Suricata on both interfaces before starting the update process.
Also i removed Suricata package and reinstalled it.
Okay... that makes more sense . I was confused there for a moment. This issue has not affected everyone (at least so far as I know), and I have not seen it during my development snapshot tests. Is pfSense (and FreeBSD itself) reporting the physical NIC interfaces with exactly the same name as before?
-
@nrgia:
Suricata uses the interface names as the "keys" when storing interface configuration. So if you examine the Suricata section ofconfig.xml
you should see sections under the <rules> element for <wan> and <lan> with each section containing all the configuration settings for that interface.Do you see that in
config.xml
, or do you see two <wan> sections? You can view the file under DIAGNOSTICS > EDIT FILE, then browse to/conf/
and openconfig.xml
.I am struggling to come up with a theory that describes what happened. Since it has apparently occurred twice to two different users, but not all users, something unique in a setup would seem to be the trigger.
As an example, here is part of the
config.xml
file from my test virtual machine showing the <rule> sections for WAN and LAN. Scroll down towards the bottom of theconfig.xml
file and find the <suricata> section like this one:<suricata> <config>
... then continue scrolling down until you find the first <rule> tag like this one:
<rule> <interface>wan</interface> <enable>on</enable> <uuid>14777</uuid> <descr><![CDATA[WAN]]></descr>
and then farther down ...
<rule> <interface>lan</interface> <enable>on</enable> <uuid>22480</uuid> <descr><![CDATA[LAN]]></descr>
I am curious what shows in these sections of your
config.xml
file. That might help me troubleshoot if you can share it. Just these subparts. Don't post the entire file as some potentially sensitive info is also stored in the file. -
@nrgia I do have a very similar issue.
On version 6.0.8_7 I have the following interfaces configured:
But after upgrading to 6.0.8_8 or 6.0.10_1 my WAN configuration (including its custom rules) have got deleted and I have duplicate LAN1 configurations, see:
For me there is no obvious way to get my WAN configuration back, besides rolling back to the previous version via boot environments.
EDIT:
I have already unsuccessfully tried the following:- Rebooting the firewall
- Removing suricata package and reinstalling version 6.0.10_1
- Restoring a backup of the config.xml file
-
@greenflash said in Suricata 6.0.10_1 Update for pfSense Plus 23.01 - Release Notes:
For me there is no obvious way to get my WAN configuration back, besides rolling back to the previous version via boot environments.
For me it was easier, because before the update, I disabled Suricata on both interfaces, so an entry in the Configuration history was added. I just clicked on revert to that point, and I have both of the interfaces again. Sure if I reinstall the package the same happens, doubled interfaces.
Maybe you can find something in Diagnostics>Backup & RestoreConfig> History
-
@bmeeks pfSense or other menus like Interface assignments reports the correct interface mappings. So only in Suricata I have issues. I will reinstall again, in order to trigger the problem again, and will respond to the rest of the questions shortly.
-
@bmeeks said in Suricata 6.0.10_1 Update for pfSense Plus 23.01 - Release Notes:
@nrgia:
Suricata uses the interface names as the "keys" when storing interface configuration. So if you examine the Suricata section ofconfig.xml
you should see sections under the <rules> element for <wan> and <lan> with each section containing all the configuration settings for that interface.Do you see that in
config.xml
, or do you see two <wan> sections? You can view the file under DIAGNOSTICS > EDIT FILE, then browse to/conf/
and openconfig.xml
.I am struggling to come up with a theory that describes what happened. Since it has apparently occurred twice to two different users, but not all users, something unique in a setup would seem to be the trigger.
As an example, here is part of the
config.xml
file from my test virtual machine showing the <rule> sections for WAN and LAN. Scroll down towards the bottom of theconfig.xml
file and find the <suricata> section like this one:<suricata> <config>
... then continue scrolling down until you find the first <rule> tag like this one:
<rule> <interface>wan</interface> <enable>on</enable> <uuid>14777</uuid> <descr><![CDATA[WAN]]></descr>
and then farther down ...
<rule> <interface>lan</interface> <enable>on</enable> <uuid>22480</uuid> <descr><![CDATA[LAN]]></descr>
I am curious what shows in these sections of your
config.xml
file. That might help me troubleshoot if you can share it. Just these subparts. Don't post the entire file as some potentially sensitive info is also stored in the file.This is what I see in the config.xml :
<rule> <interface>wan</interface> <enable>off</enable> <uuid>27404</uuid> <descr><![CDATA[WAN]]></descr>
and
<rule> <interface>wan</interface> <enable>off</enable> <uuid>27404</uuid> <descr><![CDATA[WAN]]></descr>
Also the configuration is 100 % for both interfaces, rules, etc.
If I enable Suricata on both WANs from the GUI only one instance of Suricata will start:
Also this is from the config.xml previous to updating:
<rule> <interface>wan</interface> <enable>on</enable> <uuid>27404</uuid> <descr><![CDATA[WAN]]></descr>
and
<rule> <interface>lan</interface> <enable>on</enable> <uuid>42440</uuid> <descr><![CDATA[LAN]]></descr>
I have both configs saved now, if you need more sections of them, I'm glad to help.
-
@NRgia:
Yeah, that first capture from yourconfig.xml
is definitely not correct. The entire interface appears duplicated. Notice the UUID also is the same.Not sure what is happening there. I will need to do some experimentation and hack up a config on my test VM to see if I can replicate your issue.
Your second screenshot from the previous configuration looks correct, so the revert to previous configuration works.
-
@bmeeks said in Suricata 6.0.10_1 Update for pfSense Plus 23.01 - Release Notes:
@NRgia:
Yeah, that first capture from yourconfig.xml
is definitely not correct. The entire interface appears duplicated. Notice the UUID also is the same.Not sure what is happening there. I will need to do some experimentation and hack up a config on my test VM to see if I can replicate your issue.
Your second screenshot from the previous configuration looks correct, so the revert to previous configuration works.
Correct, if I revert to a previous config the issue is not present. It's doing something in the conversion step I think, during the update/install. Sorry to bring this up, in this thread.
-
@nrgia said in Suricata 6.0.10_1 Update for pfSense Plus 23.01 - Release Notes:
Correct, if I revert to a previous config the issue is not present. It's doing something in the conversion step I think, during the update/install. Sorry to bring this up, in this thread.
No problem with the thread topic: this is as good a place as any to figure it out. Thank you for letting me know.
Your guess matches mine that something happens in the "migrate existing configuration" part of the install steps. Give me a bit to run some scenarios around in my head, and then test them. There were many PHP changes required in the package in order to become compatible with the new PHP 8.1 included in 23.01 pfSense Plus and the upcoming 2.7 CE. One of those changes could have easily broken something my testing failed to uncover.
You have a workaround by reverting to the older config section, so that gets you running. Anything I find will have to go into a new package update.
-
@bmeeks said in Suricata 6.0.10_1 Update for pfSense Plus 23.01 - Release Notes:
@nrgia said in Suricata 6.0.10_1 Update for pfSense Plus 23.01 - Release Notes:
Correct, if I revert to a previous config the issue is not present. It's doing something in the conversion step I think, during the update/install. Sorry to bring this up, in this thread.
No problem with the thread topic: this is as good a place as any to figure it out. Thank you for letting me know.
Your guess matches mine that something happens in the "migrate existing configuration" part of the install steps. Give me a bit to run some scenarios around in my head, and then test them. There were many PHP changes required in the package in order to become compatible with the new PHP 8.1 included in 23.01 pfSense Plus and the upcoming 2.7 CE.
You have a workaround by reverting to the older config section, so that gets you running. Anything I find will have to go into a new package update.
Sure Bill take your time, it's not a blocker for me.
-
I have a similar issue. My WAN interfaces is duplicated, (the LAN interface disappeared) and are showing as stopped in the Suricata overview page. However, I can see the alerts tab being populated for both WAN interfaces.
Would it be sufficient for me to change one of the interfaces back to LAN to fix this or should I be wary of something?
-
@returntrip said in Suricata 6.0.10_1 Update for pfSense Plus 23.01 - Release Notes:
I have a similar issue. My WAN interfaces is duplicated, (the LAN interface disappeared) and are showing as stopped in the Suricata overview page. However, I can see the alerts tab being populated for both WAN interfaces.
Would it be sufficient for me to change one of the interfaces back to LAN to fix this or should I be wary of something?
Thanks for the report. It's apparent something is wrong in the config migration code that runs when an updated package is installed. I never saw this in my virtual machine testing, but it could simply be because I never hit the right conditions. I have a theory on what may be happening, but I would like to reproduce it so that I can make sure my theory is correct. Will work on that today. I am pretty sure it's a PHP 8.1 thing. The move to 8.1 brought a lot of required changes in existing PHP code with it.
Anything I find will have to go into the next package update, and if my theory is correct, those of you impacted will need to either selectively restore/edit your
config.xml
from prior to the Suricata upgrade, or else recreate the missing interface from scratch. I suspect it has been permanently overwritten in your currentconfig.xml
. -
@returntrip said in Suricata 6.0.10_1 Update for pfSense Plus 23.01 - Release Notes:
are showing as stopped in the Suricata overview page. However, I can see the alerts tab being populated for both WAN interfaces.
You probably have a zombie process. Killing all the Suricata processes, or rebooting, should clear it.
Why have it on WAN and LAN? On WAN it will scan all packets before hitting the firewall so will waste time processing packets that will drop.
-
@bmeeks You can try another scenario. Install pfSense CE 2.6.0, install Suricata, and then upgrade until you reach 23.01. You have more config migrations with this approach. I have my config created a few versions back.
-
@nrgia said in Suricata 6.0.10_1 Update for pfSense Plus 23.01 - Release Notes:
@bmeeks You can try another scenario. Install pfSense CE 2.6.0, install Suricata, and then upgrade until you reach 23.01. You have more config migrations with this approach.
That's sort of what I'm doing, but using just the
config.xml
file and importing/restoring an older one. I don't actually have any pfSense Plus testing VMs. I'm using 2.7.0 for that now as 23.01 and 2.7.0 are pretty much the same at the moment.I do so much destroying and recreating the test VMs that having to upgrade each one to Plus each time would be a hassle.
-
@bmeeks said in Suricata 6.0.10_1 Update for pfSense Plus 23.01 - Release Notes:
@nrgia said in Suricata 6.0.10_1 Update for pfSense Plus 23.01 - Release Notes:
@bmeeks You can try another scenario. Install pfSense CE 2.6.0, install Suricata, and then upgrade until you reach 23.01. You have more config migrations with this approach.
That's sort of what I'm doing, but using just the
config.xml
file and importing/restoring an older one. I don't actually have any pfSense Plus testing VMs. I'm using 2.7.0 for that now as 23.01 and 2.7.0 are pretty much the same at the moment.I do so much destroying and recreating the test VMs that having to upgrade each one to Plus each time would be a hassle.
I feel you, we, the users with whiteboxes tend to test less due to this cumbersome upgrade path, instead of simple installer images.
-
@steveits If am reading your reply correctly, the best practice is to run suricata only on the LAN interface then?
-
@returntrip Yep. No need to scan packets twice, no need to scan packets that will be dropped by the firewall, and on LAN the alert will show the LAN IP not the NATted IP of the router WAN.
I suppose there's an argument to use WAN if one has lots of internal interfaces and limited memory...?
-
@returntrip said in Suricata 6.0.10_1 Update for pfSense Plus 23.01 - Release Notes:
@steveits If am reading your reply correctly, the best practice is to run suricata only on the LAN interface then?
Suricata sits in front of the firewall no matter which interface it is configured on. Packets inbound on an interface (meaning coming from the NIC on the their way into pfSense) encounter Suricata first. That means when you run Suricata on the WAN it is going to see and analyze all the Internet noise that exists there. And most, if not all, of that noise traffic is not allowed through the firewall, so why waste CPU resources and RAM having Suricata scan that Internet noise the firewall rules are probably going to drop anyway?
Better to run IDS/IPS instances on the internal interfaces such as LAN or DMZ and others. As @SteveITS mentioned, about the only time running Suricata on the WAN would make sense is if you have a large number of internal interfaces, but limited RAM and/or CPU. In that case running a single instance on the WAN might make sense due to the resource constraints.
Besides the NAT issue mentioned, another problem with running it on the WAN is all that Internet noise is going to generate a lot of logging data and eat up local disk space. Again, this is because no firewall rules have been applied at the point Suricata is seeing the interface traffic. Putting the instance on an internal interface lets the firewall do the initial traffic filtering, and then Suricata only looks at traffic the firewall allowed, cutting down on useless alerts and what gets logged.
-
Many thanks @bmeeks your reply is really clear and I now understand the reasoning behind WAN vs LAN only monitoring. I have 4 internal interfaces I want to screen so maybe I could monitor only the WAN interface then but then I would not know what internal IP am alert is generated for. Is there any way to overcome this "drawback" , besides monitoring every single internal interface?
-
@returntrip said in Suricata 6.0.10_1 Update for pfSense Plus 23.01 - Release Notes:
Many thanks @bmeeks your reply is really clear and I now understand the reasoning behind WAN vs LAN only monitoring. I have 4 internal interfaces I want to screen so maybe I could monitor only the WAN interface then but then I would not know what internal IP am alert is generated for. Is there any way to overcome this "drawback" , besides monitoring every single internal interface?
No, unless you want to run the same rules for all the interfaces and they happen to be VLANs. In that case, you could put Suricata on the physical parent interface and it would see the traffic for all VLANs defined on that parent. But that does require that you want the same rules for all the internal networks (or at least all the VLANs defined on that parent).
But also consider carefully tuning the rules you have enabled on interfaces. Customize the rules for the vulnerabilities on that network. Most folks tend to enable way more rules than they actually require. The less rules Suricata has to work through, the smaller the drain on CPU resources and RAM.
-
@bmeeks very nteresting. Am running pfsense as a router on a stick with only 1 physical interface which provides 1 vlan for wan and 4 vlans for internal..... so I guess it would be much easier for me to monitor the parent interface for everything. I do not think I would need separate rules per IF.
-
@returntrip said in Suricata 6.0.10_1 Update for pfSense Plus 23.01 - Release Notes:
@bmeeks very nteresting. Am running pfsense as a router on a stick with only 1 physical interface which provides 1 vlan for wan and 4 vlans for internal..... so I guess it would be much easier for me to monitor the parent interface for everything. I do not think I would need separate rules per IF.
Well, in your case with everything on one physical interface, you gain nothing.
Suricata runs the interface in promiscuous mode anyway. So there is no real advantage to changing anything in your case.
But that is not the most secure setup. Having WAN and LAN mixed at Layer 2 is not a good idea in my view.
-
@bmeeks I hate this setup, but I have some limitation due to HW I use for pfSense and cabling. I need to get my ISP NTU moved next to my pfsense. At the moment I have three switches between the NTU and FW.... Here is my setup in case you want to get depressed:
https://forum.netgate.com/topic/138244/2-switches-between-router-on-a-stick-and-modem?_=1677266087572
The only difference is that the switch attached to the NTU is a Cisco 2960G IIRC.
So would it be sufficient to monitor only the LAN VLAN IF and all would be covered?
-
@returntrip said in Suricata 6.0.10_1 Update for pfSense Plus 23.01 - Release Notes:
@bmeeks I hate this setup, but I have some limitation due to HW I use for pfSense and cabling. I need to get my ISP NTU moved next to my pfsense. At the moment I have three switches between the NTU and FW.... Here is my setup in case you want to get depressed:
https://forum.netgate.com/topic/138244/2-switches-between-router-on-a-stick-and-modem?_=1677266087572
The only difference is that the switch attached to the NTU is a Cisco 2960G IIRC.
So would it be sufficient to monitor only the LAN VLAN IF and all would be covered?
Yes, monitoring the LAN would actually cover all the networks on that parent. Suricata will place the physical interface in promiscuous mode when it starts, and thus will see all the traffic traversing the parent.
-
-
@darcey said in Suricata 6.0.10_1 Update for pfSense Plus 23.01 - Release Notes:
@bmeeks Will 6.0.10 be made available for pfSenseCE 2.6?
I believe the changes that might help with this were introduced in suricata 6.0.8.Suricata issue 4421.
Akismet did not allow me to post two links in one post. -
Regarding using Suricata on WAN, correct me if I am wrong but one reason to do so is if you want it to inspect traffic when using a public facing instance of HAProxy.
-
@darcey said in Suricata 6.0.10_1 Update for pfSense Plus 23.01 - Release Notes:
@bmeeks Will 6.0.10 be made available for pfSenseCE 2.6?
I believe the changes that might help with this were introduced in suricata 6.0.8.Yes, later versions of Suricata have addressed the high idle CPU usage by reverting an earlier change in the flow manager code.
As for getting a newer version of Suricata in pfSense 2.6.0, I will have to investigate to see what's feasible. Depends to some degree on what, if any, shared dependency library minimum version numbers might have changed in Suricata.
I would love to get Suricata updated in the 2.6 CE branch, but backporting the GUI code is a large task as the change in PHP from 7.4 in pfSense 2.6 to 8.1 in pfSense 2.7 CE and 23.01 Plus resulted in wholesale rewriting of large chunks of code. And those rewrites are not directly compatible with PHP 7.4.
If 2.7 CE rapidly advances through testing from the current BETA phase to RELEASE, then updating Suricata will be a non-issue as the package is current in the 2.7 snapshots. But if 2.7 CE development gets significantly delayed on the way from BETA to RELEASE, then updating of some packages in 2.6 CE may need revisiting. There is a possible solution to the PHP problem by creating a specialized compatibility module of functions to accomplish in 7.4 what is happening in 8.1.
-
@lawrencesystems said in Suricata 6.0.10_1 Update for pfSense Plus 23.01 - Release Notes:
Regarding using Suricata on WAN, correct me if I am wrong but one reason to do so is if you want it to inspect traffic when using a public facing instance of HAProxy.
Yes, there are certainly instances where running Suricata or Snort on the WAN may make sense for a particular network configuration. But this is more likely to be the case for pfSense used in a business network as opposed to a home network.
I would venture it to be very rare to need a Suricata or Snort instance running on the WAN in the typical home network. I won't say "never", but I would say "very rare" .
-
@bmeeks Thanks. That would seem not worth it then. Looking forward to CE 2.7...
-
Hi @bmeeks ,
I am afraid the Pass List improvements broke things here. I am using legacy mode. I have long had the trouble that /24 networks did not work in the pass list so on top of the /24 I put specific /32 IPs in the pass list for important machines.
While conducting tests I can reproducibly block my laptop even though it is part of the /24 network and the pass list has this specific IP in it as well. At least the latter worked up until this upgrade.
The correct pass list is enabled in the settings. And via "View" I can confirm that both the home network /24 and my laptops /32 is in it.
Running 23.01.
-
@j-koopmann:
Will you please share that Pass List? I would like to reproduce the conditions in my test virtual environment as best I can.I have never been able, for some reason, to reproduce this issue of Pass List entries not working. They always work in my testing .
-
@bmeeks Can we retest the issue for doubled interfaces with 6.0.10_3 version, or you're stil working on another fix?