Bring pfsense/suricata to its knees and eventually die?? No reboot options/recovery available?

DaddyGo

@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

bmeeks

@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 or e1000 driver. Or are you using the vmxnet3 driver in the virtual machine?

Running a VM adds another layer of complexity to the problems.

Cool_Corona

@bmeeks

Using E1000 and the em driver and no passthrough.

bmeeks

@Cool_Corona said in Bring pfsense/suricata to its knees and eventually die?? No reboot options/recovery available?:

@bmeeks

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 and ixl cards. You need to research the sysctl turning parameters available for the em and e1000 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.

Cool_Corona

@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?:

@bmeeks

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 and ixl cards. You need to research the sysctl turning parameters available for the em and e1000 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??

bmeeks

@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 the em and e1000 NICs and see if tweaking those helps. And as @DaddyGo said, those changes go in loader.conf.local so they survive future updates.

Cool_Corona

@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?

DaddyGo

@Cool_Corona

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

DaddyGo

@Cool_Corona

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

bmeeks

@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 a loader.conf.local file will not get overwritten. It is up to the user to create the *.local file when such a feature is needed.