Project

General

Profile

Actions

Bug #812

closed

SonicWALL Adventail SSL VPN Issue in Suricata af-packet IPS Mode

Added by Leonard Jacobs almost 11 years ago. Updated about 9 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Target version:
-
Affected Versions:
Effort:
Difficulty:
Label:

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

suricata.yaml (35.3 KB) suricata.yaml Suricata.yaml Leonard Jacobs, 05/17/2013 02:32 PM
Actions #1

Updated by Victor Julien almost 11 years ago

  • Priority changed from Urgent to Normal

Please add relevant info: version, error message, yaml, runmode, commandline, etc.

Actions #2

Updated by Leonard Jacobs almost 11 years ago

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 &

Actions #3

Updated by Leonard Jacobs almost 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.

Actions #4

Updated by Eric Leblond almost 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.

Actions #5

Updated by Leonard Jacobs almost 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?

Actions #6

Updated by Eric Leblond almost 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.

Actions #7

Updated by Leonard Jacobs almost 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.

Actions #8

Updated by Leonard Jacobs almost 11 years ago

We solved this problem by disabling all packet offloading on network interfaces.

Actions #9

Updated by Victor Julien almost 11 years ago

Eric, is there a sane way of supporting this?

Actions #10

Updated by Victor Julien over 10 years ago

  • Target version set to TBD
Actions #11

Updated by Eric Leblond over 10 years ago

  • Status changed from New to Closed

#944 will fix this.

Actions #12

Updated by Victor Julien about 9 years ago

  • Target version deleted (TBD)
Actions

Also available in: Atom PDF