[Oisf-users] using af-packet for capturing traffic from multiple interfaces

[Risto Vaarandi]

> On Tue, Nov 7, 2017 at 8:30 PM, Risto Vaarandi <Risto.Vaarandi at seb.ee>
> wrote:
> > Hi all,
> >
> > I need to run Suricata for capturing traffic from two interfaces with
> > af-packet. Configuring af-packet would be straightforward, but there
> > is one issue – for any TCP connection, some packets might appear on
> > one interface, while rest of the packets are available on the other
> > interface. I can see two issues here. First, it is not possible to
> > configure the same value for the ’cluster-id’ parameter for two
> > different interfaces, and the packets for the same connection are not
> received by the same thread in ’workers’
> > runmode. Second, I suspect that the order of getting the packets from
> > two distinct interfaces is not determined, and for Suricata they might
> > appear in a different order than originally in the network.
> 
> Yes that is correct - if some part of  a TCP session is on one interface and the
> other part of that same session  on a different interface - it will end up in
> different worker threads and probably out of order too.
> 
> >
> > Nevertheless, are there some recommended ways for configuring
> > af-packet for such two-interface scenario? For instance, can
> > ’async-oneside’ option be used here for improving the detection
> > capability? I would be grateful for all recommendations.
> 
> One of the important task would be (even if you bridge the interfaces if
> possible) to prevent packet reordering - since Suri (in order to see and
> inspect the traffic as the "end point" would) needs to get both sides of a flow
> in the same thread, in the correct order.
> Last time I tested async-oneside (though it was in IPS mode) it behaved as
> expected - though your case might be different you can give it a try.
> 
> 

I have an additional question about async-oneside option. How does it work if packets are actually available for both directions? From a quick experiment I have conducted, I've got an impression that in this case packets from two directions are not handled separately, but they are merged into one connection like in normal mode. Is my understanding correct and async-oneside option is making difference only when packets for one direction are missing? Also, are there any more detailed documentation on internals of async-oneside?

Kind regards,
risto

> 
> --
> Regards,
> Peter Manev