SC_ERR_LIBNET_WRITE_FAILED
-
I am trying out suricata in inline IPS mode for the first time. I set one rule's action to reject, and I'm seeing lots of these messages in the suricata log:
5/10/2021 -- 15:45:04 - <Error> -- [ERRCODE: SC_ERR_LIBNET_WRITE_FAILED(147)] - libnet_write_raw_ipv4 failed: libnet_write_raw_ipv4(): -1 bytes written (Invalid argument)It appears that some packets get blocked, but others do not.
This was mentioned in another post: https://forum.netgate.com/topic/152390/suricata-wont-start-after-updating-pfsense-to-2-4-5-release
but I thought it best to have its own topic.I am not operating in bridge mode. This is with suricata 6.0.3_3.
Thanks.
-
Note that the errors do not appear to coincide with the alert that I have set to reject, so I'm not sure what is triggering it.
-
Well, looking at the suricata code it's pretty clear that the error can only come from when suricata attempts to send an ICMP reject message. My thought at this point is that it's because I'm running on one of the internal interfaces instead of the WAN interface.
-
Nope - fired up a suricata instance on the WAN interface an got the same error. Now it is pretty clearly linked to the reject of the offending alert.
-
What type of hardware are you running on? Is it an Intel x86_64 CPU or one of the Netgate ARM appliances?
I will take a look at this, but the section of code in the Suricata binary where this error message can originate is totally "stock" on pfSense -- meaning it is unmodified from upstream. This is most likely to be a problem that needs reporting and addressing upstream on the Suricata Redmine site.
-
@bmeeks This is a Netgate SG-4860 Intel(R) Atom(TM) CPU C2558
-
@bmeeks I have filed https://redmine.openinfosecfoundation.org/issues/4740
-
@opoplawski said in SC_ERR_LIBNET_WRITE_FAILED:
@bmeeks I have filed https://redmine.openinfosecfoundation.org/issues/4740
One possibility here is you have an older version of the libdnet library. I am about to see if I can reproduce this on my test virtual machine.
-
libnet-1.1.6_5,1 Name : libnet Version : 1.1.6_5,1 Installed on : Thu Sep 23 07:34:33 2021 MDT -
I can reproduce the error. Reporting this upstream to the Suricata team is the correct action. I have not checked your ticket that you linked, but if you have not already, it would be helpful to post in the ticket text the libnet version info you posted here.
I will continue investigating this issue myself in case I come across something that I can fix on the pfSense side of things.
-
Strangely, I cannot reproduce this error on a plain-vanilla FreeBSD 12.2-STABLE virtual machine with the exact same Suricata binary as that used on pfSense including the current patches.
So that would seem to indicate this issue is limited to perhaps just pfSense, but I have no clue at the moment what the root problem might be. I don't think it is the Suricata package itself as the same binary code tests successfully on the plain-vanilla FreeBSD 12.2-STABLE VM.
I will continue looking, but at this point I'm not as convinced as I was previously that this is an upstream problem.
-
Found what appears to be a solution for this issue. Not 100% sure why it happens, though. What little bit I found on Google suggests is may just be a peculiarity with FreeBSD and exactly how sockets are addressed.
The problem resolved in my test virtual machine when I changed the IPv6 gateway from "Automatic" to "None". I have IPv6 disabled on the WAN interface of the VM I was testing with.
You can try checking the setting on your firewall to see if changing it helps you. The setting is under SYSTEM > ROUTING from the pfSense menu. Here is a screenshot:
The default value for the IPVv6 gateway was initially set for "Automatic", and that resulted in the SC_ERR_LIBNET_WRITE_FAILED error. Changing the value to "None" in the drop-down selector eliminated the error for me. As I said, on this firewall the IPv6 address for the WAN is configured for "None".
