6100 SLOW in comparison to Protectli FW6E
-
@stephenw10 Problem is: I HAVE open ports and therefore was running on WAN.
After further tests changing to LAN doesn't help. Speed is reduced the same. ONLY disabling completely "fixes" this.And I come to the conclusion that I was a LOT better served by the Protectli!
This CPU is to slow. 6100 I thought was good. It isn't!
-
It's surprising how much load Suricata is adding there. I imagine you must have a lot of signature lists loaded?
-
@stephenw10 Feodo Tracker Botnet C2 IP Rules
ABUSE.ch SSL Blacklist Rules
emerging-ciarmy.rules
emerging-compromised.rules
emerging-drop.rules
emerging-dshield.rules
emerging-malware.rules
emerging-mobile_malware.rules
emerging-phishing.rules
emerging-trojan.rules
emerging-worm.rulesAnd this:
-
@manilx said in 6100 SLOW in comparison to Protectli FW6E:
I HAVE open ports and therefore was running on WAN
For reference, having open ports is kind of irrelevant...the inbound packets would be scanned on the LAN side anyway, and dropped there so won't get to devices. See the comment in this post by the package maintainer, on putting IDS on LAN.
Also, Spamhaus DROP, etc. lists of IPs can be handled in firewall rules via pfBlockerNG(-devel) lists. DShield is in the ET_Block list there. That would pull the packet checking out of Suricata, might help a bit.
-
@steveits Thanks for all the info.
I have removed rules I had in pfblockedng, put Suricata on the LAN side.
Helped and I'm now at 700+ but far from 920 without it.
I'm now wonderin if I should use it at all and if it really is needed (on LAN) to protect my open ports. -
@manilx Usually one can adjust the rulesets to only what they need, e.g. a web server doesn’t need SQL rules in front of it. Also encrypted traffic like HTTPS can’t be scanned, it just passes through.
-
@steveits What would you suggest to activate as rules for:
NFS
Plex
EmbyAppreciate your help.
-
If you are using Suricata with Inline IPS Mode, you may notice a throughput improvement by switching the Suricata runmode from "autofp" to "workers" on the INTERFACE SETTINGS tab.
The "workers" runmode can work better with netmap. The default runmode is "autofp" as that is a good general purpose starting point, but some configurations will benefit by switching to "workers". Any change you make to the runmode requires restarting Suricata on the interface before it is effective.
I am interested in what impact switching the runmode has for you, so please report back in this thread. "Workers" mode is best for multi-queue NICs.
Also, if you don't mind, please post the hardware specs (CPU type and speed, particularly) of the Protectli unit you had previously.
-
@bmeeks Did that change and it did a HUGE boost!
I had only snort rules with IPS balanced and policy and had 815 download. After changing this setting it maxed out at 935 which is near the maximum I get. I will again select more rules I had before and recheck the speed now.The Protectli was a FW6E – 6 Port Intel i7
Intel i7 8550U Quad Core with Hyperthreading (8 threads) at up to 4GHz (turbo boost)
Dual DDR4 memory up to 64GB
mSATA and/or 2.5″ solid state drive
6 Intel Gigabit Ethernet NIC ports
AES-NI -
@manilx I have reenabled the emerging-3coresec as a test.
Run speedtest and got full download speed of 930. Excellent!BUT in the middle of repeating that I lost access to the 6100, no ping. LED was blinking blue, normal.
Scary!
Powered it off by 5s press to power button. Got an orange LED.
Various tries to power it on by 5s press were uncuccessful. Pulled the power plug.
Turned on again.Repeated tests. 930 download.
-
@manilx After some more speedtests the unit died on me twice again! Completely unstable.
This setting kills it after a short while.
Rolling back to a zfs snapshot. -
@manilx:
What were the NICs in the Protectli?There are some open iflib issues with some of the Intel NICs in FreeBSD.
A little surprised workers mode locks up, but it does make me curious. On the Suricata Redmine site some OPNsense users have a similar issue, and OPNsense defaults to workers runmode. We have been trying to determine why.
Their issue is triggered by heavy traffic such as a speed test. Would be interested if you can just let it run a bit with normal traffic flow. Also make sure all hardware offloadings are disabled. That is very critical with inline IPS mode.
-
@bmeeks Protectli had Intel NIC's as I posted above.
Yes, it's definitely caused by heavy traffic. But I can't do more tests here. I NEED a stable system. I have nightly backups running from my company.
All hardware offloadings were/are disabled. -
@manilx said in 6100 SLOW in comparison to Protectli FW6E:
Protectli had Intel NIC's as I posted above.
Can you give me the exact model or else the specific FreeBSD driver being used? For example, em, igb, ix, etc.? All Intel NICs are not using the same driver in FreeBSD.
-
@manilx said in 6100 SLOW in comparison to Protectli FW6E:
Yes, it's definitely caused by heavy traffic.
Unfortunately, I don't have a test bed that seems able to reproduce the problem. Ditto for the upstream Suricata developer working on this same issue. And not even the OPNsense principal developer has been able to duplicate the stall/hang so far as I know. But there is a European user posting in the Suricata Redmine thread here that can reliably reproduce the problem. He is using a virtual environment, so virtual NIC drivers instead of actual hardware.
There is obviously an issue, but so far we have been unable to identify the cause so we can fix it. The first step is being able to reliably reproduce the stall/hang, and thus far that has not been done on a developer's machine .
-
@bmeeks https://eu.protectli.com/product/fw6e/
Interfaces were em0 and em1
This unit is a 6100. The freeze has got me panicked and I really can't afford it to loose connectivity "at random"
-
@bmeeks Perhaps netgate can provide you a 6100 for this. It's in their interest also as pfsense is only as good as the packages.....
-
@manilx said in 6100 SLOW in comparison to Protectli FW6E:
@bmeeks https://eu.protectli.com/product/fw6e/
Interfaces were em0 and em1
This unit is a 6100. The freeze has got me panicked and I really can't afford it to loose connectivity "at random"
Understand. My request was just "if possible", but I certainly appreciate the need for stability.
Some other questions, though, if you will answer them --
On the Protectli hardware, were you also using Inline IPS Mode and able to achieve essentially line-rate speed tests on the Gigabit link with Suricata running? I think that answer is "yes" from reading your posts in this thread, but I want to be sure.
And you say the Protectli Ethernet drivers were the
em
interfaces. That is potentially a valuable clue as like I said previously, there are some differences in the drivers that support Intel NIC families on FreeBSD.I have shared your experience in the Suricata Redmine issue thread I referenced earlier.
-
@bmeeks ANY questions you need!!!!
I used exactly the same config on the Protectli. I imported the config from there actually.
Inline IPS mode, with all ETopen rules activated and I got full 980 download speed. -
@manilx said in 6100 SLOW in comparison to Protectli FW6E:
@bmeeks ANY questions you need!!!!
I used exactly the same config on the Protectli. I imported the config from there actually.
Inline IPS mode, with all ETopen rules activated and I got full 980 download speed.Thanks. I will continue looking into this. There are three of us still looking at this issue: me, a Suricata developer, and from time to time the OPNsense principal developer. Whatever fix is found will be incorporated into Suricata upstream, so you can follow the Suricata Redmine Issue if you would like. It might also turn out to be something that needs fixing in FreeBSD itself. This actually seems most likely to me as no Suricata users on Linux have reported anything similar.