Bring pfsense/suricata to its knees and eventually die?? No reboot options/recovery available?
-
@Cool_Corona said in Bring pfsense/suricata to its knees and eventually die?? No reboot options/recovery available?:
And does Snort work multithreaded and inline??
No, Snort is not multithreaded, but that makes no meaningful difference until you hit 1 Gigabit/sec sustained. But it seems you do hit that barrier, so Snort would likely perform worse (but not by a whole lot).
However, Snort only supports Inline IPS Mode on pfSense-2.5 DEVEL because it needs changes to other subsystems that are currently only present in FreeBSD-12.1.
-
@Cool_Corona said in Bring pfsense/suricata to its knees and eventually die?? No reboot options/recovery available?:
And does Snort work multithreaded and inline??
Nope, Snort is no multi thread, Suricata Yes
-
@Cool_Corona said in Bring pfsense/suricata to its knees and eventually die?? No reboot options/recovery available?:
Its running in Vmware on igb driver (esxi) on a dual port Intel 82576 adapter.
So are you passing through the physical NIC to the pfSense virtual machine, or is your virtual machine actually using say the
em
ore1000
driver. Or are you using thevmxnet3
driver in the virtual machine?Running a VM adds another layer of complexity to the problems.
-
Using E1000 and the em driver and no passthrough.
-
@Cool_Corona said in Bring pfsense/suricata to its knees and eventually die?? No reboot options/recovery available?:
Using E1000 and the em driver and no passthrough.
Then several of the NIC-specific changes you were making (or at least some of the ones you listed in your first post) are useless since they apply to
ix
andixl
cards. You need to research the sysctl turning parameters available for theem
ande1000
drivers and try tweaking those if you have not already.The netmap errors you are seeing in pfSense are coming from the virtual networking system and not your actual hardware NIC. However, be aware that there still could be problems with your hardware NIC and the ESXi driver, but those won't show up in the virtual machines. But netmap is NOT being used by ESXi.
All this is what I meant by my comment that virtualization adds another whole layer of potential issues to work through.
-
@bmeeks said in Bring pfsense/suricata to its knees and eventually die?? No reboot options/recovery available?:
@Cool_Corona said in Bring pfsense/suricata to its knees and eventually die?? No reboot options/recovery available?:
Using E1000 and the em driver and no passthrough.
Then several of the NIC-specific changes you were making (or at least some of the ones you listed in your first post) are useless since they apply to
ix
andixl
cards. You need to research the sysctl turning parameters available for theem
ande1000
drivers and try tweaking those if you have not already.The netmap errors you are seeing in pfSense are coming from the virtual networking system and not your actual hardware NIC. However, be aware that there still could be problems with your hardware NIC and the ESXi driver, but those won't show up in the virtual machines. But netmap is NOT being using by ESXi.
So you want me to configure passthrough on the host??
-
@Cool_Corona said in Bring pfsense/suricata to its knees and eventually die?? No reboot options/recovery available?:
So you want me to configure passthrough on the host??
That depends on your pain threshold. If you do, then you will need to reconfigure your pfSense setup because your interface names will change from
em
something to whatever the physical NIC you pass through needs. So all of your physical interface names change in pfSense, and that includes any defined VLANs since they have the physical interface in their names.I would first research
sysctl
tuning parameters for theem
ande1000
NICs and see if tweaking those helps. And as @DaddyGo said, those changes go inloader.conf.local
so they survive future updates. -
@bmeeks How to make the system aware of loader.conf.local??
AFAIK its using loader.conf and there is no such file in the folder?? Do I need to create and point loader.conf.local somewhere?
-
WinSCP or Putty, etc. (SSH) and just create it easily
+++edit:
I highly recommend it to you:
https://docs.netgate.com/pfsense/en/latest/hardware/tuning-and-troubleshooting-network-cards.html -
Don't be mad at me, but I can’t miss that comment (I'm a friendly guy anyway )
The installation of all major IT tools, systems and networks (etc.) begins with reading the user manual (hand book).
I am writing this, because this is the loader.conf.local theme, a basic question in FreeBSD and thus also in pfSense.https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/
https://docs.netgate.com/manuals/pfsense/en/latest/the-pfsense-book.pdf -
@Cool_Corona said in Bring pfsense/suricata to its knees and eventually die?? No reboot options/recovery available?:
@bmeeks How to make the system aware of loader.conf.local??
AFAIK its using loader.conf and there is no such file in the folder?? Do I need to create and point loader.conf.local somewhere?
I see @DaddyGo has already provided an answer, but I will add to it.
It is common practice on many Unix-type distros to use a *.local version of a configuration file. The OS will look for such a file, and if it sees it in the same place as the system version of that file (for example, in
/boot/
), then it will append the contents of the *.local file onto the content in the parent file (the one without ".local" on the end).The purpose of *.local files is to allow user customizations to be added that survive operating system upgrades. During an upgrade, the regular
loader.conf
file will get overwritten by a new version. But aloader.conf.local
file will not get overwritten. It is up to the user to create the *.local file when such a feature is needed.