Suricata InLine with igb NICs

bmeeks

@stephenw10 said in Network Card Tuning:

Try it without any additional values in there first. The default settings should be good for most setups.

Try running Suricata in legacy mode to be sure it is that throwing the errors.

Steve

Steve:
So far as I know, Suricata is the only pfSense package that will utilize a Netmap pipe. And Suricata only does that when using Inline IPS Mode operation. So returning Suricata to Legacy Mode will shutdown all Netmap pipes in the kernel, so the error would be expected to disappear.

Suricata initiates the Netmap pipe (it actually uses two for bi-directional traffic) by making FreeBSD system calls. The calls are to standardized Netmap API functions.

stephenw10

Yes, it is as far as I'm aware also. I expect the errors to resolve in legacy mode there, however if it doesn't that would be an interesting result.
I'm not sure there is anything else to be done until this is fixed upstream.

Steve

bmeeks

@stephenw10 said in Network Card Tuning:

Yes, it is as far as I'm aware also. I expect the errors to resolve in legacy mode there, however if it doesn't that would be an interesting result.
I'm not sure there is anything else to be done until this is fixed upstream.

Steve

I wish I was a better kernel code programmer so I could dive in and look at this, but there is a bit of magic stuff happening way down at that level of the network stack that I lack experience with.

newUser2pfSense

stephenw10 and bmeeks...thank you both for responding. This has been ongoing for a while now in Inline IPS Mode. It doesn't happen in Legacy Mode. I've commented all of the lines out in the loader.conf.local file. I've noticed that the first release candidate of FreeBSD 12.0 has been released. I wonder how long it will take for the developers to fix the bug report?

stephenw10

If you really want to get pro-active you could try enabling suricata in inline mode on FreeBSD 12.
I've never tried Suricata in FreeBSD directly. I know that the pfSense package has some patches also. Might not be that easy.
It might not be necessary though since what you're actually testing is netmap with igb. Something else that uses netmap would probably also trigger it. Might have to make sure it does in 11.2 first.

Steve

bmeeks

Yes, as @stephenw10 suggested, you can certainly run the base Suricata package on FreeBSD 12 using Netmap. Just install the pkg from the CLI. Of course you won't have benefit of the pfSense package's GUI to configure things, but you could copy the basic suricata.yaml file from your pfSense box to the new hardware. You might have to adjust for interface names, and you would certainly have to manage the setup using the text-based tools within a CLI session. You can find the shell startup commands for the pfSense installation in this shell script: /usr/local/etc/rc.d/suricata.sh

To use Inline IPS Mode you won't need any of the pfSense-specific Suricata patches. Those only add the custom Legacy Mode blocking functionality. Inline IPS Mode works with no patches. So just load up the package straight from FreeBSD ports or even compile it yourself using the local ports tree you can install with FreeBSD.

The culprit in this bug is Netmap within the FreeBSD kernel and perhaps in combination with issues in specific NIC drivers was well. Unless the FreeBSD 12 source tree shows some commits related to Netmap, I would not get my hopes up, though. There seems to be not a whole lot of interest in addressing the Netmap issues. Maybe the user base is not large enough to warrant the developer time required to track down the issues.

newUser2pfSense

stephenw10 and bmeeks...without an extra computer to test this on, I guess I'll have to wait until the developers take an interest in researching the issue and providing a fix. bmeeks - has anyone from pfSense/Netgate entered a bug report with FreeBSD by chance? Maybe another bug report might get the ball rolling specifically from a company instead of an individual. A company might be able to persuade the FreeBSD developers to take a more proactive approach. I don't know, just a thought.

bmeeks

@newuser2pfsense said in Network Card Tuning:

stephenw10 and bmeeks...without an extra computer to test this on, I guess I'll have to wait until the developers take an interest in researching the issue and providing a fix. bmeeks - has anyone from pfSense/Netgate entered a bug report with FreeBSD by chance? Maybe another bug report might get the ball rolling specifically from a company instead of an individual. A company might be able to persuade the FreeBSD developers to take a more proactive approach. I don't know, just a thought.

I am not affiliated with Netgate, so I wouldn't know about any possible bug report about Netmap submitted by them.

stephenw10

I have not seen anything.
Generally speaking submitting additional bug reports for which a report is already open is, at best, frowned upon! Better to add to existing bug reports. Even better to add to them with actual useful data.
FreeBSD devs will rightly want to see any issues replicated in FreeBSD directly. And they will want to see that done in a current version. I would suggest that is 12 right now though maybe 11-stable might be acceptable.

Demonstrating the bug exists in current FreeBSD and giving detailed steps to replicate that is the best way to attract developer attention.

Steve

newUser2pfSense

stephenw10 and bmeeks...I appreciate all of your help. Unfortunately, I only have one computer like my pfSense instance, and of course it's being used for pfSense, so I wouldn't be able to replicate the issue to provide more information to the developers. I guess I had hoped that others who might see this post would have additional input to the FreeBSD bug report. Thanks.

stephenw10

You can only do what you can do. There may well be others who can do more. Inline Suricata with igb is not that uncommon.

Steve

boobletins

I'm in a position to test this (and I've also been having issues with igb and em drivers + netmap).

I'm using a Jetway with I219-LM and I211-AT chips and it looks like the Supermicro is i350.

Would testing this with the lower level chips be useful, or do we expect that the i350s would work where the i2XX wouldn't?

If it would be useful, I can certainly put FreeBSD 12 and Suricata on a machine with i2XX...

newUser2pfSense

Hi boobletins...thank you for the response. That's very kind of you to offer to test this. I would only know the i350 as that's the card that I'm using. I wish I could offer more. My apologies.

boobletins

@newuser2pfsense

Can you ssh and give me the result of ifconfig on the interface in question?

I just discovered after lots of annoyance that IPv6 Transmit Checksums were not disabled via the GUI when they appeared to be. Manually configuring it off solved this issue for me (at least I can now complete speedtests over the last hour or so with Suricata in IPS mode).

You might want to double check that

TXCSUM_IPV6

does not appear in your

ifconfig igb0

output (or the interface in question).

If it does, you might try:

ifconfig igb0 -rxcsum -rxcsum6 -txcsum -txcsum6 -lro -tso -vlanhwtso

then put Suricata back into IPS mode, restart Suricata, but don't reboot pfSense. See if your connection is stable. If you reboot pfSense, txcsum6 may reappear. I don't know where to permanently disable it.

bmeeks

@boobletins said in Suricata InLine with igb NICs:

@newuser2pfsense

Can you ssh and give me the result of ifconfig on the interface in question?

I just discovered after lots of annoyance that IPv6 Transmit Checksums were not disabled via the GUI when they appeared to be. Manually configuring it off solved this issue for me (at least I can now complete speedtests over the last hour or so with Suricata in IPS mode).

You might want to double check that
TXCSUM_IPV6
does not appear in your
ifconfig igb0
output (or the interface in question).

If it does, you might try:
ifconfig igb0 -rxcsum -rxcsum6 -txcsum -txcsum6 -lro -tso -vlanhwtso
then put Suricata back into IPS mode, restart Suricata, but don't reboot pfSense. See if your connection is stable. If you reboot pfSense, txcsum6 may reappear. I don't know where to permanently disable it.

This issue is affecting more than just IPS mode in Suricata. It is impacting IPv6 connectivity for some folks on their WAN. I know there is a pfSense Redmine issue about it. The problem is within FreeBSD itself, I think. It's not a bug within Suricata itself. Suricata is a victim in this case. I think I've seen some posts about this in the IPv6 sub-forum here. I know I've seen a Redmine bug on it, too. I just had not connected directly to the IPS-Netmap problem. Good detective work!

newUser2pfSense

boobletins...Yes, TXCSUM_IPV6 is in the output of the ifconfig on my WAN interface; it's actually on all 4 interfaces on my SuperMicro ethernet adapter. If we knew where to disable it, I'm wondering if we could put that information in the loader.conf.local file? Then if we restart pfSense, I'm wondering if it would be disabled then? I don't know, just a thought.

bmeeks...I don't have IPv6 enabled anywhere on my pfSense instance, at least I don't believe.

stephenw10

@boobletins said in Suricata InLine with igb NICs:

Manually configuring it off solved this issue for me

It solved the netmap errors? Did you see any other errors that lead you to try this?

Are you actually using IPv6?

Steve

newUser2pfSense

For me, I have IPv6 blocked on my WAN as a rule in the Firewall > Rules; it's practically at the top. However, I noticed a mix of IPv4 and IPv6 addresses in my System Logs > Firewall > Normal View tab. As well, I currently have Suricata running in Legacy Mode and have a ton of IPv6 addresses of SURICATA zero length padN option in the Alerts tab and all IPv6 addresses in the Blocks tab. Maybe I'm completely wrong but if I have IPv6 blocked on the WAN, should IPv6 addresses be showing up at all in the logs?

bmeeks

@newuser2pfsense said in Suricata InLine with igb NICs:

For me, I have IPv6 blocked on my WAN as a rule in the Firewall > Rules; it's practically at the top. However, I noticed a mix of IPv4 and IPv6 addresses in my System Logs > Firewall > Normal View tab. As well, I currently have Suricata running in Legacy Mode and have a ton of IPv6 addresses of SURICATA zero length padN option in the Alerts tab and all IPv6 addresses in the Blocks tab. Maybe I'm completely wrong but if I have IPv6 blocked on the WAN, should IPv6 addresses be showing up at all in the logs?

You will likely have IPv6 Link-Local addresses created on your interfaces by default. I have them on all of my local firewall interfaces, including my WAN even though my ISP does not provide any type of IPv6 connectivity.

A typical Windows domain will spew a lot of IPv6 stuff by default. In fact, IPv6 is a preferred communications route for Windows domain traffic unless it is explicitly disabled. Most of that will be via link-local addresses.

boobletins

@stephenw10

I suppose "solved" is a strong word. What I should have said is that before I couldn't complete a single speedtest and now I can complete an arbitrary number without netmap errors. Suricata also lasted through the night in IPS mode on my LAN interface (igb) without crashing which is extremely rare. I won't know if it's truly solved until it lasts through more like a week or month.

I can reliably crash the interface by enabling TXCSUM_IPV6 and running a speedtest.

I'm not a pfSense expert -- so when you ask if I'm using IPv6, all I know to say is that I have "Allow IPv6" enabled in the UI, and I see a smattering of IPv6 IPs in both Suricata Alerts and states (the majority are IPv4).

Here is what I settled on for my boot.conf.local after referring these links:
https://calomel.org/freebsd_network_tuning.html
https://suricata.readthedocs.io/en/suricata-4.0.5/performance/packet-capture.html#rss

kern.ipc.nmbclusters="1048576"
hw.pci.enable_msix=1

hw.em.msix=1
hw.em.smart_pwr_down=0
hw.em.num_queues=1   # https://suricata.readthedocs.io/en/suricata-4.0.5/performance/packet-capture.html#rss

# below this line is all from: https://calomel.org/freebsd_network_tuning.html
if_igb_load="YES"
hw.igb.enable_msix="1"
hw.igb.enable_aim="1"
hw.igb.rx_process_limit="100" #default
hw.igb.num_queues="3"  # (default 0 , queues equal the number of CPU real cores if queues available on card)
hw.igb.max_interrupt_rate="16000" #double default
coretemp_load="YES"
hw.intr_storm_threshold="9000" #default

if_em_load="YES"
hw.em.enable_msix="1"
hw.em.msix=1

autoboot_delay="-1"
net.isr.maxthreads="-1"
net.isr.bindthreads="1"  # (default 0, runs randomly on any one cpu core)

#Larger buffers and TCP Large Window Extensions
net.inet.tcp.rfc1323=1
net.inet.tcp.recvbuf_inc=65536     # (default 16384)
net.inet.tcp.sendbuf_inc=65536     # (default 8192)
net.inet.tcp.sendspace=65536       # (default 32768)
net.inet.tcp.mssdflt=1460   # Option 1 (default 536)
net.tcp.minmss=536  # (default 216)

#syn protection
net.inet.tcp.syncache.rexmtlimit=0  # (default 3)