Bug #812
closed
SonicWALL Adventail SSL VPN Issue in Suricata af-packet IPS Mode
Added by Leonard Jacobs over 11 years ago.
Updated over 9 years ago.
Description
When enabling Suricata in af-packet IPS, The SSL VPN communications comes to a halt. SonicWALL might be doing SOCKS over HTTPS for their SSL VPN communications.
MTUs are set to 1500 on af-packet peered Ethernet interfaces.
The SSL VPN works fine in IDS mode.
Files
- Priority changed from Urgent to Normal
Please add relevant info: version, error message, yaml, runmode, commandline, etc.
Suricata version 1.4.1
Error message:
SC_ERR_INVALID_ACTION(142)
Sending packet failed on Socket 8: Message too long
Unable to release packet data
Start Suricata with this commandline:
LD_PRELOAD=./usr/lib/libtcmalloc_minimal.so.0. suricata -c /etc/suricata/suricata.yaml --af-packet &
When Linux bridging is configured and enabled and af-packet IPS is enabled, the SonicWALL Adventail SSLVPN functions normally without latency or speed issues. However, the warning errors still appear on console.
Increasing the tcp flow timeouts in suricata.yaml do not seem to matter.
Hello, can you try to set "defrag: no" in af-packet interfaces configuration ? Kernel defragmentation could result in packet bigger than MTU being receive.
I also read that some network cards have features named Large Receive Offload (lro) and Generic Receieve Offload (gro)and with these features enabled, the network card performs packet reassembly before they’re processed by the kernel. Could this be making the packets too big when they hit af-packet? Should I disable lro and gro in the interfaces?
I think there are other settings in some interfaces that deal with packet fragmentation. Should I look to disable those too?
Yes, it will be better to disable them. At least, this will help to prove that the problem comes from too big received packets.
SonicWALL took a look at the pcaps we sent them and they say that the packets are taken too long to process in Suricata and af-packet so the SSLVPN timeout so maybe af-packet is struggle with these too big packets. We will try.
We solved this problem by disabling all packet offloading on network interfaces.
Eric, is there a sane way of supporting this?
- Target version set to TBD
- Status changed from New to Closed
- Target version deleted (
TBD)
Also available in: Atom
PDF