[Oisf-devel] PF_RING, VLAN, and flow tracking

Chris Wakelin c.d.wakelin at reading.ac.uk
Fri May 17 12:36:43 UTC 2013


On 17/05/13 08:01, Victor Julien wrote:
> On 05/05/2013 03:23 AM, Tritium Cat wrote:
>> Hi.
>>
>> I'm having trouble running Suricata and I think it might be due to VLAN
>> tagging.
>>
>> The environment has a different VLAN for each direction of traffic so
>> the standard PF_RING clustering mode is not suitable.
>>
>> I patched runmode-pfring.c and source-pfring.h to allow a different
>> cluster_type of "cluster_flow_5_tuple"; this setting uses PF_RINGs
>> "cluster_per_flow_5_tuple" defined in kernel/linux/pf_ring.h.  Those
>> patches are attached to this email.
>>
>> Before this change I saw many many errors about invalid PPP packets and
>> other similar bad things; afterwards I see lots of errors about invalid
>> ACK and wrong direction.  Now I'm thinking maybe there is something
>> wrong with the flow tracking and VLAN tags.  I read this mailing list
>> discussion [1] about VLAN tags and flow tracking but I'm not sure at the
>> moment how that applies to suricata-1.4.1... I think I may need to apply
>> the patch which appears to force all flows into VLAN 0 ?
>>
>> Maybe my configuration is at fault, I've attached it to this email as well.
>>
>> tl;dr -- Ultimately I want to ignore the VLANs.  [1] mentioned something
>> about a global switch to disable VLAN consideration.. how does the
>> current suricata-1.4.1 code handle them ?  Should I apply the patch ?
> 
> In 1.4.1 Suricata decodes the vlan layer but doesn't do anything with
> the vlan id. So it pretty much ignores vlans. This can cause issues as
> it won't be able to distinguish flows with identical 5tuples. This may
> also explain the alerts you get...
> 

It may be a problem with PF_RING - I've patched mine (as suggested ages
ago by Will Metcalf) to take vlan_id out of the hash calculation
(PF_RING 5.5.2, but it's the same in other versions):-

--- pf_ring.c.orig      2013-01-10 11:15:51.000000000 +0000
+++ pf_ring.c   2013-02-14 10:54:12.642113536 +0000
@@ -1791,7 +1791,7 @@
     printk("[PF_RING] hash_pkt(vlan_id=%u, proto=%u, port_peer_a=%u,
port_peer_b=%u)\n",
           vlan_id,proto, port_peer_a, port_peer_b);

-  return(vlan_id+proto+
+  return(proto+
         host_peer_a.v6.s6_addr32[0]+host_peer_a.v6.s6_addr32[1]+
         host_peer_a.v6.s6_addr32[2]+host_peer_a.v6.s6_addr32[3]+
         host_peer_b.v6.s6_addr32[0]+host_peer_b.v6.s6_addr32[1]+

(our switch sets a VLAN tag on only one direction of the port-mirrored
traffic).

Best Wishes,
Chris

-- 
--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+-
Christopher Wakelin,                           c.d.wakelin at reading.ac.uk
IT Services Centre, The University of Reading,  Tel: +44 (0)118 378 2908
Whiteknights, Reading, RG6 6AF, UK              Fax: +44 (0)118 975 3094



More information about the Oisf-devel mailing list