Bug #812
closedSonicWALL Adventail SSL VPN Issue in Suricata af-packet IPS Mode
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
Updated by Victor Julien over 11 years ago
- Priority changed from Urgent to Normal
Please add relevant info: version, error message, yaml, runmode, commandline, etc.
Updated by Leonard Jacobs over 11 years ago
- File suricata.yaml suricata.yaml added
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 &
Updated by Leonard Jacobs over 11 years ago
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.
Updated by Eric Leblond over 11 years ago
Hello, can you try to set "defrag: no" in af-packet interfaces configuration ? Kernel defragmentation could result in packet bigger than MTU being receive.
Updated by Leonard Jacobs over 11 years ago
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?
Updated by Eric Leblond over 11 years ago
Yes, it will be better to disable them. At least, this will help to prove that the problem comes from too big received packets.
Updated by Leonard Jacobs over 11 years ago
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.
Updated by Leonard Jacobs over 11 years ago
We solved this problem by disabling all packet offloading on network interfaces.
Updated by Victor Julien over 11 years ago
Eric, is there a sane way of supporting this?